Dimitri Smits schrieb:
as for the linking of C++/FPC:
good argument, but then your fpc-compiled c++ will be incompatible with
everything else. Come to think of it, no 2 C++ compilers mangle the same due to
VMT and other abi-stuff anyway.
+1
C++ is not only a different syntax, it also comes
Marco van de Voort schrieb:
I personally think that fully automated C header conversion is not possible.
It is, but at the same cost of e.g. fully automated Delphi project
conversion. In an FPC project the related items (modes, targets, search
paths...) are configurable in several ways - the e
Marco van de Voort schrieb:
Still, C would be doable, for porting SOME existing code to co-operarate
directly with pascal code. If the C code uses lots of library calls it can't
be used directly. But, there is code for math and compression etc. which don't
call libraries much.
The implementa
Am 21.10.2010 11:00, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 21, 2010 at 8:54 AM, Florian Klaempfl
wrote:
The tests (which cover only part of the cppclass support in FPC) are one
of the reality checks for your hypotheses about the usefulness of a
crippled C++ front end. And they show:
On Thu, Oct 21, 2010 at 8:54 AM, Florian Klaempfl
wrote:
> The tests (which cover only part of the cppclass support in FPC) are one
> of the reality checks for your hypotheses about the usefulness of a
> crippled C++ front end. And they show: crippled C++ support is not
> needed, cppclasses is bas
Am 21.10.2010 09:57, schrieb Florian Klaempfl:
Am 21.10.2010 09:51, schrieb Sven Barth:
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
Am 21.10.2010 09:51, schrieb Sven Barth:
> Am 21.10.2010 08:54, schrieb Florian Klaempfl:
>> Am 20.10.2010 10:07, schrieb Michael Schnell:
>>> but this would be a lot better than the
>>> current situation where linking FPC and C++ is completely impossible due
>>> to the different ABI.
>>
>> Really?
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me?
Am 21.10.2010 09:22, schrieb Marco van de Voort:
> In our previous episode, Florian Klaempfl said:
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
>>>
>>> (euh, it doesn't lin
In our previous episode, Florian Klaempfl said:
> >> Really? How does accessing Qt then work? Do you know more than me? Did I
> >> dream that Lazarus has a Qt widget set? Even more: who does the
> >> compilation of e.g.
> >
> > (euh, it doesn't link to C++, but to a C library that wraps the C++ QT
Am 21.10.2010 09:14, schrieb Marco van de Voort:
> In our previous episode, Florian Klaempfl said:
>>> to the different ABI.
>>
>> Really? How does accessing Qt then work? Do you know more than me? Did I
>> dream that Lazarus has a Qt widget set? Even more: who does the
>> compilation of e.g.
>
>
In our previous episode, Florian Klaempfl said:
> > to the different ABI.
>
> Really? How does accessing Qt then work? Do you know more than me? Did I
> dream that Lazarus has a Qt widget set? Even more: who does the
> compilation of e.g.
(euh, it doesn't link to C++, but to a C library that wrap
Am 20.10.2010 10:07, schrieb Michael Schnell:
> but this would be a lot better than the
> current situation where linking FPC and C++ is completely impossible due
> to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set
- "Michael Schnell" schreef:
> On 10/20/2010 02:04 AM, Hans-Peter Diettrich wrote:
> >
> > I would like to see my C parser working as an FPC front-end,
>
> I feel that there in fact is a decent cause for doing a C(++)
> front-end
> for the FPC compiler: importing existing C++ code into a P
Marco van de Voort wrote:
Keep in mind that I actually am a proponent of multiple frontends (I've
wanted a M2 version for over 10 years now, but unfortunately I'm quite
realistic), I just don't like Hans-Peter's approach (which is essentially
not cooperating, and just throw raw patches to core,
On 10/20/2010 12:34 PM, Juha Manninen (gmail) wrote:
Still, C would be doable, for porting SOME existing code to co-operarate
directly with pascal code.
AFAIK, flat C sources can just can be compiled with GNU and linked with
FPC projects.
-Michael
___
In our previous episode, Juha Manninen (gmail) said:
> > Moreover I think the goals of such project can be much easier accomplished
> > by having a C compiler that outputs (FPC) pascal source.
>
> True. DoDi must have some idea to solve it with the frontend.
I only heard him about mapping the C f
On Wednesday 20 October 2010 13:52:58 Marco van de Voort wrote:
> In our previous episode, Juha Manninen (gmail) said:
> > Still, C would be doable, for porting SOME existing code to co-operarate
> > directly with pascal code. If the C code uses lots of library calls it
> > can't be used directly.
In our previous episode, Alexander Klenin said:
> > not cooperating, and just throw raw patches to core, and then trying to
> > blackmail core into accepting them by raising noise on the maillists)
>
> To be honest, I was responsible for at least half the noise in this thread.
> Also, what do you
In our previous episode, Juha Manninen (gmail) said:
> Still, C would be doable, for porting SOME existing code to co-operarate
> directly with pascal code. If the C code uses lots of library calls it can't
> be used directly. But, there is code for math and compression etc. which
> don't
> c
On Wednesday 20 October 2010 13:08:15 Marco van de Voort wrote:
> That is exactly the kind of circle reasoning that haunts these discussions.
> The actual target is a constant flux, and adapts to suit the reasoning:
>
> MS> We need a C++ frontend
> MV> Why ?
> MS> porting to Pascal is such a horro
On Wed, Oct 20, 2010 at 21:26, Marco van de Voort wrote:
> In our previous episode, Michael Schnell said:
> Keep in mind that I actually am a proponent of multiple frontends (I've
> wanted a M2 version for over 10 years now, but unfortunately I'm quite
> realistic), I just don't like Hans-Peter's
In our previous episode, Michael Schnell said:
> > The frontend would need to ban lots of syntax, practically creating a new
> > C++
> Yep. That is why it would be essential to use the original GNU
> preprocessor to keep the "pseudo c++" frontent for FPC as small as
> possible. Macros can do som
On 10/20/2010 11:43 AM, Juha Manninen (gmail) wrote:
However, C++ is a poor example because its syntax is a deep swamp.
The frontend would need to ban lots of syntax, practically creating a new C++
Yep. That is why it would be essential to use the original GNU
preprocessor to keep the "pseudo
In our previous episode, Juha Manninen (gmail) said:
> No, it would be the other way around. The "kind of C++" or "pseudo C++" or
> whatever would map to the existing compiler's data and object structure.
Then the avg C++ code would not run, since it uses boost and friends that
heavily use every
On Wednesday 20 October 2010 11:53:02 Marco van de Voort wrote:
> Again: Combining two languages into one compiler doesn't magically make
> them interoperable. And the only existing example doesn't exactly have a
> crack record on using C++ FROM Delphi (the otherway around is different,
> I'm told,
In our previous episode, Michael Schnell said:
> > Essentially you haven't answered my concern, just spread more vaguery
> > around,
> Agreed. (Any innovation starts on a very vague level.)
>
> I did not want to start or suggest any development, just wanted to state
> that DiDo's idea is not comp
On 10/20/2010 10:53 AM, Marco van de Voort wrote:
Essentially you haven't answered my concern, just spread more vaguery
around,
Agreed. (Any innovation starts on a very vague level.)
I did not want to start or suggest any development, just wanted to state
that DiDo's idea is not completely s
In our previous episode, Michael Schnell said:
> >
> > As said thousands of times, it still will be different.
> Of course I do know this. (I should have said "a kind of c++" to be more
> accurate)
>
> It would need to a kind of different/incompatible/propriety c++
> language that could only li
On 10/20/2010 10:12 AM, Marco van de Voort wrote:
As said thousands of times, it still will be different.
Of course I do know this. (I should have said "a kind of c++" to be more
accurate)
It would need to a kind of different/incompatible/propriety c++
language that could only live in #ifd
On Wed, 20 Oct 2010, Graeme Geldenhuys wrote:
Op 2010-10-20 09:21, Michael Van Canneyt het geskryf:
Because .NET has it, and the current team at Borland probably never knew
about TP-style objects in the first place.
Idiots! They are a bunch of Microsoft drones.
80% of the world is :(
O
In our previous episode, Michael Schnell said:
> >
> > I would like to see my C parser working as an FPC front-end,
>
> I feel that there in fact is a decent cause for doing a C(++) front-end
> for the FPC compiler: importing existing C++ code into a Pascal project.
> I suppose this is not possi
On 10/20/2010 02:04 AM, Hans-Peter Diettrich wrote:
I would like to see my C parser working as an FPC front-end,
I feel that there in fact is a decent cause for doing a C(++) front-end
for the FPC compiler: importing existing C++ code into a Pascal project.
I suppose this is not possible co
Op 2010-10-20 09:21, Michael Van Canneyt het geskryf:
>
> Because .NET has it, and the current team at Borland probably never knew
> about TP-style objects in the first place.
Idiots! They are a bunch of Microsoft drones.
> Other than that, I did mention that it is my personal opinion;
> I def
On Wed, 20 Oct 2010, Hans-Peter Diettrich wrote:
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
On Wed, 20 Oct 2010, Graeme Geldenhuys wrote:
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 us
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
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
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 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
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
1 - 100 of 137 matches
Mail list logo
