[fpc-devel] Re: [fpc-l] type discussion
I followed this discussion if that construction (see below) should be allowed or not (I think it should be allowed, but it's possible to live without it; I can imagine situations where it could make easier to read), and I'm missing a bit a discussion forum about the future of FPC. It should contain what is planned to be implemented, it should contain about ideas of what could be implemented. I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail). Beside of compatibility towards Delphi or MacPascal or others FPC should be open to other modifications/extensions (maybe Delphi one day copies FC a bt :-), and not always the other way round) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) writing of enums to text file; more operators which can be overloaded (should follow the ALGOL68 rules) the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol automatic assignment operators: operator * ( a : type1 ; b : type2 ) : type1 should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; multiple assignments: a := b := c := d := 0 ; etc. That are just some ideas. Maybe there are more? Greetings Gerhard - Original Message - From: Florian Klaempfl [EMAIL PROTECTED] To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Sunday, May 29, 2005 2:05 PM Subject: Re: [fpc-pascal] Re: ... type pMyRec = ^tMyRec; type tMyRec = Record data:pointer; next:pMyRec; end; and this: type pMyRec = ^tMyRec; tMyRec = Record data:pointer; next:pMyRec; end; ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail). Main plans short term to my knowledge are: * create/improve the COM/OLE support. This has multiple facets: o COM compat interfaces/vmt o Variants (needed for OLE) o implements style delegation * linking/debug/fileformats related * improve smartlinking (get rid of .a files, less mem use) * improved packages and dynamic libraries (PIC!) support in general. * crosslinking (2.0 is actually quite crosslink capable already) * stabs-dwarf crossover. * Some form of Kylix compat resources.(still under discussion) * Support for 64-bit (sized) native filetypes. Some of these target functionality (specially in the linking section) might require restructures related to * introduction of an internal linker for some core platforms (no more LD) * Rewrite of module (unit) handling For the rest, improve RTL/FCL compability and extend them in general, and of course fixbugs. Beside of compatibility towards Delphi or MacPascal or others FPC should be open to other modifications/extensions (maybe Delphi one day copies FC a bt :-), and not always the other way round) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) I'd like that too. a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) Rarely used. Specially since more than base 36 becomes a notational problem. However it has been brought up before. writing of enums to text file; This should be supported, however needs some tricks. (RTTI is available for enums!) more operators which can be overloaded (should follow the ALGOL68 rules) IMHO this is asking for a mess, and the use is limited. should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; Why to save two characters? The C operators were afaik mostly added to ease porting critical C code. However IMHO one shouldn't use them in new code, and there is no need to start adding variations on the C syntax. multiple assignments: a := b := c := d := 0 ; etc. Same point. Totally useless. That are just some ideas. Maybe there are more? To judge extensions, it might be smart to check this faq item: http://www.freepascal.org/faq.html#extensionselecthttp://www.freepascal.org/faq.html#extensionselect which is more or less a rough view on how we (or actually more I, since I wrote it) see extensions to the language. Except larger sets and more control about set packing is the only really interesting thing IMHO generics/templates, since it really makes heaps of new behaviour possible, and is not purely syntax that saves typing. The wiki also contains some roadmap info: http://www.freepascal.org/wiki/index.php/Detailed_2.1.0_branch_todo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
I followed this discussion if that construction (see below) should be allowed or not (I think it should be allowed, but it's possible to live without it; I can imagine situations where it could make easier to read), and I'm missing a bit a discussion forum about the future of FPC. It should contain what is planned to be implemented, it should contain about ideas of what could be implemented. See below I've read somewhere that Delphi 7 compatibility is planned (since I do not have it I do not know what that means in detail). Beside of compatibility towards Delphi or MacPascal or others FPC should be open to other modifications/extensions (maybe Delphi one day copies FC a bt :-), and not always the other way round) Don't expect anything. Like assigning values to enumarations we had it already before Delphi did. And also with inlining they added other rules. Useful extensions I would see: bigger sets: set of -10..10 (e.g.) a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) You can write your own routine for that. writing of enums to text file; Enums are like constant numbers. You can already write them to a file using a typecast: writeln(longint(enum)); more operators which can be overloaded (should follow the ALGOL68 rules) the C-style operators += etc. should better be written as +:= since C has = as assignment, Pascal has := as assignment symbol This will break existing code. And IMHO it looks very strange with the colon in the middle. automatic assignment operators: operator * ( a : type1 ; b : type2 ) : type1 should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; multiple assignments: a := b := c := d := 0 ; This was in the compiler in the past and caused a lot of trouble and hacks in the parser. That are just some ideas. Maybe there are more? But are they usefull? Do they add something or only save you typing? THat is why there is no discussion about future on the webpages. Discussion shall take place at the mailing lists. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Contribution
Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Petr Kristan -- Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223Czech Republic (Eastern Europe) fax: +420 466510709 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Contribution
On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote: Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Send them to me. Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Maybe Jason Southwell is working on it, but go ahead and change whatever you think needs changing. Patches can be sent to me. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Contribution
Michael Van Canneyt wrote: On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote: Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Send them to me. Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Maybe Jason Southwell is working on it, but go ahead and change whatever you think needs changing. Patches can be sent to me. VarArrayCreate should basically work with 2.0.0. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Contribution
On Wed, Jun 01, 2005 at 03:22:10PM +0200, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote: Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Send them to me. Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Maybe Jason Southwell is working on it, but go ahead and change whatever you think needs changing. Patches can be sent to me. VarArrayCreate should basically work with 2.0.0. Yes VarArrayCreate(..., varInteger) works, but VarArrayCreate(..., varVariant) emits VarArray is locked. Unfortunately my knowledge about variants internals is zero. Petr -- Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223Czech Republic (Eastern Europe) fax: +420 466510709 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Contribution
[EMAIL PROTECTED] wrote: On Wed, Jun 01, 2005 at 03:22:10PM +0200, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote: Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Send them to me. Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Maybe Jason Southwell is working on it, but go ahead and change whatever you think needs changing. Patches can be sent to me. VarArrayCreate should basically work with 2.0.0. Yes VarArrayCreate(..., varInteger) works, but VarArrayCreate(..., varVariant) emits VarArray is locked. Unfortunately my knowledge about variants internals is zero. Can you create a small example which shows the problem? BTW: Which OS do you use? Win or other? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
El Miércoles, 1 de Junio de 2005 13:50, Marco van de Voort escribió: Main plans short term to my knowledge are: ... * improved packages and dynamic libraries (PIC!) support in general. Sorry if I've been confused by improved. Is PIC already supported? -- saludos, Nico Aragón ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Contribution
On Wed, Jun 01, 2005 at 04:11:37PM +0200, Florian Klaempfl wrote: [EMAIL PROTECTED] wrote: On Wed, Jun 01, 2005 at 03:22:10PM +0200, Florian Klaempfl wrote: Michael Van Canneyt wrote: On Wed, 1 Jun 2005 [EMAIL PROTECTED] wrote: Hi. Now I'm working on porting our Delphi database application (cca 100 000 lines) to FreePascal. I have some little patches principally around TDataset. Where can I send this patches? Send them to me. Our application is now possible to translate in fpc, but first problem was unfunctional VarArrayCreate([0, 1], varVariant). Is here somebody who is working on Variants or may I try to penetrate into source and try to track down this bug? Maybe Jason Southwell is working on it, but go ahead and change whatever you think needs changing. Patches can be sent to me. VarArrayCreate should basically work with 2.0.0. Yes VarArrayCreate(..., varInteger) works, but VarArrayCreate(..., varVariant) emits VarArray is locked. Unfortunately my knowledge about variants internals is zero. Can you create a small example which shows the problem? BTW: Which OS do you use? Win or other? OS: Linux fpc 2.1.1 from svn. program pokus; uses Variants; var v: Variant; begin v := VarArrayCreate([0, 1], varVariant); end. emits EVariantBadVarTypeError : Invalid variant type Sorry for VarArray is locked mistake. It was another problem. Petr -- Ing. Petr Kristan . EPOS PRO s.r.o., Bozeny Nemcove 2625, 530 02 Pardubice tel: +420 466335223Czech Republic (Eastern Europe) fax: +420 466510709 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
- Original Message - From: Marco van de Voort [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wednesday, June 01, 2005 1:50 PM Subject: Re: [fpc-devel] Re: [fpc-l] type discussion ... (shortened) Useful extensions I would see: bigger sets: set of -10..10 (e.g.) I'd like that too. nice that we agree a way to write integer constants in any base, not only binary/octal/hexadecimal (not so important, but easy to implement) Rarely used. Specially since more than base 36 becomes a notational problem. However it has been brought up before. range 2..36 for the base should be enough. I have a working implementation; notation is: base_digits (the base is in decimal, the digits then the usual 0..9a..z) e.g.: 36_z = 35 seldom used, I admit, but easier to read than these $- and %- notations ... (shortened) more operators which can be overloaded (should follow the ALGOL68 rules) IMHO this is asking for a mess, and the use is limited. sorry, I'm don't know that abbreviation: IMHO; the use might look limited, but when implemented, people will find their use. ALGOL68 not only allowed operators like + - // etc, but also words/identifiers. should automatically permit constructions like: var x : type1, y : type2 ; x *:= y ; Why to save two characters? The C operators were afaik mostly added to ease porting critical C code. However IMHO one shouldn't use them in new code, and there is no need to start adding variations on the C syntax. X is just an example, more useful of course it is in situations like anArray[i,j]^ := anArray[i,j]^ * y ; Similar to inc(x) compared to x:=x+1; in C (and if I remember correct, ALGOL68 also) uses this as a hint for optimization: the reference to anArray[i,j]^ is evaluated only once (similar as it is handled in an WITH statement). I checked it with the FPC (nice that there are assembler files as output); the GNU C compiler translates arr[ii] += 1 better than FPC. Specially when C code is ported it is wise to look at the results; they might be different!. Beside, this is not C syntax, but ALGOL68 syntax, which is some years older. multiple assignments: a := b := c := d := 0 ; etc. Same point. Totally useless. easier to read, especially in sequencies of variable initializations Greetings Gerhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote: var x : type1, y : type2 ; x *:= y ; in my humble opinion(IMHO): := is based on the fact that A: is written normaly in math etc. where it means this is a fact about A So when someone writes A:=5; it means it's a fact that A equals 5 Writing A*:= is stupid. If nothing else do it like this: A:*= But IMHO it's useless in ANY case. Even C people tend to not use it when they want readible code(especialy * which is so ambiguos) As to the ASM: in C if you do a+=b; and a is int b is longint it does this actualy: a = a + (int)b; which is stupid and unsafe. Just my 0.05 euros ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: bug report
I tried this example, but it does compile! No problem!
- Original Message -
From:
To: fpc bug
Sent: Saturday, May 21, 2005 4:10 AM
Subject: [fpc-devel] Fwd: bug report
fpc 2.0.0 win32
problem:
I can't see pi in proceudre pre but I can see it in procedure kmp.
pre is a procedure belonging to kmp.
I found that I could only see vars in this proceudre/function and main
program, but I couldn't see vars in the procedure that this procedure
belongs to.
code:
var
t,p:string;
procedure kmp(t,p:string);
var
n,m,q,i:integer;
pi,match:array[1..255] of integer;
procedure pre(p:string);
var
k,q:integer;
begin
pi[1]:=0;
k:=0;
for q:=2 to m do begin
while (k0) and (p[k+1]p[q]) do k:=pi[k];
if p[k+1]=p[q] then k:=k+1;
pi[q]:=k;
end;
end;
begin
n:=length(t);
m:=length(p);
q:=0;
pre(p);
fillchar(match,sizeof(match),0);
for i:=1 to n do begin
while (q0) and (p[q+1]t[i]) do begin
match[i-q]:=q;
q:=pi[q];
end;
if p[q+1]=t[i] then q:=q+1;
if q=m then begin
match[i-q+1]:=q;
q:=pi[q];
end;
end;
write(match[1]);
for i:=2 to n do write(' ',match[i]);
writeln;
end;
begin
readln(t);
readln(p);
kmp(t,p);
end.
[EMAIL PROTECTED]
Do You Yahoo!?
150MP3
1G1000
___
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
[fpc-devel] ptrint and sizeint
Hi, Can somebody explain what is the difference between a ptrint and a sizeint. http://www.freepascal.org/docs-html/rtl/system/ptrint.html and http://www.freepascal.org/docs-html/rtl/system/sizeint.html indicate there is a difference, but are there systems where these two are different? Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gdb on amd64
Hi, I am investigating a crash of lazarus on the amd64 platfrom. Part of the backtrace looks like this: #18 0x00434ea0 in TAPPLICATION__RUN (this=Cannot access memory at address 0x8000ed18 ) at application.inc:980 Note the parameter of TApplication.Run is not shown, because of the invalid memory address. Is this normal (can't gdb handle this?) or does this indicate a bug in my program? Regards, Vincent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
my marks start with :
- Original Message -
From: Ales Katona [EMAIL PROTECTED]
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Wednesday, June 01, 2005 6:52 PM
Subject: Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote:
var
x : type1, y : type2 ;
x *:= y ;
in my humble opinion(IMHO):
thanks for the explanation
:= is based on the fact that A: is written normaly in math etc. where it
means this is a fact about A
So when someone writes A:=5; it means it's a fact that A equals 5
fine, but in programming := usually means becomes
Writing A*:= is stupid. If nothing else do it like this:
A:*=
But IMHO it's useless in ANY case. Even C people tend to not use it when
they want readible code(especialy * which is so ambiguos)
the star * here just was an an example for any operator, could have
been +, / or AND or whatever
As to the ASM:
in C if you do a+=b; and a is int b is longint it does this actualy:
a = a + (int)b;
which is stupid and unsafe.
I do not see this is an argument.
var a:integer; b:longint; sb : integer ;
{1} a += b ;
{2} a := a + b ;
{3} sb := b ; a+=sb ;
All three versions produce the same nonsense. To avoid such nonsense I like
the compiler checks (range on, overflow on, stack overflow on, ioerror on).
Just my 0.05 euros
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
