Hi.
(I'm not subscribed to this list, so please CC any replies to me.)
I just tried grx-2.4.3, and found a number of little things to fix and improve:
When building it, there are a few warnings because of some missing external declarations in some test programs and some unused variables in colors.pas. (diff0)
GRX_DEFAULT_FONT_PATH must be quoted (string in a C source file), and quoted again in the Makefile (which is eaten by the shell). (see diff1 -- this diff is only for the X11 target, and should probably be made similarly for the other ones). Alternatively, one could use preprocessor stringification in loadfont.c.
I suggest there to be an `install-fonts' target in the top level Makefile, so one doesn't have to chdir and call make in a subdirectory. (diff2 -- also only for X11)
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.
For the libraries linked, I suggest to add a case for the Linux console (though the default under Linux should be X11) and optional cases for libpng etc. (diff3).
I suggest to rename the Pascal `bgi2grx' unit to `Graph' (diff 4, then mv pascal/bgi/bgi2grx.pas pascal/bgi/graph.pas -- the further diffs assume this renaming), so it will be BP compatible and more natural to Pascal programmers.
demo.pas, allmodes.pas: GPC supports Str like BP, so the special case in MyStr is not necessary. sh_funcs.pas: Pi, PChar and Random have been built into GPC for a long time, so the declarations there are not necessary anymore. Furthermore, I suggest to move the remaining two declarations (KeyPressed, ReadKey) into graph.pas (perhaps conditionalized) because they'll be needed by many programs that use that unit (which would use CRT in BP), and they're external declarations of GRX routines, anyway. Then sh_funcs.pas can be removed entirely. (diff5)
In grx.pas (type GrColor) it says "MUST be 32bit". So I suggest to declare it accordingly. (diff6)
The handling of Pascal strings in C code is not recommendable because the internal format is likely to change in some future GPC version. It's also completely unnecessary since GPC supports (also for a long time) automatic conversion from Pascal to C strings, so simple external declarations of the C routines will work just fine (like it's already done for some newer routines, like TIFF and JPEG routines in this unit). This removes __gr_p_initgraph, __gr_p_textheight, __gr_p_textwidth, __gr_p_outtext, __gr_p_outtextxy, __gr_p_installuserfont, __gr_p_GPCstr and the files gpc_init.c, gpc_text.c. Also, instead of StrPas, the built-in and more efficient CString2String function can be used. (diff7)
The Pascal units should be installed from the Makefiles. (diff8)
Some argument type declarations (GrBuildPixmap, GrImageBuild, GrImageBuildUsedAsPattern, GrBuildCursor) in Pascal are, though correct, somewhat unfortunate (since pointers and arrays are not the same in Pascal). Also, grx.pas seems to be incomplete. I'm adding some of the missing routines (including PNM and PNG routines), but didn't check what more is missing. (diff9)
doc/readme.bgi says: "libbcc.h won't include GRX and pascal stuff any more; there's no Pascal support any longer, sorry". Are there any known serious problems with this Pascal interface currently, or is it just that no-one is willing to update it to future changes in GRX?
Frank
Frank Heckenbach escribió:
Hi.
(I'm not subscribed to this list, so please CC any replies to me.)
I just tried grx-2.4.3, and found a number of little things to fix and improve:
Thanks!
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.
Because I don't know Pascal I will commit the changes, but I will wait for comments from pascal users (Maurice, can you check it?)
doc/readme.bgi says: "libbcc.h won't include GRX and pascal stuff any more; there's no Pascal support any longer, sorry". Are there any known serious problems with this Pascal interface currently, or is it just that no-one is willing to update it to future changes in GRX?
This readme is quite old, some people had send patches to update the Pascal support before 2.4.3. Anyway the problem again is I don't know Pascal enough, so I can't update de Pascal interface myself.
Greetings, M.Alvarez
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.+
Because I don't know Pascal I will commit the changes, but I will wait for comments from pascal users (Maurice, can you check it?)
Relax. Franck knows better gpc than I do. He is one of the two chief maintainers
of gpc, I am only an user. Now I have applied all his patches to check if there is nothing particular in djgpp with respect to X11 (adding also the install-font target into the top level makefile.dj2). Everything is correct as expected. I have only a couple of comments and suggestions.
1) with respect to GRX_DEFAULT_FONT_PATH (diff1) The error was only in X11, djgpp case was working correctly, but used a different trick than that suggested by Franck, namely #GRX_DEFAULT_FONT_PATH=c:/grxfonts is not quoted in makedefs.grx, but CCOPT += -DGRX_DEFAULT_FONT_PATH="$(GRX_DEFAULT_FONT_PATH)" is escape quoted in src/makefile.dj2, to avoid the " being eaten by the shell as Franck indicated. I see no reason to choose, but be consistent.
2) the c:/grxfonts directory is not created if it does not exits: the attached diff10 does that.
3) Reading diff9, about differences in pascal between pointer and arrays, this is exactly the reason I had suggested changes in polygon functions in the bgi2grx (graph) interface (which were already applied). But the same error remains in the grx interface, where all polygon functions will not work as they are written. I have made the changes in grx.pas, and also written a new pascal/polygon.pas demo program, which is the translation to pascal of the test/polygon.c demo to check it. It includes the same way of giving the graphics parameters on the command line by typing e.g. polygon 1024 768 64k as all the c tests: test.pas is the equivalent of test.h, but without the uggly trick of creating a GRXmain which uses the test function as a callback function. Why do simple when you can do complex ? Or may be there is some c reason I do not understand. This is included in diff11 (to be applied after Franck's diffs), together with changes needed to all makefiles in the pascal directory.
Maurice
Maurice Lombardi escribió:
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.+
Because I don't know Pascal I will commit the changes, but I will wait for comments from pascal users (Maurice, can you check it?)
Relax. Franck knows better gpc than I do. He is one of the two chief maintainers
of gpc, I am only an user.
Thanks, Maurice
Please, can you resend the patches as a zip file? My mail client doesn't work well with text attachements.
as all the c tests: test.pas is the equivalent of test.h, but without the uggly trick of creating a GRXmain which uses the test function as a callback function. Why do simple when you can do complex ? Or may be there is some c reason I do not understand.
No, there is no reason. I think it was only to save retyping.
Regards, M.Alvarez.
(I've subscribed to this list now.)
Maurice Lombardi wrote:
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
The rest of this mail is referring to the Pascal interface. Since I'm one of the GPC maintainers, I'm mostly interested in that.+
Because I don't know Pascal I will commit the changes, but I will wait for comments from pascal users (Maurice, can you check it?)
Relax. Franck knows better gpc than I do. He is one of the two chief maintainers of gpc, I am only an user.
But I don't know GRX so well yet ... ;-)
Now I have applied all his patches to check if there is nothing particular in djgpp with respect to X11 (adding also the install-font target into the top level makefile.dj2). Everything is correct as expected. I have only a couple of comments and suggestions.
- with respect to GRX_DEFAULT_FONT_PATH (diff1) The error was only in X11, djgpp case was working correctly, but used a different trick than that suggested by Franck, namely
#GRX_DEFAULT_FONT_PATH=c:/grxfonts is not quoted in makedefs.grx, but CCOPT += -DGRX_DEFAULT_FONT_PATH="$(GRX_DEFAULT_FONT_PATH)" is escape quoted in src/makefile.dj2, to avoid the " being eaten by the shell as Franck indicated. I see no reason to choose, but be consistent.
I don't mind either way, and I agree that it should be consistent.
the c:/grxfonts directory is not created if it does not exits: the attached diff10 does that.
Reading diff9, about differences in pascal between pointer
and arrays, this is exactly the reason I had suggested changes in polygon functions in the bgi2grx (graph) interface (which were already applied).
Yes, I saw them and found that some programs of mine that use them which failed with older GRX versions work now.
But the same error remains in the grx interface, where all polygon functions will not work as they are written.
Indeed, I hadn't seen them.
I have made the changes in grx.pas, and also written a new pascal/polygon.pas demo program, which is the translation to pascal of the test/polygon.c demo to check it. It includes the same way of giving the graphics parameters on the command line by typing e.g. polygon 1024 768 64k
Works for me.
but without the uggly trick of creating a GRXmain which uses the test function as a callback function. Why do simple when you can do complex ? Or may be there is some c reason I do not understand.
I don't know which ugly trick you're referring to, but ISTK that the GRXMain stuff is needed on mingw (only?). Therefore I inserted the following in my GRX programs:
{$ifdef __MINGW32__} {$gpc-main="GRXMain"} {$endif}
Note that I don't use mingw myself; Nicola Girardi (who you probably also known from the GPC list) compiled the code for me, and it seems to work like this.
Or you pass --gpc-main=GRXMain on the command line, as the makefile.w32 does in GRX.
Even better it would be if the compiler directive as above could be in the GRX and Graph units rather than having to be given for each GRX program, but GPC doesn't support that yet -- it's on our todo list. Well, maybe it's not hard to do, actually; I'll look into it next week ...
This is included in diff11 (to be applied after Franck's diffs), together with changes needed to all makefiles in the pascal directory.
Just compiled GRX again with your diffs and had no problems.
Then, I tried to build GRX on Sparc/Solaris. Besides having to set -lsocket as noted, there were a few more problems:
- Building shared libs failed. This might be a local installation problem since I've had some problems with shared libs there before, but it might also be a matter of compiler/linker options (ISTR that the options required very from system to system, that's why libtool was invented, but I don't know much about libtool myself). For now, I just disabled shared libs by editing the makefiles, but I think this should be possible via makedefs settings (or is it possible, how?).
- test/bgi/bccbgi.c fails because it tries to include <pc.h> (on every platform except Linux and mingw, while it only exists on Dos, AFAIK). - same bug in test/bgi/fontplay.c - same bug in test/bgi/tellipse.c - same bug in test/bgi/tfill.c - same bug in test/bgi/tpoly.c - same bug in test/bgi/ttext.c (diff12)
- The install target(s) should created the directories (e.g. include, lib, info) before trying to write into them. This is particularly necessary when installing in a temp dir in order to build a binary distribution. (I didn't make a patch for that yet.)
- /etc/infodir seems to be hard-coded in the makefile. That's bad! (Not everyone is root. ;-) I strongly suggest this directory to be configurable, and to make the whole install-info stuff optional (or get rid of it at all -- something like @dircategory and @direntry in the texi file might be better, since it allows the system tools which (re)build the info directory to recognize it).
After working around these problems, however, I was able to build it and run the test programs and some of my Pascal programs successfully.
Another idea: How about a configure script for GRX? It could just make a copy or link of the respective makefile.foo to Makefile and set some options in makedefs from the command line. This way, it would be purely optional (i.e., the current way of building GRX would still work, but those who prefer ./configure && make (like me) could do that then).
If you don't reject the idea, I could probably write such a little script (only for X11, svgalib and perhaps DJGPP -- but I guess users on other platforms wouldn't expect to run configure, anyway (or mingw, maybe?).
Frank
Frank Heckenbach escribió:
Then, I tried to build GRX on Sparc/Solaris. Besides having to set -lsocket as noted, there were a few more problems:
- Building shared libs failed. This might be a local installation problem since I've had some problems with shared libs there before, but it might also be a matter of compiler/linker options (ISTR that the options required very from system to system, that's why libtool was invented, but I don't know much about libtool myself). For now, I just disabled shared libs by editing the makefiles, but I think this should be possible via makedefs settings (or is it possible, how?).
Not at this time, note that makefiles are valid/tested only for the four supported platforms. For the (few) people interested in compile GRX in other platforms the changes they must to do to makefiles are easy.
- test/bgi/bccbgi.c fails because it tries to include <pc.h> (on every platform except Linux and mingw, while it only exists on Dos, AFAIK).
- same bug in test/bgi/fontplay.c
- same bug in test/bgi/tellipse.c
- same bug in test/bgi/tfill.c
- same bug in test/bgi/tpoly.c
- same bug in test/bgi/ttext.c
(diff12)
Thanks
- The install target(s) should created the directories (e.g. include, lib, info) before trying to write into them. This is particularly necessary when installing in a temp dir in order to build a binary distribution. (I didn't make a patch for that yet.)
I'm not sure if we must do it.
- /etc/infodir seems to be hard-coded in the makefile. That's bad! (Not everyone is root. ;-) I strongly suggest this directory to be configurable, and to make the whole install-info stuff optional
Ok, but people who use the install target are suposed to be root anyway.
(or get rid of it at all -- something like @dircategory and @direntry in the texi file might be better, since it allows the system tools which (re)build the info directory to recognize it).
Sorry, I don't know well TexInfo to understand this.
After working around these problems, however, I was able to build it and run the test programs and some of my Pascal programs successfully.
Great!
Another idea: How about a configure script for GRX? It could just make a copy or link of the respective makefile.foo to Makefile and set some options in makedefs from the command line. This way, it would be purely optional (i.e., the current way of building GRX would still work, but those who prefer ./configure && make (like me) could do that then).
If you don't reject the idea, I could probably write such a little script (only for X11, svgalib and perhaps DJGPP -- but I guess users on other platforms wouldn't expect to run configure, anyway (or mingw, maybe?).
I don't like it. Stock DJGPP an Mingw users don't install "sh" and I like the simplicity of makefiles instead of configure scripts.
Greetings, M.Alvarez
Mariano Alvarez Fernandez wrote:
Frank Heckenbach escribió:
Then, I tried to build GRX on Sparc/Solaris. Besides having to set -lsocket as noted, there were a few more problems:
- Building shared libs failed. This might be a local installation problem since I've had some problems with shared libs there before, but it might also be a matter of compiler/linker options (ISTR that the options required very from system to system, that's why libtool was invented, but I don't know much about libtool myself). For now, I just disabled shared libs by editing the makefiles, but I think this should be possible via makedefs settings (or is it possible, how?).
Not at this time, note that makefiles are valid/tested only for the four supported platforms. For the (few) people interested in compile GRX in other platforms the changes they must to do to makefiles are easy.
Then you may want to change your web site which says: "On X11, it must work on any X11R5 (or later) system."
Of course, I'd consider this a bad choice, since it doesn't seem to take much to make it portable to non-Linux X11 systems.
- The install target(s) should created the directories (e.g. include, lib, info) before trying to write into them. This is particularly necessary when installing in a temp dir in order to build a binary distribution. (I didn't make a patch for that yet.)
I'm not sure if we must do it.
If you don't, then install will copy, say, grx.h to a file called include instead of a file grx.h in a (non-existing) directory include.
- /etc/infodir seems to be hard-coded in the makefile. That's bad! (Not everyone is root. ;-) I strongly suggest this directory to be configurable, and to make the whole install-info stuff optional
Ok, but people who use the install target are suposed to be root anyway.
IMHO a very unfortunate attitude, also known as "Linux arrogance". There are actually Unix systems where not every user is or can become root (like, e.g., me on our university's machines), and they might want to install things in their home directory (which works with GRX except for the hard-coded /etc in one place).
Besides, as I said, one might want to build a binary distribution ...
(or get rid of it at all -- something like @dircategory and @direntry in the texi file might be better, since it allows the system tools which (re)build the info directory to recognize it).
Sorry, I don't know well TexInfo to understand this.
Something like the following:
@dircategory Libraries @direntry * GRX: (grx). The GRX Graphics Library. @end direntry
Another idea: How about a configure script for GRX? It could just make a copy or link of the respective makefile.foo to Makefile and set some options in makedefs from the command line. This way, it would be purely optional (i.e., the current way of building GRX would still work, but those who prefer ./configure && make (like me) could do that then).
If you don't reject the idea, I could probably write such a little script (only for X11, svgalib and perhaps DJGPP -- but I guess users on other platforms wouldn't expect to run configure, anyway (or mingw, maybe?).
I don't like it. Stock DJGPP an Mingw users don't install "sh" and I like the simplicity of makefiles instead of configure scripts.
That's why I said it would be optional.
But I think we can only agree to disagree ...
Frank
Hi, Frank.
First, note that my english is very bad, so I can't explain myself well. If you find any rude expression it's no my intention, it's my bad english.
Frank Heckenbach escribió:
Not at this time, note that makefiles are valid/tested only for the four supported platforms. For the (few) people interested in compile GRX in other platforms the changes they must to do to makefiles are easy.
Then you may want to change your web site which says: "On X11, it must work on any X11R5 (or later) system."
Of course, I'd consider this a bad choice, since it doesn't seem to take much to make it portable to non-Linux X11 systems.
I tried to mean thant I can't maintain makefiles for other plattforms, because I can't check it. Note the complete sentence is "On X11, it must work on any X11R5 (or later) system after a few changes to makefiles". I think is correct.
Nevertheless if changes don't affect the supported palttforms, they will be welcome.
- The install target(s) should created the directories (e.g. include, lib, info) before trying to write into them. This is particularly necessary when installing in a temp dir in order to build a binary distribution. (I didn't make a patch for that yet.)
I'm not sure if we must do it.
If you don't, then install will copy, say, grx.h to a file called include instead of a file grx.h in a (non-existing) directory include.
Ok, my doubts was about the convenience to expand the /usr/local tree without user permission.
- /etc/infodir seems to be hard-coded in the makefile. That's bad! (Not everyone is root. ;-) I strongly suggest this directory to be configurable, and to make the whole install-info stuff optional
Ok, but people who use the install target are suposed to be root anyway.
IMHO a very unfortunate attitude, also known as "Linux arrogance". There are actually Unix systems where not every user is or can become root (like, e.g., me on our university's machines), and they might want to install things in their home directory (which works with GRX except for the hard-coded /etc in one place).
Ops! I wanted to mean, that the automatic install target is normally for the superuser, normal users can move by hand the four files to the location they want (and the readme file says what files to move). And the console linux target don't work at all if you are not supersuser, because it uses svgalib.
Really I'm not a linux advocate, my main plattform is DJGPP (and Mingw now), when I began maintaining GRX (because no one wanted to do it) I must to learn how to work with Linux. My work enviroment is HP-UX, but because I maintain GRX in my free time at home, this was not an option.
Besides, as I said, one might want to build a binary distribution ...
(or get rid of it at all -- something like @dircategory and @direntry in the texi file might be better, since it allows the system tools which (re)build the info directory to recognize it).
Sorry, I don't know well TexInfo to understand this.
Something like the following:
@dircategory Libraries @direntry
- GRX: (grx). The GRX Graphics Library.
@end direntry
Ok, thanks, where we must leave the info file?, what utility must the user run after?
Greetings, M.Alvarez
-
Frank Heckenbach -
Mariano Alvarez Fernandez -
Maurice Lombardi