On 12/24/2012 05:19 PM, Martin Schreiber wrote:
- Compile at least as fast as Delphi 7
IMHO hard to do for a portable system and not very important regarding
modern hardware. I only feel the linking stage is a viable goal here, as
in most cases the by far most of the already compiled units
On 12/25/2012 02:22 PM, Florian Klaempfl wrote:
What's the advantage in doing so? The code hangs around and does not
hurt in any way.
+1
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
2012/12/25 Sven Barth pascaldra...@googlemail.com:
On 25.12.2012 19:30, Dimitri Smits wrote:
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
I'm guessing that is NOT on a Windows platform? Every full build (it has
been a while) I've ever done of the
On 26.12.2012 10:16, luiz americo pereira camara wrote:
2012/12/25 Sven Barth pascaldra...@googlemail.com:
On 25.12.2012 19:30, Dimitri Smits wrote:
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
I'm guessing that is NOT on a Windows platform? Every full
In our previous episode, luiz americo pereira camara said:
That's likely because of the slower process startup time of Windows. Also
the GNU utilities we use (make, etc.) aren't the fastest on Windows either.
Also command line output can slow down things dramatically (cmd.exe or the
Michael Van Canneyt wrote:
On Mon, 24 Dec 2012, Martin Schreiber wrote:
- 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
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 Tue, 25 Dec 2012, Martin Schreiber wrote:
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
On Tue, 25 Dec 2012, Sven Barth wrote:
On 25.12.2012 12:13, Martin Schreiber wrote:
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
On 25.12.2012 12:40, Michael Van Canneyt wrote:
On Tue, 25 Dec 2012, Sven Barth wrote:
On 25.12.2012 12:13, Martin Schreiber wrote:
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
Sven Barth wrote:
On 25.12.2012 11:32, Mark Morgan Lloyd wrote:
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
They aren't compiled anyway, so they don't affect the compiler's
performance negatively.
So it does
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
Agreed.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 25.12.2012 12:38, schrieb Michael Van Canneyt:
On Tue, 25 Dec 2012, Martin Schreiber wrote:
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
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 25.12.2012 11:32, Mark Morgan Lloyd wrote:
Although I think the time is approaching when some CPUs- IA-64 etc.- and
OSes could usefully be moved into an attic subtree.
They aren't compiled anyway, so they don't affect the
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Is this close i386 intermediate code similar to IR LLVM generation ?
if so, this may become a good option for a new strategy ?
Am 25.12.2012 14:44, schrieb Jy V:
The only approach I see to speed it up is to kick the whole back end
and generate directly some close to i386 intermediate code directly
in the parser.
Is this close i386 intermediate code similar to IR LLVM generation ?
No. It must be much
Is this close i386 intermediate code similar to IR LLVM generation ?
No. It must be much closer to i386 else there is no speed advantage over
the current approach.
OK, understood.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 25.12.2012 14:15, Florian Klaempfl wrote:
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Ewww... please not...
Regards,
Sven
___
fpc-devel
Am 25.12.2012 15:04, schrieb Sven Barth:
On 25.12.2012 14:15, Florian Klaempfl wrote:
The only approach I see to speed it up is to kick the whole back end and
generate directly some close to i386 intermediate code directly in the
parser.
Ewww... please not...
No, we would be back in pre 1.0
Sven Barth wrote:
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic, Amiga etc.) could IMO usefully be
in compiler/attic
In our previous episode, Mark Morgan Lloyd said:
interest to implement such a CPU... *cough* m68k *cough* ;)
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic,
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
Aan: FPC developers' list fpc-devel@lists.freepascal.org
Verzonden: Dinsdag 25 december 2012 14:15:24
Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
I see no way to speed up the 2.x FPC
On 25.12.2012 18:12, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 25.12.2012 13:24, Mark Morgan Lloyd wrote:
Agreed. But combinations that don't compile meaningfully (e.g. the
compiler targeting IA-64) or at all without at least backported patches
(various RTLs including MacOS Classic,
Am 25.12.2012 19:30, schrieb Dimitri Smits:
I'm guessing that is NOT on a Windows platform? Every full build (it
has been a while) I've ever done of the compiler on windows was at
least a few minutes.
It is windows: self compilation. No rtl building or whatever.
The only approach I see to
On 25.12.2012 19:30, Dimitri Smits wrote:
- Oorspronkelijk e-mail -
Van: Florian Klaempfl flor...@freepascal.org
Aan: FPC developers' list fpc-devel@lists.freepascal.org
Verzonden: Dinsdag 25 december 2012 14:15:24
Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
I see
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
Den 24-12-2012 07:53, Martin Schreiber skrev:
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
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
Martin Schreiber wrote:
On Monday 24 December 2012 10:23:00 Sven Barth wrote:
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
In our previous episode, Mark Morgan Lloyd said:
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
On 24/12/2012 12:17, Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
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
In our previous episode, Martin said:
Hm that makes it easy to have an incomplete list, that could later
become a problem
half-width spaces etc..., control chars (RTL/LTR...), currently unused
codepoints (that could become anything in future...)
Still shorter than what is allowed. And
On 24/12/12 11:22, Martin wrote:
half-width spaces etc..., control chars (RTL/LTR...), currently unused
codepoints (that could become anything in future...)
As Marco said, the list will be smaller than the allowed list.
Also the Unicode specification defines blocks or categories for code
In our previous episode, Hans-Peter Diettrich said:
and component libraries to the new strings, RTL and LCL? IMO a typical
loose-loose situation :-(
? No, the old RTL will remain maintained. It's the same codebase, just
recompiled.
Sorry, I doubt that it is so easy :-(
Just a
On 24/12/2012 13:05, Marco van de Voort wrote:
In our previous episode, Martin said:
Hm that makes it easy to have an incomplete list, that could later
become a problem
half-width spaces etc..., control chars (RTL/LTR...), currently unused
codepoints (that could become anything in future...)
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 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
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
Graeme Geldenhuys wrote:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
Which is why I suggested that a semi-formal way of taking disputes to it
Am 23.12.2012 01:50, schrieb Graeme Geldenhuys:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
I don't think direction on unicode (or even
On 23.12.2012 01:50, Graeme Geldenhuys wrote:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
I don't think direction on unicode (or even
On Sun, 23 Dec 2012, Graeme Geldenhuys wrote:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
No, but I think you hugely overestimate what goes
On Sun, 23 Dec 2012, Sven Barth wrote:
to remember to mention which RTL they are using when reporting bugs,
keeps those two RTL's in sync over time etc. Yeah, it seams you guys are
sometimes not to knowledgeable either. All you are going to do is create
more work for yourselves. But hey, who
-
From: Hans-Peter Diettrich drdiettri...@aol.com
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Sunday, December 23, 2012 5:49 AM
Subject: Re: [fpc-devel] Forwarded message about FPC status
Graeme Geldenhuys schrieb:
Well, let me just say that the idea of two RTL's
On Sun, 23 Dec 2012, Hans-Peter Diettrich wrote:
Graeme Geldenhuys schrieb:
Well, let me just say that the idea of two RTL's is rather ridiculous
too!!
It's not different from Delphi, where the introduction of UnicodeString
required a renewed RTL, VCL and IDE. Who should do the same for
On 23.12.2012 11:11, Michael Van Canneyt wrote:
On Sun, 23 Dec 2012, Sven Barth wrote:
to remember to mention which RTL they are using when reporting bugs,
keeps those two RTL's in sync over time etc. Yeah, it seams you guys are
sometimes not to knowledgeable either. All you are going to do
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
Leif Ekblad wrote:
IMO, I wouldn't support wide-character (UnicodeString) strings for
anything new.
In the beginning the wide-character string had the advantage of being
able to represent
all characters with 2 bytes, but this is no longer the case. I would
switch to UTF-8
instead and keep
In our previous episode, Graeme Geldenhuys said:
OK, so once again it is proven that Unicode is just not sexy enough
for the core team, so it will stay stagnant for a few more years.
No. Simply getting older.
That's unless a member ignores all discussions and does his own thing [or
gets paid
In our previous episode, Leif Ekblad said:
all characters with 2 bytes, but this is no longer the case. I would switch
to UTF-8
instead and keep characters 1 byte long. A switch to UTF-8 only affects a
small amount of the code-base, and doesn't break string references.
Any solution will need
On 23/12/12 10:13, Michael Van Canneyt wrote:
? No, the old RTL will remain maintained. It's the same codebase, just
recompiled.
It was impossible to deduce that from your earlier reply
http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27659.html
With the new information at
On Sun, 23 Dec 2012, Graeme Geldenhuys wrote:
On 23/12/12 10:13, Michael Van Canneyt wrote:
? No, the old RTL will remain maintained. It's the same codebase, just
recompiled.
It was impossible to deduce that from your earlier reply
Sven Barth wrote:
Did you know that my addition of target NativeNT was published as patch
to the bug tracker? Did you know that I wrote patches for the cppclass
feature to get it a bit more working than before? It was only the class
helpers where I got access to a personal branch in SVN and
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 23.12.2012 16:58, Martin Schreiber wrote:
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
On Sun, 23 Dec 2012, Martin Schreiber wrote:
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
On 23.12.2012 17:01, Michael Van Canneyt wrote:
On Sun, 23 Dec 2012, Martin Schreiber wrote:
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
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.
___
fpc-devel
Leif Ekblad schrieb:
IMO, I wouldn't support wide-character (UnicodeString) strings for
anything new.
In the beginning the wide-character string had the advantage of being
able to represent
all characters with 2 bytes, but this is no longer the case. I would
switch to UTF-8
instead and keep
Michael Van Canneyt schrieb:
Well, let me just say that the idea of two RTL's is rather ridiculous
too!!
It's not different from Delphi, where the introduction of
UnicodeString required a renewed RTL, VCL and IDE. Who should do the
same for FPC and Lazarus, and tell the users that they
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 Sat, 22 Dec 2012, ListMember wrote:
On 2012-12-22 00:27, Sven Barth wrote:
Am 21.12.2012 22:20 schrieb ListMember listmem...@letterboxes.org:
Can you (or someone else, of course) think of a better search string to
locate it?
Go to View Issues, click on the +
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
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 2012-12-22 11:48, Michael Van Canneyt wrote:
On Sat, 22 Dec 2012, ListMember wrote:
On 2012-12-22 00:27, Sven Barth wrote:
Am 21.12.2012 22:20 schrieb ListMember
listmem...@letterboxes.org:
Can you (or someone else, of course) think of a better search
string to locate it?
On 22/12/12 10:34, Martin Schreiber wrote:
Please note that the message has not been posted to the list by me.
My apologies Martin. I should have taken your questions and rephrased
them in a list form. To save time, I simply obfuscated the names -
probably not the best idea. The names where not
On 21/12/12 16:46, Mark Morgan Lloyd wrote:
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.
Mark, much of what happens with the FPC project seems to be done in
secrecy, or a
On 21/12/12 17:16, Florian Klämpfl wrote:
The mission goal of FPC is: develop an open source pascal compiler
written in pascal in a community effort.
You forgot the last bit and be Delphi compatible!
Maybe people should indeed first work on the compiler instead of
developing another
On Sat, 22 Dec 2012, Graeme Geldenhuys wrote:
On 21/12/12 16:46, Mark Morgan Lloyd wrote:
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.
Mark, much of what happens with the FPC
In our previous episode, Graeme Geldenhuys said:
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.
Mark, much of what happens with the FPC project seems to be done in
secrecy,
Am 22.12.2012 14:01, schrieb Graeme Geldenhuys:
On 21/12/12 17:16, Florian Klämpfl wrote:
The mission goal of FPC is: develop an open source pascal compiler
written in pascal in a community effort.
You forgot the last bit and be Delphi compatible!
IMO this is actually a consequence of
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? Or just fork FPC?
In
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 22.12.2012 20:03, Martin Schreiber wrote:
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
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
I don't think direction on unicode (or even general) came up since the last
unicode discussions on
Graeme Geldenhuys schrieb:
Well, let me just say that the idea of two RTL's is rather ridiculous
too!!
It's not different from Delphi, where the introduction of UnicodeString
required a renewed RTL, VCL and IDE. Who should do the same for FPC and
Lazarus, and tell the users that they either
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 Mon, 17 Dec 2012, Graeme Geldenhuys wrote:
Hi,
Any FPC developer willing to comment on the status of some of these
issues (that have been years overdue)?
For some reason this thread ended up in my spam box. Hence the late reply.
As for the question:
I've planned to do some work on the
On 21/12/12 10:15, Michael Van Canneyt wrote:
It would be good to keep those facts in mind before ranting.
I was simply bringing some of those questions (which I had too) to
light. Unicode has been under development for many years, and has come
to a halt - with no final decisions being made.
On Fri, 21 Dec 2012, Graeme Geldenhuys wrote:
On 21/12/12 10:15, Michael Van Canneyt wrote:
It would be good to keep those facts in mind before ranting.
I was simply bringing some of those questions (which I had too) to
light. Unicode has been under development for many years, and has
On 21/12/12 12:26, Michael Van Canneyt wrote:
We know what to do. What we lack, is time.
Status currently:
Thanks for the update. Most of what you mentioned was unknown to any
person outside the FPC core team. So to us outsiders, it seems like
progress has halted.
Regards,
- Graeme -
Graeme Geldenhuys gra...@geldenhuys.co.uk hat am 21. Dezember 2012 um 13:49
geschrieben:
On 21/12/12 12:26, Michael Van Canneyt wrote:
We know what to do. What we lack, is time.
Status currently:
Thanks for the update. Most of what you mentioned was unknown to any
person outside the
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
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
Am 21.12.2012 12:58, schrieb Graeme Geldenhuys:
On 21/12/12 10:15, Michael Van Canneyt wrote:
It would be good to keep those facts in mind before ranting.
I was simply bringing some of those questions (which I had too) to
light. Unicode has been under development for many years, and has
On 2012-12-21 14:26, Michael Van Canneyt wrote:
- Inoussa has made a native unicode string manager. A large effort.
Is this code publicly available somewhere?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Fri, 21 Dec 2012, ListMember wrote:
On 2012-12-21 14:26, Michael Van Canneyt wrote:
- Inoussa has made a native unicode string manager. A large effort.
Is this code publicly available somewhere?
It's attached to a bugreport in Mantis somewhere.
Michael.
On 2012-12-21 22:29, Michael Van Canneyt wrote:
On Fri, 21 Dec 2012, ListMember wrote:
On 2012-12-21 14:26, Michael Van Canneyt wrote:
- Inoussa has made a native unicode string manager. A large effort.
Is this code publicly available somewhere?
It's attached to a bugreport in Mantis
Am 21.12.2012 22:20 schrieb ListMember listmem...@letterboxes.org:
On 2012-12-21 22:29, Michael Van Canneyt wrote:
On Fri, 21 Dec 2012, ListMember wrote:
On 2012-12-21 14:26, Michael Van Canneyt wrote:
- Inoussa has made a native unicode string manager. A large effort.
Is this code
On 2012-12-22 00:27, Sven Barth wrote:
Am 21.12.2012 22:20 schrieb ListMember listmem...@letterboxes.org
mailto:listmem...@letterboxes.org:
Can you (or someone else, of course) think of a better search string
to locate it?
Go to View Issues, click on the + before the search bix, click
Graeme Geldenhuys wrote:
This is why I decided to diversify, and why I will once again turn my
attention to Java (not
JavaScript-that-is-the-assembly-language-of-the-internet). Java seems
the sensible route to go, for long term employment. There is a very
healthy Java industry (stacks of jobs),
On 12/17/2012 03:44 PM, Graeme Geldenhuys wrote:
Probably not even implemented, because Delphi IDE is Windows only -
and there are no plans to make a cross-platform IDE by Embarcadero.
Regards, - Graeme -
IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus,
as adding a
On 12/17/2012 03:55 PM, Sven Barth wrote:
No. We need to think about this ourselves as we support more targets
than Delphi ever will support.
Even cross-platform runtime packages might make sense (e.g. linking a
native plugin package to an Android/Java Program)
Something I could
On 12/17/2012 04:29 PM, Sven Barth wrote:
From what I see so far of the route that Embarcadero takes (complete
reimplementation of compiler, sudden appearence of type helpers and
things like zero based strings) I predict that we'll reach a point
in the near(!) future where we won't (be able
On 18/12/12 12:19, Michael Schnell wrote:
IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus,
as adding a source package and recompiling does the trick just as well.
Tell that to component developers and companies like Devx, TMS etc! With
the current way things work, there
In our previous episode, Graeme Geldenhuys said:
IMHO Delphi-like IDE (design-time) packages are not useful in Lazarus,
as adding a source package and recompiling does the trick just as well.
Tell that to component developers and companies like Devx, TMS etc! With
the current way things
On 18/12/12 13:26, Marco van de Voort wrote:
They could deliver ppu's and .o's.
True, but widely untested. As a previous conversation from a few month
back ended... it should work in theory.
Also Lazarus Packages are designed to work with source only. There is no
option to install .ppu's and
: Maandag 17 december 2012 16:20:39
Onderwerp: Re: [fpc-devel] Forwarded message about FPC status
Sven Barth schrieb:
Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich:
Sven Barth schrieb:
still no Delphi-like packages...
They are planned long term, but they are no cheesecake feature.
We
Am 18.12.2012 15:00, schrieb Dimitri Smits:
As Sven wrote, I guess the FPC community needs to think about this. XE2 already
supported MacOS X (but through fpc). Haven't checked the OS-X in XE3 though.
Only iOS was done through FPC. Mac OS X itself was already done through
Embarcadero's
1 - 100 of 113 matches
Mail list logo
