Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM
On Saturday 27 October 2018 09:27:59 Sven Barth via fpc-devel wrote: > > > > Not really. The IR format has been pretty stable since version 3.9 or so > > (LLVM is current at version 8.) As far as dependencies, it would add none > > whatsoever other than a copy of the LLC or LLVM-AS binaries (as in, no > > more than any other target FPC supports. Just think of it as yet another > > assembler format.) > > It's more than just an additional assembler format as the infrastructure > inside the compiler shows. Also there are the problems that Jonas > mentioned. > In my opinion that time is better spent optimizing our own code generator. > MSElang uses the approach to write LLVM bitcode directly without a temporary LLVM assembler text. Building the needed LLVM lists and tracking the ssa values is not trivial. IMO the worst aspect of LLVM is its slowness but the resulting code is awesome. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] The 15k bounty: Optimizing executable speed for Linux x86 / LLVM
On Thursday 25 October 2018 11:18:58 Sven Barth via fpc-devel wrote: > > I'm against emulating SEH. Better implement DWARF exceptions. The > infrastructure that was created for SEH inside the compiler should help > nevertheless. > MSElang has some code for "Itanium ABI Zero-cost Exception Handling" supported by LLVM, for example the runtime part: https://gitlab.com/mseide-msegui/mselang/blob/master/mselang/compiler/__mla__personality.pas Works well so far. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to suppress warnings in code?
On Thursday 27 September 2018 09:11:01 Martin Schreiber wrote: > On 9/26/18 6:38 PM, Sven Barth via fpc-devel wrote: > > Please provide concrete examples. > > Here: > https://gitlab.com/mseide-msegui/mseide-msegui/tree/fpc_3_2 > Bug report: https://bugs.freepascal.org/view.php?id=34349 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to suppress warnings in code?
On 9/26/18 6:38 PM, Sven Barth via fpc-devel wrote: > > Please provide concrete examples. > Here: https://gitlab.com/mseide-msegui/mseide-msegui/tree/fpc_3_2 On Linux-X86-64 in clone directory compile with " -O- -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas ", repeat until only "apps/ide/mseide.pas" will be compiled. Touch "lib/common/kernel/mseformatstr.pas", compile again, "mseformatstr.pas" will be compiled without warnings. Compile with " -B -O- -Fulib/common/* -Fulib/common/kernel/linux apps/ide/mseide.pas " "mseformatstr.pas" will be compiled with warnings. BTW, compiletimes (s): run 2 3 4 FPC fixes_2_6 39.6 37.8 38.6 FPC fixes_3_0 53.9 53.3 53.8 FPC fixes_3_2 64.6 68.1 65.3 OpenSUSE LEAP 42.3 4 x Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 3.8 GiB RAM Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] How to suppress warnings in code?
Hi,
How can individual warnings be suppressed in code in Free Pascal fixes_3_2?
{$warn off} seems not to work reliable in some projects if compiled
with -B.
Thanks, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Graphical RAD IDE in FPC
Hi Alexander, It is not allowed to discuss MSEide+MSEgui themes here. I will answer on the MSEide+MSEgui mailing list: https://sourceforge.net/projects/mseide-msegui/lists/mseide-msegui-talk Archive: https://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Graphical RAD IDE in FPC
On Monday 17 September 2018 05:51:17 Alexander via fpc-devel wrote: > I try use of MSEide,gui beforehand Lasarus, but excellent result not get. > > Lasarus use non native for FPC widgets, MSE non stable work. > Can you be more specific? Reproducible MSEide+MSEgui bugs are normally fixed in hours or one to two days. > Console FPC excellent work, but without graphics. > > Need more attention for RAD graphical environments from side FPC > developers. > > Author MSE say that bad some **drivers**, but it need to more accurate > test. > > I made http://soft.self-made-free.ru/ 'Birthdays reminder' on minimal > set of possibles of MSE and it worn on this driver, but IDE on this driver > work incorrect. > > May be say author about driver is wrong ? > Do you mean the "EXA pixmap acceleration" problem with Radeon and other opensource Linux graphic drivers? I was not able to find a bug or a workaround in MSEgui. The EXA acceleration system is not maintained it seems: https://bugs.freedesktop.org/show_bug.cgi?id=69543 https://bugs.freedesktop.org/show_bug.cgi?id=84253 Please use the proprietary graphic driver for your graphic chip, it has been reported that they work well with MSEgui. Debugging Linux kernel modules and graphic drivers is out of my possibilities. There are more "unsolvable" issues with drawing primitives, ex. https://bugs.freedesktop.org/show_bug.cgi?id=99705 https://bugs.freedesktop.org/show_bug.cgi?id=106628 or with window managers. The Linux Mint team stole the show: https://forums.linuxmint.com/viewtopic.php?t=251027 where the Cinnamon devels marked reports for bugs which already have been fixed in Gnome3 as spam. Take a potion of popcorn and follow the links... It looks to me that Linux desktop environment developers only check if Firefox works OK. If yes, all further reports are ignored or the reporters are treated as idiots. BTW, the Lazarus GTK widgetset probably also suffers from minimized -> normal windowstate issue in Cinnamon. I don't have the time or nerves anymore to fight such battles, MSEide+MSEgui users must become active themselves. Please don't answer to this mail, use the MSEide+MSEgui mailinglist instead: https://sourceforge.net/projects/mseide-msegui/lists/mseide-msegui-talk Archive: https://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Wrong docs: not initialized global variables
On Thursday 05 April 2018 12:47:27 Alexander Klenin wrote: > > Allow me to yet again to single out this philosophy of > strongly preferring abstract purity to concrete user experience. > This is IMHO a significant contributing factor of Pascal decline. > I would not argue this specific point (although I quite agree with Ondrej), > I just want to remind that the cost in terms of diminishing userbase > is real, and that makes me sad. Agreed 100%. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCollection.FOwner
On 12/27/2017 04:15 PM, Juha Manninen wrote: > I am proposing to add a private > FOwner: TPersistent; > to TCollection and remove it from derived classes which already have it. Just a warning which does not necessarily apply to the TCollection issue you report: Be very careful to change component streaming behavior. It is difficult to see all consequences with inlined and inherited components and all possible combinations. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Different results of random(int32) and random(int64) for negative limit value
Hi,
FPC fixes_3_0, Linux X86:
"
var
i1: int32;
begin
for i1:= 0 to 5 do begin
writeln(random(int32(-16)));
end;
writeln('*');
for i1:= 0 to 5 do begin
writeln(random(int64(-16)));
end;
end;
"
produces
"
-9
-9
-11
-13
-10
-13
*
3
9
5
4
6
8
"
Is this intended? If not, which one is correct?
https://www.freepascal.org/docs-html/current/rtl/system/random.html
states for 32 and 64 bit
"
Random returns a random number larger or equal to 0 and strictly less than L.
"
which raises the question, what means "less"?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Overflow in TMemoryStream?
Hi, While working on the MSEgui fork of classes unit I saw a suspect piece of code in streams.inc: " function TMemoryStream.Realloc(var NewCapacity: PtrInt): Pointer; begin If NewCapacity<0 Then NewCapacity:=0 else begin // if growing, grow at least a quarter if (NewCapacity>FCapacity) and (NewCapacity < (5*FCapacity) div 4) then NewCapacity := (5*FCapacity) div 4; " Isn't there an overflow if the capacity grows above high(ptrint) div 5 (about 430MB on 32 bit)? IIRC there was a discussion on the list about memory problems with big TMemoryStream's. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Default" discussion for SmartPointers etc
On Wednesday 27 July 2016 23:27:21 Jonas Maebe wrote: > > Properly designing a new programming language concept is hard, and the > worst thing is that once it's shipped, you are stuck with it basically > forever. I think it needs more than just some example programs and tests > to design one from scratch. > > It's really too bad there is no programming language committee for the > Pascal language with language design experts that could discuss and > refine this in-depth. I'm no language design expert myself at all and > preferably would not even get involved in this kind of discussions but > at the same time I don't want to get stuck with having to maintain and > support an ever growing language that becomes less and less > self-consistent and more and more complex (while there may be simpler or > clearer ways to achieve the same things). > I second this. It is really sad what happened with the Delphi language and even worse with Free Pascal and its different dialects in recent years. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode paths
On Tuesday 12 April 2016 18:46:15 Marco van de Voort wrote: > > Anyway, I never liked the fact that argv and argc are exported symbols. If > they weren't public, we could change them at will and/or have differing > implementations and encodings depending on target. I would deprecate them > (being public) > Is there a possibility to still get the raw data in case one wants to handle encoding himself? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Debuginfo for dynamic arrays
Hi, For a "array of integer" type variable FPC 32bit stabs returns for gdb "ptype" command " type = ^(array [0..-1] of LONGINT) ". MSEide uses this info to fetch the itemcount and item memory and to show the array items in watches window. FPC 64bit dwarf "ptype" returns " type = ^LONGINT ". How can we identify a dynamic array with FPC dwarf? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debuginfo for dynamic arrays
On Sunday 24 January 2016 15:20:04 Martin wrote: > On 24/01/2016 14:06, Martin Schreiber wrote: > > How can we identify a dynamic array with FPC dwarf? > > If I remember correctly then you can do (after you got above result) > ptype foo^ > or if foo is an expression ptype (foo)^ > and this will return an array as ptype. > Works, thank you very much! Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf-3
On Sunday 24 January 2016 17:17:57 Martin wrote:
> On 24/01/2016 16:03, Florian Klämpfl wrote:
> > Dwarf-3 can handle dyn. arrays much better. What do you think about
> > switching the default dwarf level from 2 to 3?
>
> The last gdb I tested on win (32bit vista) was gdb 10.0 (current is 10.1)
>
> And (IIRC) it still crashes (gdb exe has stopped working) with dwarf3.
>
Confirmed with Linux x64 gdb 7.9.1. gdb with FPC -gw3 crashes by many watches
("self",arrays,pointers...) and does not find uppercase queries for lowercase
variables so the workaround for class variables can not be used. It is
completely unusable for IDE purpose.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fwd: While - Otherwise Statement
On Tuesday 13 October 2015 23:25:03 Michael Van Canneyt wrote: > > But the existence of such a continue block shows the fundamental issue on > > which a decision is needed. should (if a volunteer for a patch exists) > > every little "save one statement in your code helper" be added? Because > > there are thousands of them, and if you add them all the readability of > > code will go down, because you need to first learn them all. > > I think the answer to your question is a clear and loud "NO". > > The argument that we can refrain from using these new features does not > hold, because other people will be using it, and we will have to know all > of it to be able to understand their code. > None of these features will automagically make Object Pascal a popular > language. > > However, I seem to be one of the very few thinking this given the > enthousiasm with which people are discussing this. > We are at least two people. :-) > Soon I will be forced to emigrate to Javascript country. Or to MSElang? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Resourcestrings and encodings
On Tuesday 29 September 2015 00:30:48 Jonas Maebe wrote: > However, I would already like to ask everyone that uses resource strings > to check FPC trunk r31881 or later with their program to ensure it still > works correctly, and also try the changed rstconv utility. See > http://bugs.freepascal.org/view.php?id=28717#c86146 for information > about its default behaviour and new feature. > With the changes finally MSEi18n can support Unicode resourcestrings for FPC 3.1.1, see http://mseide-msegui.sourceforge.net/pics/msei18n_fpc_3_0.png Thank you very much. I do not use *.po files and rstconv -> not tested by me. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL SQLdb transactions
On Thursday 06 November 2014 15:43:03 Chris Dryburgh wrote: I understand that but I don't think your approach allows for a series of read-only queries to be run in a single transaction batch. Why not? Activate the datasets with dso_offline, the activation of the first dataset will start the transaction. Rollback or commit the transaction after loading all datasets. If one later calls applyupdates the dataset automatically starts a new transaction either by transactionwrite if assigned or the regular transaction property. If dso_autocommit is set there will be also an automatic commit. Transaction option tao_fake is off of course. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL SQLdb transactions
On Thursday 06 November 2014 17:10:13 Chris Dryburgh wrote: OK I suppose I had not gotten to the point of fully understanding how it worked. Well Michael's patch should work for all databases and is close to being put into trunk. Unless something happens porting the MSEgui transaction handling approach to other databases should not be needed. I probably was not clear. MSEgui has two approaches: 1. transaction.options tao_fake, works for all databases except Firebird which does not support implicit transactions. 2. Dataset option dso_offline, works for all databases and probably is equivalent to the FPC patch. 1. is important for users who come from Zeos or MySQL users who update from an older FPC version where MySQL transactions where not supported (normally they switch to Zeos...) or Sqlite3 where explicit transactions sometimes are problematic. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL SQLdb transactions
On Tuesday 04 November 2014 19:33:22 Chris Dryburgh wrote: The end result should be that server transactions only open when needed. Users would likely commit write transactions quickly to save data to the database. Read-only transactions might be left in a open state but can be closed by an aware developer when not needed. To eliminate open read-only transactions an option is to never open a transaction for select queries which would mean a overhead for the server opening and closing transactions for each query. What do others here think? The MSEgui version of TSQLQuery has two transaction properties, transactionwrite which is used for write operations and transaction used for read operations and for write operations if transactionwrite is not assigned. So one can use different transactions and transaction isolation levels for reading and writing. The MSEgui version of TSQLTransaction has the flag tao_fake which omits sending BEGIN, COMMIT and ROLLBACK in order to use implicit transactions if the server supports it. Additional it is possible to disconnect an open query dataset from database and transaction, they can be closed after disconnect. Later it is possible to reconnect the still open dataset. I suggest that you implement a tao_fake-like functionality yourself, maybe a patch will be accepted. I already suggested it several times because especially MySQL users don't like and often even don't know transactions. :-) If you like to know how it is done in MSEgui: https://gitorious.org/mseide-msegui Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] PostgreSQL SQLdb transactions
On Wednesday 05 November 2014 19:19:41 Chris Dryburgh wrote: [...] run together. It is also read-only transaction idiot proof which is a good thing. Michael's approach of allowing for closing a transaction without closing a still in use dataset looks like a better approach. It will still cause issues for users that don't like and often even don't know transactions. Just for clarification, the mentioned MSEgui dataset disconnect/reconnect functionality provides that possibility. Activate tmsesqlquery.contoller.options dso_offline and it will be handled automatically. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Signals
On Friday 26 September 2014 09:57:43 Michael Schnell wrote: On 09/26/2014 09:39 AM, Michael Van Canneyt wrote: You can use the Observer pattern; it is in the classes unit. I'll take a look. And to be honest, this is not a language concept, but a library concept. AFAIK he mentioned QT as a library providing this. It can be easily implemented. If so I assume that somebody already did it. Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Signals
On Friday 26 September 2014 10:38:36 Michael Van Canneyt wrote: Again have a look at MSEgui, tobjectlinker in mseclasses.pas. It is not so easy to implement as it seems. ;-) It is. Depends on your definition of difficult, of course. Or the implemented functionality. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TTimers and TThreads. Attn Michael Schnell
On Friday 27 June 2014 12:54:50 Giuliano Colla wrote: [...] Pros: you have only one timer to deal with, no overhead for useless timer events, minimal overhead on timer events. Cons: you have some overhead when programming a timer event, because the list must be scanned to insert the event in the appropriate place. The MSEgui timers work with that approach too. I am sure Michael Schnell knows lib/common/kernel/msetimer.pas. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Monday 19 August 2013 11:28:25 Michael Van Canneyt wrote: It should not take more than an hour to implement. Maybe some additional minutes for the implementation of an efficient and precise timer queue. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication
On Monday 19 August 2013 11:55:37 Michael Schnell wrote: On 08/19/2013 11:51 AM, Martin Schreiber wrote: Maybe some additional minutes for the implementation of an efficient and precise timer queue. ;-) _MANY_ thanks for the support, making me feel that I am not completely insane. BTW, why don't you simply use MSEgui which provides all this out of the box instead to constantly annoy FPC and Lazarus people? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On Thursday 23 May 2013 10:10:05 Michael Schnell wrote: That in fact is exactly what I meant to say. AFAI understand, these are cross-gdbs, running on the PC, but compiled for supporting a foreign arch via some kind of interface (e.g. a programming adapter). But they are full gdb's being accessed by a command line interface. OTOH a gdb-server (or stub) runs on the target device Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the AVR ONE! debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On Thursday 23 May 2013 11:06:52 Michael Schnell wrote: On 05/23/2013 10:50 AM, Martin Schreiber wrote: Or the gdbserver runs on the PC and communicates with a debug interface hardware. MSEide uses this approach to debug AVR32 code with the AVR ONE! debugger and ARM chips (for example Energy Micro Tiny Gecko) with the Segger J-Link debugger which is built-in in the inexpensive demo board. I see. I did not expect that someone would be inclined to go this way, as you need to implement the (published but rather internal) gdb-gdbserver pipe protocol, and additionally you need to do the arch-dependent interpretation in your own software rather than have gdb do this and provide the results via it's well-understood command line pipe interface. But obviously you did have good reasons to do so. (Can you provide a short explanation, why ?) You misunderstood. The chain is MSEide-gdb-gdbserver-debughardware-target. What kind of interface does AVR ONE! provide ? AFAIK debugWIRE, PDI, aWire, JTAG, Nexus. Does it come with a gdbserver type of driver on the PC ? Yes. BTW.: can you say anything regarding the PIC32 debugging issue ? I don't use PIC32, sorry. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sunday 17 March 2013 21:44:02 Florian Klaempfl wrote: Am 06.03.2013 14:16, schrieb Martin Schreiber: On Sunday 03 March 2013 18:35:53 Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3 A last one, simple MSEgui demo, one form, a fancy tlabel, one button: http://mseide-msegui.sourceforge.net/pics/kylix3.png Program size Kylix 3: -rwxr-xr-x 1 mse users 1038420 Mar 6 13:28 kylixdemo FPC 2.6.2, commandline: ppc386 -okylixdemo -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/linux/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fi/home/mse/packs/standard/git/mseide-msegui/lib/common/kernel/ -Fu/home/mse/packs/standard/git/mseide-msegui/lib/common/*/ -B -O2 -CX -XX -Xs kylixdemo.pas Program size: -rwxr-xr-x 1 mse users 1252204 Mar 6 14:10 kylixdemo Without the used sources it is of very little use. Because of the tone of the answers in this list I didn't expect anyone is interested in it. ;-) http://gitorious.org/mseuniverse/mseuniverse/trees/master/testcase/kylix/kylixdemo Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 09:26:53 Vittorio Giovara wrote: Martin made a point that delphi7 is faster better and whatever than fpc... so what? Don't use fpc if you don't like it, or send patches to improve it ;) You probably might know, I am the author of MSEide+MSEgui: http://sourceforge.net/projects/mseide-msegui/ In MSEgui development I am happy if users report what they need in their daily work and what is inconvenient in current MSEgui implementation. I then try to examine the problem, find out how it can be solved and implement an universal solution based on what I learned from the conrete real world example. I do not expect that users provide patches, reproducible testcases are enough. If the users provide patches there is a big risk, that they fix their current problem only instead to find an orthogonal improvement. And the quality of the code maybe is not always the best. ;-) Please read the MSEide-MSEgui mailing list archive in order to check how things are handled in MSEgui. http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/ With the MSEide Delphi/Kylix/FPC comparison I provide a real world testcase which the FPC team can use to improve their product. If the FPC team don't want to do so or think it is not necessary or it is no fun then I have to accept it and I will accept it. But from time to time I will repeat the comparison in order the facts will not get forgotten. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 12:05:37 Florian Klämpfl wrote: Am 04.03.2013 01:00, schrieb Graeme Geldenhuys: 4.4 seconds (Kylix under Linux) vs 89 seconds (FPC under Linux)... That is just too a huge performance difference to justify. Yes, we all know the argument about more platforms, maintainable code etc, but that couldn't possible be the only reason for such a huge speed difference. Somewhere there is a serious bottleneck(s), or the FPC team simply disregard optimization completely. From why I have heard them say, the latter is more likely [unfortunately]. You completely miss the point. If there are only approx 25 features/properties which make the compiler each 10% slower than in total FPC is 10 (1.1^25=10.9) times slower than before. Is this correct? It implies that every feature/property uses 100% of the total process. And if it is true it is absolutely necessary to stop adding features soon because 1.1^50 = 117.4. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 15:19:56 Tomas Hajny wrote: Any idea, why FPC Linux is slower than FPC Windows? Loading and highlighting does not sound like a task where many OS calls are involved. Is the starting MSEide (as mentioned above) bit included in the measured time? That would probably imply quite some OS calls, of course... Yes. The time is from pressing enter with mseide respective mseidefp on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 18:16:03 Mattias Gaertner wrote: Yes. The time is from pressing enter with mseide respective mseidefp on the the commandline until the last line of MacOSAll.pas from FPC 2.4.0 in the source editor window is colored. MSEide first shows the file without colors and does the highlighting in background if main event loop is idle. And how much time is spent on the highlighting on Linux and Windows? About 2/3 on booth. I need to instrument the code in order to get more precise numbers. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 14:54:01 Mattias Gaertner wrote: On Mon, 4 Mar 2013 14:50:17 +0100 Martin Schreiber mse00...@gmail.com wrote: On Monday 04 March 2013 07:08:25 Martin Schreiber wrote: Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Some more tests, starting MSEide, loading and highlighting the 277441 lines MacOSAll.pas from FPC 2.4.0: FPC 2.6.2 Windows 3.2..3.5s Delphi 7 Windows 4.0s FPC 2.6.2 Linux5.0s Kylix 3 Linux 4.0s. It seems there is actually a benefit of the reference counted Free Pascal UnicodeStrings on Windows. Any idea, why FPC Linux is slower than FPC Windows? I don't know. I often find Windows 2000 faster than Linux. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 10:04:54 Daniël Mantione wrote: Op Sun, 3 Mar 2013, schreef Martin Schreiber: BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. I think you should focus your efforts on getting those bugs fixed, such as by submitting bug reports that allow reproduction of the problem with programs as simple as you can get them to show the problem. The problem is well known since a long time AFAIK. The answer we normally get when we report a unit handling related FPC crash is that FPC unit handling should be rewritten. I can't rewrite FPC unit handling myself because I have many other tasks. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 10:42:09 Sven Barth wrote: Do you mean compiling the compiler? If so than for real tests you SHOULD NOT compile the compiler by hand, but only through make cycle in the compiler directory or make all in the top level directory. This will ensure that the compiler is compiled correctly. And yes, I know the problem with -B and it's likely related to unit loading. This normally happens only in more complex projects like the compiler. Though I've just managed yesterday to create a smaller example (by accident) that also chrashes. Maybe I'll find the problem and can fix it once and for all :) No, I mean MSEide. MSEide is a more complex application than the compiler it seems. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Friday 01 March 2013 18:33:56 Martin Schreiber wrote:
[...]
On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3,
Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3):
http://gitorious.org/mseide-msegui
Command line Kylix 3:
dcc -D+ -Aclasses=Classes -Adateutils=DateUtils -Afmtbcd=FMTBcd
-Amaskutils=MaskUtils -Astrutils=StrUtils -U${DCUS} -I../../lib/common/kernel
-U../../lib/common/kernel -U../../lib/common/audio -U../../lib/common/opengl
-U../../lib/common/report -U../../lib/common/db -U../../lib/common/crypto
-U../../lib/common/graphics -U../../lib/common/i18n
-U../../lib/common/kernel/linux -U../../lib/common/image
-U../../lib/common/widgets -U../../lib/common/designutils
-U../../lib/common/sysutils -U../../lib/common/editwidgets
-U../../lib/common/dialogs -U../../lib/common/regcomponents
-U../../lib/common/serialcomm -U../../lib/common/printer -U../../lib/common/ifi
-U../../lib/common/math -U../../lib/common/delphicompatibility
-U../../lib/common/fpccompatibility
mseide.pas
Result Kylix 3:
488041 lines, 4.40 seconds, 2762044 bytes code, 1220304 bytes data.
-rwxr-xr-x 1 mse users 5092836 Mar 3 18:16 mseide
Command line FPC 2.6.2:
ppc386 -O2 -g -Xg -Xs -B -Fi../../lib/common/kernel -Fu../../lib/common/kernel
-Fu../../lib/common/audio -Fu../../lib/common/opengl -Fu../../lib/common/report
-Fu../../lib/common/db -Fu../../lib/common/crypto -Fu../../lib/common/graphics
-Fu../../lib/common/i18n -Fu../../lib/common/kernel/linux
-Fu../../lib/common/image -Fu../../lib/common/widgets
-Fu../../lib/common/designutils -Fu../../lib/common/sysutils
-Fu../../lib/common/editwidgets -Fu../../lib/common/dialogs
-Fu../../lib/common/regcomponents -Fu../../lib/common/serialcomm
-Fu../../lib/common/printer -Fu../../lib/common/ifi -Fu../../lib/common/math
-Fu../../lib/common/delphicompatibility -Fu../../lib/common/fpccompatibility
-omseidefp
mseide.pas
Result FPC 2.6.2:
495971 lines compiled, 89.3 sec
-rwxr-xr-x 1 mse users 7463712 Mar 3 18:19 mseidefp
Please note that smartlinking with FPC is not possible on that system because
it has 1GB ram only.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 02.03.2013 11:11, schrieb Martin Schreiber: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. I checked again, time of FPC linking stage is about 2.5 seconds. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Sunday 03 March 2013 20:08:43 Michael Van Canneyt wrote: On Sun, 3 Mar 2013, Martin Schreiber wrote: On Friday 01 March 2013 18:33:56 Martin Schreiber wrote: [...] On Linux, same computer, OpenSUSE 12.2, comparison FPC 2.6.2, Kylix 3, Source (master branch a4172602c45fe5abc931dee8b8ae2f4744ee70f3): http://gitorious.org/mseide-msegui Impressive. Now that we've clearly established that FPC is slower than Delphi, and that you consider this a serious problem (which we, in fact, know since some time): When can we expect to see some constructive proposals on how to improve the situation? I supplied the benchmark, more than 10 man years of development time. A good start, no? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
On Monday 04 March 2013 00:29:51 Vittorio Giovara wrote: IMHO Martin Schreiber is doing a great job using these comparisons and some improvements could be made in FPC... but he is making a mistake in their approach of how to present FPC's defects. I am not so sure about this... I know nothing of dcc switches but he is comparing the compiler speed with a different set of features, it is easy to spot how flawed the comparison is: -O2 -Xg -Xs are all optimization flags and it is expected that optimizing code takes time. Could be interesting to see the speed and size of the binary produced by the two compilers, slower compilation time over faster or smaller code is something I would pick any time! Please note that Delphi/Kylix produce both smaller and faster code than FPC in the testcase, they do full optimisation by default. Quality of the produced code is another goal of the comparisons. MSEide sizes Delphi 7: 5'062'144 FPC 2.6.2 Windows with smart linking: 6'026'259 Kylix 3:5'092'836 FPC 2.6.2 Linux without smart linking 7'463'712 (it can't smartlink with 1MB ram only) Both Delphi 7 and Kylix 3 compiled MSEide feel more snappy than their FPC counterpart which is especially surprising for Delphi because Delphi widestrings are not reference counted. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 10:12:51 Florian Klämpfl wrote: Am 01.03.2013 22:40, schrieb Martin Schreiber: On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: Am 01.03.2013 18:33, schrieb Martin Schreiber: Hi, In order to have a good benchmark for FPC Expect the next release to be even slower. Will it produce better code instead? What means better? Faster? Less buggy? Smaller? It means faster and smaller, Delphi 7 produced code is smaller and faster than FPC 2.6.2 code. A compiler must be bug free anyway. ;-) I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe Compiled with which FPC version? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:12:52 Florian Klämpfl wrote: I did a quick test on win32, it seems to be a little bit smaller than 2.6.2: 02.03.2013 10:09 5.774.848 mseide.exe Compiled with which FPC version? trunk. ??? MSEgui compiles with trunk? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 14:01:10 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Compiled with which FPC version? trunk. ??? MSEgui compiles with trunk? It is mostly unicodestring centric, so that shouldn't be such a surprise? MSEgui has an own unicodestring manager on Linux which must be adapted to cpstrnew. Also the meaning of #nnn characters has changed and MSEgui uses some hacks with UnicodeStrings which must be adapted. I don't want to do the work before Unicode handling in FPC is finished and documented. And frankly, I don't believe in it anymore... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. It will allow me to see what IO the Delphi/Kylix compiler does. We can say for sure that the fact you use .pas as filename extension will cause FPC to do twice the number of stat() calls, because .pp is searched first...Logical therefore that the IO is slower. AFAIK *.pas is Delphi compatible? ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Sunday 03 March 2013 08:12:28 Martin Schreiber wrote: On Saturday 02 March 2013 11:28:25 Michael Van Canneyt wrote: On Sat, 2 Mar 2013, Martin Schreiber wrote: On Saturday 02 March 2013 10:52:18 Michael Van Canneyt wrote: Anyway, what seems obvious from your numbers is that it is the linking stage that needs speedup. This does not really come as a surprise. On Windows FPC linking time of MSEide is about 2-3 seconds IIRC, I'll check it later, currently I try to make MSEide+MSEgui Kylix3 compatible so we have a benchmark on Linux too. When you do, please send me the output of a strace -f I will take a while because it is much work to make the code both FPC and Delphi/Kylix compatible. BTW, a significant percentage of the time is waiting for FPC compiling because FPC normally crashes without -B. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Hi, In order to have a good benchmark for FPC I made MSEide+MSEgui Delphi 7 compatible again. Source (master branch 2400be4999b254dbf335e4777baa33b13ea72649): http://gitorious.org/mseide-msegui As testcase I used compiling MSEide, all dcu's, ppu's and o's deleted before compiling. System: win2000, AMD Atlon XP 3000+, 1GB RAM Command line Delphi 7: dcc32 -B -D+ -I..\..\lib\common\kernel -U..\..\lib\common\kernel -U..\..\lib\common\audio -U..\..\lib\common\opengl -U..\..\lib\common\report -U..\..\lib\common\db -U..\..\lib\common\crypto -U..\..\lib\common\graphics -U..\..\lib\common\i18n -U..\..\lib\common\kernel\windows -U..\..\lib\common\image -U..\..\lib\common\widgets -U..\..\lib\common\designutils -U..\..\lib\common\sysutils -U..\..\lib\common\editwidgets -U..\..\lib\common\dialogs -U..\..\lib\common\regcomponents -U..\..\lib\common\serialcomm -U..\..\lib\common\printer -U..\..\lib\common\ifi -U..\..\lib\common\math -U..\..\lib\common\delphicompatibility -U..\..\lib\common\fpccompatibility mseide.pas Result Delphi 7: 483086 lines, 6.72 seconds, 3396292 bytes code, 1217961 bytes data. F:\proj\mseide-msegui\apps\idedir mseide.exe Datenträger in Laufwerk F: ist win2000_F Datenträgernummer: 5C58-C4EF Verzeichnis von F:\proj\mseide-msegui\apps\ide 01.03.2013 17:225'062'144 mseide.exe Command line FPC 2.6.2: ppc386.exe -g -Xg -O2 -CX -XX -Xs -B -Fi..\..\lib\common\kernel -Fu..\..\lib\common\kernel -Fu..\..\lib\common\audio -Fu..\..\lib\common\opengl -Fu..\..\lib\common\report -Fu..\..\lib\common\db -Fu..\..\lib\common\crypto -Fu..\..\lib\common\graphics -Fu..\..\lib\common\i18n -Fu..\..\lib\common\kernel\windows -Fu..\..\lib\common\image -Fu..\..\lib\common\widgets -Fu..\..\lib\common\designutils -Fu..\..\lib\common\sysutils -Fu..\..\lib\common\editwidgets -Fu..\..\lib\common\dialogs -Fu..\..\lib\common\regcomponents -Fu..\..\lib\common\serialcomm -Fu..\..\lib\common\printer -Fu..\..\lib\common\ifi -Fu..\..\lib\common\math -Fu..\..\lib\common\delphicompatibility -Fu..\..\lib\common\fpccompatibility -omseidefp.exe mseide.pas Result FPC 2.6.2: 489756 lines compiled, 84.6 sec , 3309520 bytes code, 2691084 bytes data F:\proj\mseide-msegui\apps\idedir mseidefp.exe Datenträger in Laufwerk F: ist win2000_F Datenträgernummer: 5C58-C4EF Verzeichnis von F:\proj\mseide-msegui\apps\ide 01.03.2013 17:246'026'259 mseidefp.exe Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On Friday 01 March 2013 22:30:31 Florian Klämpfl wrote: Am 01.03.2013 18:33, schrieb Martin Schreiber: Hi, In order to have a good benchmark for FPC Expect the next release to be even slower. Will it produce better code instead? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?
On Wednesday 06 February 2013 20:24:34 Graeme Geldenhuys wrote: It case I'm overlooking something critical, has anybody else done something like this. If so, anybody willing to share that code - saving me some time in developing, unit testing and debugging my own Object Pascal based semaphore. MSEgui has a semaphore implementation. On Linux it uses the libc interface, on Windows an own implementation with a windows event object, lib/kernel/windows/msesysintf1.pas. Works so far, but with sync mechanics one never knows... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] for-in-index loop
On Friday 25 January 2013 09:07:27 Michael Van Canneyt wrote: Once more: simple is beautiful. Free pascal becomes less so with each of these features. Agreed. I even would say it becomes more by removing some of the existing features. ;-) Martin ___ 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)
On Saturday 05 January 2013 11:30:42 Jonas Maebe wrote:
[...]
For example, I said that basically nothing changed in 2.7.x compared to
2.6.x, except that certain string constants are no longer automatically
converted to utf-16 at compile time, and then you ask Or should we not
touch the theme strings and FPC anymore?. Since basically nothing changed
except for a few less blind auto-conversions at compile time, why should
you no longer be able to touch anything anymore?
Let me repeat: your string constants will be parsed by the compiler into
character sequences with exactly the same content in both 2.6.x and 2.7.x
(and with content I mean that if they would be converted to the same code
page in 2.6.x and in 2.7.x, you would end up with exactly the same binary
data). Whether or not they contain character literals whose value is #127
in the source code's code page, or explicit #xx, #xxx etc expressions
has no influence, nothing changed in the compiler in that account.
The *only* difference is that the compiler can now internally represent
ansistrings with arbitrary code pages, and as a result the aforementioned
character sequences may now be stored internally in the compiler in a
different format, and also stored in the program in a different format if
that can avoid conversions at run time. In particular, character sequences
are no longer all converted immediately/by default/under all circumstances
to UTF-16 in case characters #127 need to be interpreted according to a
particular code page (i.e., if a {$codepage xxx} directive is present).
The compiler will now only convert such character sequences to UTF-16,
still at compile time (just like it was able to do in 2.6.x), if it is
actually assigned to an UTF-16-encoded string, passed to an UTF-16
parameter etc. And the compiler will also convert it to another ansistring
code page is case the character sequence appeared in e.g. a file with
{$codepage utf-8} and is then assigned to a variable whose type is declared
as type ansistring(850).
Thank you very much for the detailed explanation. What I could not found in
all the answers (probably it is my ignorance of the English language), is,
does #n mean a utf16 code unit as in Delphi XE3 or does it denote something
other? You write:
Whether or not they contain character literals whose value is #127
in the source code's code page, or explicit #xx, #xxx etc expressions
has no influence, nothing changed in the compiler in that account.
Assume {$codepage utf-8} how should we enter Russian character constants in #n
form? How should we enter Russian character constants in #n form if
{$codepage 8859-5} is defined?
And again, sorry for the impertinence, how do resource strings fit in the
string handling scenario of Free Pascal trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Saturday 05 January 2013 11:42:29 Sven Barth wrote: On 05.01.2013 11:30, Jonas Maebe wrote: For example, I said that basically nothing changed in 2.7.x compared to 2.6.x, except that certain string constants are no longer automatically converted to utf-16 at compile time, and then you ask Or should we not touch the theme strings and FPC anymore?. Since basically nothing changed except for a few less blind auto-conversions at compile time, why should you no longer be able to touch anything anymore? I think it was more meant in the context of the mailing list instead of a technical context. Like in we had this topic a thousand times and maybe it's better we shut up about it now before we get moderated. Correct. :-) Martin ___ 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)
On Saturday 05 January 2013 12:28:03 Jonas Maebe wrote: Alternatively, in both cases you can instead define a unicodestring/widestring constant instead of an ansistring/shortstring constant by embedding widechar constants in the character sequence. Such widechar constants are of the form #number with number a valid Pascal representation of an integer constant between 255 and 65535. Then you can use those widechars to represent the desired characters as UTF-16 code points. In that case, the entire string will however be parsed as a sequence of UTF-16 code points (because a string is either a sequence of ansichars, or a sequence of widechars; it can never be a mixture of the two), and hence also #1 or #128 appearing in a widestring will be parsed as widechar(#1) and widechar(#128) as opposed to being interpreted according to the current codepage setting. So compiled with -Fcutf8 unicodestringvar:= 'Best'#228'tigung'; produces a different result on fixes_2_6 and trunk? I assume in trunk there will be a compile error? We use this form of character constants in MSEgui to have the sources in pure ASCII. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Saturday 05 January 2013 12:39:21 Jonas Maebe wrote: Then maybe I should just stop completely answering any questions about this, because apparently not answering completely enough to your liking gets interpreted as telling you to shut up or getting moderated. Just like Sven I don't understand where this interpretation comes from, and I strongly resent it. I didn't answer because I thought the information was all in my previous answers already, and if someone else felt they could clarify it better than I did, they were free to do so. My time is also finite, and trying to get me to elaborate further by getting my on my high horse because I feel I'm being misrepresented, is something that will not work very well in the long term. It will much more likely result in silence than in more help. No, no, you understand me wrong. I am merely cautious not to annoy the FPC team, please accept my apology, but I need to decide if FPC is still the right tool for my purposes. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Saturday 05 January 2013 13:01:44 Michael Van Canneyt wrote: Seeing that you have already invested lots of time in FPC, you could also ask yourself 'How can I help improve fpc so it remains the right tool for my purposes' ? Or have you decided that cooperation with the FPC team is an impossibility ? It is not easy mainly because the mission goal is so broad. And a division of work probably would be the better solution. I make my job to build a highly productive open source development environment for Free Pascal and the FPC team makes a compiler which allows to build such a tool. But now we are off topic. Martin ___ 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)
On Saturday 05 January 2013 12:57:44 Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Martin Schreiber wrote: So compiled with -Fcutf8 unicodestringvar:= 'Best'#228'tigung'; produces a different result on fixes_2_6 and trunk? I assume in trunk there will be a compile error? No. In both cases it results in a widestring with this content: .short66,101,115,116,228,116,105,103,117,110,103,0 I guess invalid utf-8 values are just copied through by the compiler. As mentioned: absolutely nothing whatsoever changed in how character sequences are interpreted by the compiler in 2.7.x. The explanation you quoted above (and which I deleted) applies to both 2.6.x and 2.7.x. I really don't know how I can say this in another way, and repeating it clearly doesn't help. I think it's best if you compile trunk for yourself and test as many scenarios as you can, because I feel I cannot add anything further to the discussion, and I'm not interested in playing compile bot. Then it was a misunderstanding again because I read Alternatively, in both cases you can instead define a unicodestring/widestring constant instead of an ansistring/shortstring constant by embedding widechar constants in the character sequence. Such widechar constants are of the form #number with number a valid Pascal representation of an integer constant between 255 and 65535. and Whether or not they contain character literals whose value is #127 in the source code's code page, or explicit #xx, #xxx etc expressions has no influence, nothing changed in the compiler in that account. and I have no idea how anything I wrote suggests that it wouldn't. As mentioned, the only difference is that string constants containing characters #127 are no longer always converted to unicodestring constants at compile time. -- #255 #127 and the question arose how can one define widechar constants for strings without a character value 255. Martin Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
On 01 Jan 2013, at 15:14, Martin wrote:
On my hardware it is normally all fine, but fails if I add the $codepage.
I could spent a lot of work boiling that down to a sample. But given that
I couldn't even find the docs what I really should expect,
Without a {$codepage xxx} directive, string constants containing characters
#127 remain exactly as they appear in the source code.
With a {$codepage xxx} directive, string constants containing characters
#127 are converted into unicodestrings during the parsing (according to the
specified code page), and converted back into ansistrings (using the ansi
code page of that particular program run) at run time if they are assigned
to ansistring/shortstrings or passed to routines expecting such parameters.
Note that the above is for 2.6.x (as the subject mentions).
How does it work in trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Tuesday 01 January 2013 16:44:28 Jonas Maebe wrote:
On 01 Jan 2013, at 16:31, Martin Schreiber wrote:
On Tuesday 01 January 2013 15:24:05 Jonas Maebe wrote:
Without a {$codepage xxx} directive, string constants containing
characters
#127 remain exactly as they appear in the source code.
With a {$codepage xxx} directive, string constants containing characters
#127 are converted into unicodestrings during the parsing (according
to the specified code page), and converted back into ansistrings (using
the ansi code page of that particular program run) at run time if they
are assigned to ansistring/shortstrings or passed to routines expecting
such parameters.
Note that the above is for 2.6.x (as the subject mentions).
How does it work in trunk?
The strings are stored as ansistrings with the appropriate code page.
So
UnicodeStringVariable:= 'abcdäüö';
always will call a conversion function?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Tuesday 01 January 2013 16:54:21 Martin Schreiber wrote:
So
UnicodeStringVariable:= 'abcdäüö';
always will call a conversion function?
And how works
{$codepage 8859-1}
...
UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074;
?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
Thanks, another question, or is the behavior already documented?
UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074;
?
That string contains codepoints #255 and hence is a unicodestring rather
than a single byte string. No conversion at either compile or run time
happens, and the codepage directive has no influence.
{$codepage utf8}
...
UnicodeStringVar:= 'abcd'#228#252#246;
Does it store 'abcdäüö' in trunk?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] utf8 in 2.6.0
On Tuesday 01 January 2013 18:00:59 Jonas Maebe wrote:
I have no idea how anything I wrote suggests that it wouldn't. As
mentioned, the only difference is that string constants containing
characters #127 are no longer always converted to unicodestring constants
at compile time. They are ansistring constants with the appropriate code
page by default, and hence are only converted (at compile, since they are
constants) to a different string type/code page when required.
So #n or #nn or #nnn or # or #n always means Unicode codepoint and
will be at compiletime converted to an 8bit character sequence depending on
{$codepage} and stored in a cpstrnew with the codepage of {$codepage} if
assigned to a cpstrnew variable?
And if the constant is assigned to a UnicodeString variable the Unicode
codepoints are converted and stored to a utf-16 16bit character sequence at
compiletime independent if they contain codepoints 255?
Has somebody a link to Embarcadero documentation about the matter? I assume
FPC trunk does exactly the same as Delphi XE3 with strings?
Thanks for your patience, Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
On Wednesday 26 December 2012 11:20:35 Florian Klämpfl wrote: Am 26.12.2012 06:07, schrieb Martin Schreiber: Hi, Does any body work on a LLVM backend for Free Pascal? Thoughts? The counterpart of what you want: tries to generate great code at any cost while being maintainable and having a portable code generator. Do you have experiences with LLVM? Does it actually create great code? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On Wednesday 26 December 2012 12:41:42 Sven Barth wrote: On 26.12.2012 05:42, Martin Schreiber wrote: Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. AFAIK Delphi 7 does not need such an approach so I hope there is room for optimizations in FPC. Did you even read what we wrote? The mere fact that FPC's backend is more seperated from it's frontend than Delphi's was till XE2 is very likely one of the biggest performance problems FPC has. And this must be compensated in unusal ways like Florian described. Otherwise you'd need to go back to the way that pre-1.9 FPC worked and I don't think anyone of the FPC devs wants that. You'd basically need to rewrite the complete compiler as it is currently geared towards that seperation. Sven, no offending meant, but I know how the FPC RTL, FCL and compiler is programmed. There *is* room for improvement. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Tuesday 25 December 2012 11:20:02 Michael Van Canneyt wrote:
Everybody is aware of the speed difference between Delphi and FPC.
The compiling itself (parsing/producing assembler code) is not slow.
From what I remember, the problems you (and everyone else) experience
with smartlinking and so on are largely due to the GNU linker being
slow and memory hungry.
AFAIK there are significant differences in parsing and code producing too.
Last time I checked on Windows with the internal FPC linker Delphi 7 compiled
and linked about 10 times as fast as FPC.
What concerns produced code: I think that the largest speed gain there
will come from a reorganisation of the exception handling.
What concerns 'stripping the unnecessary' : if you are talking
about language features, I doubt you will gain much speed by that.
The goal here is to reduce the count of the used different concepts so one has
not to learn much to tap the full potential of the language.
I am also fairly confident that if you would create a patch to
introduce a new compiler mode switch {$MODE D7} which would
selectively enable/disable some language features to go back
to the roots, it would be accepted. (I myself would use it ;))
It would unfortunately blow up the code base again.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC statusy
On Tuesday 25 December 2012 18:01:50 Florian Klaempfl wrote: Am 25.12.2012 15:28, schrieb Mattias Gaertner: On Tue, 25 Dec 2012 12:55:41 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] The numbers Martin names (up till 10 times slower, even without linking) are the numbers I have in mind too. IMHO denial without tests is unfair. Maybe the parallelization could be improved? Yes, this might be a good solution for the future but last time this topic came up, Martin still wanted to run FPC on some almost 10 years old machine so parallelization does not help. I use this machine often so I am forced to write efficient code for MSEgui and my projects. Another thing would be an fpc compiler daemon which stays in memory between compilations and keeps also ppus loaded. AFAIK Delphi 7 does not need such an approach so I hope there is room for optimizations in FPC. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Monday 24 December 2012 10:23:00 Sven Barth wrote: Am 24.12.2012 07:48 schrieb Martin Schreiber mse00...@gmail.com: On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. Not Delphi 2009+ btw, which allow UTF8 identifiers. What will FPC do? As I already wrote there are currently no plans to change that FPC supports only ASCII identifiers. I don't think we can trust on that. I hoped that FPC will not use cpstrnew too. So if somebody implements non ASCII identifiers because he needs a second source Delphi compiler it will be merged because the addition does not break existing code. I assume utf-8 identifiers would not be very difficult to do in compiler. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Friday 21 December 2012 18:16:06 Florian Klämpfl wrote: If nobody is interested in features you need, bad luck for you, you have three possibilities: develop them yourself, pay somebody to develop them or use another compiler. BTW, I actually think about to fork Free Pascal. Not in the near future but the primary goals are defined already: - Back to the roots. - Add the necessary to build the most productive universal programming language. - Remove the not necessary. - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Monday 24 December 2012 17:45:34 Henry Vermaak wrote: On Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote: BTW, I actually think about to fork Free Pascal. Not in the near future but the primary goals are defined already: - Back to the roots. What are the roots? - Add the necessary to build the most productive universal programming language. - Remove the not necessary. Subjective, requirements differ. I assume this definition of productive and necessary will be dictated by you and drive other people away from the project. Just like e.g. your coding style has previously. Yup. - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. You know that sacrifices need to be made to make a compiler cross platform and easily portable. You can't have it all. We will see. It will be a shame to see your considerable talent wasted on another project with a bus factor of approximately 1. Correct, but for me an important 1. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sunday 23 December 2012 11:12:42 Leif Ekblad wrote: IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. I don't like to read that. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote: After that there will be 2 RTLs: 1. The classical RTL, compatible with what you have now. 2. The unicode-string RTL which will use the namespaces of Delphi. Do you know how RTTI will be encoded? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. Not Delphi 2009+ btw, which allow UTF8 identifiers. What will FPC do? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Friday 21 December 2012 18:16:06 Florian Klämpfl wrote: Am 21.12.2012 09:23, schrieb Martin Schreiber: On Tuesday 18 December 2012 19:07:47 Florian Klämpfl wrote: Am 17.12.2012 10:36, schrieb Graeme Geldenhuys: Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? It narrows basically down to the fact that fpc lacks developers and contributors, or do I miss something? Don't you think after more than a year of decision-making about Unicode it is necessary for a serious compiler to actually make and communicate a decision? See mail from Michael. Thanks. Don't you think for a serious compiler there should be communicated design goals The mission goal of FPC is: develop an open source pascal compiler written in pascal in a community effort. Thanks. and the missing pieces and necessary boring improvements should be done before adding sexy new things? Maybe people should indeed first work on the compiler instead of developing another gui and ide. In 1999? There was no other useful gui and ide for Free Pascal IIRC. I cannot tell you neither any other developer what they have to develop. We could close down all write accesses to fpc svn till the features you need are developed but I fear you won't get them either this way. People would just fork fpc or fpc would die. So what do you propose? I propose to extend and render more precisely the mission goals of FPC and to concentrate the power on the defined goals. Or is FPC simply a playground for the FPC-developers? Then that should be communicated too and I probably was wrong to invest so much time into the development of MSEide+MSEgui. If nobody is interested in features you need, bad luck for you, you have three possibilities: develop them yourself, pay somebody to develop them or use another compiler. Thanks for the message. I must say, in MSEide+MSEgui project the things are handled a little bit different. For example I never planned to internationalize MSEide because it complicates things, is a boring task and I did not see a benefit. Now a Russian speaking user convinced me, that MSEide can be used in Russian schools only, if translated to Russian. I liked the idea to use our loved Free Pascal in schools, so I took the boring task and moved the string constants to tstringcontainer so it can be translated. Remember, FPC does not support Unicode resource strings up to now. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Friday 21 December 2012 17:46:26 Mark Morgan Lloyd wrote: It would be good to keep those facts in mind before ranting. Cutting out a whole lot of crap: as somebody very much on the periphery of the project, I'm disappointed to see sentiments of this tenor being aired in public. First, in traditional debate it's not considered necessary to be quite so explicit naming names: anybody who follows the project would probably understand certain persons are difficult to get on with because they have their own agenda entirely adequately. Please note that the message has not been posted to the list by me. Additionally many members of the Free Pascal community, including me, don't know English language so writing explicit statements is unavoidable. [...] Apart from that, happy Midwinter Solstice everyone. Yup. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Saturday 22 December 2012 19:09:27 Florian Klämpfl wrote: I must say, in MSEide+MSEgui project the things are handled a little bit different. For example I never planned to internationalize MSEide because it complicates things, is a boring task and I did not see a benefit. Now a Russian speaking user convinced me, that MSEide can be used in Russian schools only, if translated to Russian. I liked the idea to use our loved And what had happened if you didn't like the idea? It depends if I see that someone actually works for the Free Pascal community. If it does not impair the quality of MSEide+MSEgui I help independent whether I like the idea or not. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Saturday 22 December 2012 19:09:27 Florian Klämpfl wrote: Am 22.12.2012 11:23, schrieb Martin Schreiber: I propose to extend and render more precisely the mission goals of FPC and to concentrate the power on the defined goals. And you think people will work on this defined goals instead of maybe completely other projects? Yes. It is a pleasure to work for a project which reaches the goals. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Tuesday 18 December 2012 19:07:47 Florian Klämpfl wrote: Am 17.12.2012 10:36, schrieb Graeme Geldenhuys: Hi, Any FPC developer willing to comment on the status of some of these issues (that have been years overdue)? It narrows basically down to the fact that fpc lacks developers and contributors, or do I miss something? Don't you think after more than a year of decision-making about Unicode it is necessary for a serious compiler to actually make and communicate a decision? Don't you think for a serious compiler there should be communicated design goals and the missing pieces and necessary boring improvements should be done before adding sexy new things? Or is FPC simply a playground for the FPC-developers? Then that should be communicated too and I probably was wrong to invest so much time into the development of MSEide+MSEgui. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Offer to repair and maintain the FPC community website (repeat msg, no HTML)
On Wednesday 26 September 2012 16:02:31 Graeme Geldenhuys wrote: On 2012-09-26 14:33, Marco van de Voort wrote: In our previous episode, Graeme Geldenhuys said: Why not do the best of both worlds. In whose opinion? I thought it would have been obvious. I'm not ready yet to declare FPC/Lazarus as an oldtimers only fad. I'm afraid I don't understand your reply. People who prefer NNTP over a nice and modern WEB-forum are dumb oldtimers. So I am a dumb oldtimer too. I hate WEB-forums and think NNTP is the most convenient and productive discussion format for opensource projects. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: SV: [fpc-devel] fpc on AVR32
On Friday 14 September 2012 05:23:50 Michel Catudal wrote: I bought JTAGICE mkII, it works nicely with Scientific Linux 6.2. The binaries from Fedora 12 and 13 work with Scientifc Linux. I will have no problem with debugging AVR32 code. What I find with AVR32 is that it makes nice compact code. I have written code for a cluster with a Micronas (ARM7TDMI) and AVR32UC3C 144 pins and found a major reduction in code size and code is a lot faster. That is running at the same speed. I run both at 48Mhz. Agreed, it is a very good processor. MSEide can be used to debug AVR32 programs with gdb and the ATMEL gdb server. I use it in combination with the AVR ONE! debug interface and the gnu tool chain. http://sourceforge.net/projects/mseide-msegui/ Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] But what /is/ a string?
On Monday 27 August 2012 13:40:59 Michael Fuchs wrote: Am 27.08.2012 10:51, schrieb Michael Schnell: If in future TObject is reference (as it might be in a future Delphi version, according to an Embarcadero blog) counting (and thus using .Free is not mandatory any more), [...] I hope this will never happen. Me too. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote: You still miss the point. Why deal with single characters, by index, when working with substrings also covers the single-character use? Why not if it is faster, simpler and more intuitive for beginners? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
On Wednesday 22 August 2012 21:47:53 Felipe Monteiro de Carvalho wrote: On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber mse00...@gmail.com wrote: I am not talking about Unicode. I am talking about day by day programming of an average programmer where the live is easier with utf-16 than with utf-8. Unicode is not done by using pos() instead of character indexes. I think everybody knows my opinion, I stop now. Please be clear in the terminogy. Don't say live is easier with utf-16 than with utf-8 if you don't mean utf-16 as it is. Just say live is easier with ucs-2 than with utf-8, then everything is clear that you are talking about ucs2 and not true utf-16. It is with utf-16 and known character constants of the BMP. Please try it. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Tuesday 21 August 2012 09:56:57 Ivanko B wrote: For non-fixed char length there's nothing better than UTF8 (default ASCII compatible, ready for any future alphabets,..). For fixed-char length (fast string operations etc) also there's nothing better than UCS-2 (the Earth coverage ) UCS-4 (the galaxy coverage). The non-fixed char length UTF-16 (UCS-2 + surrogate pairs) looks less efficient than UTF-8 almost from any look point. I disagree. Handling 1..4(6) bytes is less efficient than handling surrogate *pairs*. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 21.08.2012 09:31, schrieb Graeme Geldenhuys: On 21 August 2012 09:13, Martin Schreibermse00...@gmail.com wrote: I disagree. Handling 1..4(6) bytes is less efficient than handling surrogate *pairs*. Yet another myth Ehm, I did both. In the beginning MSEgui switched from Widestring to utf-8 encoded Ansistring because of the buggy FPC widestring implementation (MSEgui started with Delphi/Kylix). Some weeks later I switched back to widestring and bite the bullet to write FPC bug reports until it reached usable stability. But if you are such a UTF-16 (actually UCS-2 as that is what MSEgui supports) fan, why isn't MSEgui source code stored in UTF-16 encoding either? ;-) Sure, MSEgui uses utf-8 for external storing and exchanging text data. Internal all is 16 bit UnicodeString. Use the best encoding for the task. ;-) There is good reason why UTF-8 is so popular. And by the way, a UTF-8 codepoint is only 1-4 bytes in size. It depends on the specification, seen the parentheses?. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
Am 21.08.2012 09:32, schrieb Mattias Gaertner: On Mon, 20 Aug 2012 20:56:46 +0200 Florian Klämpflflor...@freepascal.org wrote: [...] The current situation is: - either somebody starts to implement support for unicodestring being utf-8 (or whatever) on linux in a compatible way with the current approach, then 2.8.0 will use this - nobody works on it, then 2.8.0 comes with unicodestring=utf-16 always. IMO unicodestring should be the same on all platforms, because otherwise the character size switches per platform, which is hard to test and asking for trouble. 100% agreed. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
Am 21.08.2012 09:55, schrieb Graeme Geldenhuys: On 21 August 2012 07:10, Ivanko Bivankob4m...@gmail.com wrote: How about supporting in the RTL all versions of UCS-2 UTF-16 (for fast per-char access etc optimizations) and UTF-8 (for unlimited number of alphabets) ? All access a char by index into a string code I have seen, 99.99% of the time work in a sequential manner. For that reason there is no speed difference between using a UTF-16 or UTF-8 encoded string. Both can be coded equally efficient. Graeme, this is simply not true. Searching for known German characters in a UnicodeString the program can use the simple approach by character (code unit) index. It is even possible for known Chinese symbols of the BMP. And a simple if for surrogate pairs is more efficent as a 4-stage case for utf-8. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode in the RTL (my ideas)
Am 21.08.2012 12:52, schrieb Hans-Peter Diettrich: The good ole Pos() can do that, why search for more complicated implementations? You still try to use old coding patterns which are simply inappropriate for dealing with Unicode strings. Why make a distinction between searching for a single character or multiple characters, when it's known that one character can require multiple bytes or words in UTF-8/16? I wrote known German characters and known Chinese symbols of the BMP for example character constants. If you want to read some examples of problems with utf-8 especially for pupils and Pascal beginners read the German Lazarus Forum or freepascal.ru. Why should we design programming so that it complicates the work for them? Anyway, I don't care, do what you want but please implement Unicode resource strings in FPC compiler. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 09:52:47 Sven Barth wrote: Just to avoid confusion: The reference counted 2-byte string type on all platforms is UnicodeString, not WideString (the latter is not reference counted on Windows platforms). WideString was reference counted on Windows when it was introduced in FPC. The FPC revision was 1.9.x IIRC. The first bug report I made in wide area is from 30.4.2004 and revision 1.9.3. http://bugs.freepascal.org/view.php?id=5084 Later it has been changed to OLE string on Windows because of Delphi compatibility. http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg07520.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03010.html http://www.mail-archive.com/fpc-devel%40lists.freepascal.org/msg03018.html Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 10:35:09 Mattias Gaertner wrote: Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. I guess most people would say that good multi language Unicode support in FPC requires a Unicode supporting RTL. Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 11:10:27 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. IMHO it is more a question if a hard break like Delphi is necessary or that there is a way to switch basetypes. (like what to do with overrides?) I'm starting to believe the hard break is the only serious option. My opinion: Do what you want with RTL and FCL but optimize the compiler so it is possible to build optimal frameworks for different requirements. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 11:39:34 Mattias Gaertner wrote: Not necessarily. Lazarus, fpGUI and MSEgui have their own implementations which don't need to be strictly Delphi compatible and therefore can better suit the users needs. Yes, specializations have advantages. I only think that good Unicode support in FPC sounds as if all the important things of Unicode are in FPC and you don't need extra libs. True. I actually meant the possibilities of the compiler. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 12:37:24 Anton Kavalenka wrote: Since the beginning of my FPC use I maintain the following FPC/Delphi compatible code. Does it work if the source has been compiled with -Fcutf8 on Windows? IIRC FPC converts the source utf8 constants to the system encoding before building the resource string tables. Another question is the encoding of the *.rst files we need in the MSEi18n tool. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Monday 20 August 2012 14:45:34 Anton Kavalenka wrote:
On 20.08.2012 15:45, Martin Schreiber wrote:
On Monday 20 August 2012 14:32:22 Anton Kavalenka wrote:
Resources from both Windows and Linux EXE are extracted in UTF-8 (not
win1251).
Do you compile with -Fcutf8 or {$codepage utf8}?
I use default implicit settings (I suppose it is UTF8).
None of my sources contain codepage controlling directive.
This probably explains the difference. MSEgui uses UnicodeString and is
compiled with -Fcutf8 for assignement of Unicode string constants to
UnicodeString variables and transparent conversion of Unicode string
constants to system encoding at runtime.
Without -Fcutf8 or {$codepage utf8} FPC copies the 8 bit strings as is into
the executable.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Unicode resource strings
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. Is there a replacement or supplement for http://wiki.freepascal.org/FPC_Unicode_support which answers such questions? Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resource strings
On Sunday 19 August 2012 09:41:48 Paul Ishenin wrote: 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. Thanks Jonas and Paul. Please permit a little comment. All what was missing for good multi language Unicode support in FPC after Florian and Peter implemented widestrings (which were reference counted on all platforms at the beginning!) are Unicode resource strings. Now, many years later, we still don't have Unicode resource strings but we have codepage aware 8-bit strings? I don't understand the priorities. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Opening FPC base classes
Hi, I am the author of MSEide+MSEgui, a Free Pascal development environment: http://sourceforge.net/projects/mseide-msegui/ MSEide+MSEgui is not Delphi compatible and handles some basic TComponent issues differently to Lazarus: http://www.lazarus.freepascal.org/ Is it possible to add protected //for toolkit access only property OwnerPrivate: TComponent read FOwner write FOwner; deprecated; property NamePrivate: TComponentName read FName write FName; deprecated; property ComponentsPrivate: TfpList read FComponents write FComponents; deprecated; property ComponentStatePrivate: TComponentState read FComponentState write FComponentState; deprecated; property FreeNotifiesPrivate: TFpList read FFreeNotifies write FFreeNotifies; deprecated; to TComponent in order other toolkits than Lazarus can fulfil their taskwithout the necessity of changes in the FPC RTL? TReader and TWriter are classes which normally are used by frameworks only. Is it possible to move all private fields of TFiler, TReader and TWriter to protected in order other toolkits than Lazarus can fulfil their task without the necessity of changes in the FPC RTL? Is it possible to add protected //for toolkit access only property HandlePrivate: THandle read FHandle write FHandle; deprecated; to THandleStream and protected //for toolkit access only property CapacityPrivate: PtrInt read FCapacity write FCapacity; deprecated; to TMemoryStream? Thank you very much, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote: Numbers, not count. I want to know which bugs are worked around by crackers. That's easy: 0 bugs. Sorry, there where bugs in the past and there probably will be in the future. Martin needs the crackers for some mse* features. Which otherwise can't be implemented without changes in FPC or FCL. I don't dare to ask for changes so cracker classes were a workaround without to bother FPC team. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Class field reordering
On Sunday 22 July 2012 11:28:22 Michael Van Canneyt wrote: On Sun, 22 Jul 2012, Martin Schreiber wrote: On Sunday 22 July 2012 10:52:33 Michael Van Canneyt wrote: Numbers, not count. I want to know which bugs are worked around by crackers. That's easy: 0 bugs. Sorry, there where bugs in the past and there probably will be in the future. There are always bugs. We fix those as soon as we can. Florian is talking about bugs you fix with cracker classes. Me too. Martin needs the crackers for some mse* features. Which otherwise can't be implemented without changes in FPC or FCL. I don't dare to ask for changes so cracker classes were a workaround without to bother FPC team. That's because you don't just ask for changes. You ask for your own solutions to be implemented in FPC. I do not ask for my own solutions, I ask to move private FPC class fields and methods of base classes which are used in different toolkits to protected in order to make them more flexible without changing any functionality and because the current workaround with cracker classes may be not possible anymore in future because of upcoming FPC optimisations. [...] Cooperation works in 2 directions. I'm willing to think about solutions. You must give detailed descriptions of what you think is a problem, and be prepared to accept solutions that are maybe not 100% to your liking. If you are not prepared to accept such solutions, then I cannot help you. Sorry Michael, I do not trust that the effort is worth the outcome for me. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
