Op 2010-10-20 02:04, Hans-Peter Diettrich het geskryf:
> to that list. I hope that such a fork can be kept in sync with the SVN
> trunk, at least for the compiler back-ends, somehow - Graeme?
Yes, an easy task. Add a new remote repository (current github mirror of
FPC's SubVersion repository). The
Op 2010-10-19 18:38, Alexander Klenin het geskryf:
>
> Ok, I went ahead and have taken look at the code.
> I assume you speak about TFPHashList vs TFPCustomHashTable.
> The classes are not really comparable, because they use quite
> different internal data structures.
I did the same thing last ni
Op 2010-10-19 18:22, Michael Van Canneyt het geskryf:
>
> Sorry, I was talking about classes. I don't use objects from TP;
> I consider them deprecated.
I still use objects instead of classes in certain parts of my code. They
definitely have their uses. They're like records with methods (which by
Am 20.10.2010 01:09, schrieb Hans-Peter Diettrich:
It sounds like you give us little credit.
Sorry for that and thanks you for your work.
But, by the same token, don't you think that you also give a little
credit to
Hans' work? Maybe his reasons are also good?
As I explained in another mail, I
Michael Van Canneyt schrieb:
Sorry, I was talking about classes. I don't use objects from TP;
I consider them deprecated.
I use Object in the semantic stuff, just to avoid try-finally blocks. As
long as Class objects must reside on the heap, Object still has advantages.
Besides my personal
Alexander Klenin schrieb:
Actually, I certainly think (and hope) that DoDi's goal is _not_ a "C frontend",
but to find _any_ possible venue to upgrade the code structure of FPC code.
Well - both ;-)
I would like to see my C parser working as an FPC front-end, instead of
producing intermediate
Florian Klaempfl schrieb:
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
First Pascal-like languages and later C.
FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage over existing C compilers except being a pascal compi
Florian Klämpfl schrieb:
Well, DoDi is not willing to fix the flaws of his patches so they were
rejected, see e.g.: http://bugs.freepascal.org/view.php?id=17584
You're kidding. The same result in a branch, with intermediate steps,
would be rejected as well (NoGlobal branch). Why break one pat
Florian Klaempfl schrieb:
and refactorings are not welcome.
Who says this? Usefull refactoring *is* welcome.
Umm, please specify what you understand by "refactoring".
Something that does not move code around, or into new subroutines?
Something that can be achieved in a sequence of only sma
Martin Schreiber schrieb:
This is a typical showcase for the premature micro-optimization --
for a few percentages of speed in the short term,
you pay in reduced code maintainability,
which precludes high-level optimizations in the long term.
IIRC one of the goals are to enable muti threaded c
On Tuesday 19 October 2010 14:44:38 Florian Klaempfl wrote:
> Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
> > First Pascal-like languages and later C.
> > FPC's main developer doesn't see a need for it.
>
> Indeed. Please tell what a C front end to FPC helps? FPC has no
> advantage over ex
Marco van de Voort wrote:
Hello,
We have placed the first release-candidate of the Free Pascal Compiler
version 2.4.2 on our ftp-servers.
You can help improve the upcoming 2.4.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.free
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
/tests/test/units/fpcunit/? If so, is that all of th
Am 19.10.2010 16:42, schrieb Alexander Klenin:
> On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote:
>> On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
>>
>>> 1) I have serious suspicions that compile time on modern processors
>>> is dominated by linking and I/O.
>>> At least this
In our previous episode, Sergei Gorelkin said:
> >
> > Average string length 45 characters:
> > ShortString: 12.0 s
> > AnsiString: 3.2 s
> >
> > I agree that the first case is more relevant for the compiler,
> > but still you can see that ShortStrings are clearly not always faster.
> >
> I beli
Michael Van Canneyt пишет:
I believe it's not ShortStrings per se to blame, but storing them in a
large single memory block as it is being done in TFPHashList. Adding a
lot of keys will cause many reallocations. Large size of the block
forces memory manager to use variable-size pool, which is
On Tue, 19 Oct 2010, Sergei Gorelkin wrote:
Alexander Klenin пишет:
Ok, I went ahead and have taken look at the code.
I assume you speak about TFPHashList vs TFPCustomHashTable.
The classes are not really comparable, because they use quite
different internal data structures.
So instead I con
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. The pchar
version is easily 20% faster. It comes from the
Thanks Helmut for your encouraging message. I enjoy lurking and
learning by reading these extensive threads.
Back in March 2010 there was a similar thread about Lazarus development
and in the end several people posted their success stories which are now
here:
http://www.lazarussupport.com/
On Wed, Oct 20, 2010 at 04:54, Sergei Gorelkin wrote:
> Alexander Klenin пишет:
>> Benchmarking included 3*10^6 calls to Add and Find methods
>> with the arguments of various lengths.
>>
>> Average string length 5 characters:
>> ShortString: 1.15 s
>> AnsiString: 1.56 s
>>
>> Average string length
Alexander Klenin пишет:
Ok, I went ahead and have taken look at the code.
I assume you speak about TFPHashList vs TFPCustomHashTable.
The classes are not really comparable, because they use quite
different internal data structures.
So instead I converted TFPHashList list to use ansistrings.
Ben
Am 19.10.10 15:40, schrieb Alexander Klenin:
I fully understand that the reason for degrading the code structure
was efficiency.
I just doubt that it was/is a good trade-off.
Dear FPC Team,
After finishing porting the bullet physics library from C++ to FPC in the
last 2 months (http://bulletph
On 2010-10-19 19:38, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
If you need more convincing: the contnrs unit contains 2 hash classes.
one based on ansistrings, one with pchars and shortstrings. The pchar
version is easily 20% faster. It comes from the c
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
> If you need more convincing: the contnrs unit contains 2 hash classes.
> one based on ansistrings, one with pchars and shortstrings. The pchar
> version is easily 20% faster. It comes from the compiler code and was
> written specially by
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
What can be optimized, must be optimized.
Sorry, but does not this sound slightly exaggerated? :-)
2) I may believe that records are faster then classes,
but if they are faster then obje
On Tuesday, 19. October 2010 17.17:04 Graeme Geldenhuys wrote:
> Op 2010-10-19 17:06, Martin Schreiber het geskryf:
> > core aware compiler without a team of highest skilled fulltime developers
> > working several years...
>
> Why do you think we are not that already? :-)
>
Aha! Maybe that's the r
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
> What can be optimized, must be optimized.
Sorry, but does not this sound slightly exaggerated? :-)
>> 2) I may believe that records are faster then classes,
>> but if they are faster then objects, then this is a compiler problem,
>> sinc
On 19/10/10 15:42, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote:
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
1) I have serious suspicions that compile time on modern processors
is dominated by linking and I/O.
At least this is certainly true
Op 2010-10-19 17:06, Martin Schreiber het geskryf:
> core aware compiler without a team of highest skilled fulltime developers
> working several years...
Why do you think we are not that already? :-)
[...I have learned from past experience that assuming something is very
bad, especially if you
On Tuesday, 19. October 2010 16.42:19 Alexander Klenin wrote:
> > Do you remember the factor 10 compiling speed advangage of Delphi7
> > compared with FPC 2.4?
> > http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg19068.html
>
> I do. I also remember that one of the goals of DoDi's pre
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and
Am 19.10.2010 14:38, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl
> wrote:
>> Am 19.10.2010 13:54, schrieb Alexander Klenin:
>>> from fixing case and reformatting of Math unit
>>
>> This does not help anybody ;)
> See, you have already rejected it ;-)
> The initial
Hi,
i know that in a Release Candidate stage is difficult or not appropriate
to make big changes, but the http://bugs.freepascal.org/view.php?id=17664
is a trivial one.
"In the initialization section of the ibase60.inc, is missing the const
'fbembedlib' of the library name for the default Fireb
On Wed, Oct 20, 2010 at 01:30, Martin Schreiber wrote:
> On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
>
>> 1) I have serious suspicions that compile time on modern processors
>> is dominated by linking and I/O.
>> At least this is certainly true for FPC on Windows case.
>
> Do you
On Tuesday, 19. October 2010 16.11:33 Alexander Klenin wrote:
> 1) I have serious suspicions that compile time on modern processors
> is dominated by linking and I/O.
> At least this is certainly true for FPC on Windows case.
Do you remember the factor 10 compiling speed advangage of Delphi7 comp
Am 19.10.2010 14:02, schrieb Florian Klaempfl:
to finishing/extending Paul's work on for..in loop.
Does it still miss stuff? Actually, I never used it :)
Perhaps Alexander is talking about the points mentioned here:
http://wiki.freepascal.org/for-in_loop#Proposed_extensions
I am currently
On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl wrote:
> Am 19.10.2010 12:07, schrieb Alexander Klenin:
>> I personally wanted to do some things for FPC (although Unicode was
>> not one of them),
>> but hesitated, because the current code is too messy and fragile to touch,
>
> In which areas?
I h
Am 19.10.2010 13:54, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 22:41, Florian Klaempfl
> wrote:
>> Am 19.10.2010 12:07, schrieb Alexander Klenin:
>>> I personally wanted to do some things for FPC (although Unicode was
>>> not one of them),
>>> but hesitated, because the current code is
Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
wrote:
2) I'd say that at least half of his mistakes could be avoided
by better code structure of FPC -- he was really uncomfortable
using strange records and pchars instead of normal objects and strings.
That has nothi
On Tuesday, 19. October 2010 15.42:30 Alexander Klenin wrote:
> 2) I'd say that at least half of his mistakes could be avoided
> by better code structure of FPC -- he was really uncomfortable
> using strange records and pchars instead of normal objects and strings.
Hmm, strange records and pchars
On Wed, Oct 20, 2010 at 00:50, Michael Van Canneyt
wrote:
>> 2) I'd say that at least half of his mistakes could be avoided
>> by better code structure of FPC -- he was really uncomfortable
>> using strange records and pchars instead of normal objects and strings.
>
> That has nothing to do with c
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl wrote:
> Am 19.10.2010 14:02, schrieb Alexander Klenin:
> The topic of this thread and the patch was/is alternative parsers. As
> you worked on the case of string stuff (or your student) you might also
> know that the fpc parser is written straight f
Am 19.10.2010 14:48, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl
> wrote:
>> Am 19.10.2010 14:02, schrieb Alexander Klenin:
>> The topic of this thread and the patch was/is alternative parsers. As
>> you worked on the case of string stuff (or your student) you migh
Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
> First Pascal-like languages and later C.
> FPC's main developer doesn't see a need for it.
Indeed. Please tell what a C front end to FPC helps? FPC has no
advantage over existing C compilers except being a pascal compiler ;).
Do you think any C
On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl wrote:
> Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
>> First Pascal-like languages and later C.
>> FPC's main developer doesn't see a need for it.
>
> Indeed. Please tell what a C front end to FPC helps? FPC has no
> advantage over existing
Am 19.10.2010 12:07, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 17:59, Paul Ishenin wrote:
>> 19.10.2010 14:49, Vincent Snijders wrote:
>>
>>> So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
>>
>> About a year ago I created a document which describes what feature
On Tue, Oct 19, 2010 at 23:02, Florian Klaempfl wrote:
> Am 19.10.2010 13:54, schrieb Alexander Klenin:
>> from fixing case and reformatting of Math unit
>
> This does not help anybody ;)
See, you have already rejected it ;-)
The initial motivation was that current unit have lower-case
procedure n
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
/tests/test/units/fpcunit/? If so, is that all of th
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl wrote:
Am 19.10.2010 14:48, schrieb Alexander Klenin:
On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl wrote:
I actually teach compiler construction at the university,
and he correctly noted that co
Hi,
Florian mentioned that the compiler is well tested, and I can see there are
many .pp files in the src/tests/ hierarchy.
Where would I look for the RTL and FCL unit tests? Is it the code in
/tests/test/units/fpcunit/? If so, is that all of them, or is there
another directory (eg: maybe for FC
On 10/19/2010 11:24 AM, Felipe Monteiro de Carvalho wrote:
?
They were deeply frustrated that we have a simple and reliable Unicode
support which supports any language in the world?
I'm not going to discuss (again) what a beginner will do and what he
will see when stepping character by ch
On Wed, Oct 20, 2010 at 00:11, Florian Klaempfl wrote:
> Am 19.10.2010 14:48, schrieb Alexander Klenin:
>> On Tue, Oct 19, 2010 at 23:14, Florian Klaempfl
>> wrote:
>> I actually teach compiler construction at the university,
>> and he correctly noted that compilers produced by some
>> students
Am 19.10.2010 14:02, schrieb Alexander Klenin:
> On Tue, Oct 19, 2010 at 22:44, Florian Klaempfl
> wrote:
>> Am 19.10.2010 11:08, schrieb Juha Manninen (gmail):
>>> First Pascal-like languages and later C.
>>> FPC's main developer doesn't see a need for it.
>>
>> Indeed. Please tell what a C fron
Am 19.10.2010 12:47, schrieb Graeme Geldenhuys:
/opt/fpc-2.4.0/bin/fpc -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE.
-FU../../rtl/units/x86_64-linux -Cg -dx86_64 -Us -Sg system.pp
Free Pascal Compiler version 2.4.0 [2009/12/18] for x86_64
Copyright (c) 1993-2009 by Florian Klaempfl
thread.inc(
Am 19.10.2010 12:18, schrieb Graeme Geldenhuys:
>
> Like I've said a million times before, the management of the FPC project
> seems a bit off (sorry if this offends some of you, don't take it
> personally). Hardly anybody looks at the various branches, so to truly test
> something new
Indeed, it
In our previous episode, Graeme Geldenhuys said:
> >
> > As mentioned in other mails, the compilation order is "first the new RTL,
> > then the new compiler"
>
> I saw your reply to Sven. I didn't know that, and never used it like that
> before. I guess I was lucky.
http://www.stack.nl/~marcov/
Ah, just to close the issue. The original text from Michael Schnell
was ambiguous and I understood he was talking about the Lazarus
unicode support, but now I see that he could be talking about the Free
Pascal unicode support ... which are 2 different things.
Indeed, if he was about Lazarus Unicod
On 19 Oct 2010, at 12:47, Graeme Geldenhuys wrote:
> Op 2010-10-19 12:33, Jonas Maebe het geskryf:
>>
>> As mentioned in other mails, the compilation order is "first the new RTL,
>> then the new compiler"
>
> I saw your reply to Sven. I didn't know that, and never used it like that
> before. I
Op 2010-10-19 12:33, Jonas Maebe het geskryf:
>
> As mentioned in other mails, the compilation order is "first the new RTL,
> then the new compiler"
I saw your reply to Sven. I didn't know that, and never used it like that
before. I guess I was lucky.
Anyway, just downloaded and installed a fre
2010/10/19 Graeme Geldenhuys :
> Op 2010-10-19 09:07, Vincent Snijders het geskryf:
>>
>> Yes, but I doubt this possible fork will be, but feel free to prove me wrong.
>
> Nobody will know, until a fork has been made. As for your opinion that it
> will simply fail is a bit of thumb sucking. Some co
On 19 Oct 2010, at 12:23, Graeme Geldenhuys wrote:
> Op 2010-10-19 11:43, Jonas Maebe het geskryf:
>>
>> I'm not sure how that's related to the merge I did.
>> DefaultSystemCodePage is a system unit variable that was introduced in
>> the cpstrnew branch.
>
> What good is a merge that breaks the
Op 2010-10-19 11:43, Jonas Maebe het geskryf:
>
> I'm not sure how that's related to the merge I did.
> DefaultSystemCodePage is a system unit variable that was introduced in
> the cpstrnew branch.
What good is a merge that breaks the compiling of the compiler?
> The error message suggests that
Op 2010-10-19 10:49, Martin Schreiber het geskryf:
>
> FPC is used in *production*!
I agree, but this shouldn't prevent enhancements, forward thinking and
innovation.
> We can't accept experimental changes of the compiler architecture in
> trunk.
For production use, and for "stability", that i
On Tue, Oct 19, 2010 at 17:59, Paul Ishenin wrote:
> 19.10.2010 14:49, Vincent Snijders wrote:
>
>> So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
>
> About a year ago I created a document which describes what features FPC
> requires to compile recent Delphi code. If som
Am 19.10.2010 11:52, schrieb Jonas Maebe:
On 19 Oct 2010, at 11:45, Sven Barth wrote:
Am 19.10.2010 11:43, schrieb Jonas Maebe:
I'm not sure how that's related to the merge I did. DefaultSystemCodePage is a
system unit variable that was introduced in the cpstrnew branch. The error
message
On 19 Oct 2010, at 11:45, Sven Barth wrote:
> Am 19.10.2010 11:43, schrieb Jonas Maebe:
>>
>> I'm not sure how that's related to the merge I did. DefaultSystemCodePage is
>> a system unit variable that was introduced in the cpstrnew branch. The error
>> message suggests that you are trying to
On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote:
> cresstr.pas(149,178) Error: Identifier not found "DefaultSystemCodePage"
> cresstr.pas(165,117) Error: Identifier not found "DefaultSystemCodePage"
> cresstr.pas(170,126) Error: Identifier not found "DefaultSystemCodePage"
> cresstr.pas(320) Fa
Am 19.10.2010 09:37, schrieb Michael Van Canneyt:
[...]
Currently all we got from Hans Peter were unmanageable patches
supposedly fixing things that were not broken or in need of fixing.
If he had first done some smaller things - take your pick in the bugtracker
- and we had seen that this g
Am 19.10.2010 11:43, schrieb Jonas Maebe:
On 19 Oct 2010, at 11:18, Graeme Geldenhuys wrote:
cresstr.pas(149,178) Error: Identifier not found "DefaultSystemCodePage"
cresstr.pas(165,117) Error: Identifier not found "DefaultSystemCodePage"
cresstr.pas(170,126) Error: Identifier not found "Defau
Op 2010-10-19 11:31, Marc Weustink het geskryf:
>
> What if you use a released compiler as starting compiler ?
> (other versions are not supported)
Like I said, this was just a quick test so I could post some output.
Originally I did use the latest released compiler - 2.4.0 I believe.
I'll try la
Graeme Geldenhuys wrote:
Op 2010-10-19 10:51, Jonas Maebe het geskryf:
You still have not said a single time what the actual problem is that you are
having.
I believe I have, but I can't remember all the errors, and I have no time
to search the mail archive Just tried to compile that br
On 19 Oct 2010, at 11:24, Felipe Monteiro de Carvalho wrote:
> On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell wrote:
>> And I in the German Lazarus Forum watched several beginners trying to use
>> this Lazarus version for doing programs dealing with German text.
>>
>> They were a lot more th
On Tue, Oct 19, 2010 at 10:23 AM, Michael Schnell wrote:
> And I in the German Lazarus Forum watched several beginners trying to use
> this Lazarus version for doing programs dealing with German text.
>
> They were a lot more than "not amused" but rather deeply frustrated.
?
They were deeply
Op 2010-10-19 10:06, Michael Schnell het geskryf:
> On 10/19/2010 07:50 AM, Alexander Klenin wrote:
>>
>> I suggest you start a git-maintained fork.
> Of course git is superior to svn for this purpose.
>
> Is the "base" repository hosted on a git server ?
Yes, I maintain the mirror on GitHub.
Op 2010-10-19 10:51, Jonas Maebe het geskryf:
>
> You still have not said a single time what the actual problem is that you are
> having.
I believe I have, but I can't remember all the errors, and I have no time
to search the mail archive Just tried to compile that branch again
under 64-bit
On Tuesday 19 October 2010 11:10:29 Matt Emson wrote:
> On 19 Oct 2010, at 06:50, Alexander Klenin wrote:
> > On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich
> >
> > wrote:
> >> So there's left nothing what I could do for FPC.
> >
> > I suggest you start a git-maintained fork.
>
> I have b
On 10/19/2010 07:50 AM, Alexander Klenin wrote:
I suggest you start a git-maintained fork.
Of course git is superior to svn for this purpose.
Is the "base" repository hosted on a git server ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.fre
Op 2010-10-19 10:37, Michael Van Canneyt het geskryf:
>
> Changes to the compiler are allowed and have been implemented at various
> times with very good results. Paul is living proof of this.
...and you totally missed my sarcastic intent with that message.
DoDi's path forward seems clear... For
On 19 Oct 2010, at 10:40, Graeme Geldenhuys wrote:
> I still have local changes that add more unicode support and improved
> unicode support under Linux, but the unicode branch is currently not
> compilable on my system - due to the latest merge done in that branch. So
> my work regarding that br
Am 19.10.2010 10:31, schrieb Florian Klaempfl:
Am 19.10.2010 10:20, schrieb Sven Barth:
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is "Unicode string support".
What Ha
On Tue, 19 Oct 2010, Graeme Geldenhuys wrote:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is "Unicode string support".
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
d
Op 2010-10-19 10:18, Michael Schnell het geskryf:
>> The most wanted feature is "Unicode string support".
> Which means "new Delphi Strings" with dynamic code support ?
>
> There is a branch in the svn. How is the state and the pan ?
I still have local changes that add more unicode support and im
Am 19.10.2010 10:20, schrieb Sven Barth:
> Am 19.10.2010 10:12, schrieb Florian Klaempfl:
>> Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
>>> Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is "Unicode string support".
>>>
>>> What Hans-Peter meant is that even i
I meant to write:
-->> Some colleagues of mine need to port their projects from
non-Unicode Delphi to the new Unicode enabled Delphi version.
Sorry
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailm
On 10/19/2010 09:32 AM, Graeme Geldenhuys wrote:
'plus he sees no need for Unicode
String support, so why would others. ;-)
Some colleagues of mine need to port their projects from non-Delphi to
the new Unicode enabled version.
They are "not amused".
I did try to work with the Unicode-ena
Am 19.10.2010 10:12, schrieb Florian Klaempfl:
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
The most wanted feature is "Unicode string support".
What Hans-Peter meant is that even if he does implement Unicode String
support, that would requir
On 10/19/2010 08:59 AM, Paul Ishenin wrote:
The most wanted feature is "Unicode string support".
Which means "new Delphi Strings" with dynamic code support ?
There is a branch in the svn. How is the state and the pan ?
Other stuff recently discussed is thread support (not or not perfectly
Am 19.10.2010 09:32, schrieb Graeme Geldenhuys:
> Op 2010-10-19 08:59, Paul Ishenin het geskryf:
>>
>> The most wanted feature is "Unicode string support".
>
> What Hans-Peter meant is that even if he does implement Unicode String
> support, that would require changes in the compiler. Florian appa
Sent from my iPhone
On 19 Oct 2010, at 06:50, Alexander Klenin wrote:
> On Tue, Oct 19, 2010 at 16:19, Hans-Peter Diettrich
> wrote:
>
>> So there's left nothing what I could do for FPC.
>
> I suggest you start a git-maintained fork.
I have been biting my tongue a lot this week and almost
Op 2010-10-19 09:07, Vincent Snijders het geskryf:
>
> Yes, but I doubt this possible fork will be, but feel free to prove me wrong.
Nobody will know, until a fork has been made. As for your opinion that it
will simply fail is a bit of thumb sucking. Some commercial entity could
easily fork FPC,
Op 2010-10-19 08:59, Paul Ishenin het geskryf:
>
> The most wanted feature is "Unicode string support".
What Hans-Peter meant is that even if he does implement Unicode String
support, that would require changes in the compiler. Florian apparently
doesn't like any changes to the compiler, plus he
2010/10/19 Graeme Geldenhuys :
> I guess that doesn't mean Florian or some other core developer must accept
> your patch or new features, but that's the beauty of open source software.
> Simply fork the project and continue with your own Object Pascal compiler.
> Many projects have done that in the
19.10.2010 14:49, Vincent Snijders wrote:
So maybe you cannot do anything for FPC, except creating an Enhanced FPC.
About a year ago I created a document which describes what features FPC
requires to compile recent Delphi code. If someone does not know what to
do for FPC then he is welcome t
93 matches
Mail list logo