Talk:Peerd.c

From Organic Design wiki
(Redirected from Talk:Husk.c)

Need some help to figure out what these lines do. I think that they contain the right directives but I can't get it to produce a binary. SDLMain.m and SDLMain.h are cocca stuff or OSX. The first line works and produces a .o file.

gcc -I/Library/Frameworks/SDL.framework/Headers/ -I/Library/Frameworks/SDL_image.framework/Headers/ -I/System/Library/Frameworks/OpenGL.framework/Headers/ -c *.c
gcc -framework SDL -framework OpenGL -framework SDL_image -framework GLUT -framework AppKit -framework Foundation SDLMain.o peerd.o -lobjc -o peerd

--Rob 20:53, 21 Aug 2006 (NZST)

What does it say when it fails? --Nad 21:11, 21 Aug 2006 (NZST)

Success in building the current husk in darwin (with a screenfull of hideous warnings). Two extra files are required, the SDLMain.m and SDLMain.h. Here is the gcc command:

gcc -I/Library/Frameworks/SDL.framework/Headers -I/Library/Frameworks/SDL_image.framework/Headers husk.c SDLmain.m -framework SDL -framework SDL_image -framework Cocoa

All the expected things happen and in most ways this looks and works just like the win32 version. Resizing the window looks a bit different. The OS provides a resize 'handle' overlayed on the graphics surface bottom right to let you resize. On resizing the whole window goes white until the drag ends, but all other redraws are as any other OS window.

Will figure out a Makefile.darwin to add to the wiki tomorrow. --Rob 00:13, 7 Aug 2006 (NZST)

There needs to be a libSDLmain.a available in those paths and specified in the same way as the other .a's like SDL_image etc... --Nad 09:12, 7 Aug 2006 (NZST)

Was thinking about the best way to provide tests for the c components. I see you've commented out the testing code. Maybe the best way is to use IFDEF to include or exclude based on a CONSTANT, say:

#define UNITTESTS true

Then use:

#IFDEF UNITTESTS
doSomeTesting();
#ENDIF

This way we can build, do a test, and if it passes, omit the test code to get a smaller binary. --Rob 19:16, 4 Jul 2006 (NZST)


  • Compacted husk by moving sections out to #includes.
  • Fixed newline problem by adding them for .c and .h files in bender's file.pl
  • Tested that it compiles and restarts ok.
--Nad 17:15, 2 Jul 2006 (NZST)
Question: What is the article that does the compile now husk.c/compile is gone? --Rob 18:12, 2 Jul 2006 (NZST)
Remember we can't use c.php for husk now that there are #includes, so must use the one in init.d etc --Nad 18:14, 2 Jul 2006 (NZST)
Yes of course. What Bender menu option kicks off the init? --Rob 18:28, 2 Jul 2006 (NZST)
Bender doesn't do it, have to do it from shell - the next thing is to get peerd to restart, which I'm working on now in server.c --Nad 18:31, 2 Jul 2006 (NZST)
So the process is: edit c code, run manual wikisync, run /etc/init.d/peerd from sh --Rob 18:35, 2 Jul 2006 (NZST)
Yip, until we can restart from a something like https://organicdesign.nz:2012/cmd/restart

Compiling locally under darwin I get some output and then a bus error. The output matches the remote box. I think this is an address out of bounds problem. Maybe we can dump the pointers as we go and compare to the address space. I did change some of the printf syntax slightly, so that may have had some affect. --Rob 21:48, 27 Jun 2006 (NZST)

All that output was correct - the same happens on the server (except "bus error" is "segmentation fault"). It doesn't seem to be the printf itself, as you can make out="test" and it works fine - just fails when the strncpy is added... --Nad 22:07, 27 Jun 2006 (NZST)
Maybe try strlcpy to add x00 --Rob 22:18, 27 Jun 2006 (NZST)

About nodeGetState(node): shouldn't this just return a serialsed binary of the function? --Rob 22:01, 26 Jun 2006 (NZST)

We'd need to have TinyCC working to do that - or have the gcc-compiling, loading and executing. We're starting with pre-declared functions for now, not runtime building/declaring/executing. --Nad 22:04, 26 Jun 2006 (NZST)
Just as long as we can easily distinguish what are the nodal functions and what are the external functions. Putting them in another file looks difficult with the current setup (or is it?) --Rob 22:19, 26 Jun 2006 (NZST)
They're in the last section of the script called marked with // NODAL FUNCTIONS
ok but maybe a slightly different shade of red. But that will do for now.

Well it was a bit of a mission, but its compiling now, but its very tempromental and giving segemntation faults. When I just print "hello world" in the test code, its fine, but as soon as I print a value (like how it is now printing size) it crashes. It shows no output, but if you shell in and run /var/www/organicdesign/wiki/a.out manually you'll see it crash. --Nad 19:52, 23 Jun 2006 (NZST)

Seg faults and bus errors tracked down to a type mismatch in sprintf where an int is accessed via %s. --Rob 03:21, 25 Jun 2006 (NZST)

I'll set up a XmlWiki c-compiling script, so we can test the husk in husk.c/compile. If there's any problems I'll probly stop and carry on with husk.as, but it should work fairly easily I think... --Nad 13:06, 23 Jun 2006 (NZST)


I moved it to "husk" since we'll want to implement a node-space over the list-space too, so we may as well develop it along side husk.as using same functions etc. --Nad 12:41, 23 Jun 2006 (NZST)


Testing: Builds with warnings:

ListSpace.c:64: warning: conflicting types for 'setData'
ListSpace.c:27: warning: previous implicit declaration of 'setData' was here

Resulting binary:

Bus error

--Rob 11:22, 23 Jun 2006 (NZST)


Testing: Builds with some warnings:

ListSpace.c:64: warning: type mismatch with previous implicit declaration
ListSpace.c:27: warning: previous implicit declaration of `setData'
ListSpace.c:64: warning: `setData' was previously implicitly declared to return `int'

--Rob 22:47, 22 Jun 2006 (NZST)


So it builds ok now. I suggest we set up a simple set data structure and test that traverse() is working as it should. --Rob 18:45, 22 Jun 2006 (NZST)


There's an implementation of a linked list here which is done with structs instead --Nad 17:54, 22 Jun 2006 (NZST)


Re Error: ListSpace.c:31: warning: assignment makes pointer from integer without a cast

from statement subject = addr || (addr = insert());
this is the problem I thought would come up - we need to assign the content of address addr to subject, not the address itself.
This also applies to the addr = insert() part which is supposed to be storing the return int in the address of addr, not set the value. --Nad 17:32, 22 Jun 2006 (NZST)
Maybe use subject = *addr || *(addr = insert()); --Rob 17:44, 22 Jun 2006 (NZST)
No, * means to return a pointer to the thing, we need the thing being pointed to --Nad 17:51, 22 Jun 2006 (NZST)
Actually you're right - the * is also the dereference operator - so what you did should work... --Nad 17:56, 22 Jun 2006 (NZST)

Fixed syntax of #define. The = was screwing it up. No = required as this is a macro string substitution. --Rob 15:02, 22 Jun 2006 (NZST)

Right I see - it was because it only came across the faulty "=" when the const was accessed on line 11! (the clue was that the error said the "=" token, not operator) --Nad 15:53, 22 Jun 2006 (NZST)
Indeed, but of course it makes perfect sense now. Maybe there's some option that will display the source after macro processing but before compilation. So now i'm on to making pointers to pointers. Must not use int to hold pointers as they may be more bits than int. --Rob 16:29, 22 Jun 2006 (NZST)

Still to do:

  • include nodal reduction in a reduce() function as modeled in Peer-nodal.as. --Rob 18:33, 18 Jun 2006 (NZST)
  • this should really be a part of peer.c since it will also include nodal reduction etc