Re: [fpc-devel] fp IDE with libgdb
Mark Morgan Lloyd wrote: Jonas Maebe wrote: On 05 Oct 2009, at 15:27, Mark Morgan Lloyd wrote: The fp IDE can drive libgdb to do straightforward debugging on x86 and ARM, there might be failures with complex stuff that I've not been able to test. Those two platforms are no problem, the problems are on PowerPC and SPARC. You're really picking your fights, aren't you? :) The textmode IDE is probably the least maintained part of FPC currently, and Linux/SPARC is not exactly the most used release either :) [GRIN] Yes, and I'm the one trying to get to grips with the IDE "for the common good" starting with finding out exactly what files are being built into it on the different platforms- hence the Perl filter. If SPARC is of any continuing relevance it's because it's possible to get fairly large systems dirt-cheap right now, I've been very quiet on this over the last few months specifically because I was trying to get to grips with the IDE issue... I didn't want to say anything until I was confident of my facts. Note that the code is correct: it's output the Hello World message even though subsequently the debugger is confused. d48656c = #13'Hel'. gdb on SPARC is trying to dereference the string itself. I've fixed this in r13813 in trunk. 0d48. Well spotted :-) OK, I'll get back onto that as soon as I've got a couple more live jobs off my desk. Apologies that once again I've taken months getting back onto this. I checked the code but there was still a problem, however I think that there's a possibility that I somehow screwed up getting the most up-to-date version (I don't claim great experience with SVN etc.). I took a bit of a look at the generated code using -al but I really need to get getting 2.4.0 onto the various development machines and re-test. One question if I may: am I correct in believing that I need to generate the compiler with EXTDEBUG before -an works? Are there any undesirable side effects to doing this? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Marco van de Voort schreef: That is not my call, but I won't commit it. Because all this stuff must be maintained when real solutions come later. if Lazarus needs a quick fix, they should keep it in own SVN. Or use the units from msegui or use the units from tiopf or use the units from (any other group that needed a quick fix). I just do not like that everybody needs to implement this on their own. I would vote to add them in 2.5.1 and you can remove them if you have implemented these things in the RTL. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort wrote: > > More importantly, the stuff in the FCL depends on the RTL, so stuffing in > > the FCL is useless since it would need primitives in the RTL to operate on. > > Does it mean, if i provide a FCL package with: > > unit > UnicodeFileUtils; > > function FindFirst(const Name: UnicodeString) > ... > > function IncludeTrailngPathDelimiter(const path: UnicodeString) > > > type > TFileStreamUnicode = class(THandleStream) > constructor Create(const AFileName: UnicodeString) > > etc... > > it would be rejected? That is not my call, but I won't commit it. Because all this stuff must be maintained when real solutions come later. if Lazarus needs a quick fix, they should keep it in own SVN. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Mon, Feb 1, 2010 at 3:20 PM, Marco van de Voort wrote: > More importantly, the stuff in the FCL depends on the RTL, so stuffing in > the FCL is useless since it would need primitives in the RTL to operate on. Does it mean, if i provide a FCL package with: unit UnicodeFileUtils; function FindFirst(const Name: UnicodeString) ... function IncludeTrailngPathDelimiter(const path: UnicodeString) type TFileStreamUnicode = class(THandleStream) constructor Create(const AFileName: UnicodeString) etc... it would be rejected? thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > > in fpGUI project (fpg_utils.pas unit), having functions like > > fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the > > standard RTL functions, and they will try and handle Unicode file system > > access correctly on each platform. > > Can Unicode file operations become a FCL package? No, since this is part of the RTL, and needs to stay that way out of delphi compat. More importantly, the stuff in the FCL depends on the RTL, so stuffing in the FCL is useless since it would need primitives in the RTL to operate on. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Mon, Feb 1, 2010 at 11:09 AM, Graeme Geldenhuys wrote: > Alternatively you can introduce helper RTL functions. We have done similar > in fpGUI project (fpg_utils.pas unit), having functions like > fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the > standard RTL functions, and they will try and handle Unicode file system > access correctly on each platform. Can Unicode file operations become a FCL package? So it would be RTL implementation independent. As well as always available for FPC user, without need of external GUI packages (i.e. fpGUI, LCL or mse) thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On 02/01/2010 12:26 PM, Marco van de Voort wrote: > Daniel touches the main problem. The string type is compiletime, while the > standard encoding is runtime. > I do see this (that is why I said "If possible", even if I have no idea about what impact this has. Maybe it could be possible to find a way to invent a "one-time conversion" for this class of strings: The first time they are touched they get converted and the next time they are already in place correctly. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Michael Schnell said: > > I feel that the runtime performance overhead necessary for doing the RTL > with dynamically encoded strings is not too big, provided the RTL itself > does not force automatic conversions (e.g. by inappropriately encoded > string constants) . Daniel touches the main problem. The string type is compiletime, while the standard encoding is runtime. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On 02/01/2010 10:53 AM, Marco van de Voort wrote: > It makes sense to take the > encoding closest to the system, to at least allow minimal conversion > scenarios. > Of course ! If the RTL is done with dynamically encoded strings you would need to take care that anything string value that neither comes from the GUI framework (and thus is encoded in a way the RTL designer might know but should ignore as largely as possible to produce as portable code as possible) nor comes from the user code (the RTL designers can't know which encoding they use) is handled appropriately. I suppose most of this is string constants. If possible, those should be allocated with the system encoding at compile time. I feel that the runtime performance overhead necessary for doing the RTL with dynamically encoded strings is not too big, provided the RTL itself does not force automatic conversions (e.g. by inappropriately encoded string constants) . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Op Mon, 1 Feb 2010, schreef Marco van de Voort: In our previous episode, Dani?l Mantione said: Some commercial unices are also using utf-16 afaik, since they haven't switched their TTY to UTF-8 yet. To be investigated. I lean towards RTLString=utf8string; and RTLString=unicodestring on the respective platforms, and then express the RTL in RTLString. No, RTLString=ansistring on Linux and most Unix platforms. Unix is encoding agnostic so if you want to use the native string type you must simple use old fashioned ansistring. This means crossplatform unicode support goes out of the window. I don't like that. It is a consequence if using the native string type. Otherwiser you can just as well use UTF-16 everywhere. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Michael Schnell said: > Right, But exactly this seems to ask for dynamically encoded strings > allowing to do the user code as agnostic of the system encoding as > possible while automatic conversions are made whenever necessary, but > avoided whenever possible. Both string types will probably be fully supported on unicode supporting platforms. The point is what the RTL uses. It makes sense to take the encoding closest to the system, to at least allow minimal conversion scenarios. > (Which as we all know can't be provided in an absolutely perfect way: in > some cases the "agnostic" user code will not work as expected and in some > other cases performance might be reduced due to multiple automatic > conversions). Yes. Note that what I say goes for the RTL, since obviously, in the core library, speed and reducing dependancies is the most important. I don't mind if some XML lib or so is is always either UTF-16 or UTF-8 (depending on pedigree). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On 02/01/2010 10:27 AM, Marco van de Voort wrote: > We are not Codegear, for which everything but Windows is an afterthought. > Right, But exactly this seems to ask for dynamically encoded strings allowing to do the user code as agnostic of the system encoding as possible while automatic conversions are made whenever necessary, but avoided whenever possible. (Which as we all know can't be provided in an absolutely perfect way: in some cases the "agnostic" user code will not work as expected and in some other cases performance might be reduced due to multiple automatic conversions). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Dani?l Mantione said: > > Some commercial unices are also using utf-16 afaik, since they haven't > > switched their TTY to UTF-8 yet. To be investigated. > > > > I lean towards RTLString=utf8string; and RTLString=unicodestring on the > > respective platforms, and then express the RTL in RTLString. > > No, RTLString=ansistring on Linux and most Unix platforms. Unix is > encoding agnostic so if you want to use the native string type you must > simple use old fashioned ansistring. This means crossplatform unicode support goes out of the window. I don't like that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
Op Mon, 1 Feb 2010, schreef Marco van de Voort: In our previous episode, Michael Schnell said: D2009/d2010 are still windows only. Do you think there is any general problem in using D2009 strings with dynamic encoding with Unix ? On the first view I don't see one. In general I prefer to use each platform using its native encoding. Some commercial unices are also using utf-16 afaik, since they haven't switched their TTY to UTF-8 yet. To be investigated. I lean towards RTLString=utf8string; and RTLString=unicodestring on the respective platforms, and then express the RTL in RTLString. No, RTLString=ansistring on Linux and most Unix platforms. Unix is encoding agnostic so if you want to use the native string type you must simple use old fashioned ansistring. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, Michael Schnell said: > > D2009/d2010 are still windows only. > > > Do you think there is any general problem in using D2009 strings with > dynamic encoding with Unix ? On the first view I don't see one. In general I prefer to use each platform using its native encoding. Some commercial unices are also using utf-16 afaik, since they haven't switched their TTY to UTF-8 yet. To be investigated. I lean towards RTLString=utf8string; and RTLString=unicodestring on the respective platforms, and then express the RTL in RTLString. Since both types can be passed to another for the most, aside for a few VAR functions this is transparent, and leaves the decision to the user what his main string type is, and how many conversions he wants to allow or avoid. Moreover, it allows for passing UTF-8 strings to system functions on freebsd/linux in the base system (which could be benificial for the smaller utils and the compiler itself), since then just passing it on does not require cwstring We are not Codegear, for which everything but Windows is an afterthought. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On 02/01/2010 09:46 AM, Marco van de Voort wrote: > D2009/d2010 are still windows only. > Do you think there is any general problem in using D2009 strings with dynamic encoding with Unix ? On the first view I don't see one. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > Now, i see, the technical solution is not easy. > > > The point is more or less to come up with some logical system, not just > > random additions when something is missing. > > FPC will be forced to catch-up with D2009, anyway. Yes, but D2009/d2010 are still windows only. This is probably going to change with Codegear's crosscompiling plans (expected in +/- august/september). Otoh they'll probably keep everything UTF-16, since that is what they are used to. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Mon, Feb 1, 2010 at 11:31 AM, Marco van de Voort wrote: > Which requires libc, and *nix supports UTF-8 directly. Now, i see, the technical solution is not easy. > The point is more or less to come up with some logical system, not just > random additions when something is missing. FPC will be forced to catch-up with D2009, anyway. I guess Win32 Unicode problem will be fixed on LCL level. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > > What would you do on Unix? Any solution must be platform-wide. > > I'm not talking about removing Ansi functions. I'm talking about the > possibility of adding Unicode function equivalents. > For Unix unicode functions would simply call Ansi functions, > converting Unicode to AnsiString. Which requires libc, and *nix supports UTF-8 directly. The point is more or less to come up with some logical system, not just random additions when something is missing. And IMHO it is still to early, first the unicodestring support must be finished, and then a course has to be laid out which of the thousands of strings operations to convert. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
On Mon, Feb 1, 2010 at 11:01 AM, Marco van de Voort wrote: > What would you do on Unix? Any solution must be platform-wide. I'm not talking about removing Ansi functions. I'm talking about the possibility of adding Unicode function equivalents. For Unix unicode functions would simply call Ansi functions, converting Unicode to AnsiString. thanks, dmitry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
dmitry boyarintsev wrote: > > Would it be possible to fix the problem in RTL? by adding > UnicodeString (WideString) version of file operation functions? Until the cpstrnew branch in FPC is complete, I guess the answer is No. Alternatively you can introduce helper RTL functions. We have done similar in fpGUI project (fpg_utils.pas unit), having functions like fpgFileExists(), fpgFindFirst(), fpgFindNext() etc. Use them instead of the standard RTL functions, and they will try and handle Unicode file system access correctly on each platform. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler output and resources
01.02.2010 15:03, Marco van de Voort wrote: Yes, but it might not have the source (src/) directory later for the next compile, only the output dir.(units/$FPCTARGET) For the later compile it has .or file which has all lfm and res merged together. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler output and resources
In our previous episode, Paul Ishenin said: > > The reason is explained in this log message (2008-01-10): > > > > * .res files must be copied to units output folder, otherwise .res files > > will not be found when only compiled units path is available and > > compiler does not know anything about sources folder. > > Don't understand. To copy the res file compiler must know the location > to copy from. No? Yes, but it might not have the source (src/) directory later for the next compile, only the output dir.(units/$FPCTARGET) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] compiler output and resources
Il 01/02/2010 08:58, Paul Ishenin ha scritto: 01.02.2010 14:50, Giulio Bernardi wrote: The reason is explained in this log message (2008-01-10): * .res files must be copied to units output folder, otherwise .res files will not be found when only compiled units path is available and compiler does not know anything about sources folder. Don't understand. To copy the res file compiler must know the location to copy from. No? It copies the .res files from where they are to the compiler output directory. I agree that it might be better to directly put .res files in the output directory, just I don't remember now if there were some drawbacks... Giulio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTL and Unicode filenames operations.
In our previous episode, dmitry boyarintsev said: > Any hints on these bugs? > http://bugs.freepascal.org/view.php?id=12923 > http://bugs.freepascal.org/view.php?id=15642 // patch proposed to > workaround RTL limitation in LCL > > This is mostly concern of Windows OS. Moders Unix doesn't have the > problem, usually having UTF8 as their's Ansi codepage. > > Would it be possible to fix the problem in RTL? by adding > UnicodeString (WideString) version of file operation functions? What would you do on Unix? Any solution must be platform-wide. First the UnicodeString (which is not Widestring) should be finished, and some global decisions how to implement unicode system wide should be taken. > Ant other "simplier" way than switching compiler itself to Unicode or > other special string type? Temporarily have some helper functions in the LCL. FPC doesn't support unicode for all operations atm, while Lazarus does. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
