Re: BTW

[Lloyd Dupont]

> > I could see there is an update of the libraries (base is now 1.10.3 & GUI 
> > is now 0.9.5) but the windows installer hasen't been updated.
> >
> > what could I do about that?
>
> I don't know ... perhaps contact the people who provided the installer 
> directly.  Perhaps you could update the installer and provide a newer 
> version?
uh... I have no idea how the installer is made...

> > Tomorrow I might try the following: download the sources, update my 
> > installation compiled from source, (try to update to latest GCC as well), 
> > recompile. would it be ok?
>
> Well ... I don't know about the 'latest' GCC ... but if you use the latest 
> GNUstep code from CVS, and follow the instructions for MinGW in the 
> GNUstep-make package exactly (ie use the same versions of 
> mingw,msys,gcc,libraries), you should end up with a working system.  I 
> know Nicola has done that in the last couple of days, and I updated from 
> CVS not long ago and ended up with a working system, so those instructions 
> work (at least on windows-xp).

uh... some reading on the web made me warry about grabbing the latest CVS 
stuff.
for example a web reviewer was commenting about the (past?) instability of 
some GNUstep
code and Adam Fedor replyed, "of course, he uses CVS instead of the released 
packages",
so you see....
Beside I've tryed in some remote time (back in... 2001/2? when I was still 
interested in home C coding)
to do just that (exactly follow instruction for MinGW): unsuccesffully.....

> I would recommend getting a working version using that procedure before 
> trying to vary anything by using different versions of tools and 
> libraries.
>
> > In case no one knows I'll keep you informed....
> >
> > BTW reading the website to try to find what has changed: I stumbled many 
> > times on this uninformative cryptive description: "Minor bugfixe from 
> > MingW report."
> >
> > How is the 'minority' determined?
>
> I don't know of many such descriptions ... but I would imagine it's a 
> personal judgement, and usually means that the code change is 
> small/obvious if you look at it.  Of course, if it happens to fix a 
> persistent crash in your particualr application, it might not be minor for 
> you.
>
> > For example I'm sure there is some memory corruption with 1.10.1 (leading 
> > to regular random crash), could these 'minor' bugfixes, repair my 
> > application's crashes?
>
> Maybe ... you need to look at the changes to find out.  Simpler, if there 
> are a *lot* of changes you are interested in, might be just to update to 
> latest CVS version and try it.
> Where do you think this memory corruption is?  I think the base library is

I have not clearly pointed it out yet.
The fact is: in some circumstances, just calling 
'LoadLibrary("gnustep-base.dll")'
will crash the process. so it's hard to diagnose.
But yesterday I found a crash (SEGFAULT, in a pointer spaghetti code) deep 
NSLayoutManager
(for code working fine on MacOSX)
and another, sometimes crash, for a NSFont object coming out of an 
NSAttributedString attribute's
array.
The NSLayoutManager I manage to work around it (as I don't use GNUstep, but 
for my application data),
but the NSFont problem I have to fix (as NSAttributedString are part of my 
data objects).

> very good at not corrupting memory on gnu/linux as I have a lot of 
> preograms which use the base library and which I fairly frequently run 
> under valgrind. The gui and backend libraries are less well tested, but 
> still pretty good.  That being said, there are variations for running 
> under windows, so there could be system specific memory corruption issues, 
> and I know of no good free tool like valgrind for windows which would let 
> us find them.  I believe that the commercial product 'purify' is 
> comparable to valgrind, but as I'm not a windows programmer (I just use it 
> occasionally to fix/test gnustep-base issues on mingw), I'm not likely to 
> pay for a copy.
>
>
> > (and why not update the windows installer when the only changes where 
> > windows related?)
> >
> >
> > That makes me think, recently there was a discussion about the importance 
> > of the Windows port. Unfortunately I see no one seems to be interested in 
> > doing it .... :-( (well all motivated, geek kind of Windows developpers, 
> > are doing ..NET at the moment, that might be the reason...)
>
> Guess so.  As far as I know, none of the core GNUstep developers use 
> windows at all ... apart from booting it up occasionally in order to port 
> gnustep as a good-will gesture to the windows users out there.  That's 
> really why the windows port goes so slowly ... it's largely powered by 
> people who don't use (and don't want to use) windows.  I think we would 
> all like the windows stuff to improve, and are all eager to help windows 
> developers in improving it ... but we do need those windows developers.