Menu
▾
▴
gump-develop
You can subscribe to this list here.
| 2000 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Steve M. <sm...@ne...> - 2000-02-29 14:37:32
|
David Whitten writes: > Is this a result of your change? Probably. I commented out the definition of USE_SYS_TIME_H in mpsdef0.h. That was my first attempt to fix the timezone problem on Solaris and I forgot to undo it. In the end I deleted all the various timezone code which depended on various non portable timezone enhancements and went to what I think is a lowest common denominator solution of calculation the timezone difference. I have since backed out the USE_SYS_TIME_H change (it's defined again) so it should work now. It works both ways on Solaris. Could you try the new version. I assume that you are working on Linux? We desperately need a configuration dependent header file although in this case making portable code was probably a better solution anyway. The only thing I am confused by is that your error message refers to 'Timebuffer' but the at code at line 3340 uses 'timebuffer'. Also the function is xecline, not lline. I hope that these are typos or there might be a different problem. > I checked out a copy and tried make all > in the top directory, I got a message: > > make all > (cd src; make install) > make[1]: Entering directory /home/groups/gump/htdocs/work/FreeM/src' > cc -g -O -DHACK_NOXLATE -c version.c -o version.o > cc version.o -o version > ./version > version.h > cc -g -O -DHACK_NOXLATE -c compact.c -o compact.o > cc -g -O -DHACK_NOXLATE -c xecline.c -o xecline.o > xecline.c: In function 'lline': > xecline.c:3340: storage size of 'Timebuffer' isn't known > make[1]: *** [xecline.o] Error 1 > make[1]: Leaving directory /home/groups/gump/htdocs/work/FreeM/src' > make: *** [all] Error 2 > |
|
From: David W. <wh...@ne...> - 2000-02-29 00:55:13
|
> > > After several days of fiddling I have finally been able to checkin my > test round of global.c changes. To do this I needed to fix a few > solaris specific problems as follows: > > 1) exec_qa and encode are no longer dependent on bash. > > 2) I tried to make the timezone stuff in mumps.c more portable. I checked out a copy and tried make all in the top directory, I got a message: make all (cd src; make install) make[1]: Entering directory /home/groups/gump/htdocs/work/FreeM/src' cc -g -O -DHACK_NOXLATE -c version.c -o version.o cc version.o -o version ./version > version.h cc -g -O -DHACK_NOXLATE -c compact.c -o compact.o cc -g -O -DHACK_NOXLATE -c xecline.c -o xecline.o xecline.c: In function 'lline': xecline.c:3340: storage size of 'Timebuffer' isn't known make[1]: *** [xecline.o] Error 1 make[1]: Leaving directory /home/groups/gump/htdocs/work/FreeM/src' make: *** [all] Error 2 Is this a result of your change? > 3) I have taken a bunch of function declarations out of the header > files and made them static in global.c. > > I made a couple of minor changes to cleanup compiler warnings. > > Note: After fixing the two qa scripts the qa tests seem to fail the > same way they did before my changes. I have not yet cleaned up the > output. I am going to temporarily take the version number output out > of %LOGIN until we find a better solution. I think make all in the qa directory uudecodes all the want.out and want.err files, at least that is what Makefile seem to say.. > Unless anyone else steps up I will try to do the qa cleanup (make the > expected output reflect current version numbers etc.) next so that I > can use this stuff. > > Then maybe I can get back to the global handler. Sorry to slow down your development. Dave |
|
From: Steve M. <sm...@ne...> - 2000-02-28 18:21:32
|
After several days of fiddling I have finally been able to checkin my test round of global.c changes. To do this I needed to fix a few solaris specific problems as follows: 1) exec_qa and encode are no longer dependent on bash. 2) I tried to make the timezone stuff in mumps.c more portable. 3) I have taken a bunch of function declarations out of the header files and made them static in global.c. I made a couple of minor changes to cleanup compiler warnings. Note: After fixing the two qa scripts the qa tests seem to fail the same way they did before my changes. I have not yet cleaned up the output. I am going to temporarily take the version number output out of %LOGIN until we find a better solution. Unless anyone else steps up I will try to do the qa cleanup (make the expected output reflect current version numbers etc.) next so that I can use this stuff. Then maybe I can get back to the global handler. |
|
From: Steve M. <sm...@ne...> - 2000-02-18 22:55:45
|
This is not a blocker for me but something that needs to be thought about soon. Procedural question: OK... I've made some initial changes to isolate global.c, namely I have made various functions static so they don't show up as externals in the C symbol tables. In the process I changed one of the header files that are used everywhere. I have also made minor changes to get rid of some gcc warnings (declared main to return int as it should etc.) Now I have something that should be functionally identical to where I started almost to the point of matching byte by byte in the executable. I have more work to do (external functions and global data) but this is a nice break and normally I would be looking to do a little testing and then checkin what I've done before moving forward. So what is the drill for testing? I do a make and get lots of errors: /bin/sh: ../exec_qa: not found What is this telling me? Is it attempting to run our test suite? Is there a different test suite that I should be running. I am used to, when there is a shared but relatively stable repository, that there is a minimum test suite requirement before people are allowed to commit. (This is frequently called the checkin test suite.) Is the one in the makefile (but broken) the correct one to use for this? |
|
From: Steve M. <sm...@ne...> - 2000-02-14 16:19:28
|
They have cleared the repository again except that they did not refresh the CVSROOT directory. I updated the modules file one more time to restore it to the original version in the hopes that this will remove any confusion. Now every file should in that directory should be the same as the original version except that the version numbers are not original. |
|
From: LD L. <arc...@db...> - 2000-02-12 01:24:37
|
This message was sent from Geocrawler.com by "LD Landis" <ld...@ro...> Be sure to reply to that address. Hi, I've actually talked to someone there, and things are close to being ready... All that is left is to remove the existing module entries for FreeM(count=2) and GLM(count=1) so that I can recreate the modules. Apparently the name of a module does not have a unique constraint, as each gets its own id (so the two FreeM modules have different ids). Not sure that I want to think about what would go awry if we left things stand as they do. Anyway, I hope that today I'll be able to populate the CVS on SourceForge... Cheers, --ldl Geocrawler.com - The Knowledge Archive |
|
From: LD L. <arc...@db...> - 2000-02-12 01:24:10
|
This message was sent from Geocrawler.com by "LD Landis" <ld...@ro...> Be sure to reply to that address. Hi, I have contacted (voice) someone at VALinux, and they gave me a number to call after 10:30am PST. So... hope that we get this resolved today (been 1 week). More on this as I get more... Won't post to the GUMP list until I have real news. (This is THE 'developer channel' ;-) Cheers, --ldl Geocrawler.com - The Knowledge Archive |
|
From: Steve M. <sm...@ne...> - 2000-02-03 18:09:32
|
This is the book site and includes free electronic versions of the CVS
chapters.
http://cvsbook.red-bean.com/
This FAQ is well worth exploring. It is full of "how do I" type of questions.
http://www.loria.fr/~molli/cvs-index.html
The official distribution site of CVS.
http://www.sourcegear.com/CVS
This site has a list of docs telling how to use sourceforge.
http://sfdocs.sourceforge.net/sfdocs
|
|
From: LD L. <ld...@ld...> - 2000-01-31 21:06:55
|
Cross-posted: gum...@li... and
GU...@ld...
Hi,
I am in the process of reading the book Open Source Development with
CVS by Karl Fogel. At present I have not yet figured out where this
host (sourceforge) plugs projects into the CVS architecture, so I am
planning to figure this out over the next day or so.
Items I am exploring include:
- How do we want to do "sub projects".. e.g. FreeM as a sub-project
of the GUM Project.
- What management is available to a sourceforge project (e.g. where
do we limit access, etc.
- Creating the repository for the GUM project, to include:
- all releases (starting with the original from Shalom) for FreeM
- all releases of the "other" GUM stuff (e.g. Berkeley DB handler)
Please become a member of the sourceforge to gain access to the CVS
repository... Be aware that until you hear more, there is nothing
there...
--
Cheers,
--ldl
-----------------------------------------------------------------------------
LD Landis ld...@He... N0YRQ Voice 612/883-5511 FAX 612/883-7199
HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309
Shape your life not from your memories, but from your hopes. (Borrowed)
-----------------------------------------------------------------------------
|
