[fpc-devel] FPC version 2.2.2 RC2 is out
Hello, After some testing and fixing minor installation and other issues, RC2 for version 2.2.2 is available for testing. Downloads for major platforms (Linux/Windows/FreeBSD/Mac OS X/Dos) are available from ftp://ftp.freepascal.org/fpc/beta/2.2.2rc2 (this should propagate to mirrors soon) A list of major changes (unchanged when compared to RC 1) is available in the Wiki: http://wiki.freepascal.org/User_Changes_2.2.2 A major issue that was fixed when compared to RC1 was that the Linux RPM installation installed units in a location where the compiler wasn't searching, so testing of the RPMs can proceed now. We urge everybody to test this release candidate thoroughly. If all goes well, this will become the final release real soon now. Enjoy ! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] iconv unit/problem
On Tue, 15 Jul 2008, Marco van de Voort wrote: because there are several bugreports asking for an iconv header translations, and one contained a patch from Whitewind which I tried to cleanup and get working. I now have a bit of an odd problem with it that it seems to decode one char less than the input specifies. Shouldn't you make allowances for the terminating #0 ? It's the input, not the output. It does this even when you set the output buffer really high. The man page doesn't mention a #0, and the behaviour is the same on Linux and FreeBSD so I assume intentional. And doesn't a text file have a unicode marker at the start ? It goes wrong before I/O, and the input is not unicode but text in a codepage. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Hi, - snip -- Include(WindowAttributes, waStayOnTop); // == doesn't compile with FPC 2.3.1 WindowAttributes:=WindowAttributes +[waStayOnTop]; // == this does - end -- As far as I understood, the above two lines should do exactly the same thing and I have been using Include() since Delphi 5 days and FPC 2.0.2. Now in FPC 2.3.1 it doesn't work any more. I get the following error. -- [EMAIL PROTECTED]:splashscreen$ fpc @extrafpc.cfg test.lpr Free Pascal Compiler version 2.3.1 [2008/06/02] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for i386 Compiling test.lpr Compiling frm_main.pas Compiling commands.pas Compiling frm_splashscreen.pas frm_splashscreen.pas(75,40) Error: Can't take the address of constant expressions frm_splashscreen.pas(125) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /opt/fpc_svn/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled) -- It compiles without issues under FPC 2.2.3 and prior. What is wrong with using Include() to add to a set? I do it all the time, plus WindowAttribute is a read/write property, unlike the compiler error in 2.0.4 where you could use Include() with a read-only property. Is this not a regression bug in FPC 2.3.1 maybe? WindowAttributes are defined as follows: ... property WindowAttributes: TWindowAttributes read FWindowAttributes write FWindowAttributes; ... Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Graeme Geldenhuys wrote: WindowAttributes are defined as follows: ... property WindowAttributes: TWindowAttributes read FWindowAttributes write FWindowAttributes; ... It's the same thing as mentioned before, FPC now guarantees you can change that into GetWindowAttributes function. If this is the case, then you can't take the address anymore of a variable, because that doesn't exist. Include() implementation takes the address, then modifies it to add to it. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Graeme Geldenhuys wrote: Hi, - snip -- Include(WindowAttributes, waStayOnTop); // == doesn't compile with FPC 2.3.1 WindowAttributes:=WindowAttributes +[waStayOnTop]; // == this does - end -- As far as I understood, the above two lines should do exactly the same thing and I have been using Include() since Delphi 5 days and FPC 2.0.2. Now in FPC 2.3.1 it doesn't work any more. I get the following error. You cannot pas properties in var parameters. (Imagine WindowAttributes had a Getter and didn't read directly from FWindowAttributes) Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys: It compiles without issues under FPC 2.2.3 and prior. What is wrong with using Include() to add to a set? I do it all the time, plus WindowAttribute is a read/write property, unlike the compiler error in 2.0.4 where you could use Include() with a read-only property. Is this not a regression bug in FPC 2.3.1 maybe? 2.3 prevents you form taking the address of a property, because that way you can read/write its value directly, circumventing the getter/setter. So you cannot use the @ operator, but neither can you pass properties to var parameters. Include is an internal procedure that calls an rtl function that receives the set as a var parameter, preventing include to work. I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. - While include is not a real procedure, its set parameter is clearly defined as var. Passing properties to var parameters is not allowed, so it should not be allowed for include either. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Op Wed, 16 Jul 2008, schreef Daniël Mantione: 2.3 prevents you form taking the address of a property, because that way you can read/write its value directly, circumventing the getter/setter. So you cannot use the @ operator, but neither can you pass properties to var parameters. Include is an internal procedure that calls an rtl function that receives the set as a var parameter, preventing include to work. I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. - While include is not a real procedure, its set parameter is clearly defined as var. Passing properties to var parameters is not allowed, so it should not be allowed for include either. I forgot: The fact that 2.2 allows it does not mean 2.2 will generate correct code! Your getter/setter will be bypassed with 2.2 if you use include, that is why 2.3 prevents the generation of incorrect code. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione [EMAIL PROTECTED] wrote: I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. It's easy for me (from a developers point of view wink) to say, but I think that it's up to the compiler to resolve the issue at hand. It's not the job of the developer to change all existing code. Surely the compiler must be able to detect if set is a property or field variable. If it's a property, resolve the call to set := set + [member] As it stands now, FPC 2.3.1 is going to break a LOT of code. Yes I know it was maybe a unsafe way of using Include(), but surely the compiler can handle it better. Thoughts? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
2.3 prevents you form taking the address of a property, because that way you can read/write its value directly, circumventing the getter/setter. So you cannot use the @ operator, but neither can you pass properties to var parameters. Include is an internal procedure that calls an rtl function that receives the set as a var parameter, preventing include to work. While this is obvious and of course using the address of a property should issue an error message, it seems desirable id a way is provided to allow using it in case that there is no getter or setter method. As this is defined in the interface of the component's unit, the calling code _does_ know about that fact. (Of course it's bad style as updating the called component will brake the caller's code and a Warning would be appropriate.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys: On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione [EMAIL PROTECTED] wrote: I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. It's easy for me (from a developers point of view wink) to say, but I think that it's up to the compiler to resolve the issue at hand. It's not the job of the developer to change all existing code. Surely the compiler must be able to detect if set is a property or field variable. If it's a property, resolve the call to set := set + [member] This is argumentation for transparantly calling any procedure; it does not hold as an argument to handle it transparently for include only. As it stands now, FPC 2.3.1 is going to break a LOT of code. Yes I know it was maybe a unsafe way of using Include(), but surely the compiler can handle it better. Thoughts? We are aware it breaks a lot of code, and the fact that include is also affected does not change this, it is just a procedure that has a var parameter. Any procedure that passes properties to var parameters is affected. The reason 2.2 still accepts it is that while the old behaviour is incorrect, many code may appear to work correctly and we do not want to break it during a stable series. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
On 16 Jul 2008, at 10:01, Graeme Geldenhuys wrote: On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione [EMAIL PROTECTED] wrote: I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. Adding such exceptions complicates both the compiler sources (special cases have to be added for particular constructs in particular circumstances) and the language (x is not allowed, except in cases a, b and c). Over time, such exceptions (even if initially added for convenience reasons) actually make things harder rather than easier for most developers, because they keep adding up and you create a completely inconsistent set of rules. The reason is that you end up in a situation where people have to be aware which routines are compiler-internal and thus can be magically changed to do the right thing, and which are plain rtl routines which abide by the normal language rules (other exampleq would be inc/ dec). Such differences in behaviour actually already exist nowadays, e.g. regarding overloading, causing confusion: http://bugs.freepascal.org/view.php?id=8399 Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
2008/7/16 Jonas Maebe [EMAIL PROTECTED]: I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. Adding such exceptions complicates both the compiler sources (special cases have to be added for particular constructs in particular circumstances) and the language (x is not allowed, except in cases a, b and c). Over time, such exceptions (even if initially added for convenience reasons) actually make things harder rather than easier for most developers, because they keep adding up and you create a completely inconsistent set of rules. The reason is that you end up in a situation where people have to be aware which routines are compiler-internal and thus can be magically changed to do the right thing, and which are plain rtl routines which abide by the normal language rules (other exampleq would be inc/dec). Such differences in behaviour actually already exist nowadays, e.g. regarding overloading, causing confusion: http://bugs.freepascal.org/view.php?id=8399 OK, I understand you point over the long term. So would the following still be okay? set += [member]; Not that I ever use the C style operators like '+=', but it does act as nice shorthand for code - replacing the need for Include(). BTW: Is C style operator '+=' available by default in compiler mode objfpc? Or must I explicitly add -Sc ? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Hi, just to add another opinion. Personally, I would thing that it was nice to allow (write-able) Properties to any var-param (even out-param). Write-able include properties with a setter-procedure. IMHO the way it could be done would be for the compiler to create a temporary variable. This could be passed in as var/out-param, and then be assigned to the property, using the proper setter-procedure. I do of course understand, that this is extra work on the compiler. And I can not judge if it has enough value for anyone to implement it. Best Regards Martin Jonas Maebe wrote: On 16 Jul 2008, at 10:01, Graeme Geldenhuys wrote: On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione [EMAIL PROTECTED] wrote: I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. Adding such exceptions complicates both the compiler sources (special cases have to be added for particular constructs in particular circumstances) and the language (x is not allowed, except in cases a, b and c). Over time, such exceptions (even if initially added for convenience reasons) actually make things harder rather than easier for most developers, because they keep adding up and you create a completely inconsistent set of rules. The reason is that you end up in a situation where people have to be aware which routines are compiler-internal and thus can be magically changed to do the right thing, and which are plain rtl routines which abide by the normal language rules (other exampleq would be inc/dec). Such differences in behaviour actually already exist nowadays, e.g. regarding overloading, causing confusion: http://bugs.freepascal.org/view.php?id=8399 Jonas___ 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] The usage of Include() doesn't work any more in 2.3.1
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione [EMAIL PROTECTED] wrote: I think there can be two visions here: - Include is not a real procedure, so this internal implementation detail should be hidden and this can/should be allowed; the compiler internally should convert it into set:=set+[member]. I think this would be ideal. Using Include() is much cleaner than set := set + [member]. And yes I understand that as it was implement, you could circumvent the getter/setter, but I believe it's something the compiler must handle correctly. It's easy for me (from a developers point of view wink) to say, but I think that it's up to the compiler to resolve the issue at hand. It's not the job of the developer to change all existing code. Surely the compiler must be able to detect if set is a property or field variable. If it's a property, resolve the call to set := set + [member] As it stands now, FPC 2.3.1 is going to break a LOT of code. Yes I know it was maybe a unsafe way of using Include(), but surely the compiler can handle it better. Thoughts? At least the error message can be improved. Additional we can maybe introduce a new switch and reduce the error to a warning in case the property is a varaible only and not a procedure. Peter ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
I think this is also same in Delphi, but I agree that passing pure properties (without getter/setter) to var should possibly be reduced to warning or even hint. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Op Wed, 16 Jul 2008, schreef Ales Katona: I think this is also same in Delphi, but I agree that passing pure properties (without getter/setter) to var should possibly be reduced to warning or even hint. This was discussed before and rejected. The reason is that a change in implementation of the property should not hav any effect on code that uses of the property. I.e. a programmer that exposes a variable by means of a property wants to have the option of introducing getters/setters later, otherwise he would have used a public variable. Therefore any code using properties has to be ready for future getter/setters. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
On 16 Jul 2008, at 11:58, Graeme Geldenhuys wrote: OK, I understand you point over the long term. So would the following still be okay? set += [member]; Not that I ever use the C style operators like '+=', but it does act as nice shorthand for code - replacing the need for Include(). It should work fine, as x+=y is really just a notation shorthand for x:=x+y and is not treated specially in any way by the compiler afaik. BTW: Is C style operator '+=' available by default in compiler mode objfpc? Or must I explicitly add -Sc ? You have to use -Sc. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
On 16 Jul 2008, at 12:16, Martin Friebe wrote: IMHO the way it could be done would be for the compiler to create a temporary variable. This could be passed in as var/out-param, and then be assigned to the property, using the proper setter-procedure. That results in semantics than a var/out parameter, because updates to a var/out parameter are expected to be immediately globally visible, while in this case they would only be visible after the callee has returned. You'd need something like a copyback parameter type for this (which then indeed could also be used with properties as opposed to only with regular fields/variables. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] C style operator doesn't work with properties in 2.3.1
Hi, After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; i := i + 2; I tried it, and yes I did add the -Sc compiler parameter... The error message Free Pascal Compiler version 2.3.1 [2008/07/16] for i386 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for i386 Compiling guitestrunner_fpgui.pas Compiling fpg_guitestrunner.pas /home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(207,15) Error: Variable identifier expected /home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(208,24) Error: Variable identifier expected /home/graemeg/programming/fpgui.wc/examples/apps/fpcunit/fpg_guitestrunner.pas(636) Fatal: There were 2 errors compiling module, stopping And the code --- type // introduced to test += operator TMyOb = class(TObject) private FValue: integer; public property Value: integer read FValue write FValue; end; procedure TGUITestRunnerForm.EndTest(ATest: TTest); var i: integer; // both of these are simply o: TMyOb; // to test the += operator begin i := 0; i += 2; // no problems o := TMyob.Create; o.Value := 0; o.Value += 2; // Fails here pbName1.Position += 1; // === Fails here, o object wasn't used --- So it seems I can't use the += operator with properties either!! :-( I'm using FPC 2.3.1 updated today. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; i := i + 2; Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes sense again, for the same reasons as before. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort [EMAIL PROTECTED] wrote: After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; i := i + 2; Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes sense again, for the same reasons as before. Boy of boy FPC 2.3.1 is becoming frustrating!! So is there a performance difference between: inc(i,2)vsi := i + 2; If not, then can the += operator rather use the latter? After all, just about every peace of documentation on += operator I could find, they mention that it's an shorthand form of x := x + y Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort [EMAIL PROTECTED] wrote: After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; i := i + 2; Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes sense again, for the same reasons as before. Following on my previous post... If it translates to inc(i,2) then why is the error message different to the Include() issue? Error: Variable identifier expected vs Error: Can't take the address of constant expressions Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
On Wed, Jul 16, 2008 at 2:43 PM, Jonas Maebe [EMAIL PROTECTED] wrote: OK, I understand you point over the long term. So would the following still be okay? set += [member]; Not that I ever use the C style operators like '+=', but it does act as nice shorthand for code - replacing the need for Include(). It should work fine, as x+=y is really just a notation shorthand for x:=x+y and is not treated specially in any way by the compiler afaik. You would have thought that, but surprise, surprise it doesn't!! WindowAttributes += [waStayOnTop]; Gives me the following error: Error: Variable identifier expected Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
On 16 Jul 2008, at 16:23, Graeme Geldenhuys wrote: So it seems I can't use the += operator with properties either!! :-( Indeed. I've checked the code and properties are explicitly not allowed for the C-style operators. The reason is that the x+=y is translated into x:=x+y at the parser level rather than at the lexical level. This means that in case x is a property, at the point that this transformation is performed the compiler already resolved it into the setter property (so it can no longer access the getter). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Unicode Letters
Is there a way to separate unicode letters from punctuation and the like? The reason is simple: I would like to separate words in a text for a spell-checker. I see there are tables which list unicode categories http://www.sql-und-xml.de/unicode-database/#kategorien Is there already something for freepascal to get such information? Is there a better way to do what I need? Thanks Theo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register
I'm getting a Error: Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register when compiling the following code. This happens when using default parameter values. Here is an example: var Callback: procedure(Data: Pointer); procedure Proc(AData: Pointer = nil); begin end; initialization Callback := Proc; If the = nil is removed, then the code compiles. Thanks, Sean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register
On Wed, 16 Jul 2008 15:05:44 -0500 Sean McIlwain [EMAIL PROTECTED] wrote: I'm getting a Error: Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register when compiling the following code. This happens when using default parameter values. Here is an example: var Callback: procedure(Data: Pointer); procedure Proc(AData: Pointer = nil); begin end; initialization Callback := Proc; If the = nil is removed, then the code compiles. Use mode objfpc and CallBack:[EMAIL PROTECTED] Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Tiburon compatibility
Apparently the new Delphi version (Tiburon) will change the way strings are handled by the rtl and the compiler, this changes affects Unicode characters specially. Surely the code created with the new Delphi version shouldn't compile with FPC. Is somebody addressing the changes to make them compatible with future versions of FPC, or this will be the finish of compatibility between the two compilers? Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Illegal type conversion: enumeration type to TObject
The following code fails to compile in Delphi mode but successfully compiles in objfpc mode: type TEnum = (a, b, c); var AValue: TEnum; AObject : TObject; implementation initialization AObject := TObject(AValue); Could this be supported in the Delphi mode as well? Thanks, Sean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Tiburon compatibility
Leonardo M. Ramé wrote: Apparently the new Delphi version (Tiburon) will change the way strings are handled by the rtl and the compiler, this changes affects Unicode characters specially. Surely the code created with the new Delphi version shouldn't compile with FPC. Why shouldn't ? Is somebody addressing the changes to make them compatible with future versions of FPC, or this will be the finish of compatibility between the two compilers? Ehm... afaik, tiburon is not released yet, so how should we know what the incompatibilities are ? Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
Graeme Geldenhuys wrote: On Wed, Jul 16, 2008 at 4:29 PM, Marco van de Voort [EMAIL PROTECTED] wrote: After our discussion about not being able to use Include() with a class property, I thought I would then use the C Style += operator. After all that boils down to: i += 2; i := i + 2; Suspect that it gets translated to inc(i,2); not i:=i+2; and then it makes sense again, for the same reasons as before. Boy of boy FPC 2.3.1 is becoming frustrating!! So is there a performance difference between: inc(i,2)vsi := i + 2; If not, then can the += operator rather use the latter? After all, just about every peace of documentation on += operator I could find, they mention that it's an shorthand form of x := x + y Just if you want to know my humble opinion: your statement isn't fair. You know a property isn't a variable, so don't assume it will behave like that. If you want a property function as a variable, eg reading and writing a class member directly, do use a public variable instead. Fpc core is doing a really nice job, improving and extending the compiler in their spare time, helping all developers writing better source code. This one is a good sample. They don't deserve such comment. -- Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode Letters
In hebrew (at least) the punctuation is a different char that comes after the letter, but painted like it was part of the letter, so you can parse each word and ignore non letter value (it arrives in different range in the unicode table). Ido On Wed, Jul 16, 2008 at 10:09 PM, theo [EMAIL PROTECTED] wrote: Is there a way to separate unicode letters from punctuation and the like? The reason is simple: I would like to separate words in a text for a spell-checker. I see there are tables which list unicode categories http://www.sql-und-xml.de/unicode-database/#kategorien Is there already something for freepascal to get such information? Is there a better way to do what I need? Thanks Theo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel -- http://ik.homelinux.org/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
