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,
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"
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 only
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
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 (altho
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 compon
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 n
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 (NewCapac
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 s
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
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 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 pt
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 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
> > th
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.o
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 han
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 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 cau
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
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 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 mention
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
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 no
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-
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!&qu
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 be
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, Op
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
On Monday 04 March 2013 14:54:01 Mattias Gaertner wrote:
> On Mon, 4 Mar 2013 14:50:17 +0100
>
> Martin Schreiber 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
> &
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 co
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 w
On Monday 04 March 2013 14:37:40 Daniël Mantione wrote:
> Originally the compiler was doing the candidate selection with a simple
> loop through the parameters that took the first suitable match. When the
> type conversion matters became more complex the "Unable to determine
> overloaded procedure
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 MSEi
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, mai
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.n
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"
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,
>
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
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
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 compile
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 get
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 obv
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 n
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 cen
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 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,
> >>>
>
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, curr
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 produc
Am 01.03.2013 20:52, schrieb Michael Van Canneyt:
For a correct test, you should not enable debug information in FPC.
Or enable generation of turbo debug information and the corresponding
linker map in Delphi.
Otherwise you are comparing apples with pears, as -D+ in delphi does not
do nearly th
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:
wi
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 sema
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 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 fix
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
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 un
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 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
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 t
On Tuesday 01 January 2013 18:36:01 Martin Schreiber wrote:
>
> 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 {$
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
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
>
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:= 'ab
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
> >>
>
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 reall
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 De
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
>
Hi,
Does any body work on a LLVM backend for Free Pascal?
Has anybody experience with LLVM?
Are there licensing issues?
What about the quality of the produced code?
What about compiling speed?
Thoughts?
Thanks, Martin
___
fpc-devel maillist - fpc-devel
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)
> >
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 smartli
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
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 10:23:00 Sven Barth wrote:
> Am 24.12.2012 07:48 schrieb "Martin Schreiber" :
> > On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote:
> > > In our previous episode, Michael Van Canneyt said:
> > > > > Do you know
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 allo
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 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.free
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 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
> >
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.
>
> F
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,
> >>>
> >>&
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 devel
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
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), [...]
>
>
On Wednesday 22 August 2012 21:47:53 Felipe Monteiro de Carvalho wrote:
> On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber
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 Wednesday 22 August 2012 15:07:50 Hans-Peter Diettrich wrote:
> Martin Schreiber schrieb:
> > 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 substr
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
___
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 cha
Am 21.08.2012 09:55, schrieb Graeme Geldenhuys:
On 21 August 2012 07:10, Ivanko B 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
Am 21.08.2012 09:32, schrieb Mattias Gaertner:
On Mon, 20 Aug 2012 20:56:46 +0200
Florian Klämpfl 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
Am 21.08.2012 09:31, schrieb Graeme Geldenhuys:
On 21 August 2012 09:13, Martin Schreiber 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
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-
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).
> >
&
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
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 bu
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 thin
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
> > b
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
1 - 100 of 584 matches
Mail list logo
