Hi,

I used to process XML files in my Lazarus applications using SimpleXML library for Delphi. Recently I tried to switch to fcl-xml (because of better performance) and faced with the following problem.

Since LCL uses utf-8 as internal string encoding, I use it for all string data in my applications too. But DOM/XMLRead/XMLWrite units use usc-2/utf-16 (WideString) so when working with TXmlDocument I have to do conversion like this:

myUtf8String := UTF8Encode(myElement['name']);
myElement['name'] := UTF8Decode(myString);

What I would like is to get rid of UTF8Encode/UTF8Decode stuff in my source. I guess CodeTools uses modified fcl-xml units to achieve exactly that, but these units seem to be pretty outdated compared to recent fcl-xml version in FPC 2.4.0.

* Does someone else use fcl-xml with LCL? Are there any tricks to avoid excessive UTF8Encode/UTF8Decode calls?

* Are there any plans to update CodeTools version and/or merge it into FCL? Well, according to the header of modified units there were such plans, but is it still true or the idea was abandoned for some reason?

* If the problem is lack of time only, it would be great to know the fcl-xml revision against which CodeTools modified version was made. Then updating it to the most recent fcl-xml version would be much easier for volunteers.

Thanks in advance.

This will not be easy, since currently there is no native UTF-8 type in FPC, so an automatic conversion is not possible.

Work has started on such feature in FPC (cpstrnew, base types for D2009 compatibility ), to be merged into 2.5.1 or even later, but nothing has been committed in the last 5 months.

* Does someone else use fcl-xml with LCL? Are there any tricks to avoid excessive UTF8Encode/UTF8Decode calls?

Not that I know.

* Are there any plans to update CodeTools version and/or merge it into FCL? Well, according to the header of modified units there were such plans, but is it still true or the idea was abandoned for some reason?

Afaik first the lazarus units were branched of because of fcl-xml not being fast enough. Since that time though, Sergei has invested massive amounts of time in fcl-xml, and we moved to unicode based Windows versions (Win2000,XP and later). and of course, the average computer has gotten faster too.

The last time I talked to Mattias about this, a few years back, IIRC he said that the current situation was stable, and there was no reason to change it.

* If the problem is lack of time only, it would be great to know the fcl-xml revision against which CodeTools modified version was made. Then updating it to the most recent fcl-xml version would be much easier for volunteers.

Since, as you noticed, this is all dependant on a solution for the manual unicode problem, I think this is a discussion better saved for when the unicode solution of FPC is in production. Now it is only guess work.

Marco van de Voort wrote

Work has started on such feature in FPC (cpstrnew, base types for D2009 compatibility ), to be merged into 2.5.1 or even later, but nothing has been committed in the last 5 months.

This reminds me, I still have some local commits of work I have done over December on the cpstrnew branch. I'll see if I can make some time this week and push those to SubVersion.

Since, as you noticed, this is all dependant on a solution for the manual unicode problem, I think this is a discussion better saved for when the unicode solution of FPC is in production. Now it is only guess work.

I have extensive code that requires Unicode string types (like D2009). I can't keep the code in sync any more with Delphi because of the lack of Unicode in FPC - so I had to resort to stay on a older version of the framework in question. If there is any volunteers to help with this (unicode support in FPC) task, it will be a great step forward for FPC.

Marco van de Voort wrote

Work has started on such feature in FPC (cpstrnew, base types for D2009 compatibility ), to be merged into 2.5.1 or even later, but nothing has been committed in the last 5 months.

(Why) Has this (IMHO very important) project stopped ?

I do know that there are a lot of logical / compatibility problems to be considered / solved (besides coding the stuff, of course). But I feel that it's necessary to provide a "modern" string type (maybe even as the default) to allow FPC to keep up with "the industry".

-Michael

Michael Schnell wrote

> (Why) Has this (IMHO very important) project stopped ?

I can only speak for myself (but am sure others have similar stories). I am extremely busy with my daytime job. Being a family man as well, also reduces my time for open source projects. Not to mention that I already maintain/contribute to fpGUI, tiOPF, DUnit2, FBLib, DCPCrypt and minor contributions to FPC & Lazarus.

I also consider the CodePage enabled String type a *very important feature* missing in FPC. I have some local commits, which I haven't had time to review again (last worked on it in December) and need push to the SubVersion repository.

This is why I mentioned earlier that if there are any other would-be contributors, please step forward and help out the FPC project. This missing feature would be a great step forward for FPC and is a major missing feature compared to Delphi at the moment. I don't know much about Compiler coding myself, but other FPC core members have been quick to help when I had any queries. FPC is a open source, community driven project - we need the community to help. We can't expect one or two people to do all the work!

Please let me know if you did this. Maybe I can help doing some tests. (I currently only use the "default branch" - whatever this is - of the svn. you would need to guide me how to checkout an additional one and how to use it alternatively with or without Lazarus)

-Michael

Michael Schnell wrote

Please let me know if you did this. Maybe I can help doing some tests. (I currently only use the "default branch" - whatever this is - of the svn. you would need to guide me how to checkout an additional one and how to use it alternatively with or without Lazarus)

Will do. I use a private Git mirror, but the normal SubVersion checkout looks as follows:

svn co http://svn.freepascal.org/svn/fpc/branches/cpstrnew

If you have any questions, post them in the fpc-devel mailing list.

I was able to check it out,

Let me know if your patches are included.

-Michael

Michael Schnell wrote

I was able to check it out,

Excellent. :)

Hint:
You can use Lazarus IDE to compile the compiler. Compiler project files (pp*.lpi) are in the <fpc>/compiler/ directory. You then use that new compiler to compile the RTL.

Let me know if your patches are included.

Not yet. I'll try during this week.

Nice.

As I recently tried it was easy to compile the compiler from the command line.

But after that I had big trouble to install it in a way that Lazarus
uses it.

So I'm a bit afraid of holding a dual version of the compiler at the same time.

> Let me know if your patches are included. > Not yet. I'll try during this week.

Great !
-Michael

So you assume that the other "powers" agree on this, too ?

On the German Lazarus forum, I had been bashed several times when expressing this opinion, and in consequence suggesting that the LCL's user interface should be upgraded to ubiquitously using the new string type.

-Michael

Graeme Geldenhuys wrote

Excellent. :)

Not quite:

by "make all" I get:

/bin/mkdir -p i386/units/i386-linux
/usr/bin/ppc386 -Ur -Xs -O2 -n -Fui386 -Fusystems
-Fu/home/mschnell/Downloads/svn/fpc-cpstrnew/cpstrnew/rtl/units/i386-linux -Fii386 -FE. -FUi386/units/i386-linux -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas
pstatmnt.pas(547,39) Error: Call by var for arg no. 1 has to match exactly: Got "ttempcreatenode" expected "tnode"

-Michael

:-)
I struggled in the beginning as well. I had to create a build script and modify my fpc.cfg file to include the correct paths to run multiple FPC versions.

Here is my build script. I also attached my ~/.fpc.cfg file. Modify each to suite your setup. Note the "IFDEF cpstrnew" section in the fpc.cfg file.

-----------[ build_64-linux.sh ]-------------------- #!/bin/sh
fpcdir=/opt/git/fpc_cpstrnew
cd $fpcdir/rtl
make clean FPC=$fpcdir/bin/x86_64-linux/ppcx64
cd ..
make rtl OPT="-dDEBUG -dcpstrnew" FPC=$fpcdir/bin/x86_64-linux/ppcx64 -------------------[ end ]---------------------------

Graeme Geldenhuys wrote

I struggled in the beginning as well. I had to create a build script and modify my fpc.cfg file to include the correct paths to run multiple FPC versions.

Hmm. The trunk version does compile just fine.

Here is my build script. I also attached my ~/.fpc.cfg file. Modify each to suite your setup. Note the "IFDEF cpstrnew" section in the fpc.cfg file.

I'll check this out.

-Michael

I suppose the script is for compiling the RTL rather than the compiler itself.

I moved the fpc.cfg file into the cpstrnew directory besides the main Makefile.

No change :(.

-Michael

Michael Schnell wrote

I suppose the script is for compiling the RTL rather than the compiler itself.

Yes, I compile the Compiler with Lazarus IDE or fpGUI IDE. I then use the script to compile the RTL.

On a side note:
fpGUI IDE will have Project Groups soon (something like Delphi 7 has) so compiling the Compiler and RTL will be possible soon from inside the IDE. My IDE already has support for various macro groups per project so switching compiler versions is simply done by toggling a single switch which alters the ${COMPILER} macro value. These are two things I really missed in Lazarus IDE and will be extremely useful in cross-compiling too (hint, hint to the Lazarus devs <smile>).

I moved the fpc.cfg file into the cpstrnew directory besides the main Makefile. No change :(.

I renamed the file for the email attachment. The fpc.cfg file should be in /etc/ if it must be global (and the filename stays as in the attachment), or as ~/.fpc.cfg if it's only meant for your user. Note the "." in-front of the file name, when it lives in your home directory (as a hidden file). No idea where it goes under Windows.

Graeme, it seems you had a deeper look into MSEide, don't you? ;-)

Martin

Martin Schreiber wrote

Graeme, it seems you had a deeper look into MSEide, don't you? ;-)

Yup. :-) You created a very flexible and "future proof" IDE. I love the flexibility of compiler settings in MSEide and how quickly you can toggle between them. I borrowed some of your dialog designs too, but the source code is all written from scratch. I just didn't like the many "per project" settings you have in MSEide (personal preference or what I am used to I guess). So my IDE has similar settings, but some of those settings are now global IDE settings and applies to all projects (new and existing). The joys of open source software - borrowing ideas from everywhere. ;-)

What amazes me though is that MSEide has one single unit for GDB support. Lazarus has 6+ large units. Yet MSEide seems to have more GDB implemented features. Go figure! :)

I see.

No change on the first try. I see that the file assumes some files in /opt/fpc. My installation does not use this.

I need to investigate where these files might be.

-Michael

Graeme Geldenhuys wrote

What amazes me though is that MSEide has one single unit for GDB support. Lazarus has 6+ large units. Yet MSEide seems to have more GDB implemented features. Go figure! :)

What hurts me especially in Lazarus is that there is no way to do writeln (or even the dedicated debug output) in a way that it can be read in a decent windows when a breakpoint is hit.

-Michael

The problem here is to decide what should be global and what should be per project. Because MSEide can be used for very different purposes (MSEgui development, Pascal PC programs, C-microcontroller programming...) most of the settings are project specific with project templates. Maybe later there will be multiple global settings with project overrides. At the moment I find it too complicated.

The joys of open source software - borrowing ideas from everywhere. ;-)

Agreed. :-)

Martin

Zitat von Graeme Geldenhuys :

[...] What amazes me though is that MSEide has one single unit for GDB support. Lazarus has 6+ large units. Yet MSEide seems to have more GDB implemented features. Go figure! :)

Lazarus supports various debuggers.
gdb support is in units gdbmidebugger and gdbtypeinfo. gdb over ssh in unit sshgdbmidebugger.

The other debugger units are the dialogs.

What gdb features has MSEGui?

Mattias

Michael Schnell wrote

No change on the first try. I see that the file assumes some files in /opt/fpc. My installation does not use this.

That's why I said in my initial post: "Modify each [script and config file] to suite your setup" :-)

2010/5/12 Mattias G?rtner :

The other debugger units are the dialogs.

What is the TProcessDebugger for?

What gdb features has MSEGui?

* Debugging console applications. Lazarus debugs the console and not the app running inside the console.
* WatchPoints (watching memory for read, write or read/write access and then breaks. I only found out about this today in MSEide, and it is extremely handy.
* ... I'm sure Martin can mention a few more.

I uploaded updated versions in revision 25343. See components/codetools/laz2_*.pas

Can you test them?

When they work they can replace the old units.

Mattias

It is not really a debugger, but it simply runs the target as a process.

This made the IDE a lot simpler. In the past there was code for running projets with and other code for running project without debugger. Now it is always run in a "debugger", where the TProcessDebugger only supports 2 funtions: start and stop

Marc

Marc Weustink wrote

This made the IDE a lot simpler. In the past there was code for running projets with and other code for running project without debugger. Now it is always run in a "debugger",

Thanks Marc. That design seems like a good fit.