Thread: [Simplygnustep-discuss] InterimDeveloperRelease-1 due for update?
Status: Alpha
Brought to you by:
cehardin
From: Peter-Henry M. <gn...@ma...> - 2003-03-11 14:57:45
|
Hi SGSteppers, Hi Chad, I'm getting more curious about this project, and I wonder if the ISO download is due for a revision soon? I'm a professional coder with scant spare time, but the idea of plugging away at a "pure" GNUstep platform interests me. I find WindowMaker to be the fastest and easiest to use, and I suspect the rest of GNUstep is likewise. I believe I've enough programming skill to be useful here, but I need a *very* quick and easy start (I'm counting minutes here) and the ISO is definitely the way to go. So, do I download and start hacking now, or should I wait until the next revision? Pete. |
From: <ceh...@ma...> - 2003-03-17 07:05:26
|
The source code that produces the ido installer image is being worked on right now. The actual installer still needs to be made. In short, this is gonna take while. Feel free to checkout the source from cvs, just co the Prometheus module. If you need help with that just ask. Right now the system is built to use XFree86 and windowmkaer, but the eventual goal is to go to a new lightweight window manager system. I have started on it, it is called nuVu. Basically it uses SysV IPC and shared memory to draw to the linux video framebuffer. Some help would be appreciated with that project if you'd like. There is also, graphite, which aims to be an LGPL version of Carbon. Think of it as a c bridge to gnustep that happens to have the same api as Carbon. I started on this a while back but lost the source code. Perhaps I will upload a skeleton to cvs to facilitate it being worked on. Anyhow, feel free to help if you'd like! Chad On Tuesday, Mar 11, 2003, at 03:54 Pacific/Honolulu, Peter-Henry Mander wrote: > Hi SGSteppers, Hi Chad, > > I'm getting more curious about this project, and I wonder if the ISO > download is due for a revision soon? I'm a professional coder with > scant spare time, but the idea of plugging away at a "pure" GNUstep > platform interests me. I find WindowMaker to be the fastest and > easiest to use, and I suspect the rest of GNUstep is likewise. I > believe I've enough programming skill to be useful here, but I need a > *very* quick and easy start (I'm counting minutes here) and the ISO is > definitely the way to go. > > So, do I download and start hacking now, or should I wait until the > next revision? > > Pete. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! Get > cracking and register here for some mind boggling fun and the chance > of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Peter-Henry M. <gn...@ma...> - 2003-03-24 09:43:33
|
Hi Chad, Thanks for responding, sorry for being a bit slow in return. I'm in the process of doing a cvs co of Prometheus, and I'll have a go at building it out of the box. Oh, it's just completed! 30Mb sounds about right? I gather I should run ./Build-SGSTEP.sh and then run ./EnterSGstep.sh Any words of wisedom to share before I venture forth? Is it possible to use Prometheus as a development platform, to bootstrap itself? I.e. avoid developing under SuSE/RH/Other and exclusively use Prometheus? Is it worthwhile keeping abreast of developments in the GNUstep project? What needs doing in nuVu? Pete. From: <cehardin@ma...> Re: InterimDeveloperRelease-1 due for update? 2003-03-16 23:05 The source code that produces the ido installer image is being worked on right now. The actual installer still needs to be made. In short, this is gonna take while. Feel free to checkout the source from cvs, just co the Prometheus module. If you need help with that just ask. Right now the system is built to use XFree86 and windowmkaer, but the eventual goal is to go to a new lightweight window manager system. I have started on it, it is called nuVu. Basically it uses SysV IPC and shared memory to draw to the linux video framebuffer. Some help would be appreciated with that project if you'd like. There is also, graphite, which aims to be an LGPL version of Carbon. Think of it as a c bridge to gnustep that happens to have the same api as Carbon. I started on this a while back but lost the source code. Perhaps I will upload a skeleton to cvs to facilitate it being worked on. Anyhow, feel free to help if you'd like! Chad On Tuesday, Mar 11, 2003, at 03:54 Pacific/Honolulu, Peter-Henry Mander wrote: > Hi SGSteppers, Hi Chad, > > I'm getting more curious about this project, and I wonder if the ISO > download is due for a revision soon? I'm a professional coder with > scant spare time, but the idea of plugging away at a "pure" GNUstep > platform interests me. I find WindowMaker to be the fastest and > easiest to use, and I suspect the rest of GNUstep is likewise. I > believe I've enough programming skill to be useful here, but I need a > *very* quick and easy start (I'm counting minutes here) and the ISO is > definitely the way to go. > > So, do I download and start hacking now, or should I wait until the > next revision? > > Pete. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! Get > cracking and register here for some mind boggling fun and the chance > of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Simplygnustep-discuss mailing list > Simplygnustep-discuss@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Peter-Henry M. <gn...@ma...> - 2003-03-24 15:38:09
|
Hi Chad, Just making notes as I compile, and I need your help as I seem to have screwed up along the way. This is the diary so far... --------------------------------------- ftp://ftp.cvshome.org/pub/cvs-1.11.5/cvs-1.11.5.tar.gz got terminally stuck, so downloaded it by hand and temporarily removed this line from the Prometheus/WorkingTree/Source/Common/SourcesToDownload.txt file. ftp://ftp.debian.org/debian/pool/main/f/fbset/fbset_2.1.orig.tar.gz was getting in a spin: "Error in server response, closing control connection. Retrying." Again, downloaded by hand, and removed the problem line as above. ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz "Invalid PORT.Retrying." Ditto, by hand. Compilation underway... 11:00 GMT (I hope that the 2GHz machine will take less than 10 hours!) Ooops! Can't chroot unless logged on as root! Try again... Ah, here's a cryptic message: !!!!!!!!!!About to start building shared libs!!!!!!! Make sure eveything is static! I assume that if everything has built according to plan, this should be so, but how do I "Make sure eveything is static"? Is there a way to check this? If so, a short explanation would help here. binutils-2.13.2.1.tar.bz2 had to be changed to bin86-0.16.11.tar.gz in Prometheus/WorkingTree/Source/Common The SourcesToDownload.txt file has binutils-2.13.2.1.tar.bz2 but a .tar.gz is expected in one of the scripts. Fixed by recompressing binutils-2.13.2.1.tar with gzip, continuing... make-3.80.tar.bz2 same as above! Oh dear, I've got a show stopper. Why would chgrp: invalid group name `root' cause a problem? Maybe something to do with the cryptic message above? Here's the last few lines on the console: make[4]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80/doc' make[3]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80/doc' make[3]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' make[4]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' /bin/sh ./config/mkinstalldirs /usr/bin /bin/sh /Source/SharedLib/Standard/make/make-3.80/config/install-sh -c -s make /usr/bin/make /bin/sh ./config/mkinstalldirs /usr/man/man1 /usr/bin/install -c -m 644 ./make.1 /usr/man/man1/make.1 make[4]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' make[3]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' make[2]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' make[1]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' chgrp: invalid group name `root' make: *** [make/DONE] Error 1 make[2]: *** [Standard/DONE] Error 2 make[2]: Leaving directory `/public/GnuSTEP/Prometheus/WorkingTree/Source/SharedLib' make[1]: *** [SharedLib/DONE] Error 2 make[1]: Leaving directory `/public/GnuSTEP/Prometheus/WorkingTree/Source' make: *** [BUILDING-DONE] Error 2 Ahem! Okay, lets do that again, but starting from scratch as root! Started from scratch, cvs co and, copied downloaded files in /public/GnuSTEP/Prometheus/WorkingTree/Source/Common tar: ../../Common/make-3.80.tar.bz2: Cannot open: No such file or directory which seems to contradict the previous make-3.80.tar.bz2, anyway, added *both* make-3.80.tar.gz and make-3.80.tar.bz2 which seems to have fixed the problem for now. Here's that message again... !!!!!!!!!!About to start building shared libs!!!!!!! Make sure eveything is static! Proceeding regardless (like the wreckless fool I am!) Nope! same problem. What do I do now? |
From: <ceh...@ma...> - 2003-03-25 04:47:41
|
Hi Peter, thanks for trying it out. I'm sorry to say that I will not be able to work on this project for a week or two at least. This is because I'm in the U.S. army and am quite busy right now. Pretty soon I will be back in full-force! Thanks, Chad On Monday, Mar 24, 2003, at 05:35 Pacific/Honolulu, Peter-Henry Mander wrote: > Hi Chad, > > Just making notes as I compile, and I need your help as I seem to have > screwed up along the way. This is the diary so far... > > --------------------------------------- > > ftp://ftp.cvshome.org/pub/cvs-1.11.5/cvs-1.11.5.tar.gz got terminally > stuck, so downloaded it by hand and temporarily removed this line from > the Prometheus/WorkingTree/Source/Common/SourcesToDownload.txt file. > > ftp://ftp.debian.org/debian/pool/main/f/fbset/fbset_2.1.orig.tar.gz > was getting in a spin: > "Error in server response, closing control connection. Retrying." > Again, downloaded by hand, and removed the problem line as above. > > ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz > "Invalid PORT.Retrying." > Ditto, by hand. > > Compilation underway... 11:00 GMT (I hope that the 2GHz machine will > take less than 10 hours!) > > Ooops! Can't chroot unless logged on as root! Try again... Ah, here's > a cryptic message: > !!!!!!!!!!About to start building shared libs!!!!!!! > Make sure eveything is static! > > I assume that if everything has built according to plan, this should > be so, but how do I "Make sure eveything is static"? Is there a way to > check this? If so, a short explanation would help here. > > binutils-2.13.2.1.tar.bz2 had to be changed to bin86-0.16.11.tar.gz in > Prometheus/WorkingTree/Source/Common > The SourcesToDownload.txt file has binutils-2.13.2.1.tar.bz2 but a > .tar.gz is expected in one of the scripts. Fixed by recompressing > binutils-2.13.2.1.tar with gzip, continuing... > > make-3.80.tar.bz2 same as above! > > Oh dear, I've got a show stopper. Why would > chgrp: invalid group name `root' > cause a problem? Maybe something to do with the cryptic message above? > > Here's the last few lines on the console: > > make[4]: Leaving directory > `/Source/SharedLib/Standard/make/make-3.80/doc' > make[3]: Leaving directory > `/Source/SharedLib/Standard/make/make-3.80/doc' > make[3]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' > make[4]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' > /bin/sh ./config/mkinstalldirs /usr/bin > /bin/sh /Source/SharedLib/Standard/make/make-3.80/config/install-sh > -c -s make /usr/bin/make > /bin/sh ./config/mkinstalldirs /usr/man/man1 > /usr/bin/install -c -m 644 ./make.1 /usr/man/man1/make.1 > make[4]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[3]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[2]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[1]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > chgrp: invalid group name `root' > make: *** [make/DONE] Error 1 > make[2]: *** [Standard/DONE] Error 2 > make[2]: Leaving directory > `/public/GnuSTEP/Prometheus/WorkingTree/Source/SharedLib' > make[1]: *** [SharedLib/DONE] Error 2 > make[1]: Leaving directory > `/public/GnuSTEP/Prometheus/WorkingTree/Source' > make: *** [BUILDING-DONE] Error 2 > > > Ahem! Okay, lets do that again, but starting from scratch as root! > > Started from scratch, cvs co and, copied downloaded files in > /public/GnuSTEP/Prometheus/WorkingTree/Source/Common > > tar: ../../Common/make-3.80.tar.bz2: Cannot open: No such file or > directory > which seems to contradict the previous make-3.80.tar.bz2, anyway, > added *both* make-3.80.tar.gz and make-3.80.tar.bz2 which seems to > have fixed the problem for now. > > Here's that message again... > !!!!!!!!!!About to start building shared libs!!!!!!! > Make sure eveything is static! > Proceeding regardless (like the wreckless fool I am!) > > Nope! same problem. > > What do I do now? > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: Peter-Henry M. <gn...@ma...> - 2003-03-25 09:16:31
|
ceh...@ma... wrote: > Hi Peter, > thanks for trying it out. No problem Chad, it's worth the effort. > I'm sorry to say that I will not be able to > work on this project for a week or two at least. This is because I'm in > the U.S. army and am quite busy right now. Pretty soon I will be back > in full-force! > I understand you have a lot to do right now! Take care, and let us know how you're doing. Pete. > Thanks, > > Chad > On Monday, Mar 24, 2003, at 05:35 Pacific/Honolulu, Peter-Henry Mander > wrote: > >> Hi Chad, >> >> Just making notes as I compile, and I need your help as I seem to have >> screwed up along the way. This is the diary so far... >> >> --------------------------------------- >> snipped! |
From: <ceh...@ma...> - 2003-03-26 03:49:47
|
On Monday, Mar 24, 2003, at 23:14 Pacific/Honolulu, Peter-Henry Mander wrote: > > > ceh...@ma... wrote: >> Hi Peter, >> thanks for trying it out. > > No problem Chad, it's worth the effort. Thanks! > >> I'm sorry to say that I will not be able to work on this project for >> a week or two at least. This is because I'm in the U.S. army and am >> quite busy right now. Pretty soon I will be back in full-force! > > I understand you have a lot to do right now! Take care, and let us > know how you're doing. Pretty good, I'm not in harms way or anything, just busy. > > Pete. > >> Thanks, >> Chad >> On Monday, Mar 24, 2003, at 05:35 Pacific/Honolulu, Peter-Henry >> Mander wrote: >>> Hi Chad, >>> >>> Just making notes as I compile, and I need your help as I seem to >>> have screwed up along the way. This is the diary so far... >>> >>> --------------------------------------- >>> > > snipped! > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: <ceh...@ma...> - 2003-03-26 03:57:06
|
On Monday, Mar 24, 2003, at 23:14 Pacific/Honolulu, Peter-Henry Mander wrote: > > > ceh...@ma... wrote: >> Hi Peter, >> thanks for trying it out. > > No problem Chad, it's worth the effort. Thanks! > >> I'm sorry to say that I will not be able to work on this project for >> a week or two at least. This is because I'm in the U.S. army and am >> quite busy right now. Pretty soon I will be back in full-force! > > I understand you have a lot to do right now! Take care, and let us > know how you're doing. Pretty good, I'm not in harms way or anything, just busy. > > Pete. > >> Thanks, >> Chad >> On Monday, Mar 24, 2003, at 05:35 Pacific/Honolulu, Peter-Henry >> Mander wrote: >>> Hi Chad, >>> >>> Just making notes as I compile, and I need your help as I seem to >>> have screwed up along the way. This is the diary so far... >>> >>> --------------------------------------- >>> > > snipped! > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |
From: <ceh...@ma...> - 2003-03-26 03:56:52
|
Holy crud there are some big bugs in the Build process. Ouch (See below) On Monday, Mar 24, 2003, at 05:35 Pacific/Honolulu, Peter-Henry Mander wrote: > Hi Chad, > > Just making notes as I compile, and I need your help as I seem to have > screwed up along the way. This is the diary so far... > > --------------------------------------- > > ftp://ftp.cvshome.org/pub/cvs-1.11.5/cvs-1.11.5.tar.gz got terminally > stuck, so downloaded it by hand and temporarily removed this line from > the Prometheus/WorkingTree/Source/Common/SourcesToDownload.txt file. Right, many of these problems stem from some servers requiring passive ftp transfers, or not supporting them. since the wget command is done at once with SourcesTodownload.txt being fed to it, it does not differentiate between who needs passive mode and who does not. the solution i think is to remove the single wget command and replace it with individual wget(s) that specifiy --ftp-passive or not, depending on which server is being used. If we had a mirror to put all the sources the problem could be solved that way as well. > > ftp://ftp.debian.org/debian/pool/main/f/fbset/fbset_2.1.orig.tar.gz > was getting in a spin: > "Error in server response, closing control connection. Retrying." > Again, downloaded by hand, and removed the problem line as above. > > ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.6.4.tar.gz > "Invalid PORT.Retrying." > Ditto, by hand. See above > > Compilation underway... 11:00 GMT (I hope that the 2GHz machine will > take less than 10 hours!) > > Ooops! Can't chroot unless logged on as root! Try again... Ah, here's > a cryptic message: > !!!!!!!!!!About to start building shared libs!!!!!!! > Make sure eveything is static! > this is a little note for the builder (up to now, only me) to remind myself to make sure that everything previously built is static. It can be removed really. > I assume that if everything has built according to plan, this should > be so, but how do I "Make sure eveything is static"? Is there a way to > check this? If so, a short explanation would help here. > see above > binutils-2.13.2.1.tar.bz2 had to be changed to bin86-0.16.11.tar.gz in > Prometheus/WorkingTree/Source/Common > The SourcesToDownload.txt file has binutils-2.13.2.1.tar.bz2 but a > .tar.gz is expected in one of the scripts. Fixed by recompressing > binutils-2.13.2.1.tar with gzip, continuing... > k, can't promise when I can fix this, maybe tomorrow > make-3.80.tar.bz2 same as above! > > Oh dear, I've got a show stopper. Why would > chgrp: invalid group name `root' > cause a problem? Maybe something to do with the cryptic message above? > This is agood one indeed. I'll check it out ASAP. > Here's the last few lines on the console: > > make[4]: Leaving directory > `/Source/SharedLib/Standard/make/make-3.80/doc' > make[3]: Leaving directory > `/Source/SharedLib/Standard/make/make-3.80/doc' > make[3]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' > make[4]: Entering directory `/Source/SharedLib/Standard/make/make-3.80' > /bin/sh ./config/mkinstalldirs /usr/bin > /bin/sh /Source/SharedLib/Standard/make/make-3.80/config/install-sh > -c -s make /usr/bin/make > /bin/sh ./config/mkinstalldirs /usr/man/man1 > /usr/bin/install -c -m 644 ./make.1 /usr/man/man1/make.1 > make[4]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[3]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[2]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > make[1]: Leaving directory `/Source/SharedLib/Standard/make/make-3.80' > chgrp: invalid group name `root' > make: *** [make/DONE] Error 1 > make[2]: *** [Standard/DONE] Error 2 > make[2]: Leaving directory > `/public/GnuSTEP/Prometheus/WorkingTree/Source/SharedLib' > make[1]: *** [SharedLib/DONE] Error 2 > make[1]: Leaving directory > `/public/GnuSTEP/Prometheus/WorkingTree/Source' > make: *** [BUILDING-DONE] Error 2 > > > Ahem! Okay, lets do that again, but starting from scratch as root! > > Started from scratch, cvs co and, copied downloaded files in > /public/GnuSTEP/Prometheus/WorkingTree/Source/Common > > tar: ../../Common/make-3.80.tar.bz2: Cannot open: No such file or > directory > which seems to contradict the previous make-3.80.tar.bz2, anyway, > added *both* make-3.80.tar.gz and make-3.80.tar.bz2 which seems to > have fixed the problem for now. > > Here's that message again... > !!!!!!!!!!About to start building shared libs!!!!!!! > Make sure eveything is static! > Proceeding regardless (like the wreckless fool I am!) > > Nope! same problem. > > What do I do now? Wait a few, unfortunately, sorry. I would like to eventually gove other people cvs access. Perhaps after I am done "cleaning up" the cvs source tree. |
From: <ceh...@ma...> - 2003-03-26 04:05:35
|
On Sunday, Mar 23, 2003, at 23:41 Pacific/Honolulu, Peter-Henry Mander wrote: > Hi Chad, > > Thanks for responding, sorry for being a bit slow in return. I'm in > the process of doing a cvs co of Prometheus, and I'll have a go at > building it out of the box. Oh, it's just completed! 30Mb sounds about > right? No problem, we are not in any real rush here :-) > > I gather I should run ./Build-SGSTEP.sh and then run ./EnterSGstep.sh ./EnterSGstep.sh is there for the sole purpose of testing WorkingTree. All it really does is chroot into /workingTree. the idea is to be able to chroot in there and test out if things have been building and installing correctly. > > Any words of wisedom to share before I venture forth? > > Is it possible to use Prometheus as a development platform, to > bootstrap itself? That is the goal. i would actually like to start building Prometheus within Prometheus as soon as possible. > I.e. avoid developing under SuSE/RH/Other and exclusively use > Prometheus? Is it worthwhile keeping abreast of developments in the > GNUstep project? Yes! Advances in GNUstep system and GNUstep applications are critical. If that project flutters out we are royally screwed. > > What needs doing in nuVu? Glad you asked! Right now, NuVuServer contains almost completely inclined c++ code. It seemed like a good idea at first, but inlined code is hard as hell to compile. If there errors in the compile figuring out where the problem is is practically impossible. So, NuVuServer needs to regular modularized c++ with only certain key methods inlined (such as getPixel(). putPixel(), etc) It needs a main class, the infracstrucutre is there but there is not real startup code. The plan is to use the new eventX stuff in linux for mouse and keyboard events, so you may want to read up on that stuff. the newest linux journal has an article about it. some documentation/diagramming of the server would be nice, I should do that. would you like cvs access to NuVu? Development in NuVu is done with the Anjuta IDE http://anjuta.org/ it is a good IDE. Later! Chad > > Pete. > > |
From: Peter-Henry M. <gn...@ma...> - 2003-03-26 08:30:04
|
ceh...@ma... wrote: #include <answers> // to previous questions, thanks. >> What needs doing in nuVu? > > Glad you asked! Right now, NuVuServer contains almost completely > inclined c++ code. It seemed like a good idea at first, but inlined > code is hard as hell to compile. If there errors in the compile > figuring out where the problem is is practically impossible. So, > NuVuServer needs to regular modularized c++ with only certain key > methods inlined (such as getPixel(). putPixel(), etc) Try templated code for really cryptic error reports! May I ask why you're inlining (apparently) everything, specially so early in the project? I find inlining more trouble than the speed gain is worth, at least until reaching a (late) stage when profiling becomes practical. Guesswork isn't really any good when optimising, the low-hanging fruit often get missed unless a profiler is used. Besides, the best results are almost always achieved with better algorithms than with tweaks. [1] It would seem to me that some Linux games programming libraries may be suitable for nuVu, and would avoid reinventing the wheel for most of the graphics. I'll do a search. I think SDL may be suitable. > It needs a main class, the infracstrucutre is there but there is not > real startup code. The plan is to use the new eventX stuff in linux for > mouse and keyboard events, so you may want to read up on that stuff. > the newest linux journal has an article about it. some > documentation/diagramming of the server would be nice, I should do > that. would you like cvs access to NuVu? Development in NuVu is done > with the Anjuta IDE http://anjuta.org/ it is a good IDE. I'll go look at those. As for CVS access, I would like to get comfortable with building Prometheus first. I'll ask for CVS access when I've adjusted my driving position and rear view mirrors :-) Pete. --------------------------------------------------- [1] Okay, putPixel() may not be improved with a better algorithm! But when I was hacking away at my AtariST (a loooong time ago) I wrote various graphics routines that trounced the OEM code, and text output could be optimised by a factor of 3, simply by finding special cases which allowed for better algorithms. I.e. horizontal line drawing, rectangle fills, rectangle move and copy, aligning on 32 bit boundaries etc. I then built a windowing system above all that which was quite nippy :-) Unfortunately it's all lost, no code, no ST, but I doubt there was anything that could be reused. These were easy improvements because Atari had used generic unoptimised algorithms, and I targeted special cases with more efficient algorithms. Needless to say that inlining wasn't part of the K&R C compiler I used at the time! (Anyone remember Sozobon C? I didn't think so!) But I did learn a lot about the MC68000 because compiler optimisation was so poor! Today I trust the compiler to do assembly level optimisation, so I don't bother with that any more since I doubt I can do any better by hand. |
From: <ceh...@ma...> - 2003-03-26 13:55:52
|
On Tuesday, Mar 25, 2003, at 22:29 Pacific/Honolulu, Peter-Henry Mander=20= wrote: > ceh...@ma... wrote: > > #include <answers> // to previous questions, thanks. > >>> What needs doing in nuVu? >> Glad you asked! Right now, NuVuServer contains almost completely=20 >> inclined c++ code. It seemed like a good idea at first, but inlined=20= >> code is hard as hell to compile. If there errors in the compile=20 >> figuring out where the problem is is practically impossible. So,=20 >> NuVuServer needs to regular modularized c++ with only certain key=20 >> methods inlined (such as getPixel(). putPixel(), etc) > > Try templated code for really cryptic error reports! May I ask why=20 > you're inlining (apparently) everything, specially so early in the=20 > project? I find inlining more trouble than the speed gain is worth, at=20= > least until reaching a (late) stage when profiling becomes practical. this is templated code! With inlining it can get so much worse... I did it all inlined as an experiment, yunno, to see what would happen.=20= There are only a few methods which really need inlining. > > Guesswork isn't really any good when optimising, the low-hanging fruit=20= > often get missed unless a profiler is used. Besides, the best results=20= > are almost always achieved with better algorithms than with tweaks. > = [1] > > It would seem to me that some Linux games programming libraries may be=20= > suitable for nuVu, and would avoid reinventing the wheel for most of=20= > the graphics. I'll do a search. I think SDL may be suitable. Feel free, =88'm interested in what you find out about SDL. > >> It needs a main class, the infracstrucutre is there but there is not=20= >> real startup code. The plan is to use the new eventX stuff in linux=20= >> for mouse and keyboard events, so you may want to read up on that=20 >> stuff. the newest linux journal has an article about it. some=20 >> documentation/diagramming of the server would be nice, I should do=20 >> that. would you like cvs access to NuVu? Development in NuVu is=20 >> done with the Anjuta IDE http://anjuta.org/ it is a good IDE. > > I'll go look at those. As for CVS access, I would like to get=20 > comfortable with building Prometheus first. I'll ask for CVS access=20 > when I've adjusted my driving position and rear view mirrors :-) > > Pete. K Later, chad > > --------------------------------------------------- > > [1] Okay, putPixel() may not be improved with a better algorithm! But=20= > when I was hacking away at my AtariST (a loooong time ago) I wrote=20 > various graphics routines that trounced the OEM code, and text output=20= > could be optimised by a factor of 3, simply by finding special cases=20= > which allowed for better algorithms. I.e. horizontal line drawing,=20 > rectangle fills, rectangle move and copy, aligning on 32 bit=20 > boundaries etc. I then built a windowing system above all that which=20= > was quite nippy :-) Unfortunately it's all lost, no code, no ST, but I=20= > doubt there was anything that could be reused. > > These were easy improvements because Atari had used generic=20 > unoptimised algorithms, and I targeted special cases with more=20 > efficient algorithms. Needless to say that inlining wasn't part of the=20= > K&R C compiler I used at the time! (Anyone remember Sozobon C? I=20 > didn't think so!) But I did learn a lot about the MC68000 because=20 > compiler optimisation was so poor! > > Today I trust the compiler to do assembly level optimisation, so I=20 > don't bother with that any more since I doubt I can do any better by=20= > hand. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: > The Definitive IT and Networking Event. Be There! > NetWorld+Interop Las Vegas 2003 -- Register today! > http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en > _______________________________________________ > Simplygnustep-discuss mailing list > Sim...@li... > https://lists.sourceforge.net/lists/listinfo/simplygnustep-discuss |