[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 14 Jul 2005 10:00:55 +1000
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
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
for example a web reviewer was commenting about the (past?) instability of
code and Adam Fedor replyed, "of course, he uses CVS instead of the released
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
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
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
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
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
will crash the process. so it's hard to diagnose.
But yesterday I found a crash (SEGFAULT, in a pointer spaghetti code) deep
(for code working fine on MacOSX)
and another, sometimes crash, for a NSFont object coming out of an
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
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
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.
- Re: ANN: StepTalk 0.9.1 - with actor prototype, oberhage, 2005/07/13
- BTW, Lloyd Dupont, 2005/07/13
- Re: BTW, Richard Frith-Macdonald, 2005/07/13
- Re: BTW,
Lloyd Dupont <=
- Re: BTW, Richard Frith-Macdonald, 2005/07/14
- Re: BTW, Sheldon Gill, 2005/07/14
- Re: ANN: StepTalk 0.9.1 - with actor prototype, Adam Fedor, 2005/07/13