Re: [fpc-devel] {$DEFINE x := something}
On Friday 01 July 2005 00:12, L505 wrote: As I have indicated, I am very happy to have 83-88 lines of Pascal code on my screen versus even 70 or 55. Doesn't matter. One function at a time is enough to see. ;-) I have 72x30 (yes, that's width height in chars). All function not fitting into that window need refactoring. :- Are we done with the dicksize war now? Vinzent. -- public key: http://www.t-domaingrabbing.ch/publickey.asc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Function variables and overload
Hello, Let's say there is a function function ICmp(A,B: PBigInt): SInt32; and a TBigIntList class having the following method that can sort the list according to Cmp procedure TBigIntList.Sort(Cmp: TBigIntCompareFunc); with, of course, type TBigIntCompareFunc = function(A,B: PBigInt): SInt32; Now, if ICmp is not overloaded, there is no problem, the call L.Sort(@ICmp); works. But, of course, it doesn't work if ICmp is overloaded. In fact, we cannot have both overloaded functions _and_ the the possibility to use them as variables. Yes, there are ways to fix the problem (no overload or embedding the overloaded functions in local functions) but none is really satisfying. Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would exactly know which overloaded function it has to use. When I ask 'would it be possible', I mean 'would it be possible without having to rewite all the compiler' ;-) mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] low level function for pascal language
While working on some functions in the strwrap1.zip package I am upgrading, I have found the need for a new low level function I think. Something similar to ReadLn(F,Line) This one is slightly different: PassLn(F) Instead of reading the line, copying the text the line into a Line var, the PassLn function just passes by the line and sets the pointer up at the beginning of the next line. No copying of the string. This way you can skip copying the text of the line, and move on to the next one directly. I have made a whole bunch of patches to my Fpc sources and recompiled a lot of units, and have got a PassLn function working today :) All the error messages and some low level units needed slight modification (i.e. _readln_passln_writeln instead of _readln_writeln, fpc_PassLn_End addition, etc.). But it wasn't so bad really. Now the question I have is: does Pascal already have a function like this? I definitely need a function like this for some ideas I have with strwrap1 package. If there is already a way to do this, at least I know my way around the FPC low level string sources a bit more now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Function variables and overload
Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would There is ambiguity with a normal call to the function. The compiler sees the ( and thinks it is parsing a call to Icmp(). and then sees a type identifier in a syntax thats not a typecast which makes it totally clear that this can't be a call. i dunno how much complexity supporting this syntax would add to the parser though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] concernig Bug Id 4145: Request for Bit-level packing in MacPas mode
if really someone does this, it would be nice to have it in standard (FPC)
mode also.
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Function variables and overload
peter green wrote: Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would There is ambiguity with a normal call to the function. The compiler sees the ( and thinks it is parsing a call to Icmp(). and then sees a type identifier in a syntax thats not a typecast which makes it totally clear that this can't be a call. Really ;)? What about @ICmp(TObject) ? i dunno how much complexity supporting this syntax would add to the parser though. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] low level function for pascal language
While working on some functions in the strwrap1.zip package I am upgrading, I have found the need for a new low level function I think. Something similar to ReadLn(F,Line) This one is slightly different: PassLn(F) Instead of reading the line, copying the text the line into a Line var, the PassLn function just passes by the line and sets the pointer up at the beginning of the next line. No copying of the string. This way you can skip copying the text of the line, and move on to the next one directly. I have made a whole bunch of patches to my Fpc sources and recompiled a lot of units, and have got a PassLn function working today :) All the error messages and some low level units needed slight modification (i.e. _readln_passln_writeln instead of _readln_writeln, fpc_PassLn_End addition, etc.). But it wasn't so bad really. Now the question I have is: does Pascal already have a function like this? I definitely need a function like this for some ideas I have with strwrap1 package. SeekEoln(Text) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] low level function for pascal language
On 01 Jul 2005, at 23:25, L505 wrote: Now the question I have is: does Pascal already have a function like this? Yes: readln(f) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port
Hi, I reached significant waypoint in WinCE port. I have Hello world application running on WinCE. :) Here are some notes: Official binutils seems to be buggy for WinCE target. I used binutils from Pocket GCC port and they work fine. procedure fpc_cpuinit for ARM performs illegal instruction (rfs r0) on WinCE. A question why this init is needed and is it needed at WinCE? rfs r0 and r0,r0,#0xffe0 orr r0,r0,#0x0002 wfs r0 Currently I excluded this code for WinCE using ifdefs. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] concernig Bug Id 4145: Request for Bit-level packing in MacPas mode
On 01 Jul 2005, at 22:32, Gerhard Scholz wrote:
if really someone does this, it would be nice to have it in
standard (FPC)
mode also.
You will be able to activate it with a preprocessor switch.
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
The implementation of that would be completely separate from the
support required for records. Also, since that is not required for
compatibility, that will have a lower priority (unless someone
submits a clean patch for it, of course)
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Function variables and overload
Peter Vreman wrote: Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would There is ambiguity with a normal call to the function. The compiler sees the ( and thinks it is parsing a call to Icmp(). So, perhaps it would be nice if there was a way to declare an alias for overloaded functions? E.g. type TNoParamFunc = function:boolean; TIntParamFunc = function(i:integer):boolean; function MyOverloadedFunc:boolean; alias MyOverLoadedFuncNoParams; function MyOverloadedFunc(i:integer):boolean; alias MyOverLoadedFuncInt; procedure MyProc(f:TNoParamFunc); procedure MyProc(f:TIntParamFunc); // so MyProc is also overloaded ... MyProc(@MyOverLoadedFuncNoParams); MyProc(@MyOverLoadedFuncInt); This example also demonstrates exactly why we can't use the list of possible parameter types of MyProc in order to determine which overloaded function to pass. One might argue this 'alias' construction takes away the purpose of overloading functions (which, simply put, is convenience for the programmer I think), but that is not neccessarily true because you only need to use the 'long' alias in relatively rare cases such as MyProc(@MyOverloadedFunc). Another note is that the 'alias' keyword might already be in use for some other purpose (I don't exactly remember which), so we might need another keyword or construction to give alias names. Regards, Bram ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] low level function for pascal language
| | Now the question I have is: does Pascal already have a function | like this? | | Yes: readln(f) | | | Jonas | Wonderful.. Hmm, how do we add this to the FPDOC help safely, since it isn't doesn't seem to be created automatically by FPDOC? Maybe we could just make another example demo for people i.e. online fpdoc help just shows readln(args) but not readln(f) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port
Yury Sidorov wrote: Hi, I reached significant waypoint in WinCE port. I have Hello world application running on WinCE. :) GJ :) Hope, you'll contribute the patches soon ;) Here are some notes: Official binutils seems to be buggy for WinCE target. I used binutils from Pocket GCC port and they work fine. procedure fpc_cpuinit for ARM performs illegal instruction (rfs r0) on WinCE. A question why this init is needed and is it needed at WinCE? rfs r0 and r0,r0,#0xffe0 orr r0,r0,#0x0002 wfs r0 It turns floating point exceptions on. Currently I excluded this code for WinCE using ifdefs. It doesn't hurt much but you won't get floating point exceptions then. Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] WinCE port
Yury Sidorov wrote: One more question. I created 2 files t_wince.pas and i_wince.pas for WinCE target. But now I see that it will be better to add WinCE support to t_win.pas and i_win.pas files. Is it ok to do that? Yes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] AR problem
Hi, FPC can not create smartlink library under Windows host using AR from cross-binutils for arm-wince-pe, because AR refuses to accept \ dir separator when mask symbol * is specified. Any AR compiled under cygwin has this issue. How to solve this issue? Yury Sidorov. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AR problem
Yury Sidorov wrote: Hi, FPC can not create smartlink library under Windows host using AR from cross-binutils for arm-wince-pe, because AR refuses to accept \ dir separator when mask symbol * is specified. Any AR compiled under cygwin has this issue. How to solve this issue? Maybe some of our mingw experts can compile arm-wince binutils :) Marco? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] concernig Bug Id 4145: Request for Bit-level packingin MacPas mode
...
not just packed records, but also packed arrays:
packed array [ 1..2 ] of 0..15 { one byte }
packed array [ 1..8 ] of boolean { one byte }
The implementation of that would be completely separate from the
support required for records. Also, since that is not required for
compatibility, that will have a lower priority (unless someone
submits a clean patch for it, of course)
Jonas
has been in Pascal (running on CDC), but Borland dropped it .
Gerhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Function variables and overload
Peter Vreman a écrit : Hello, Let's say there is a function function ICmp(A,B: PBigInt): SInt32; and a TBigIntList class having the following method that can sort the list according to Cmp procedure TBigIntList.Sort(Cmp: TBigIntCompareFunc); with, of course, type TBigIntCompareFunc = function(A,B: PBigInt): SInt32; Now, if ICmp is not overloaded, there is no problem, the call L.Sort(@ICmp); works. But, of course, it doesn't work if ICmp is overloaded. In fact, we cannot have both overloaded functions _and_ the the possibility to use them as variables. Yes, there are ways to fix the problem (no overload or embedding the overloaded functions in local functions) but none is really satisfying. Would it be possible to get something like L.Sort(@ICmp(PBigInt,PBigInt)); in case ICmp is overloaded? If we could add the parameter types, there would be no more ambiguity, the compiler would There is ambiguity with a normal call to the function. The compiler sees the ( and thinks it is parsing a call to Icmp(). Yes. I already encountered this problem when using a function variable. Ok. And this way L.Sort(@ICmp:PBigInt:PBigInt); and if ever ICmp was overloaded but had no parameter L.Sort(@ICmp); Well, of course, I don't know the compiler enough to propose something clean and not ambiguous but the problem is not to find a way to tell the compiler Use this routine and not an other one, I am sure it is not too much difficult. No, the problem is Is it easy to modify the parser in order to implement it?. It would really be nice to be able to use overloaded routines as non overloaded ones. At the moment, in order not to lose the possibility to transmit routines to lists, like procedure TBigIntList.ForEach(Proc: TBigIntBinaryOperator; A: PBigInt; Test: TBigIntTestFunc=nil); // add A to all even integers of the list L.ForEach(@IAdd,A,@IIsEven); which is much faster than for i := 0 to L.Count-1 do if IIsEven(L[i]) then IAdd(L[i],A); I suppressed most overloaded routines by adding suffixes: IAddUI32, IAddSI32, IAddUI64, etc. It works but that's rather ugly :-) To conclude, if you cannot add such a feature to FPC, you cannot. Don't worry, FPC is already very good as it is. mm ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
