You might know me as a stout supporter of CMake transition, but a single experience shattered my certainity. Today i tried to resolve a backtrace for a bug report, done with a cmake iso. The results were horrendous. The backtrace was lenghty, but on rbuild such task would take around 15 mintues for me, having all files extracted and prepped log.. At the present moment, cmake bt resolving is a total mess and practically prevents anyone doing such log. I might not be a programmer, but was somewhat skilled in my testers duties, also as some recall, i loved doing manual traces by raddr2line. With cmake - i hate it:
1. the whole process takes minutes more per frame: you need the base address, add the offset and type in the addr2line command
2. base address from kdbg: mod is not reliable, as modules might be relocated. addr2line doesn't know about that...
3. C++ function names are not demangled. For those modules that are written in c++ you will only get source lines, unless you check them up manually.
4. Being somewhat experienced, i see no way how i`m to explain newcomer how to do a backtrace... on the other hand, do you expect anyone to waste half an hour doing so?
This HAS to be resolved before rbuild is put to retirement. Amine was talking about getting back to rsym - sure, why not? Anything that works will be better than current situation.
--
With best regards
Caemyr
cgutman(a)svn.reactos.org wrote:
> - Implement support for scatter/gather DMA
This commit deserves a huge LIKE button, thanks!
Will try it out as soon as I have access to my ReactOS laptop again.
Finally a chance for getting its Ethernet port to work :-)
- Colin
Hi!!
This is wrong, 8^(
+ class.style |= CS_GLOBALCLASS;
+ class.hInstance = COMCTL32_hModule;
The point in THEMING_Initialize was to get the current global classes
and make locals for each process. So that process could have it. Not
the whole system!
Note from a msdn blog, "If you pass the CS_GLOBALCLASS flag when
registering the class, then the window manager will ignore the
instance handle when looking for your class. All of the USER32 classes
are registered as global."
I spent a week now looking through it all, ReactOS is handling the
class registration correctly. My best guess, if themes is active do as
the original code had it before and use IsThemeActive like it is
setup. Keep class.hInstance = COMCTL32_hModule; and don't use
CS_GLOBALCLAS so you can find it again.
Thanks,
James
Hi,
today, after looking at the daily source analysis we have, I found out
that all that stuff could be improved by lightening trunk. We have huge
amount of unused code (even not linked in CMake) rotting in trunk.
I'm mainly talking about icu4ros. AFAIK it was an attempt from KJK for I
even don't recall what.
Here is my proposal: we do a branch for this. And then, we remove it
from trunk. This will make things lighter, without loosing code.
Any objections/comments?
Regards,
Pierre
With this attempt Thomas proved that it is possible to use patchbot for both trunk and rostests patching. Ask him how he did it:>
On Wednesday, October 05, 2011 9:05 AM, ReactOS.Bugzilla(a)reactos.org wrote:
> --- Comment #1 from ThFabba <thfabba(a)gmx.de> 2011-10-05 09:05:44 CET ---
> Created an attachment (id=6782)
> --> (http://www.reactos.org/bugzilla/attachment.cgi?id=6782)
> patch 2
>
> Maybe this works :p
>
--
With best regards
Caemyr
Hi,
I've been looking at VirtualBox 4.1.x guest additions, which don't install
in ROS [1] and came up with a patch [2] that seems to fix them.
While patchbot says this is okay [3] (and the last hunk even fixes a few
setupapi tests), I am very unsure about the SP_COPY_NOOVERWRITE part.
The correct solution might instead be to handle SetupCopyOEMInf returning
ERROR_FILE_EXISTS or I might be "fixing" something in the completely
wrong place.
It would be great if someone with some insight into setupapi
(Eric? Hervé? ;]) could review this and give some pointers.
Thanks!
-Thomas
[1] http://www.reactos.org/bugzilla/show_bug.cgi?id=6522
[2] http://www.reactos.org/bugzilla/attachment.cgi?id=6753
[3] http://www.reactos.org/testman/compare.php?ids=8272,8294,8303,8305
Patch explanation:
- The first hunk isn't really required, but I guess it shouldn't break
anything, and seems to find what it's looking for this way.
- The second hunk is in the code path used by VBox guest additions setup.
It is apparently called with an already-existing inf file, but I have
no idea why. :|
- The third hunk is a trivial bug that our CreateService just didn't
complain about before r53872/r53886
Though the August minutes were already posted on the forum, they are being
resent here for people who may have missed them.
August Summary
A proposal was made to do winesyncs before a release to force the project to
do a better job keeping things in sync and perhaps do a better job making
syncs feasible/less time consuming. Rejected by plurality of votes.
Questions about how/whether to continue the driver signing program was
raised. An advisory vote was held and the majority wished to continue it in
one form or another. Feedback based on the advisory vote was incorporated
into revised guidelines posted on the Driver Signing wiki page. New projects
are now required to find a sponsor ReactOS "core developer" willing to audit
their code if they wish to get their driver signed.
Decision to integrate arwinss into trunk under a separate directory
structure and make it a compile-time option. Passed by majority vote.
Decision to switch main Linux build server to use cmake. Passed by majority
vote.
September Summary
Agenda
1. CMake Adoption Status
2. Release Preparation, Determination of Release Date
3. Webportal Upgrade Status
4. ReactOS Target Version
Report
1. The build environments for both Windows and Unix have gone through
several release candidates and are effectively finalized. For the Windows
BE an installer release client using MSI instead of NSIS also needs to be
prepared. Minor problems still seem to exist on Mac OS X when using a
combination of GCC and LLVM, but these were deemed non-blockers. Building
ReactOS using CMake has been reported to take more time than using rbuild,
though developers are still working to verify and determine the cause.
Current theory is related to changed debug format and more thorough
dependency checking by CMake. At present the plan is to put the build
environment release candidates on the Linux build servers and determine if
there are any problems. The Windows build servers have already been running
the new build environments for testing purposes.
2. Due to the significant number of regressions and overall bugginess of
ReactOS' current state, release scheduling has been deferred until the next
meeting. A list of regressions and bugs has already been compiled and the
team intends to work its way through the reported issues in the meantime.
At the next meeting, the OS' state will be re-assessed to see whether a
release is viable or not.
3. Most of the modules needed to bridge Drupal with things like Bugzilla
have already been completed. To speed the transition, a decision was made
to retain the current website design. Once the transition is complete, the
web team can go back to updating the site's theme. Desired content changes
will also not block transition to the new backend. No timetable was given
for when the transition would happen.
4. For a while the project adopted the goal of targeting the Windows 2003
kernel and the latest version of Windows for user mode components. Several
developers however raised objections to this and presented examples where
this methodology does not work. A specific example involved symbolic link
support, which required Microsoft rearchitecture not only NTFS but also the
kernel's security systems. Its addition in ReactOS, assuming it is done
correctly, would require changes to the kernel to adopt features from the
Vista kernel, thus violating the kernel target. With these considerations,
the project has decided to set both the user and kernel targets to Windows
2003. Dependency on Wine for many user mode libraries actually complicates
this, as Wine has been adding Vista and later APIs without proper
segregation and the developers will need to figure out how to deal with this
in the long run.
Am 02.10.2011 22:59, schrieb akhaldi(a)svn.reactos.org:
> Author: akhaldi
> Date: Sun Oct 2 20:59:15 2011
> New Revision: 53941
>
> URL: http://svn.reactos.org/svn/reactos?rev=53941&view=rev
> Log:
> [RBUILD]
> * Plug a leak.
Bugfix of the month! ;-)
Hi,
at present I work for mid-sized company for ticketing, parking and mobile
solutions in Germany (and Great Britain). I personally work in a project for
railway services (using gsm-r network). To understand the tools given below I
want to figure out our target and environment in short. We develop for
embedded Linux systems with ARM-CPU and Qt-Framework. Therefore C++ was and
is used as programming language.
Apart from he usual tools like
- make-alike build tools (written in perl - a project specific one)
- regular make files for some special targets
- SVN for source code management
we use some interesting tools to keep the source readable and to preserve a
minimum of source quality automatically (bear in mind we use C++ instead of
C, for our purpose we need to alter some tools for our needs):
- Hudson for automatic build and checking the source (see below)
- cpplint.py (by Google) for some checking the source
- cppcheck for another check of the source
- doxygen for checking the missing documentation (in that special case check
only by tricky configuration instead of costly generating all documentation
files)
- format the source code (after agreement of all devs) in a uniform style with
astyle before commit (for ReactOS better as commit hook)
- finally we gather all check results in one table and mark the results for
hudson as stable (if no errors), failed (in case of any errors), unstable (in
case of some low-prio warnings)
Maybe we can think about some of them, because even if some problems of
development remains, it might give us some edge and may also attract some
devs. I don't make any suggestions, but I want to tell you how others work.
Matthias
PS: We are the first project in the company going that way and other project
groups would like to adapt the way, because they see the benefit for
their/other/future projects.
--
Matthias Kupfer phone +49 371 236 46 52
Wilhelm-Firl-Straße 21 mobile +49 160 859 43 54
09122 Chemnitz, Germany
Hi,
due to a HDD failure in one of our major servers, you've been
encountering services interruptions (mail, svn, web, mainly) this
afternoon and tonight. The issue has been successfully addressed right
now, and the server is back online with its new hard-drive.
Regards,
The ReactOS sysadmins.
Hi,
this is a reminder about the Status meeting, which is to happen
tomorrow, 29th of September at 19:00 UTC. Please don't miss it. The
meeting is declared private. I will lead the meeting, as usual.
Proposed agenda for the meeting:
1. CMake adoption progress.
2. Release preparation status report, deciding on the release date.
3. Webportal upgrade plans.
4. ReactOS target version: strict sticking to it or hybrid.
List of participants:
- Giannis Adamopoulos (smiley1_)
- Johannes Anderwald (janderwald)
- Javier Agustìn Fernàndez Arroyo (elhoir)
- Maciej Bialas (niski)
- Jan Blomqvist-Kinander (JaixBly)
- Aleksey Bragin (abragin)
- Thomas Faber (ThFabba)
- Colin Finck (Colin_Finck)
- Jérôme Gardou (zefklop)
- Danny Götte (dangerground)
- Cameron Gutman (aicom)
- Ziliang Guo (ZWabbit)
- Rafal Harabien (rafalh)
- Andrew Hill (ash77)
- Kamil Hornicek (Pigglesworth)
- Gabriel Ilardi (gabriel_it)
- Alex Ionescu (Alex_Ionescu)
- Amine Khaldi (AmineKhaldi)
- Igor Koshpaev (tower)
- Timo Kreuzer (tkreuzer)
- Matthias Kupfer (Collibri)
- Michael Martin (mjmartin)
- Victor Martinez (vicmarcal)
- Roel Messiant (Mephisto)
- Claudiu Mihail (KlausM)
- Andrew Munger (WaxDragon)
- Ged Murphy (GedMurphy)
- Igor Paliychuk (igorko)
- Sylvain Petreolle (Usurp)
- Hervé Poussineau (hpoussin)
- Daniel Reimer (dreimer)
- Pierre Schweitzer (HeisSpiter)
- Samuel Serapion (encoded)
- Olaf Siejka (Caemyr)
- James Tabor (jimtabor)
- Christoph von Wittich (Christoph_vW)
- Art Yerkes (arty)
WBR,
Aleksey Bragin.
FYI:
This is Linus' interview. http://h30565.www3.hp.com/t5/Feature-
Articles/Linus-Torvalds-s-Lessons-on-Software-Development-Management/
ba-p/440
He very correctly outlines many things. One of the most important:
"The other thing—and it's kind of related—that people seem to get
wrong is to think that the code they write is what matters. No, even
if you wrote 100% of the code, and even if you are the best
programmer in the world and will never need any help with the project
at all, the thing that really matters is the users of the code. The
code itself is unimportant; the project is only as useful as people
actually find it.”
And this:
"Way too many projects seem to think that the code is more important
than the user, and they break things left and right, and they don't
apologize for it, because they feel that they are ‘fixing’ the code
and doing the right thing.”
WBR,
Aleksey Bragin.
Hi all,
Just for your information, I have enabled ACPI for the KVM machine used
by the Linux Testslave today.
For reference, the full VM configuration is like this:
* QEMU/KVM-based i686 ACPI machine
* 256MB of RAM
* 512MB HDD on IDE Primary Master
* ReactOS ISO on IDE Secondary Master
* AMD PCNet-compatible Network Adapter
* COM1 port redirected to a virtual Linux terminal device
* PS/2 mouse
* Tablet pointing device on USB
Usually useful if any KVM machine is controlled over VNC, but probably
not relevant for ReactOS yet.
As you see, there is no virtual sound card (disabled as of 2011-06-07
due to r52098 according to my notes). Is this still correct?
- Colin
Wont be that usual. Happened twice today, still broken atm. I`m not a dev, hence i have no idea how the devs commit stuff works and all the problems you guys have to overcome...
I suppose it is too difficult for you simply to visit http://build.reactos.org/waterfall and just check if its all green (yes, no need to check stdio, just noticing the color). Your time is probably too precious to wait up to 5 bloody minutes, to see if previous build was ok...
I`m not even talking about runtime regressions. Its understandable, that 45 minutes is often too much to wait, but 5??
I`m not even talking about patchbot, why should I? Already did, already tried, to no effect.
If you really care about ROS, then by commiting on a broken trunk, you are practically shooting yourself in your foot. Trunk will be most likely not fixed until several other commits, sometimes a day or so. ISO will not be build. Commits will not be tested, neither by automation, nor by community, bugs will not be reported and regressions will only be found in more distant future. Then, you will ask for regtesting.
You should better start doing it yourself, because you guys too often are not doing even the simplest things to keep trunk clean and working, making development harder for everyone around!
--
With best regards
Caemyr
Hi,
Are there any bugs:
/reactos/dll/directx/ksproxy/allocator.cpp: In member function 'void
CKsAllocator::FreeMediaSamples()':
/reactos/dll/directx/ksproxy/allocator.cpp:586:16: warning: deleting
object of abstract class type 'IMediaSample' which has non-virtual
destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]
/reactos/dll/directx/ksproxy/proxy.cpp: In function 'HRESULT
CKsProxy_Constructor(IUnknown*, const IID&, void**)':
/reactos/dll/directx/ksproxy/proxy.cpp:3188:16: warning: deleting
object of polymorphic class type 'CKsProxy' which has non-virtual
destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor]
In file included from /reactos/dll/win32/browseui/precomp.h:8:0,
from /reactos/dll/win32/browseui/browseui.cpp:21:
/reactos/lib/atl/atlcom.h: In instantiation of 'static HRESULT
ATL::CComCreator<T1>::CreateInstance(void*, const IID&, void**) [with
T1 = ATL::CComObjectCached<ATL::CComClassFactory>, HRESULT = int, IID
= _GUID, LPVOID = void*]':
/reactos/dll/win32/browseui/browseui.cpp:32:1: required from here
/reactos/lib/atl/atlcom.h:253:5: warning: deleting object of
polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/reactos/lib/atl/atlcom.h: In instantiation of 'ULONG
ATL::CComObjectCached<Base>::Release() [with Base =
ATL::CComClassFactory, ULONG = unsigned int]':
/reactos/dll/win32/browseui/browseui.cpp:121:1: required from here
/reactos/lib/atl/atlcom.h:304:4: warning: deleting object of
polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
In file included from /reactos/dll/win32/shell32/precomp.h:50:0,
from /reactos/dll/win32/shell32/shell32_main.cpp:22:
/reactos/lib/atl/atlcom.h: In instantiation of 'static HRESULT
ATL::CComCreator<T1>::CreateInstance(void*, const IID&, void**) [with
T1 = ATL::CComObjectCached<ATL::CComClassFactory>, HRESULT = long int,
IID = _GUID, LPVOID = void*]':
/reactos/dll/win32/shell32/shell32_main.cpp:1273:1: required from here
/reactos/lib/atl/atlcom.h:253:5: warning: deleting object of
polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/reactos/lib/atl/atlcom.h: In instantiation of 'ULONG
ATL::CComObjectCached<Base>::Release() [with Base =
ATL::CComClassFactory, ULONG = long unsigned int]':
/reactos/dll/win32/shell32/shell32_main.cpp:1478:1: required from here
/reactos/lib/atl/atlcom.h:304:4: warning: deleting object of
polymorphic class type 'ATL::CComObjectCached<ATL::CComClassFactory>'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In
member function 'virtual ULONG CMiniportDMusUART::Release()':
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:114:20:
warning: deleting object of polymorphic class type 'CMiniportDMusUART'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In
member function 'virtual ULONG CMiniportDMusUARTStream::Release()':
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:239:20:
warning: deleting object of polymorphic class type
'CMiniportDMusUARTStream' which has non-virtual destructor might cause
undefined behaviour [-Wdelete-non-virtual-dtor]
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp: In
function 'NTSTATUS NewMiniportDMusUART(IMiniport**, const CLSID&)':
/reactos/drivers/wdm/audio/backpln/portcls/miniport_dmus.cpp:1274:16:
warning: deleting object of polymorphic class type 'CMiniportDMusUART'
which has non-virtual destructor might cause undefined behaviour
[-Wdelete-non-virtual-dtor]
Windows cmake builder is running new BE since yesterday. First thing that i noticed, is the increase of buildtime. Previous version was consistent around 5 minutes, the new candidate - more than 7. I doublechecked it by swapping BE's back and forth.
This might look not serious, but if this problem scales up, we are talking about 35 minutes of buildtime for someone who needed 25 minutes previously.
--
With best regards
Caemyr
Hi,
small note to inform people who were having issues connecting to secured IServ services due to wrong SSL certificate (issued for the wrong address) that the certificate has been renewed today and the issues are gone.
Regards,
Pierre