Re: [Pipmak-Users] Compiling pipmak

[Christian W. <cwa...@gm...>]

Hi Andrea, it seems you're making progress faster than I can answer your 
questions! :) Some of the answers below are probably obsolete after your 
"Unofficial Release of Pipmak Build 155 for Win32" announcement (which 
I'll have a look at later today, hopefully), but since I've already 
written them I though I might as well send them.

> "Error running enternode handler:
> 1/node.lua:6: calling 'message' on bad self (node expected got table)"
> 
> "Error running Lua file resources/defaults.lua:275:
> calling 'setstandardcursor' on bad self (node expected got table)"

Interesting. Nodes are represented in Lua by tables, but they have a 
metatable, containing all the node methods, that identifies them as 
nodes (Lua's way of implementing a "class"). That metatable seems to be 
there, or it wouldn't even find the method. So it seems that there's 
something wrong in the code that checks for the metatable. That's the 
function checkinstanceof() in pipmakLuaLib.c, called from 
nodeMessageLua() and nodeSetstandardcursorLua() (and others).

> "I'm not sure what you mean by that. 
> There's no function "enternode()" in the C code..."
> 
> It's defined in the file nodes.c
> 
> CNode *enterNode(int nodeID, CNode *prev) 

Oops. Seems my brain (and my search dialog in Xcode) was in 
case-sensitive mode... :)

So, your infinite loop is most probably caused by enterNode() trying to 
load node 0 (the main menu) after loading the first node fails, which 
fails as well and causes another recursive call, etc. Normally we just 
assume that node 0, which is shipped with Pipmak, will load without 
errors. Perhaps a check could be added for that...

> "L" isn't passed: is it global?

Yes, it's the Lua state that's used in every call into Lua. Declared in 
main.c (as are all globals, IIRC).

> I have had to change your code a little:
> 
> 1) Seems that Microsoft Visual C++ don't permit variable definition
> in the middle of blocks {}, but only at the beginning...
> It's very strange, because I remember that the possibility to
> define new variable everywhere instead at the beginning of the block
> was one of the differences of the C++ from C language...

Yes, that's right, and apparently VC++ knows that these files should be 
compiled as C, not C++. This is just sloppy coding on my part. I could 
probably find these too by enabling more warnings in GCC, but if you 
have a patch handy to fix them, I'll gladly apply it.

> 2) I found M_PI in math.h, but it's included 
> in a #ifdef _USE_MATH_DEFINES 
> 
> the remark tell: 
> 
> /* Define _USE_MATH_DEFINES before including math.h to expose these macro
>  * definitions for common math constants.  These are placed under an #ifdef
>  * since these commonly-defined names are not part of the C/C++ standards.
>  */

Interesting. I didn't know that.

> 3) There is also boring warning messages about deprecation of 
> function strcpy, and similar functions, 
> 
> so I have to define:
> _CRT_SECURE_NO_DEPRECATE 
> _CRT_NONSTDC_NO_DEPRECATE

According to MSDN, strcpy is deprecated because it can be involved in 
buffer overruns. Oh well. It can't hurt double-checking the code for 
this, but usually when I say strcpy I mean strcpy. Silencing that 
warning is probably the most sensible thing to do.

> 4) in pipmak_windows.c :
> 
> #ifdef WIN32
> #define snprintf _snprintf
> #endif
> 
> because I not found "snprintf"  but only "_snprintf"

Right. I should probably re-check all occurrences of this because 
Windows' _snprintf isn't C99 compliant (it returns -1 instead of the 
required length if there's not enough space).

> I am a little perplexed about this use:
> 
> File pipmakLuaLib.c, line 297 (build 155)
> 
>    char *path = newProjectPath();

That's a special case for pointer declarations with initialization, I 
agree it's a bit confusing. It's really path, not *path, that gets 
initialized here. The line is equivalent to

   char *path;
   path = newProjectPath();

Perhaps writing it

   char* path = newProjectPath();

would be less confusing (but I'm in the habit of sticking the asterisk 
to the variable name, not the type, because in most other cases this 
makes more sense in C).

> 6) What do you think about a file "pipmak.h" included in all ".c" files,
> To have a place where add definition for all the file?

Such a file exists, it's called "config.h".

> I have understood that x=..,y=.. were in alternative to nx=..,ny=..,nz=..
> It's true?
> 
> because I have to define always x and y?
> (but the values are ininfluent...) or I get the error:
> 
> "property "x" of patch: number expected got nil"

Oops, that's someting I forgot to adapt. Fixed in r156, thanks for 
catching this. As you can see I haven't tested this stuff very 
thoroughly yet...

> I cannot specify size without specifying font file?

Yes. There would be no speed benefit in doing it differently because 
SDL_ttf has to open the font file again anyway to render in a different 
size, so it's only the slight inconvenience of having to write 
"../resources/Vera.ttf". Besides, there would be a conflict between the 
"size" and "align" arguments if I would make the "font" argument 
optional - I can tell "font" and "align" apart because one is a string 
and the other a number, but "size" and "align" are both numbers.


  -Christian