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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
>
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
> >
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
>
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
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
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
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
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
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
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
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 -
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
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
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
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
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:
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 -
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
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
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
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
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.
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
1 - 100 of 513 matches
Mail list logo
