Re: [fpc-devel] resources on non-windows platform
21.11.2016 21:13, Anton Kavalenka wrote: Is not the time came for own resource compiler for limited type of resources (BITMAP, CURSOR, MANIFEST, VERSIONINFO)? It should not be a problem for a very limited syntax. But if you look at what delphi resource compiler can do then you find a very hard to implement feature - "include directive" which allows to use macroses and constants from .pas, .h and .cpp files. -- Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ANN: Management operators - final patch
21.11.2016 8:16, Maciej Izak wrote: Overall you've made a great job and a perfect example of how to supply patches for FPC. I have a small question regards the following commit: 13. https://github.com/maciej-izak/freepascal/commit/9baa32a49a204686427981d33c9054f64b2057c4 Use fpc_Copy for Clone and fpc_Addref for Copy is misleading. I know Florian insisted on Copy and Clone names but still for my taste it would be the best to have conformity between compiler and RTL. -- Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence
03.02.2014 9:42, Martin Frb пишет: It also appears that the . takes precedence over @ @Object.Foo is equal to @(Object.Foo) well otherwise it could not compile In this case . is not operator. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 18:33, Michael Van Canneyt пишет: So how one can help at this stage: 1. Check related FPC tests and write new for the missing cases. 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi during the unicodestring move and check whether something minor can be added to FPC. All major changes like the new TStringList class based on UnicodeString should wait for 2.8 release. I don't think that this is a good idea, it means that e.g. TStrings.SaveToFile() or TFileStream.Create() is still crippled. Better bite the bullet. This is what I wanted to test in feb/march. This will also mean that we will release 2.8 much later (looking at cpstr development speed probably few years later) because together with this implementation we need to solve ansi/unicode RTL problem (dotted unit names in RTL and packages). Imo it is better to release all that huge changes we have in trunk as is (maybe together with resourcestring solution). Then with the following minor releases we improve dotted unit names support (like default namespaces) together with experiments for ansi/unicode RTL. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 20:25, Michael Van Canneyt wrote: But the experiments for ansi/unicode RTL are already in trunk. Do you plan to take them out ? By experiments I ment having 2 (or 1.5) RTL with unicode + ansi classes which we planned to solve using namespaces. What good is having the unicode string support if none of the classes or units make use of it ? No-one will test it or even be able to test it because none of the base classes/routines are adapted to it. We have string, file and console routings for use and testing. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 20:59, Michael Van Canneyt wrote: That was my idea. If it turns out to be really impossible, we can still do as Paul suggests, but if it works, I would attempt to release 2.8 with dotted units. In each case, the ground work will be done in a branch, so as not to irreversibly damage trunk and destroy Paul's dreams :) I have nothing against if you think there are no risks to delay the release for more than a year. Let's see how well I fare; 2.8.0 is not for next month anyway. First get 2.6.4 out of the door. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Encoded AnsiString
30.12.2013 9:07, Hans-Peter Diettrich пишет: Do you think that FPC should really reproduce all this inconsistent behaviour? Who would test or even specify the compatible behaviour, when every new variation will result in more unexpected results? IMO it's much easier to do it right, and fix the Delphi flaws in FPC. The work is already done by FPC team. AnsiString(codepage) works and works compatible with Delphi (whether someone like this or not) and the behavior is covered by tests. Trunk version is very close to 2.8 release. The only related thing which we thought to touch before the release was resourcestring handling. If I have some free time during the new year holidays I will look at it. So how one can help at this stage: 1. Check related FPC tests and write new for the missing cases. 2. Compare FPC and Delphi RTL classes which had beed adjusted in Delphi during the unicodestring move and check whether something minor can be added to FPC. All major changes like the new TStringList class based on UnicodeString should wait for 2.8 release. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] question on dwarf2 info written by fpc 2.6.2
06.10.13, 3:08, Martin пишет: On the other hand var a: longint; generates the same. Why? Because Integer is an alias - inside compiler only the symbol is different for thise case and the definition is the same. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible issue with 2.7.1 string encodings
25.08.13, 20:44, Martin пишет: To find some info I added debugln as follows. Note the part PInteger(ASource)[0], // just some part of the string, for verification PInteger(ASource)[1], // on 2.7.1 Encoding ? // on 2.6.2 length PInteger(ASource)[-2] // on 2.7.1 length // on 2.6.2 ref count. Don't guess, just look at astrings.inc TAnsiRec. Only something changed its encoding. I have no idea what... Please look whether you have UTF8String type somewhere or you use a constant from a unit with BOM. In this case UTF-8 will be converted to DefaultSystemCodePage encoding. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Little feature teaser
04.08.13, 20:20, Sven Barth пишет: Then I just need to wait until you've done the 635364 other items on your list. Sounds doable :P This is not doable even if Florian will do 10 items per day. The life is not as long as we wish. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TTypeKind, strings and chars
01.06.13, 6:48, Maciej Izak пишет: Hi, I'm creating another more advanced (and 99% compatible with Delphi) version of the library Generics.Collections (without GetValueSize and GetReferenceToValue specially for Sven :P) and I have some dilemmas about TTypeKind. What happened to tkLString? All strings with code page, UTF8String, AnsiString, RawByteString etc. become tkAString. In Delphi analogous types are as tkLString. tkLString is deprecated/dead? ;) I can't find the type that have tkLString type kind. Compiler uses internally some LongStrings which is not possible to use for variable declarations. I don't know whether this type is needed in RTTI. And yes, Delphi uses tkLString instead of tkAString for ansistrings. Another thing: Why there is tkUChar when we have tkWChar?... I can't find the type that have tkUChar type kind too (UnicodeChar is tkWChar). I also don't know why we have it. Compiler does not use it. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
29.05.2013 14:06, Michel Catudal пишет: The one that I compiled before the code was broken To answer on your question I need to know paticular compiler version. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Crash while compiling fpc 2.7.1 on ARM
29.05.2013 10:09, Michel Catudal пишет: My platform is odroid U2 with funtoo Linux, desktop is mate. Processor is a 4 core arm processor from Samsung, running at 1.7Ghz with 2G of RAM, OS runs on a 32G SD Card. I also have an Ubuntu system also on a 32G SD card, haven't tested fpc compile on it yet. A few weeks ago I was able to compile fpc with hard float support on odroid U2. I still have it along with lazarus. I have created a few graphic programs, they work like a champ so far, no crash. For the past few weeks fpc no longer compiles. It works until it is time to compile the RTL. What starting compiler do you use? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures via interfaces
27.05.2013 15:32, Sven Barth пишет: The new extended RTTI introduced in Delphi 2009 which allows access to private/protected/public members as well together with attributes and things like TVirtualMethodInterceptor, Invoke and TValue. Sven, I did not ask what and how delphi implemented. I asked Maciej Izak what he wants from extended RTTI. Maybe this is a small subset which is not very hard to implement. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures via interfaces
27.05.2013 17:17, Maciej Izak wrote: Unfortunately, Sven is right :). I need this to share another free library for FPC. It was originally intended for sale to the Embarcadero. Absolute automatic binary streaming (seriously, for each type that exists in Pascal, including Class, ClassRef, Interfaces, Pointers, menaged records with help of attributes). Small demo: ... 1. Extended RTTI (especially with attributes and access to private/protected/public members. This library don't need TVirtualMethodInterceptor, Invoke (but I think attributes needs Invoke :( ) and TValue) If you don't need RTTI unit then it will be much more simplier to implement your requirements. Attributes are half ready in a branch. RTTI for non-published elements (together with $RTTI directive) is not a very hard task. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures via interfaces
27.05.2013 5:52, Maciej Izak пишет: So I am waiting impatiently ^^. I think it's interesting time for FPC! To be completely happy, there is only one seriously lack - extended RTTI. :) RTTI has been extended recently: http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes Please tell what exactly you are waiting for? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] issue with trunk and dyn array
17.05.2013 0:24, Jonas Maebe пишет: On 16 May 2013, at 17:43, Martin wrote: using rev 24475 the below fails. It works using 2.6.0 Afaik it should work? dynamic types (such as TDynIntArray ) should be initialized? Yes. The RTTI for that type seems to be completely messed up in current trunk. Probably caused by r24458. Dynamic arrays were not touched by this revision. I only changed RTTI for non-dynamic array types. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] issue with trunk and dyn array
17.05.2013 8:59, Paul Ishenin пишет: Yes. The RTTI for that type seems to be completely messed up in current trunk. Probably caused by r24458. Dynamic arrays were not touched by this revision. I only changed RTTI for non-dynamic array types. Heh. But in the Martic example was array[...] of dynamic array which was wrongly treated as 2-dimension array of integer. I've fixed that in r24522. Sorry for error. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] properties accessing field of nested object ?
13.05.13, 18:36, Martin пишет: Makes sense, since it does not work for properties, but only for fields. The access to record fields is intended though? Yes. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Announcement: RTTI extension
Hello, FPC developers' list Please note the following changes regards RTTI for some types: 1. RTTI for Pointers and Class References is now generated by compiler with an ability to get a pointed type. 2. RTTI for AnsiStrings now allows to get an initial Code Page an AnsiString type (it may be changes at any moment by SetCodePage()). 3. RTTI for arrays has been significantly changed and now is public. Previosly RTTI for arrays was used only internally by RTL low level functions. 4. RTTI for Procedural Variables now contains information about calling convention, arguments and result type. 5. RTTI for Record managed fields has been adjusted to match internal compiler reprenstation. There were few motivations for these changes: user requests, RTL needs (AnsiString CodePage) and Delphi compatibility (where that was possible and reasonable). You can find an example of how to deal with this new RTTI and some more information by the following link: http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit for handling UTF-8 strings
09.04.2013 15:13, Mattias Gaertner wrote: Will there be UTF-8 functions too or do you have to convert to UnicodeString? At the moment TCharacter contains methods which delphi TCharacter has. If there is demand we will add UTF8 overloads. Will there be PUnicodeChar functions too? // flat functions function ConvertFromUtf32(AChar : UCS4Char) : UnicodeString; function ConvertToUtf32(const AString : UnicodeString; AIndex : Integer) : UCS4Char; overload; function ConvertToUtf32(const AString : UnicodeString; AIndex : Integer; out ACharLength : Integer) : UCS4Char; overload; function ConvertToUtf32(const AHighSurrogate, ALowSurrogate : UnicodeChar) : UCS4Char; overload; Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit for handling UTF-8 strings
09.04.2013 17:10, Sven Barth пишет: Demand+=1 (1,8) Error: Illegal expression (1,9) Error: Illegal expression (1,9) Fatal: Syntax error, ; expected but ordinal const found (Sorry, had to be said :P ) Also, Patches variable seems to be equal to zero. And assigning Demand without assigning Patches has almost no effect :) Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit for handling UTF-8 strings
09.04.2013 18:09, Mattias Gaertner пишет: Creating a patch is not hard. The lazutf8 already contains the code. But I have no idea how the the interface should look like. TCharacter is a Delphi class and Delphi does not have UTF-8 functions. Michael wrote that these functions are implicit, so maybe these functions need to fit some form? In other words: Are there any suggestions, recommendations how the UTF-8 functions should look like? Let's see. The next function should stay as is. Compiler will add required implicit conversion when you assign result to UTF8String variable. function ConvertFromUtf32(AChar : UCS4Char) : UnicodeString; Here you can add UTF8String overloads if needed: function ConvertToUtf32(const AString : UnicodeString; AIndex : Integer) : UCS4Char; overload; function ConvertToUtf32(const AString : UnicodeString; AIndex : Integer; out ACharLength : Integer) : UCS4Char; overload; At the same time even without UTF8 overloads compiler will insert implicit conversion from UTF8String to UnicodeString when you pass it to that functions. So UTF8 overloads can only increase spead by removing 1 implicit conversion. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Should the compiler work, if compiled with -Cr?
16.03.13, 17:55, Jonas Maebe пишет: It definitely should work (there's even a special extcycle target in the compiler Makefile to test it), and has worked mostly in the past. It's not always checked and occasionally does get broken though. I tried to run a testsuite with compiler and packages built with -Cr. It has more failures than a regular build. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Should the compiler work, if compiled with -Cr?
16.03.13, 1:54, Martin wrote: revision 23848 As reported recently: make clean make.exe allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT=-gl -O2 No, it does not work. Testsuite has many failures too when the compiler is built with -Cr. Why this is a problem for you? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] crash when building trunk
12.03.2013 5:24, Martin wrote: So failure is on my side. But I expect that if it failed, it still should not crash. I am not sure in which step it was, when it crashed. I will not crash if you remove -Cr from your make string. I don't know whether compiler can be used with range checks. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 15:57, Michael Van Canneyt wrote: With such an attitude you should remove objfpc (and perhaps all non-delphi modes) alltogether, and rename Free Pascal to Free Delphi. The situation with FPC and Delphi is very like to what had happened with browsers. Every had it own vision of CSS, JS and HTML. Currently then finally understood that these dirrences are bad. So if I could I would organaize some forum between Delphi and FPC developers where all new features before been implemented had been discussed first and if accepted nobody could implement it different. I tried to contact with some delphi team members on their forum on twitter and on some blogs but without result. Regards FPC, I would indeed remove FPC mode. Those who need it can use FPC 2.6. I would also minimize the difference between objfpc and delphi modes. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 16:30, Sven Barth wrote: Just to say one thing clear: I will NOT drop FPC's generic implementation and I'll revert every commit that tries to do so, because Sven, relax - FPC is not your own project and not mine. We can't simple commit or revert what we want. not only do we have to keep backwards compatibility, but the Delphi syntax is a nightmare to parse. Yes, it is hard to parse but anyway you need to implement it. So this argument if false. And regards backward compatibility - it is not too much places to fix: some in FPC itself and some in Lazarus components. Mode ObjFPC is not for Delphi compatiblity. It's there to implement a cleaner variant of the (Object) Pascal language (and Michael wrote), and if that means higher maintenance burden, so be it. That cleaner variants split pascal for nothing - to make 3-5 developers happy. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 17:14, Sven Barth wrote: Just for your information: I will implement generic methods will full requirement for generic and specialize in mode ObjFPC (and no, you can't change my opinion on that). Yes, I didn't expect my mails will suddenly change your opinion. And even if they would change there are enough fpc team members who will protected objfpc generics :) I only hope to stop duplicate implementation of other delphi features. And regarding backwards compatibility: we are not only talking about FPC and Lazarus. There are enough people around that use FPC's generic syntax and that alone is reason enough to keep it. Enough - how much? 50 or 100 projects? What will be needed to make them work with dephi syntax? Remove word generic and specialize? Especially those that don't care about Delphi compatibility. Also it seems that those that like to develop in Delphi are the only ones complaining... Think about component and applications developers who need to care about FPC and Delphi. Less incompatibilities FPC will have more 3rd party components and applications it will get. I remember author of Total Commander who had failed to port his project to FPC + Laz because of many incompatilities in both projects. I remember Fib+ developer who stoped his effort to port component to FPC after some found incompatibilities. There is nothing good in incompatibilities. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 17:12, Michael Van Canneyt wrote: Of course we can, if you violate a basic rule: do not undo other peoples work. Can you imagine me or anybody other in FPC team who do so without total agreement? It does not split. It offers people the choice. Again we see one thing from different sides. For me this is not a benefit but defect requires elimination. This is the basis of open source: Having a choice. Yes, but I'd love to see this choise not inside 1 project. We do not deny you your work on Delphi mode. We expect you not to deny us our work on objfpc mode. Okay. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 17:55, Sven Barth wrote: @Paul: see? :) I see you, Graeme, Michael and probably some more 5-6 developers. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 21:00, Marcos Douglas пишет: So now we have 7! ;-) I want to keep the language sane too. I wrote not about sane/insane. Delphi adds features to pascal the way they want - this is reality. We can't do anything with this. If they add a feature not the sane way we can't undo their feature. From that moment language become so - with this feature. Whether we want or no. Sooner or later we will have to deal with this feature exactly as Delphi developers see it. What I was against is to add the second implementation for already existent language feature. But after mail of Michael I already look at this more tolerant now. So please let's stop this endless dispute about nothing. We have different vision and this is good after all. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
05.03.13, 14:10, Sven Barth wrote: ObjFPC mode is not compatible with mode Delphi, because of conscious decisions. Think for example about the @ for procedure variable assignments here or the use of symbolic operator names for overload declarations, instead of words like Delphi did it. And generics are a further example. And I would left (if needed) only those minimal differences. Or even tried to reduce (removed own generics implementation and left only Delphi compatible). In any case I would not add more incompatibilities. Many times the main point to have incompatibilites was: We implemented it earlier. But regards generics how we implemeneted it earlier? Even now they have some bugs/missing features. And in 2009 when Delphi announced them they had much more (you know of course). That was more a prototype of generics. But inspite of that we did not drop our own implementation. Regards for-in loop. To add it to objfpc mode I had to add 'enumerator' keyword. Who uses it? 1.5 developers who wants to see pascal clean? Besides that I'm not against own features like string case or '+=' operations but I strongly against 2 implementations of 1 feature: one to be delphi compatible, one to satisfy few people from pascal community. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
03.03.13, 22:09, Alexander Klenin пишет: I agree with the plan. But I am not sure about the order -- perhaps implement Delphi-compatible variant first, since it have to be done anyway, and there is already a spec for it. I also vote for Delphi-compatible feature the first, then implement extensions. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC-JVM: Problem with with in nested records
12.02.2013 18:58, Nicola wrote:
Rec1.a := 123;
Log('with: ' + IntToStr(Data.Rec1.a));// !!FAIL!!, it
shows 0
Non JVM compiler outputs 123. So indeed a JVM compiler bug.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
08.02.13, 21:52, Gerhard Scholz wrote:
Maybe I didn't understand the syntax correctly: I didn't see how to get
the value inside the method?
By accessing Self
example:
type
TLongIntHelper = type helper for LongInt
class procedure ShowValue; static;
end;
class procedure TLongIntHelper.Test;
begin
Writeln('Value=',self);
end;
Replace your static class procedure with regular method:
procecure TLongIntHelper.Test;
begin
WriteLn(Self);
end;
Class static method is only needed if you are going to call it for the
type declaration itself like: LongInt.PrintSize:
class procedure TLongIntHelper.PrintSize;
begin
WriteLn(SizeOf(LongInt));
end;
static methods don't have a magic Self variable.
In any case I suggest to look for test which had been commited together
with Sven patch.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
08.02.2013 7:30, Gerhard Scholz пишет: 0:25:46,51 G:\ob\syncdirsppc386 -vv -al -CioOrt -Cs600 -gclt -Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u -Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u -FiP:\gs\tp55\includes -Fif:\-u -FE. thelper thelper.pas(2,33) Error: Identifier not found helper thelper.pas(2,33) Error: Error in type definition thelper.pas(2,33) Error: Can't create unique type from this type thelper.pas(2,33) Fatal: Syntax error, ; expected but FOR found Fatal: Compilation aborted The compiler is freshly generated from the SVN Does the compiler expect special options to invoke the record helper feature? Nothing. On objFPC mode which you use they are enabled by default. It is something with your compiler. Mine compiles your code. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-announce] Feature announcement: Type helpers
08.02.2013 14:03, Sven Barth пишет:
0:25:46,51 G:\ob\syncdirsppc386 -vv -al -CioOrt -Cs600 -gclt
-Mobjfpc -O1 -OpPENTIUM -Fuu:\ -FuM:\u -FuC:\c\-u -FiC:\c\-u -Fuz:\-u
-Fiz:\-u -FuP:\gs\tp55\includes -Fuf:\-u -Fiu:\ -FiM:\u
-FiP:\gs\tp55\includes -Fif:\-u -FE. thelper
thelper.pas(2,33) Error: Identifier not found helper
thelper.pas(2,33) Error: Error in type definition
thelper.pas(2,33) Error: Can't create unique type from this type
thelper.pas(2,33) Fatal: Syntax error, ; expected but FOR found
Fatal: Compilation aborted
The compiler is freshly generated from the SVN
Does the compiler expect special options to invoke the record helper
feature?
Did you add {$mode objfpc} to your program?
Look at the compile string argument: -Mobjfpc
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
06.02.13, 19:29, Michael Schnell пишет: but I feel point.x := x; point.y := y; s := point.ToString; is most clear. This is what you can already do in FPC 2.6.0 with advanced records feature active. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Type helpers
06.02.13, 21:51, Alexander Klenin пишет: On Wed, Feb 6, 2013 at 10:31 PM, Michael Schnell mschn...@lumino.de wrote: point.x := x; point.y := y; s := point.ToString; or s := (x,y).ToString; Has there not recently been a discussion on Tupels ?!?!?! :-) At least according to my proposal, tuples will not be a type, so you'll have to force a type by constructor: s := TPoint(x,y).ToString; or, as it is currently, by a special function: s := Point(x,y).ToString; or with a record constructor: TPoint.Create(X, Y).ToString; Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
29.01.13, 17:23, Hans-Peter Diettrich пишет: Paul Ishenin schrieb: At least it's more fun to implement something very new, instead of working on incomplete parts (loadable libraries, targets) which had been delayed due to problems. The same situation in Lazarus and in many open source projects BTW. Where are your patches for loadable libraries and new targets? Where are the bugs to fix? I don't know. I thought you know that since you wrote about them. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 20:33, Graeme Geldenhuys пишет: On 01/25/13 08:07, Michael Van Canneyt wrote: Delphi 7 object pascal could be learned very easily. Nowadays with all the features added you go, try and explain pascal to someone. Say it is 'nice and readable'. +1 Generics, for-in loops, anonymous methods, classes defined inside classes etc... I have and see no need for them, and they simply complicate the beautiful Object Pascal language (at least from the D7 days). Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. I used for-in loop many times in my applications simple because it reduce the code and therefore makes it more readable. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. I use avanced record syntax because it makes code more understandable. I scarry to use generics but that simple because they have many bugs. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:20, Michael Van Canneyt wrote: Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) Very weak argument :) In your work you use system APIs and other frameworks which are made in C, C++ or assembler. I believe you don't understand everything and if you don't - you use the reference if needed. The same way with pascal - if you don't want to learn new features then use libraries as black boxes but if you need then use a reference. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Since you can do the same with simple named methods too, I see no need for creating the readibility horror that results of it. It is a readability horror when for injecting a small piece of code as anonymouse method in place where it is needed you *must* declare a new named method (which will no be used anywhere else) few screens up or down. It offers nothing that objects didn't already have. It offers understandable memory layout without VMT. Just trying to say that this is one of these things where Delphi could simply have re-instated the TP-style objects. The compiler compiled them anyway already. There was no need to burden records with methods in an attempt to make them 'object-like'. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:27, Mattias Gaertner пишет: You are free to not use a feature, but you must understand all when using third party code. And the new features are neither easy to understand nor to remember. Already replied to Michael. You don't need to understand third-party code the same way as you don't need to understand API sources. For winapi and cocoa you don't even have the sources to understand something. True. But it adds quite a lot of stuff and a simple loop can become much slower. True. Classes adds quite a lot of stuff and simple procedures can become much slower. Let's don't use them. I also used types inside classes - this is a great feature. I don't need to polute global namespace with internal types. True. What about nested classes? Class is just one of the types pascal have. If for some reason you need to use internal class - use it. But in my practive I mostly need some enumerations. I would use anonymouse methods in pascal - I use them in javascript when I need to perform something asynchronosly. Correct me if I'm wrong, but all the alternatives in javascript have some drawbacks, you don't write big programs in javascript and the anonymous methods easily confuse the javascript debuggers. You can use named methods too wihout drawbacks. Of course one of the benefits of anonymouse methods is javascript is access to local variables. And I don't notice that chrome debugger is confused much by them. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
28.01.13, 21:51, Michael Van Canneyt пишет: Enough bickering; it is useless. We will not agree, no matter how many arguments are presented: simply because the arguments are of a metaphysical/human/whatever nature, and not technical. Agreed. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
29.01.2013 9:51, Hans-Peter Diettrich wrote: As a strong argument: you *must* understand everything when you want to read other people's code, which use the new language features :-( Only if you want this. And if you want a new feature will not stop you. Your brains learn something every day anyway. And I believe that the majority of features which you touch below are easy to learn and understand. At least it must be much easier to learn and understand than code from fpc\rtl\i386 which nobody complains about. IMO most of the new features had been added *only* for .NET compatibility. But since Delphi.NET is dead, I see no need to introduce them into FPC, where .NET never was on topic. But I understand that the compiler developers need something to put their hands on, so that the new language features come in at the right time. The Delphi developers had a goal (.NET) and limited time, while the FPC developers have time and look out for new goals. At least it's more fun to implement something very new, instead of working on incomplete parts (loadable libraries, targets) which had been delayed due to problems. The same situation in Lazarus and in many open source projects BTW. Where are your patches for loadable libraries and new targets? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
26.01.13, 2:32, Michael Van Canneyt пишет: Pascal is an explicitly declarative language. Anonymous functions go 100% against this. It is the readability horror I associate with Javascript. I wonder where you were when Operators feature has been added to pascal? Or generics? I think now when operators for simple types are present in the language it is too late to care about explicitly declarative language. It is simple not explicit anymore. And index (or better to call it key) extension for for-in loop will not make it less explicit for sure. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
26.01.13, 4:47, Sven Barth пишет: I definitely have to disagree here (while still not having an opinion on the topic for-in-index itself): once you've worked on Delphi style generics you know what messy parsing is... and I already get nightmares thinking about what I still need to add for Delphi's generics support... This for-in-index is a peace of cake to parse in comparison. I confirm. When I tried think how to add delphi like generic parse to language I also had this nightnares. As result I simple stoped to work on them. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
25.01.2013 11:47, Василий Кевролетин пишет: May be you understood what I'm from university in wrong way. It does *not* mean what I need to quickly do any changes anywhere. It means what I have resources /(time, motivation, direct support of very good programmer) /to improve good open project. Work will not have any good value for me if results of work will not have any good value for other people. That's good that you have resources and motivation. The question is where to apply them. I understand why you don't want to support bad features. But I don't understand why reasonable extension of existing feature (which will not break compatibility and which exists in other languages) is bad ? :) You need to look at another Michael mail where he claims that he was against for-in loop feature when it had going to be implemented. So no suprise that he is against extending it now. Michael, please don't demotivate our potential compiler developers :) Let's look how suggested feature makes compiler worse. Some answers I already know, some needs to be clarified: 1. Does it adds new (semi-)reserved words? No, index is already a semi-reserved word which is used for property declaration. So scanner will not be changed. 2. Does it influence other features than for-in loop? As I see, other parts of compiler will not be changed. 3. Will it add much code which is needs to be supported? I don't know but expect it will add not much. Vasiliy, can you put your patch somewhere to look at overall compiler change? 4. Jonas, can you tell about for-in loop for objective-pascal dialect? I know it implementation depends on some Objective-C classes. Do they support current index/key return? Do you against 'index' extension for ObjP dialect and in general? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
05.01.13, 19:40, Jonas Maebe пишет: You can put anything in it and it may or may not work depending on the current system code page, but afaik the only thing that is guaranteed to work at this time is plain ASCII. ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStrings as UnicodeString type. I think FPC will follow this in m_default_unicodestring modeswitch. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)
05.01.13, 23:54, Michael Van Canneyt пишет: You are very much wrong. To start with, resource strings are not stored as Win32 resources. I personally think that resources should be stored in their native formats where is possible. This will allow to change them using software designed for that environment. For example for windows there are many resource editors which can replace icons, bitmap and string resources too. It would be nice to have this ability also for binaries which FPC do. On OS X resources are also stored different from what FPC do currently - they are stored in application bundles as I know, so they can be edited by external programs too. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
25.12.12, 21:59, Yury Sidorov пишет: Hmm, Seems to be a false alarm :( I've made some tests just now with memory allocation and found that such pooling will not speed up the compiler too much. Only minor improvement such as 10-20% :( 10-20% is still much better than nothing. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Considerations about observer [was: Free Pascal 2.6.2 rc1]
28.11.2012 16:23, Vincent Snijders wrote: 2012/11/28 michael.vancann...@wisa.be It IS a big change. There is production code out there that uses this, and this is an incompatible change. Then Luiz is right on time with his proposal, with the frist release candidate of the first release that contains this feature. If production code already uses it, then the production code writers must have taken a risk for change knowing that this was a not yet released feature. This is exactly my minds. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC related fairy tale
18.10.12, 21:29, Jonas Maebe wrote: On 18 Oct 2012, at 15:22, Tomas Hajny wrote: I'd guess for one of the left-overs from the 1.0 - 2.0 transition (on the compiler side). Since I've never been involved so deeply in the compiler area, I can't remember the topic well, but I can remember repeated references to a need for rewrite of one of compiler parts - possibly something related to PPU loading / writing? Possibly, yes. Both Peter and I worked on that. And I believe Sven mentioned in the past he needed it for some generics-related functionality as well. I also think that should be something generics related since Sven is working on them last time (as well as on record helpers for simple types). Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] MemSize
Hello, FPC developers' list. What should MemSize function do? Should it return the same info for statically allocated memory? I don't see any documentation on MemSize function here: http://freepascal.org/docs-html/rtl/system/memoryfunctions.html So I decided to test it since we rely on it in LCL: var Data: array[0..2] of Integer; begin WriteLn(MemSize(@Data[0])); end. Without heaptrc on 32bit windows: 4294967284 With heaptrc: 0 -- Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] corba interface casting
Hello, FPC developers' list I have a code with 2 parent-child corba interfaces and 2 parent-child classes: Intf1 = interface ... end; Intf2 = interface(Intf1) ... procedure DoSomething; end; Class1 = class Intf: Intf1; function GetIntf: Intf1; virtual; end; Class2 = class Intf: Intf2; function GetIntf: Intf1; override; end; function Class2.GetIntf: Intf1; begin Result := Itnf; // this is Intf2 end; var C: Class2; I: Intf2; ... I := Intf2(C.GetIntf); Is this a correct interface cast? If not then how to cast one corba interface to another propely? I'm asking because without -CR the code compiles and with it gives an error Error: Class or COM interface type expected, but got Intf2 Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] corba interface casting
01.10.12, 23:40, Sven Barth wrote: I := Intf2(C.GetIntf); Is this a correct interface cast? If not then how to cast one corba interface to another propely? I'm asking because without -CR the code compiles and with it gives an error Error: Class or COM interface type expected, but got Intf2 Did you try with C.GetIntf as Intf2? That should be the correct way to do this... Yes, but it does not work. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
19.08.12, 15:18, Martin Schreiber wrote: Hi, In 2008 and 2011 there were threads about FPC and Unicode resource strings with the conclusion that FPC does not support them. Are Unicode resource strings implemented in FPC now? I did not find it in documentation. At the moment FPC resource strings are still ansi strings even in delphi unicode mode. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to set code page in terminal? (Windows)
22.06.12 5:39, silvioprog пишет:
Hello,
I'm trying to write Atenção in terminal, but it writes At├º├úo
instead of Atenção (please see http://imagebin.org/217387 ). :(
...
program test;
{$mode objfpc}{$H+}
try {$codepage utf8} or add an utf8 BOM because your constant is encoded
in utf8.
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Differences between 'tsym' and 'tdef'
18.05.2012 14:23, Joost van der Sluis wrote: This information can be bound to a properties but also whole classes at least. (I'll have to test for methods and public fields) So no, not only properties may have this information. If methods may have this information then it is not possible to put it to tsym because paticular method is a tprocdef and several tprocdefs may have 1 tprocsym (overloaded methods). Therefore I would put this info to tstoreddef. But what to do with a property? Create a special def for it? And, to answer your second question, properties in a descendant class do *not* inherited the properties of the ancestor. I found that pretty strange, but that's how it is implemented in Delphi. There may be 3 cases. Does it work in any: case 1: property descendant TAncestor = class [attributes] property SomeProp: TSomeType read GetSomeProp; end; TDescendant = class(TAncestor) property SomeProp write SetSomeProp; // - this is property descendant end; case 2: new property hides old TDescendant = class(TAncestor) property SomeProp: TSomeType read GetSomeProp; // - this property hides old SomeProp end; case 3: new class uses property as is TDescendant = class(TAncestor) end; So in this case create a special symbol and symtable for it? Looking at http://docwiki.embarcadero.com/RADStudio/en/Annotating_Types_and_Type_Members I see that attribute is a class + a list of arguments for that class contructor. As this is a class - compiler already creates a symbol and a definition for it and all it members. So you need to store a link to this class (or to class contructor) + a list of arguments to pass there. So it is not a special symbol, just a reference to it. If you need an example of how to store/restore reference to a class then look at how it is done with tobjectdef.childof or tobjectdef.extendeddef. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Differences between 'tsym' and 'tdef'
18.05.2012 15:49, Joost van der Sluis написал: Indeed. And I do have the symbol of the corresponding type and a list of parameters already. I thought I needed a symbol/definition to store the references. Else I would have to store those references in the TPropertySym, but also in the symbol of the class. That doesn't look good to me? I think you need to store this information both in TStoredDef - for classes, records, enumerations, arays, ordinals, functions. At the same time you need to store it in tpropertysym, tfieldvarsym (maybe TStoredSym) since they are not definitions. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Differences between 'tsym' and 'tdef'
18.05.12 5:32, Joost van der Sluis wrote: Now I'm wondering if I should make this new field of Tpropertysym a TDef or a TSym(table). I know that Tsym can store itself to a ppu while a TDef does not. But There was something else, too. But I don't remember exactly. TSym is about symbol and TDef is about definition. Each symbol is just an identifier which compiler founds during parse which may have 1 definitions (overloaded functions for example). A definition does not have a name (generally) but instead have information how to work with it. It may refer to no symbol at all. Both are stored in a TSymTable and ppu (look at TStoredDef). A property does not have a definition of itself - only a symbol and list of fields/procedures for read,write,stored. So two questions: how should I extend the Tpropertysym for the extended attributes, and what is the dfference/use of Tdef and Tsym. Does any symbol in delphi may have this information? If property has this information and you created a descendant property - will it have the same attributes as an ancestor property? For now if only property may have this information then choose TPropertySym for storing it. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Problem with nested classes and const struct values
05.05.2012 11:08, Andrew Brunner wrote: Ok, Attached is a sample program that demonstrates the problem. FPC 2.6.0 compiles just fine. FPC Trunk has a problem. Probably this happen because of some bug fix because I have the same error in delphi: htest.pas(44) Test.lpr(41) Error: E2003 Undeclared identifier: 'CLSInfo' Test.lpr(42) Error: E2003 Undeclared identifier: 'ACLInfo' Test.lpr(49) Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Problem with nested classes and const struct values
05.05.2012 14:23, Paul Ishenin wrote: Probably this happen because of some bug fix because I have the same error in delphi: htest.pas(44) Test.lpr(41) Error: E2003 Undeclared identifier: 'CLSInfo' Test.lpr(42) Error: E2003 Undeclared identifier: 'ACLInfo' Test.lpr(49) Although if I change your sources to: Header:TCoreObjectInfo=( ID : 0; ProviderID : 0; Enabled : true; Anonymous: false; NotifyOnBuffersChanged : false; Scale: 0; CLSInfo : @Root.Test.CLSInfo; ACLInfo : @Root.Test.ACLInfo; ); then delphi start to compile while FPC still does not. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
02.05.2012 15:00, Hans-Peter Diettrich wrote: To the user this means not compatible with D7 nor D2009 :-[ It is both compatible with D7 and some D2009 features. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
02.05.12 18:18, Graeme Geldenhuys wrote: So instead of jumping around with various delphi versions (a bit of D7 and a bit of 2009 etc), maybe start from the oldest delphi version (eg: D7) and move towards the newest? Maybe you can teach us how to do this by sending appropriate patches? We will sit then and criticize them. If you don't like the dish - cook yourself. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
02.05.12 21:32, Graeme Geldenhuys wrote: Maybe the FPC core team will be so kind as to create a new FPC features since xxx page on the wiki (similar to what I have done for Lazarus). From the anouncement of FPC 2.6.0 which was posted to this mail list: Changes that may break backwards compatibility are documented at: http://wiki.freepascal.org/User_Changes_2.6.0 ... Details about these new features can be found at http://wiki.freepascal.org/FPC_New_Features_2.6.0 Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug #0021641: Array of const gives check range error
04.04.2012 17:08, kyan написал: Delphi doesn't support qword at all, so there is no Delphi behaviour to be compatible with in that case. Or at least it didn't when the above was implemented. Does it now? No, it does not. Delphi XE has a UInt64 type. From the documentation: UInt64 represents a subset of the whole numbers. The range for the UInt64 type is from 0 through 2^64-1. The UInt64 format is unsigned 64-bit. Therefore it is equivalent to FPC's QWord type. The question was about TVarRec structure, was not it? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class section (public, private) in debug info
20.03.12 19:02, Jonas Maebe написал: That's of course a very old version of gdb (some fork based on 6.3.50), so maybe it's a regression. As I remember this was fixed in fpc trunk only? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] global property, with getter in other unit
28.02.2012 9:11, Martin пишет: Attached. It needed 3 units, accessing Foo in the same unit, in which it is declared (unit2) compiles (not tested if it runs...) You found some bug in the compiler. Property can only be declared inside a structure but compiler allowed to do this in a unit level. If this is not some FPC feature unknown to me I will fix it. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] global property, with getter in other unit
29.02.2012 10:20, Martin wrote: If this is not some FPC feature unknown to me I will fix it. http://www.freepascal.org/docs-html/ref/refse24.html#x56-630004.6 questiion is about where the getterr/setter must be defined. btw, they can not be prefixed this fails property FooSinteger read SomeUnit.GetFoo; this passes, but fails from 3rd unit property FooSinteger read GetFooFromSomeUnit; Looks like this old feature was not maintained in the compiler since the intial svn import from cvs. The code contains various errors which was not noticed since 2005 year like: procedure property_dec; begin ... message(parser_e_resourcestring_only_sg); This should give an error about resource strings when you have a deal with a property. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] global property, with getter in other unit
28.02.2012 3:01, Martin пишет: Defining a property in the interface section (outside a class), that refers to methods in another unit, gives an *unexpected* error. It may well be not allowed and then should give an error, but the right error in the right place. Btw, only tested with 2.4.4, apologies if that is fixed in 2.6.0 A none existing function, reports an immediate error, on the line where the property is declared: property Foo: TObject read NoneExistingFunction; But property Foo: TObject read FunctionFromOtherUnit; // OtherUnit is in uses The compiler passes that line without error. But when trying to read the property UnitFoo.pas(999,3) Error: Wrong number of parameters specified for call to FunctionFromOtherUnit Can you submit a more complete example? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Warning: Implicit string type conversion
02.02.2012 17:00, Hans-Peter Diettrich пишет:
I wonder how these many messages occur, even in building the libraries.
Is it only lazyness why according fixes are missing, or are there
reasons why such conversions are inevitable?
Compiler informs that there are places which has suspicious code.
Probably the code there needs a review.
Dumb question: what's the default string type in FPC trunk? When it's
AnsiString, in which situations are UnicodeString conversions really
required, in contrast to pre-UnicodeString versions?
The default string type is ShortString/AnsiString and this depends on
{$h+/-} option. UnicodeString convertions are required when string in
one codepage is converted to another or when ansistring is assigned to
unicode/wide string type.
What about WideString? E.g. fcl-xml contains a lot of WideString types -
shouldn't these be replaced by (or retyped into) UnicodeString now? IMO
only the Windows COM libraries require real WideString (BSTR) arguments,
while the ordinary W API should be happy with pointers to UnicodeStrings.
I agree that better to review fcl-xml code and at least replace
WideStrings with UnicodeStrings.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Warning: Implicit string type conversion
02.02.12 19:51, Hans-Peter Diettrich пишет:
What's the codepage/encoding of AnsiString? Depending on the platform?
DefaultSystemCodePage - this const depends on platform
UnicodeString convertions are required when string in one codepage is
converted to another or when ansistring is assigned to unicode/wide
string type.
In many places I could not find strings of different encoding nor
unicode/widestrings. That's why I asked for other reasons, which in
pre-Unicode FPC didn't require any conversion - in these cases it had
been necessary to convert the strings explicitly, what should be obvious
in the (old) source code.
Can char or string literals or resource strings cause implicit
conversions?
Not themself but operations with them.
What's the encoding of resource strings?
They are still ansistring with compiler codepage (defined by -Fc or
{$codepage}).
In Delphi resourcestrings are unicodestrings but this is not so in FPC
because team still not decided about the default string type.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC JVM snapshot: Android support
20.12.2011 7:00, Mattias Gaertner пишет:
On Sun, 18 Dec 2011 13:45:07 +0100
Jonas Maebejonas.ma...@elis.ugent.be wrote:
On 18 Dec 2011, at 13:22, Sven Barth wrote:
[...]
Yes, that was indeed a bit complicated, but this way I might be able to use the JVM
compiler in Lazarus easily for the creation of Android application (though Lazarus first
needs to learn about the unicodestrings modeswitch,
What's that?
A modeswitch introduced in the JVM branch to turn the string type to
unicodestring (similar to {$H+} turns string to ansistring).
Best regards,
Paul Ishenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC JVM snapshot: Android support
18.12.2011 20:45, Jonas Maebe wrote: And final fields. Final methods can't be overriden in the descendants. But what are final fields for? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC JVM snapshot: Android support
20.12.2011 10:47, Felipe Monteiro de Carvalho пишет: On Tue, Dec 20, 2011 at 1:00 AM, Paul Ishenini...@kmiac.ru wrote: Final methods can't be overriden in the descendants. But what are final fields for? I think they are the way to write a constant in Java. Because they have no procedural elements, they need to work around with class elements to do everything. FPC classes support internal constants so I don't believe Jonas would add another syntax element for already existent feature. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problems with namespaces and structs
16.12.11 1:58, Andrew Brunner пишет: class storage class Folders Type Item=record end; PItem=^TItem TItems=array of PItem Variables in some other unit compile OK. in some other unit: type MyCallback=procedure(Var Items:Storage.Folders.TItems); // linking fails // procedures/functions of these namespaced types fail to link with the following messages /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x1692): undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' /Developer/Source/Builds/Aurawin/Linux/Sync/64/.Output/x86_64-linux/frmMain.o:(.data+0x16ca): undefined reference to `RTTI_$DBMUSERSTORAGE_$$_DEF346' Can Anyone can fix this soon? This particular unit involves heavy namespace usage for complex organization. Can you report a small but full example to the bug tracker? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exception handling differences with Delphi
24.11.11 21:59, Sergei Gorelkin пишет: 1) Delphi uses EZeroDivide for floating-point division by zero, while FPC uses EDivByZero (the same exception class is used for integer division by zero). Should it be fixed? 2) Delphi uses EUnderflow for floating-point underflow condition, while FPC uses EOverflow. Should it be fixed? Noticed that before too when ported my delphi code. I vote yes for both - it will simplify the porting. It is better to handle paticular exception types in the user code than generic Exception class and therefore such differences may cause a malfunction of the application. Btw, this article may be very useful for the task you are doing: http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1392 Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] UnicodeStrings - Variant conversion
14.11.11 11:02, Alexander Shishkin пишет: Currently assigning UnicodeString to variant converts string to WideString and makes variant of type varOleStr. I think it should be varUString and w|o any conversion (also this is delphi compatible). But the question is which type should be if WideString=UnicodeString? I don't remember exactly but it is seems to me that delphi also uses unicodestring for WideStrings on osx. If this is ideed so it will be easy to check. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with Now() and time changed by ntpd
03.11.2011 15:04, Martin Schreiber wrote: No, I can not use trunk because of cpstrnew. I'll try the file Michael sent. If it is not difficult please explain exact problems with cpstrnew you have in a separate thread. It is important to know for me what problems do you have with the new ansistring type. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Problem with Now() and time changed by ntpd
03.11.2011 15:29, zeljko wrote: Maybe it's not problem *now*, but looking into mailing list ppl have a lot of problems, so I think that fear is only problem (at least for me). People mostly expressed their FUD although there were few problems and there are some. But why do you think they should affect you? Do you any ansistring type except 'AnsiString' in your applications? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [iconv][glibc] function iconvctl not found.
23.10.11 20:56, Jonas Maebe пишет: On 23 Oct 2011, at 14:25, Marco van de Voort wrote: Seems that that function is not in the open group's specification of iconv, it is a GNU extension. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/iconv.h.html Ah, yes. Even Mac OS X apparently uses GNU libiconv. So a weak symbol is probably the best solution. Does weaksymbol works on all platforms where cwstrings is used (I know that it is not implemented on windows at least but there we don't need cwstrings too)? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [iconv][glibc] function iconvctl not found.
23.10.2011 20:01, Paul Ishenin пишет: 23.10.11 19:49, 4iter пишет: Hi! Fatal: Compilation aborted .. Maybe fixit it with #ifdef ? How to define this ifdef? Maybe it could be fixed either by dynamic loading or weakexternal directive? I tried to handle the situation by using LoadLibrary, GetProcAddress and also failed on osx. The next line tries to load iconv.dylib while on osx the library name is /usr/lib/libiconv.dylib: iconvlib:=LoadLibrary(libiconvname+'.'+SharedSuffix); Now I don't understand how it works with the static linking if libiconvname variable is iconv? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trunk does not compile on Linux x86-64
19.10.11 21:47, Leonardo M. Ramé пишет: Hi, I'm trying to compile trunk on Ubuntu 11.10 x86-64: Linux leonardo-laptop 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux And get this: ... /usr/local/bin/fpc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/home/leonardo/Desarrollo/fpc/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE ../objpas/sysconst.pp sysconst.pp(243,7) Error: Wrong number of parameters specified for call to $fpc_ansistr_sint sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted ... Are you using the latest released FPC = fpc 2.4.4 to build the trunk? If not please build with it. Building trunk compiler by an earlier version of trunk compiler is not supported. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi new AnsiStrings are incredibly broken :-(
14.10.2011 20:23, Hans-Peter Diettrich wrote: Apart from the mentioned implementation flaws, I came across severe problems with the new AnsiString *model* in general. Let's play around with the Pos() function, which certainly is an inevitable part of any stringhandling. A general function function Pos(SubStr: T1; Str: T2): integer; should return the character index of SubStr in Str, i.e. Str[i] should definitely be the begin of SubStr within Str. Just think of Pos() as it only compares bytes. AnsiPos() should care about encoding too. As I remember AnsiPos() has AnsiString arguments instead of RawByteString and therefore the conversion will be made before the byte compare. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
13.10.2011 14:57, Hans-Peter Diettrich пишет: Paul Ishenin schrieb: 13.10.2011 9:13, Hans-Peter Diettrich wrote: Sven Barth schrieb: http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444view=markup I don't understand the use of encoding 0 and CP_NONE in FPC. Can somebody explain? DefaultSystemCodepage is used When the paticular encoding must be known both for 0 and CP_NONE codepages. What's CP_NONE? Value and purpose? RawByteString codepage. Value $ and purpose - inform that string has no codepage assigned. I think at the moment compiler does not produce strings of codepage $ anymore but before it did. So now we can probably clear the RTL from this codepage checks. It turned out that the result only is correct when at least one of the strings is an UnicodeString. Otherwise Pos seems to end up in a RawByteString compare, with the encoding ignored. That's because if one UnicodeString type is present another Pos() works. In this case the second RawByteString argument converts into UnicodeString with taking encoding into account. Old Pos() works without codepage conversions. This shows the test I gave and other tests. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug report 20473: Please add a directive to define string=utf8string
13.10.2011 15:29, Felipe Monteiro de Carvalho пишет:
Hello,
Posting here as this was requested in the bug report:
http://bugs.freepascal.org/view.php?id=20473
I think it is very simple: Having such a directive would save a lot of
work when porting Lazarus-based projects to FPC 2.7
Wrote to that issue and writing here.
When String = AnsiString you only need the way to set codepage of
ansistring constants to UTF8 and default codepage for conversions.
The first can be made either by {$codepage UTF8} directive or by -FcUTF8
directive.
The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at
the program start.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug report 20473: Please add a directive to define string=utf8string
13.10.2011 16:14, Felipe Monteiro de Carvalho wrote: On Thu, Oct 13, 2011 at 9:44 AM, Paul Ishenini...@kmiac.ru wrote: The later can be made by call SetMultiByteConversionCodePage(CP_UTF8) at the program start. From my comment on the bug report: Won't SetMultyByteConversionCodePage inadvertedly affect 3rd party libraries used by the program which, for example, execute something like: myansistring := mywidestring; And then expect myansistring to be in the system encoding? It will affect as well as compiler directive you suggested to add. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bug report 20473: Please add a directive to define string=utf8string
13.10.2011 16:30, Felipe Monteiro de Carvalho wrote:
On Thu, Oct 13, 2011 at 10:26 AM, Paul Ishenini...@kmiac.ru wrote:
It will affect as well as compiler directive you suggested to add.
No, the directive is per source code file. 3rd party libraries do not
need to use it.
Then use {$codepage UTF8} only. This directive treats all ansistring
constants in UTF8 codepage. So the next code:
{$codepage UTF8}
var
s: ansistring;
begin
s := 'utf8 string';
WriteLn(StringCodePage(s));
end.
will output CP_UTF8 constant.
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Ansistring code page
13.10.2011 21:21, Jonas Maebe wrote: This I don't really understand. This is how delphi works according to my tests. I will retest to be 100% sure. Shouldn't the constant be converted at run time from UTF-8 to the DefaultSystemCodePage to make sure that an ansistring(0) variable always contains strings encoded in the DefaultSystemCodePage? If you assign e.g. a string(866) variable to a plain ansistring variable, then such a conversion is also done, no? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
12.10.2011 16:03, Michael Schnell wrote: I suppose a variable of the type String is pre-loaded with the predefined System encoding ID. If you mean AnsiString then it is loaded with encoding 0 which means default system codepage. It will get the real encoding number after the first assignment. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
13.10.2011 9:13, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/astrings.inc?revision=19444view=markup
I don't understand the use of encoding 0 and CP_NONE in FPC. Can
somebody explain?
DefaultSystemCodepage is used When the paticular encoding must be known
both for 0 and CP_NONE codepages.
Furthermore I suspect that the implementation of
Function Pos(Const Substr : RawByteString; Const Source : RawByteString)
: SizeInt;
is wrong. The comparison must take into account the encodings of both
strings.
Function Pos(c : AnsiChar; Const s : RawByteString) : SizeInt;
is questionable at all, when the encoding of the arguments is unknown or
ignored (as is).
Did you run some tests in delphi for these functions?
Please run the next program to be sure:
{$apptype console}
type
T866Sting = type AnsiString(866);
T1251String = type AnsiString(1251);
var
s866: T866Sting;
s1251: T1251String;
begin
s866 := 'привет';
writeln(s866);
s1251 := 'рив';
writeln(s1251);
writeln(pos(s1251, s866));
end.
I have the bad impression that the implementors didn't understand the
purpose and correct use of RawByteString, or try to implement something
incompatible with Delphi :-(
Do you base your impression on paticular knowlege of how delphi RTL
works or only on your ideas of how it should work?
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new strings, rawbyte type, but what about raw encoding
11.10.2011 15:25, Michael Schnell wrote: I suppose there is a way to just set the encoding of a new string. This should not affect the stored bytes (or words or DWords). Yes, there is SetCodePage() both for AnsiString types and UnicodeString type. Also RTL has SetMultiByteConversionCodePage functions to set default codepage for AnsiString. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
11.10.2011 16:52, Michael Schnell wrote: In fact I still don't understand the difference between a type called RawByteStringand a basic new String that happens to be set to the encoding RawByte. Encoding RawByte as well as encoding 0 (CP_ACP) are both treated as DefaultSystemCodePage at pleaces where the paticular encoding must be known. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sysconst error
11.10.2011 19:29, ik wrote: I'm having a problem compiling FPC 2.7.1 under linux 64 bit: sysconst.pp(243,7) Error: Wrong number of parameters specified for call to $fpc_ansistr_sint sysconst.pp(249) Fatal: There were 1 errors compiling module, stopping Please check that you are building fpc 2.7.1 with fpc 2.4.4 and not with old version of fpc 2.7.1 Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
12.10.2011 4:11, Hans-Peter Diettrich wrote: When I have a variable of type AnsiString, and assign an string to it, then its encoding is reported as 1252 (my system codepage). On Paul's machine it will have a different encoding, I assume? Yes, 1251 here. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc trunk (today) just stops with Fatal: Compilation aborted
10.10.2011 15:54, Michael Schnell wrote: I understand that Lazarus will not be able to run with the NewString version of FPC. Strange logic. How you decided that if something does not do now it will not be able to do the same at future. Semmingly it can't even be compiled. I think the issue Martin reports is not related to the NewString at all. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
11.10.2011 6:10, Martin wrote: I wasn't askin for changing the default. just for how to do procedure foo(x: utf8string); begin end; var a: string; //ansistring, but contains already utf8 foo(a); // do not convert use foo(x: rawbytestring) And what happens if an app did read data from some external source (serial port) and then wants to declare what encoding it is? http://docwiki.embarcadero.com/VCL/en/System.SetCodePage I hadn't seen that. That may help. Though not the best solution... I can call it before calling the foo proc. But I must revert it afterwards, or at sometime later, the string will be translated, when it will be used in a normal string again (yet expected to keep being utf8.. Yes, I know, what i want to do, is not what it was designed for. ultimately a huge update to the entire source will be needed... but now I need a temporary solution until then Don't use utf8string type until all Lazarus code use it. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] new string - question on usage
11.10.2011 6:23, Martin wrote: I'd like to. at curren LazUtils does For this case we have a Russian saying: do not run ahead of the locomotive. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
