Re: [fpc-pascal] Windows 64 bit
Eugene Mayevski wrote: > Hello! > > I downloaded 64-bit toolset in April (afair). Is there any new version > available? No, but building them from source is no problem. > Also, is it possible to deploy the pre-compiled tools in 32-bit format? It > can be run in Windows 64-bit easily, and at the same time 32-bit format > would let one do cross-compilation. See above :) > > Sincerely yours, > Eugene Mayevski > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
Steve Williams wrote: Michael Van Canneyt wrote: Which is why I think that it's better to have them as local functions, instead of having to introduce a lot of new functions. Local functions are very pascal-ish. C doesn't have it, which is why they can't use it. Let's use the language features to their full extent. *procedure* SubTask(*var* x : *array of* Float); *var* /// Variables declared here have /|*private*|/ context./ iam : Integer; nt : Integer; ipoints : Integer; *parallel* iam := OMP.Get_Thread_Num; /// OMP library calls./ nt := OMP.Get_Num_Threads; ipoints := Length (x) *div* nt; /// size of partition/ istart := iam * ipoints; /// starting array index/ *if* iam = Pred (nt) *then* ipoints := Length (x) - istart; /// last thread may do more/ SubDomain (x, istart, ipoints); *end*; Wouldn't it be better to write it like this: procedure SubTask(var x: array of Float); parallel; var ... begin ... end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Wednesday 26 July 2006 10:05, Andreas Berger wrote: > Steve Williams wrote: > > Michael Van Canneyt wrote: > >> Which is why I think that it's better to have them as local > >> functions, instead of having to introduce a lot of new functions. > >> > >> Local functions are very pascal-ish. C doesn't have it, which is > >> why they can't use it. > >> Let's use the language features to their full extent. > > > >*procedure* SubTask(*var* x : *array of* Float); > >*var* > > /// Variables declared here have /|*private*|/ context./ > > iam : Integer; > > nt : Integer; > > ipoints : Integer; > >*parallel* > > iam := OMP.Get_Thread_Num; /// OMP library calls./ > > nt := OMP.Get_Num_Threads; > > ipoints := Length (x) *div* nt; /// size of partition/ > > istart := iam * ipoints; /// starting array index/ > > *if* iam = Pred (nt) *then* > >ipoints := Length (x) - istart; /// last thread may do more/ > > SubDomain (x, istart, ipoints); > >*end*; > > Wouldn't it be better to write it like this: > procedure SubTask(var x: array of Float); *parallel*; > var >... > begin >... > end; Actually no. I thought about it, but I didn't get through all that stuff yesterday evening or else I would have updated the WiKi already. The problem I see is that the parallel directive has more meanings (basically it is the main directive). For that reason, I wouldn't want to put in on the callee, but rather on the caller. I think it would also be easier for the compiler then to detect alls those parallel regions. Let's see. Anyway, there was already more response I would have expected after the days of silence. :) Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
Vinzent wrote: > .. According to the documentation, the size of the > local variables (allocated on the stack) should not exceed 32 KiBytes > for portability reasons. Thanks a lot. And I thought, I did RTFM often enough ... BTW, do you know why exceptions donŽt return a line number? As I understand it, the except clause can return everything I want, when an exception occurs. I wished the compiler would throw the line number in addition to e.Classname and e.Message automatically. Wolfram ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
On Thursday 27 July 2006 12:05, Wolfram Kläger wrote: > Vinzent wrote: > > .. According to the documentation, the size of the > > local variables (allocated on the stack) should not exceed 32 > > KiBytes for portability reasons. > > Thanks a lot. And I thought, I did RTFM often enough ... > > BTW, do you know why exceptions donŽt return a line number? Because you forgot to include the "-gl" switch for automatically including the line info unit? If you do that, the backtrace usually consists of procedure names and line numbers instead of just addresses. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
2006/7/27, Vinzent Hoefler <[EMAIL PROTECTED]>: On Wednesday 26 July 2006 10:05, Andreas Berger wrote: > Steve Williams wrote: > > Michael Van Canneyt wrote: > >> Which is why I think that it's better to have them as local > >> functions, instead of having to introduce a lot of new functions. > >> > >> Local functions are very pascal-ish. C doesn't have it, which is > >> why they can't use it. > >> Let's use the language features to their full extent. > > > >*procedure* SubTask(*var* x : *array of* Float); > >*var* > > /// Variables declared here have /|*private*|/ context./ > > iam : Integer; > > nt : Integer; > > ipoints : Integer; > >*parallel* > > iam := OMP.Get_Thread_Num; /// OMP library calls./ > > nt := OMP.Get_Num_Threads; > > ipoints := Length (x) *div* nt; /// size of partition/ > > istart := iam * ipoints; /// starting array index/ > > *if* iam = Pred (nt) *then* > >ipoints := Length (x) - istart; /// last thread may do more/ > > SubDomain (x, istart, ipoints); > >*end*; > > Wouldn't it be better to write it like this: > procedure SubTask(var x: array of Float); *parallel*; > var >... > begin >... > end; Actually no. I thought about it, but I didn't get through all that stuff yesterday evening or else I would have updated the WiKi already. The problem I see is that the parallel directive has more meanings (basically it is the main directive). For that reason, I wouldn't want to put in on the callee, but rather on the caller. I think it would also be easier for the compiler then to detect alls those parallel regions. Let's see. Anyway, there was already more response I would have expected after the days of silence. :) What about the same approach as the class procedures? Actually we have in a class the possibility to: class procedure MyProc; class function MyFunc: Integer; Then we could very simply have: parallel procedure ParallelBlock; parallel function ParallelFunction; //if this can happen... Also, I read that in example 1: "Variables declared here should have shared context." In fact by default they have private context and to me it looks like more normal. Maybe we should have a way to do the contrary: specify that a variable has shared context... What others think? -- Alexandre Leclerc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
Vinzent wrote: > > BTW, do you know why exceptions donŽt return a line number? > > Because you forgot to include the "-gl" switch for automatically > including the line info unit? As I understand it, this option is only helpful when you are struggling with the debugger. My question is: What is the problem to throw the line number on the console as well as e.message, e.classname and everything else specified in the except clause, e.g. the contents of a local variable named LastLineDone? Wolfram ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
On Thu, 27 Jul 2006, Wolfram Kläger wrote: Vinzent wrote: BTW, do you know why exceptions don?t return a line number? Because you forgot to include the "-gl" switch for automatically including the line info unit? As I understand it, this option is only helpful when you are struggling with the debugger. No. It is also meant for adding more information to the exception backtrace. My question is: What is the problem to throw the line number on the console as well as e.message, e.classname and everything else specified in the except clause, e.g. the contents of a local variable named LastLineDone? Because you need the debug information for that. Hence the -gl switch. It adds a HUGE amount of data to your executable, which is why it is not included by default. FileName/Linenumber info is only available through debug information. It's not an interpreted language, but compiled language. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
Am Donnerstag, 27. Juli 2006 15:15 schrieb Wolfram Kläger: > Vinzent wrote: > > > BTW, do you know why exceptions donŽt return a line number? > > > > Because you forgot to include the "-gl" switch for automatically > > including the line info unit? > > As I understand it, this option is only helpful when you are > struggling with the debugger. My question is: What is the problem to > throw the line number on the console as well as e.message, > e.classname and everything else specified in the except clause, e.g. > the contents of a local variable named LastLineDone? The program needs to *know* the linenumber, otherwise it can't tell you. That's what option -gl is for: include linenumbers into executable. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Common OpenMP syntax?
On Thursday 27 July 2006 12:53, Alexandre Leclerc wrote: > Then we could very simply have: > parallel procedure ParallelBlock; > parallel function ParallelFunction; //if this can happen... Yes. I thought of something like that, because it could quite easily match with a "parallel for" construct. That's why I don't like the idea of a function modifier. But pleeeaaase, people. This was only one single and little example and it's not nearly close to what the spec says. It just scratched the surface of it. So it's a bit early to hang on this only parallel keyword in that particular example. In the end, *all* constructs should nicely match together. What about those "parallel section" and "parallel workshare" constructs? The latter bothers me a lot (section might prove to be quite easy) plus all the /parameters/ those stuff can have: You don't want to write |parallel (Num_Threads := 3, ...) |function or something similar, do you? Or think of this "reduction" keyword... > Also, I read that in example 1: "Variables declared here should have > shared context." Yes, if they're declared outside of the parallel block, they can be seen by every single one, so "shared" would IMO be a more natural visibility rule here. This could remove the need for another keyword. > In fact by default they have private context and to > me it looks like more normal. What do you mean "by default"? The OpenMP spec? Well, I wasn't trying to copy the idiocies mainly caused by the chosen base language(s). :-> Thread private variables don't make sense outside of the parallel block, especially *after* it, so why should the default be "private" here? > Maybe we should have a way to do the > contrary: specify that a variable has shared context... What others > think? The approach allowed both in a (I think, logical way, because of the implied scoping rules). The problems begin with the "firstprivate" and such directives. Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CRT unit, Fedora 5, Doesn't Work- Elaboration here
>>Jason P Sage wrote: >>> A good example is that FreeVision and the FPC IDE do not work on my >>> Linux either. >> >>Elaborate on "do not work" please ? >> >>Micha [Jason Peter Sage] Hello Michael. "Does Not Work" means in this case that the source code compiles, but when I run it (It DOES RUN) I have a blinking cursor... that's it. Now this "test" was KDE xwindows, Fedora 5, I tried the non xwindow mode just because I was curious... no dice - same symptoms. I tried both shell and linux console varieties of the KDE "Terminal Window". In the past I knew and expected character set difference, so I always wrote a "text only" mode that just used colors and simple thing like asterisks and pipe characters and dashes to make text gui windows etc.. no dice. Jason P Sage ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CRT unit, Fedora 5, Doesn't Work- Elaboration here
On Thu, 27 Jul 2006, Jason P Sage wrote: Jason P Sage wrote: A good example is that FreeVision and the FPC IDE do not work on my Linux either. Elaborate on "do not work" please ? Micha [Jason Peter Sage] Hello Michael. Micha <> Michael :-) "Does Not Work" means in this case that the source code compiles, but when I run it (It DOES RUN) I have a blinking cursor... that's it. Now this "test" was KDE xwindows, Fedora 5, I tried the non xwindow mode just because I was curious... no dice - same symptoms. I tried both shell and linux console varieties of the KDE "Terminal Window". This is a known problem, and will be fixed in 2.0.4 Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unknown runtime error 202
Michael wrote: > .. FileName/Linenumber info is only available through debug information. > It's not an interpreted language, but compiled language. Thanks for explanation. Wolfram ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
On 25 Jul 06, at 16:45, Andreas Berger wrote: > Vincent Snijders wrote: > > Andreas Berger schreef: > >> Andreas Berger wrote: > >>> I have a problem compiling the compiler. After a lot of compilation > >>> it attempts to compile pp.pas and I get the following error: > >>>pp.pas(213,1) Error: Entrypoint start not defined. > >> I downloaded todays snapshot and had the same problem. Then I > >> compiled using "make all" + "make install" instead of "make cycle" > >> and it worked. Is this correct? What does "make cycle" do exactly? > > > > There is at least one difference. > > If you do make cycle in the compiler directory, the fpc.cfg file is used. > > If you do make all or make compiler_cycle in the fpc source directory > > (that contains a compiler subdirectory), then no fpc.cfg file is used. > > > > So maybe you should try make cycle OPT="-n" > > > Sorry, it gave the same error. No wonder. ;-) When using "make all", the new (2.1.1) compiler is compiled using the starting compiler (2.0.x). "Make cycle" tries to make sure that the created compiler is still useable, at least that useable that it can still build itself. It does so by doing the same thing in a cycle: 1) RTL and compiler (ppc1.exe) are compiled using the starting compiler. 2) Everything except ppc1.exe is cleaned, RTL and compiler (ppc2.exe) are compiled using ppc1.exe. 3) Everything except ppc2.exe is cleaned, RTL and compiler (ppc3.exe) are compiled using ppc2.exe. 4) ppc2.exe and ppc3.exe are compared - they should be equal. If they are the same, ppc3.exe is renamed to ppc386.exe. 5) If you build more than just the compiler (e.g. snapshot or release - i.e. this last step isn't part of "make cycle" any more), the newly created ppc386.exe is used for compilation of RTL, FCL, FV, packages and IDE. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Tomas Hajny wrote: No wonder. ;-) When using "make all", the new (2.1.1) compiler is compiled using the starting compiler (2.0.x). "Make cycle" tries to make sure that the created compiler is still useable, at least that useable that it can still build itself. It does so by doing the same thing in a cycle: 1) RTL and compiler (ppc1.exe) are compiled using the starting compiler. 2) Everything except ppc1.exe is cleaned, RTL and compiler (ppc2.exe) are compiled using ppc1.exe. 3) Everything except ppc2.exe is cleaned, RTL and compiler (ppc3.exe) are compiled using ppc2.exe. 4) ppc2.exe and ppc3.exe are compared - they should be equal. If they are the same, ppc3.exe is renamed to ppc386.exe. 5) If you build more than just the compiler (e.g. snapshot or release - i.e. this last step isn't part of "make cycle" any more), the newly created ppc386.exe is used for compilation of RTL, FCL, FV, packages and IDE. So you mean that the newly created compiler is giving the error? Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] national support
On 26 Jul 06, at 9:38, Michael Van Canneyt wrote: > On Wed, 26 Jul 2006, Friš Martin Mgr wrote: > > > I give additional details. I write programs for mathematical linguistics. > > Especially program for frequency dictionary of chosen text. > > I write text to the editor. The text is in Czech. It displays correctly in > > editor window , > > i.e. with diacritics. Then follows transformation into words. In program > > for frequency > > diactionary, which contains binary search I have usual read and write > > statements. > > When I send the result to the printer with write it is displayed > > incorrectly on the > > print output - the diacritics. I am working under Windows |X|P. > > You cannot do that; The screen is in codepage 1250 (or 1251), but the > codepage of the > printer is most likely 850 or so (whatever plain ascii is). What you can try > to do is > to use the windows AnsiToOEMChar routine to convert the windows codepage to > something > that the printer understands. "Something that the printer understands" is the important part. It might be that it doesn't support the characters with diacritics by default and that you need to switch to another character set using some control code first (where the control code would be most likely specific to the particular printer or at least "category")... Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
On 27 Jul 06, at 19:01, Andreas Berger wrote: > Tomas Hajny wrote: > > No wonder. ;-) When using "make all", the new > > (2.1.1) compiler is compiled using the starting > > compiler (2.0.x). "Make cycle" tries to make sure > > that the created compiler is still useable, at > > least that useable that it can still build > > itself. It does so by doing the same thing in a > > cycle: > > > > 1) RTL and compiler (ppc1.exe) are compiled using > > the starting compiler. > > > > 2) Everything except ppc1.exe is cleaned, RTL and > > compiler (ppc2.exe) are compiled using ppc1.exe. > > > > 3) Everything except ppc2.exe is cleaned, RTL and > > compiler (ppc3.exe) are compiled using ppc2.exe. > > > > 4) ppc2.exe and ppc3.exe are compared - they > > should be equal. If they are the same, ppc3.exe > > is renamed to ppc386.exe. > > > > 5) If you build more than just the compiler (e.g. > > snapshot or release - i.e. this last step isn't > > part of "make cycle" any more), the newly created > > ppc386.exe is used for compilation of RTL, FCL, > > FV, packages and IDE. > > > So you mean that the newly created compiler is giving the error? Specifically, with ppc1.exe (which is 2.1.1 compiler already if working with 2.1.1 sources) - you should be able to see this in the log/make output. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling the compiler
Tomas Hajny wrote: On 27 Jul 06, at 19:01, Andreas Berger wrote: Tomas Hajny wrote: No wonder. ;-) When using "make all", the new (2.1.1) compiler is compiled using the starting compiler (2.0.x). "Make cycle" tries to make sure that the created compiler is still useable, at least that useable that it can still build itself. It does so by doing the same thing in a cycle: 1) RTL and compiler (ppc1.exe) are compiled using the starting compiler. 2) Everything except ppc1.exe is cleaned, RTL and compiler (ppc2.exe) are compiled using ppc1.exe. 3) Everything except ppc2.exe is cleaned, RTL and compiler (ppc3.exe) are compiled using ppc2.exe. 4) ppc2.exe and ppc3.exe are compared - they should be equal. If they are the same, ppc3.exe is renamed to ppc386.exe. 5) If you build more than just the compiler (e.g. snapshot or release - i.e. this last step isn't part of "make cycle" any more), the newly created ppc386.exe is used for compilation of RTL, FCL, FV, packages and IDE. So you mean that the newly created compiler is giving the error? Specifically, with ppc1.exe (which is 2.1.1 compiler already if working with 2.1.1 sources) - you should be able to see this in the log/make output. Ok, the ppc1.exe was created and but it couldn't create ppc2.exe. I'll start developing on the 2.0.x branch until this is resolved. All I do should be readily transferable to 2.1.x later Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
