Gpc July 2005

gpc@gnu.de

25 participants
67 discussions

ICE when compiling ncurses demo program with -O1
by Adriaan van Os 29 Jul '05

29 Jul '05

Compiling <http://www.microbizz.nl/ncurses-20050730.tar.gz> with -O1 causes an ICE on Mac OS X. [G5:~/Desktop/ncurses-gpc-20050730] adriaan% gp firework.pas -O1 /Users/adriaan/Desktop/ncurses-gpc-20050730/ncurses.pas:178: warning: identifiers should not start with an underscore /Users/adriaan/Desktop/ncurses-gpc-20050730/firework.pas: In main program: /Users/adriaan/Desktop/ncurses-gpc-20050730/firework.pas:146: error: insn does not satisfy its constraints: (insn 951 991 952 2 (set (reg:DI 63 f31 [157]) (mem/u/f:DI (lo_sum:SI (reg/u:SI 2 r2) (const:SI (minus:SI (symbol_ref/u:SI ("*LC16") [flags 0x2]) (symbol_ref:SI ("<pic base>"))))) [0 S8 A64])) 325 {*movdi_internal32} (nil) (expr_list:REG_EQUIV (const_int 2 [0x2]) (nil))) /Users/adriaan/Desktop/ncurses-gpc-20050730/firework.pas:146: internal compiler error: in reload_cse_simplify_operands, at postreload.c:391 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu-pascal.de/todo.html> for instructions. [G5:~/Desktop/ncurses-gpc-20050730] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc344d2/lib/gcc/powerpc-apple-darwin7/3.4.4/specs Configured with: ../gcc-3.4.4/configure --enable-languages=pascal,c --enable-threads=posix --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 --build=powerpc-apple-darwin7 --prefix=/Developer/Pascal/gpc344d2 Thread model: posix gpc version 20050331, based on gcc-3.4.4 Regards, Adriaan van Os

1 0

installation if units DOS and CRT
by J.N.J. van Lingen 27 Jul '05

27 Jul '05

Hello, I just compiled GPC on a dual opteron machine for a friend and it works fine. However my friend wants to use his old sources which use the units crt and dos. These are not included in this installation, while they were there in a earlier windows version he used to use. Can anybody tell me how to get these units up and running? Thanks in advance Joost van Lingen Theoretical Chemistry Group Utrecht University The Netherlands

2 3

Re: Packing strings ()
by Frank Heckenbach 27 Jul '05

27 Jul '05

Contestcen(a)aol.com wrote: > > Not again please!!! Peter himself made it explicitly clear that he > > asked for runtime storage (which was clear to all of us except you > > from the beginning). > > I suggested the macros once, at the very beginning of this thread. As soon > as it became clear that he wanted run-time macros, I made suggestions for that > case. I never again suggested the static solution. However, it keeps coming > up because people keep claiming that I am off the topic. Are you lying intentionally, or don't you even know what you wrote? Below are several mails of yours that all talk about static storage, as late as two weeks after the initial question. Note that in the last and 4th-last of these quoted excerpts, you actively try to bring the subject "back" to static storage. Actually, these mails mention the "Pascal Macro Compiler" so often, even after it was clear (as you say) it's off-topic, it's close to spamming! Sure, some of these mails are to answer questions and criticism by others, but if it really was clear to you it was off-topic, you could have said: "Sorry, I misunderstood the question. The Pascal Macro Compiler is not useful for this purpose.", instead of carrying on a pointless discussion and annoying everybody. : Date: Thu, 7 Jul 2005 02:46:38 EDT : The Pascal Macro Compiler has a set of macros that will pack character : strings without any wasted space between them The macros can be downloaded directly : from the webpage http://www.contestcen.com/paskey.htm which has both the : source code and a detailed description. : Date: Fri, 8 Jul 2005 02:51:10 EDT : I assumed that the strings were being stored at runtime because storing them : end-to-end at compile time was too tedious. If there is a static set of : strings, then the Pascal Macro Compiler can store them without any wasted space. : Date: Mon, 11 Jul 2005 13:37:35 EDT : Conclusion: If the strings are known at compile time, the most efficient way : to store them without gaps is to use the Pascal Macro Compiler. : Date: Wed, 13 Jul 2005 02:57:37 EDT : Whether you choose to align the length field on an integer-size boundary or : not is a decision you could make based on a time versus space trade-off. The : macros that I have written happen to store the strings with no gaps at all, and : do not do any alignment. If you decided that for your application and : platform aligning the strings was better, then you would not use my macros, you : would write your own macros, or modify my macros to align the strings. The Pascal : Macro Compiler is a general-purpose preprocessor, and can align or not align : as the user wishes. : Date: Wed, 13 Jul 2005 03:07:05 EDT : Using the Pascal Macro Compiler you can store the strings with no gaps and no : wasted space whatsoever. I don't see how you can improve on that. : Moreover, the method requires no code, makes no calls, and takes no time at : run time. I don't see how you can improve on that. : Date: Thu, 14 Jul 2005 02:07:45 EDT : This may be true for executable code generated by the Pascal Macro Compiler, : but it is not true for the data declarations that are generated for the packed : strings. There is no executable code involved, so the compiler has nothing : to optimize. : There is no wasted space, so there is nothing that can be improved. : Date: Thu, 14 Jul 2005 03:18:40 EDT : The prologue of these macros says, "This version is intended mainly as a : demonstration." It is an example designed to illustrate some of the features and : capabilities of the Pascal Macro Compiler. Users who do not need alignment : can use the macros as provided. Users who need alignment can easily add that : feature to the macros. : If there are any requests from bona fide users of the Pascal Macro Compiler : for an alignment feature, then I will be glad to add it. : Date: Sun, 17 Jul 2005 02:16:49 EDT : That's very nice. However, please recall that I said the main reason for : using a character array instead of a string is because I needed more than 255 : characters. So, having a better way to initialize a character array of up to 255 : characters doesn't help me. If I only wanted 255 characters I would have : used a string in the first place. : Date: Mon, 18 Jul 2005 02:13:55 EDT : My understanding from the original post is that he wanted the strings stored : as given, not compressed. The macros simply store the strings end-to-end : without any gaps. However, the macros would work equally for compressed strings, : assuming they have the same form, namely length field and data string. : If you want the entire body of strings compressed as a unit, then you could : use the macros to create the concatenation of all the individual strings, and : compress the result. It would be up to you to devise methods for accessing the : strings within the compressed mass. : Date: Tue, 19 Jul 2005 02:47:42 EDT : In any case, we are getting off the subject, which was how to store a set of : varying-length strings with minimal wasted space. The method that I : suggested, using the Pascal Macro Compiler, uses no wasted space at all. : Date: Tue, 19 Jul 2005 03:12:02 EDT : The Pascal Macro Compiler could certainly generate code for accessing the : strings, however the Keyword String macros do not generate access code; they : generate data structures. : Date: Thu, 21 Jul 2005 00:55:11 EDT : If you need to initialize a character array greater than 255 chars in BP, you : can resort to using absolute. : Date: Thu, 21 Jul 2005 16:23:31 EDT : The subject of this thread in the GPC mailing list is how to store : character strings without wasted space. Notive that the subject of this thread is : "Packing strings ()" That was the subject of the original posting that : started the thread. : I have mentioned the Pascal Macro Compiler because it comes with macros : that have the ability to pack strings without wasted space. That is the : original question, and this is an appropriate answer to the question. I have not : discussed the Pascal Macro Compiler in any other context except to answer the : question in this thread. > My answer about compile-time storage was long ago. This thread has moved > beyond that into other aspects of storage management and data access. I have > since suggested allocating storage as a set of extension blocks, and as a single > block that gets copied when it overflows. I have moved on from compile-time > storage. See above. Your mails speak a different language. > So let me remind you of another topic that got raised, namely perfect > hashing. You suggested the use of gperf, a program which I read about many years > ago, but had forgotten. The reason I ignored gperf is that I think it can work > only for very easy sets of keywords, and it will fail badly for hard sets, even > if they are fairly small. I proposed that you and I test gperf on some > harder keyword sets. Are you willing to try this? There's one thing you're really good at -- causing other people work. First you make us explain you how email works and basic netiquette rules again and again and again, now you want *us* to test gperf. Can't you do it yourself? Create those data sets you're concerned with, produce gperf output, look at applicable gperf options, and comment on the results, perhaps comparing them with other programs, then present us your results. As this is a bit off-topic on this list, better put them on your web site and post a pointer to the site here. > > Really not. Unfortunately, the main archives are still offline (but > > you might be able to find mirrors through Google). There you'll see > > that few, if anyone, had so many initial problems. Some did an HTML > > posting or strange quoting in their initial mail, but after a > > friendly reminder, they changed it. You're probably the first one > > who seems to need a majority vote of all list subscribers to > > convince you (would 2/3 of all who ever posted to the list be enough > > for you, counting abstentions as negative votes? ;-), and constantly > > ignores all pointers to standard netiquette (including numerous ones > > in private mail, I must add). > > I am not trying to ignore or flout the requests for non-HTML postings. In > fact, I have gone to a good deal of effort to try to find ways of minimizing or > eliminating the HTML in my postings. > > The net result is that I have been unable to find any control that will turn > off the HTML, So, if you apparently realized by now that non-HTML mail is common practice, and your can't find a way to do this simple thing in your mailer, what does this tell you about your mailer? Either it's crap or it's poorly documented so even basic settings are hard to find. (You did read the documentation, didn't you?) > and I have not yet found another mailer that has that ability. > None of the people who have been corresponding with me offline have been able > to tell me what mailer could work. What twisted form of argument is this? After people online (such as Emil Jerabek and me) have repeatedly pointed you to alternatives, your excuse now is that people you correspond with *offline* don't know better answers!? (Perhaps that's why they correspond offline. ;-) What's next? If some of them happens to send you a postcard naming another mailer, are you going to claim your cat and dog couldn't tell you one??? > I don't know the features of other > mailers, and the descriptions I have seen on the Internet never mention an HTML-free > option. Perhaps because it's so obvious they don't bother to mention? When you're buying a car, do you only look at advertisements that point out that is has several wheels and an engine??? To repeat, plain text mail is the default. MIME is an EXTENSION (the E in MIME really stands for extensions!) to encode other formats into plain text. So every mailer that sends MIME must ultimately be able to send plain text mails. And all except perhaps a few extremely perverse ones don't hide this fact from the user. Frank -- Frank Heckenbach, frank(a)g-n-u.de http://fjf.gnu.de/ GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)

1 0

Cryptic runtime error
by Pascal Viandier 26 Jul '05

26 Jul '05

Hi, I am currently converting many SUN Pascal programs to GPC (on Solaris for now). I must say, the operation goes pretty well for now (with the help of a Perl translation program I build progressively when I encounter syntax issues). In this context, the first time I ran my second translated program, I got the following runtime error: run.shell: Value out of range (error #300 at 4692b) Here comes my point: - That is true, there was an error, but I had to browse the code a lot to find it! - With such a message, is there a way to find out where the faulty code is? - What means the 4692b (an address in hex?)? - Is it feasible to implement (in a future release) more explicit error messages, like 'run.shell: Value out of range in run.shell.pas, line 1229' for example, when the program is compiled with -o0 and -g options? Anyway, I would greatly appreciate a hint for the next time I will have such a runtime error. Thanks Pascal Viandier

2 3

No HTML here, please
by Contestcen＠aol.com 25 Jul '05

25 Jul '05

> I would encourage that, but please don't just dump HTML messages, > bounce them with the specific reason. That might improve the > breed. I looked at some of my emails to this mailing list, and I found the following HTML tags: a few standard tags at the front to establish that it was an HTML message, and to start the body. A BR tag at the end of each line in the body of the text, and some DIV tags where I skipped lines. Then I looked at your email, this one where you complained that I was using HTML. I found the following HTML tags: a few standard tags at the front to establish that it was an HTML message, and to start the body. A BR tag at the end of each line in the body of the text. The only difference was that there were no DIV tags. However, there was still pretty much one tag for every line in the file. In this forum, people apparently prefer > signs at the start of each line of quoted text. In fact, some people insist on that. You might not realize this, but those line divisions are achieved by using BR tags. As far as I can see, roughly the same amount of HTML is generated in your emails as in my emails. I can make it exactly equal by not skipping any lines. Would you prefer that? Would it be easier for you if my answers were always in a solid block of text without any blank lines separating paragraphs? Let me give that a test. Here is my answer repeated without the blank lines: I looked at some of my emails to this mailing list, and I found the following HTML tags: a few standard tags at the front to establish that it was an HTML message, and to start the body. A BR tag at the end of each line in the body of the text, and some DIV tags where I skipped lines. Then I looked at your email, this one where you complained that I was using HTML. I found the following HTML tags: a few standard tags at the front to establish that it was an HTML message, and to start the body. A BR tag at the end of each line in the body of the text. The only difference was that there were no DIV tags. However, there was still pretty much one tag for every line in the file. In this forum, people apparently prefer > signs at the start of each line of quoted text. In fact, some people insist on that. You might not realize this, but those line divisions are achieved by using BR tags. As far as I can see, roughly the same amount of HTML is generated in your emails as in my emails. I can make it exactly equal by not skipping any lines. Would you prefer that? Would it be easier for you if my answers were always in a solid block of text without any blank lines separating paragraphs?

6 9

GP creates unresolved links when compilation is done using GP
by Igor Marnat 25 Jul '05

25 Jul '05

Hello Peter, >>I have the main program file program.pas, it uses >>a few units unit1.pas, unit2.pas, ... After the compilation process is >>finished, file program.o contains unresolved links to the functions >>init_Unit1, init_Unit2, ... PNL> gp will create each of the .o files for each unit, it PNL> unit1.o, unit2.o, program.o PNL> unit1.o will include the init_Unit1 function. PNL> You then need to link them all together. Well, this is the problem: unit1.o doesn't contain the function init_Unit1. Therefore unresolved link to init_Unit1 in program.o cannot be resolved. This is the difference from program.o compiled with "arm-elf-gpc --autobuild ..." command line. Program.o compiled in such a fashion doesn't contain unresolved link to init_Unit1. The file program.o compiled with "gp PC=arm-elf-gpc ... " does contain the link to init_Unit1 that cannot be resolved. In the both cases the same arm-elf-gpc compiler is used. Regards, Igor Marnat mailto:marny@rambler.ru

1 0

Re: unit dependencies (about GPC compiler internals)
by Igor Marnat 25 Jul '05

25 Jul '05

AvO> There are known problems with --autobuild and --automake. Anyway, since AvO> these options will be deprecated in the near future, try "gp" AvO> (<http://fjf.gnu.de/>) instead. Adriaan, thank you very much! It works ... partially:) It works fine with my native gpc compiler (it is of version "gpc version 20050217, based on gcc-3.4.3"). I'm also forced to use cross compiler (for arm-elf- target). Here is the problem. More detailed: I have the main program file program.pas, it uses a few units unit1.pas, unit2.pas, ... After the compilation process is finished, file program.o contains unresolved links to the functions init_Unit1, init_Unit2, ... Some of the units don't have such a functions. It is the units that don't have the code that is executed on unit initialization time. So these references cannot be resolved and build process stopped with error. Is it possible that the problem is caused by my cross compiler which is a bit old? (my arm-elf-gpc is "gpc version 20030830, based on gcc-3.3.1"). Actually, I'm confused because this very compiler can build the project if it is called in another way. When build process is inited in "arm-elf-gpc --autobuild ..." fashion (an old fashion), there is no program.o file in current directory - compiler builds main program object file in a temporary directory and all works fine (obviously, it doesn't add links to non-existing functions). When build process is inited as "gp PC=arm-elf-gpc ..." (a new fashion), there is program.o file in current directory which contains unresolved links. waiting for any ideas, Regards, Igor Marnat mailto:marny@rambler.ru

2 1

Re: New as function
by Peter N Lewis 25 Jul '05

25 Jul '05

> > Peter N Lewis wrote: > > > Does New as a function return nil or does it still give a runtime error? >> > >> > If I want to allocate memory, but handle it gracefully if it fails, > > > what are the recommended approaches? >You could also trap runtime errors, using `AtExit', or use the >`Trap' unit (which does this internally). This comes somewhat closer >to exception, though it's not quite the same. Indeed, this may be >the best solution available. It's a bit code to write, but it uses >`New' and has no disadvantages in this regard. Ok, it's an interesting approach, but I'd have to write that code for each type, which is still pretty ugly. I just checked, and if New returns nil (using the UndocumentedReturnNil for example), the compiler will blindly try to Initialize the returned data, and bus error. I'm not sure if this counts as a bug, since presumably UndocumentedReturnNil is only suppose to be for BP compatibility, and with BP compatibility there would be no Schema and thus no initialization. Unless perhaps BP has objects, in which case, New(obj) which returned UndocumentedReturnNil would probably have the same bus error issue. It's a shame, as this would be the best solution (documenting UndocumentedReturnNil and allowing GetMem to return it). I'd love to start using New and Schema and such, but the best solution seems to be the Trap technique and that's some ugly code to have any place you want to use New and not crash out. I guess I can stick to using the system NewPtr routine and manually calling Initialize, but that doesn't mesh will with Schema. I did think of another hack, which was to pre-allocate a chunk of memory larger than the largest New command, and then have GetMem return that for failure, then rather than testing for nil, I could test of that safe return value. It's ugly, but probably the simplest solution that provides clean New code. Peter. -- <http://www.stairways.com/> <http://download.stairways.com/>

4 20

Pascal in .ar prisons + xlate Pascal to Spanish
by Nicolas Rosner 25 Jul '05

25 Jul '05

Hi. I just sent an email [see below] to Florian from the Free Pascal team. Then I found out about GNU Pascal, and thought this list might be another good place to ask. Any pointers to i18n or related efforts that could be of any use to us are most welcome. TIA, I look forward to hearing from you, N. ------ Hello! I'm involved in a project called "UBA 22" where we teach basic computer skills to inmates of local (Buenos Aires, Argentina) prisons. It's a difficult task, the penitentiary service tolerates but hardly helps us, state support is scarce, etc. At the prison where I used to teach until recently (SPF U2, "Devoto"), we had five almost-falling-apart 486s and one Pentium 1 or so, for a very high demand of students (nearly 800 interested per term, of which nearly 200 are admitted). We teach the basics, from "what is a computer" to Windows usage, MS Office tools, etc. During the last couple of years I've been thinking about setting up a newer, more advanced course for the few inmates who survive the 3 or 4 basic ones. I'd like to teach a very basic intro to programming. Pascal seems like a decent language for this (there are better options, but each has its own cons [no pun intended]). Anyway, I've been looking for a compiler, but there's a big language problem -- most of our students hardly read or write in Spanish, let alone anything in English. "Begin", "While" and "For" don't mean anything to them. So my aim is to find - a free pascal compiler for DOS, Windows and Linux on Intel hardware - which {already is || can easily be} translated to Spanish where by "translated" I mean - basic language keywords - basic lib elements (nothing very specific, just basic i/o, etc.) - basic compiler and linker output More advanced / obscure stuff might very well be in English. I can translate, I have no problem with that. But I need the right product, a license that allows for this, and any reasonably simple method in order to find the strings and replace them with Spanish equivalents. Do you think FP [GPC] would be a good option? Any input will be very welcome. Thanks a bunch IA & greetings from Buenos Aires. Nicolás Rosner Departamento de Computación Facultad de Ciencias Exactas y Naturales Universidad de Buenos Aires Argentina

2 1

(no subject)
by Contestcen＠aol.com 24 Jul '05

24 Jul '05

> Does New as a function return nil or does it still give a runtime error? > > If I want to allocate memory, but handle it gracefully if it fails, > what are the recommended approaches? In BP there is a HeapError variable which points to the default error procedure. You can reset it to point to your own error procedure and handle the error however you like. I don't know if this works with other Pascal compilers. Frank Rubin

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc July 2005