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
On Wed, 20 Oct 2010, Sven Barth wrote:
On 20.10.2010 15:33, Jonas Maebe wrote:
On 20 Oct 2010, at 15:12, Sergei Gorelkin wrote:
Jonas Maebe пишет:
Prohibiting it breaks the compilation of dom_html.pp:
dom_html.pp(66,14) Error: Duplicate identifier "ClassName"
If dom_html is the only probl
On 20.10.2010 15:33, Jonas Maebe wrote:
On 20 Oct 2010, at 15:12, Sergei Gorelkin wrote:
Jonas Maebe пишет:
Prohibiting it breaks the compilation of dom_html.pp:
dom_html.pp(66,14) Error: Duplicate identifier "ClassName"
If dom_html is the only problem, I think it can be fixed (by renaming
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,
Alexander Klenin пишет:
On Thu, Oct 21, 2010 at 00:03, Sergei Gorelkin wrote:
Alexander Klenin пишет:
Running the test, I get quite opposite results:
0.750 sec
0.766 sec
short add: 1.829 sec
short find: 0.781 sec
ansi add: 1.750 sec
ansi find: 1.406 sec
The only modifications I made to th
On 20 Oct 2010, at 15:12, Sergei Gorelkin wrote:
> Jonas Maebe пишет:
>> Prohibiting it breaks the compilation of dom_html.pp:
>> dom_html.pp(66,14) Error: Duplicate identifier "ClassName"
> If dom_html is the only problem, I think it can be fixed (by renaming
> ClassName). The w3.org specs
> ha
On Thu, Oct 21, 2010 at 00:03, Sergei Gorelkin wrote:
> Alexander Klenin пишет:
> Running the test, I get quite opposite results:
>
> 0.750 sec
> 0.766 sec
> short add: 1.829 sec
> short find: 0.781 sec
> ansi add: 1.750 sec
> ansi find: 1.406 sec
>
> The only modifications I made to the test
Jonas Maebe пишет:
On 20 Oct 2010, at 13:37, Michael Van Canneyt wrote:
Can you please enter a bug-report for this, and simply mention these facts ?
- Fix as suggested in Delphi mode
- Prohibit in ObjFPC mode ?
Prohibiting it breaks the compilation of dom_html.pp:
dom_html.pp(66,14) Error: D
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
___
On 20 Oct 2010, at 14:56, Jonas Maebe wrote:
>
> On 20 Oct 2010, at 13:37, Michael Van Canneyt wrote:
>
>> Can you please enter a bug-report for this, and simply mention these facts ?
>> - Fix as suggested in Delphi mode
>> - Prohibit in ObjFPC mode ?
>
> Prohibiting it breaks the compilation
Alexander Klenin пишет:
Ok, I re-tested with 2*10^6 Find's. Then AnsiString variants wins even
for length 5:
ShortString: 0.547 s
AnsiString: 0.437 s
Running the test, I get quite opposite results:
0.750 sec
0.766 sec
short add: 1.829 sec
short find: 0.781 sec
ansi add: 1.750 sec
ansi fin
On 20 Oct 2010, at 13:37, Michael Van Canneyt wrote:
> Can you please enter a bug-report for this, and simply mention these facts ?
> - Fix as suggested in Delphi mode
> - Prohibit in ObjFPC mode ?
Prohibiting it breaks the compilation of dom_html.pp:
dom_html.pp(66,14) Error: Duplicate identif
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 Wed, 20 Oct 2010, Birger Jansen wrote:
Can you please enter a bug-report for this, and simply mention these facts ?
Done: http://bugs.freepascal.org/view.php?id=17675
Thank you.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.o
Am 20.10.2010 13:44, schrieb Alexander Klenin:
> On Wed, Oct 20, 2010 at 22:33, Florian Klaempfl
> wrote:
>> Am 20.10.2010 12:27, schrieb Alexander Klenin:
>>>
>>> This sub-thread was started by mentioning the series of errors
>>> my student made when trying to implement case of string.
>>> Most
> Can you please enter a bug-report for this, and simply mention these facts ?
Done: http://bugs.freepascal.org/view.php?id=17675
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, Oct 20, 2010 at 22:33, Florian Klaempfl wrote:
> Am 20.10.2010 12:27, schrieb Alexander Klenin:
>>
>> This sub-thread was started by mentioning the series of errors
>> my student made when trying to implement case of string.
>> Most of them was due to the fact the code used pchars and reco
On Wed, 20 Oct 2010, Birger Jansen wrote:
Hi Michael,
Yes, TSub.Count should be used. I agree that it is dirty and confusing. Best
would be to only have it work in Delphi mode.
Hi,
Can you please enter a bug-report for this, and simply mention these facts ?
- Fix as suggested in Delphi m
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.
Am 20.10.2010 12:27, schrieb Alexander Klenin:
>
> This sub-thread was started by mentioning the series of errors
> my student made when trying to implement case of string.
> Most of them was due to the fact the code used pchars and records
> instead of strings and (hierarchy of) objects.
> Surely
Hi Michael,
Yes, TSub.Count should be used. I agree that it is dirty and confusing. Best
would be to only have it work in Delphi mode.
Kind regards,
Birger
-Oorspronkelijk bericht-
Van: Michael Van Canneyt
Verzonden: wo 20-10-2010 13:22
Aan: FPC developers' list ;
Onderwerp: Re: [f
Hello,
Which 'Count' should the compiler select ? I suspect TSub.Count ?
I think we should prohibit this dubious construct in ObjFC mode.
(but try to be delphi compatible in Delphi mode)
Michael.
On Wed, 20 Oct 2010, Birger Jansen wrote:
I'm not sure if this is the correct way to report thi
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
I'm not sure if this is the correct way to report this, please correct me if I
should report in another way.
I found an old conversation between Leonardo and Florian about the Fatail
internal error 200111022. The thread concluded that they could not reproduce
the error.
I got this error while
In our previous episode, Alexander Klenin said:
> >
> > Major work like that is already always combined with major refactoring and
> > rewriting, so that is unlikely, and they touch totally different systems
> > (frontend vs backend)
>
> I am not sure I understood you point.
> Is not your whole ar
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
On Wed, Oct 20, 2010 at 21:21, Marco van de Voort wrote:
> In our previous episode, Alexander Klenin said:
>> One day all this obfuscation may prevent some higher-level optimization,
>> like multi-threading or built-in linking,
>
> Major work like that is already always combined with major refacto
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
In our previous episode, Alexander Klenin said:
> > shortstrings have another advantage over ansistrings. Of course, I
> > suspect that using ansistrings against shortstrings would be hardly
> > measurable in the compiler speed, but one hundred of such micro
> > optimizations might make the compile
On Wed, Oct 20, 2010 at 20:36, Florian Klaempfl wrote:
> Keep also in mind that the extra indirection of ansistrings increases
> cache polution (one access touches two instead of one cache line) and
> this might not be modelled by the test. So in a real world example
> shortstrings have another ad
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 Wed, Oct 20, 2010 at 20:33, Michael Van Canneyt
wrote:
> Can you post the fixed code ? (with optimizations or without, does not
> matter)
Attached. The fix is rather clumsy though.
I vaguely remember that Delphi (or was it some library we used...)
had something like IncRefCount procedure speci
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
Am 20.10.2010 11:21, schrieb Alexander Klenin:
> On Wed, Oct 20, 2010 at 19:16, Florian Klaempfl
> wrote:
>> Am 20.10.2010 09:23, schrieb Alexander Klenin:
>
>> Also Add is probably broken. I cannot see where AddStr does proper ref.
>> counting.
>
> Indeed. And after I fixed it, the Add have re
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 19:16, Florian Klaempfl wrote:
Am 20.10.2010 09:23, schrieb Alexander Klenin:
Also Add is probably broken. I cannot see where AddStr does proper ref.
counting.
Indeed. And after I fixed it, the Add have really slowed d
On Wed, Oct 20, 2010 at 19:16, Florian Klaempfl wrote:
> Am 20.10.2010 09:23, schrieb Alexander Klenin:
> Also Add is probably broken. I cannot see where AddStr does proper ref.
> counting.
Indeed. And after I fixed it, the Add have really slowed down by 5-50%
depending on string length.
OTOH, w
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
On 20 Oct 2010, at 10:50, Graeme Geldenhuys wrote:
> I did get a compiler
> error in chmreader.pas, but that is not something I would worry about,
> because that is in the packages (FCL) directory.
I think it is caused by a bug in the cpstrnew compiler (unrelated to any
merging). That code pass
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
Am 20.10.2010 10:50, schrieb Graeme Geldenhuys:
> PS:
> Is there a make command to only compile the RTL and compiler? Excludes the
> FCL. Would that be the 'make cycle' from inside the src/compiler/
> directory?
Yes.
___
fpc-devel maillist - fpc-deve
Op 2010-10-20 10:18, Jonas Maebe het geskryf:
>
> The output you posted suggests that your Makefile compiles the RTL units
> in a different order than the Makefile in svn.
Indeed that seems to have been the problem. I did a 'git clean' which
reset/reverted any tracked files, and removed any non-t
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 19 Oct 2010, at 12:49, Jonas Maebe wrote:
>
> On 19 Oct 2010, at 12:47, Graeme Geldenhuys wrote:
>
>> Anyway, just downloaded and installed a fresh copy of FPC 2.4.0 from
>> SourceForge. "make cycle FPC=..." still fails I when I have the time,
>> I'll take another look, but I can't spend
On Wed, 20 Oct 2010, Jonas Maebe wrote:
On 20 Oct 2010, at 09:22, Michael Van Canneyt wrote:
On Wed, 20 Oct 2010, Graeme Geldenhuys wrote:
After applying the changes from patch 001, the project compiled without
problems using FPC 2.5.1.
Quite strange, because it contains files that dupl
Am 20.10.2010 09:23, schrieb 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 45 characters:
>>> ShortS
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
On 20 Oct 2010, at 09:22, Michael Van Canneyt wrote:
> On Wed, 20 Oct 2010, Graeme Geldenhuys wrote:
>
>> After applying the changes from patch 001, the project compiled without
>> problems using FPC 2.5.1.
>
> Quite strange, because it contains files that duplicate files in the classes
> unit.
On 10/19/2010 11:26 AM, Jonas Maebe wrote:
Please move this branch of the discussion to the lazarus (or
lazarus-other) list.
This in fact is not a native Lazarus issue. The Lazarus team can't do a
"decent" Unicode implementation, unless FPC and the RTL provide the
appropriate infrastructu
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:22, Michael Van Canneyt het geskryf:
>
> Quite strange, because it contains files that duplicate files in the classes
> unit.
I used the testclasses.lpi project file, and the testclasses.lpr only
contain tcXXX units in the uses clause, which doesn't seem to conflict
anywhere on m
On Wed, Oct 20, 2010 at 05:57, Sergei Gorelkin wrote:
> 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 t
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, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 05:36, Michael Van Canneyt
wrote:
On Wed, 20 Oct 2010, Alexander Klenin wrote:
On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
wrote:
Try and improve that class with ansistrings. If you succeed, only then we
can start
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, Oct 20, 2010 at 05:36, Michael Van Canneyt
wrote:
> On Wed, 20 Oct 2010, Alexander Klenin wrote:
>> On Wed, Oct 20, 2010 at 01:45, Michael Van Canneyt
>> wrote:
>>> Try and improve that class with ansistrings. If you succeed, only then we
>>> can start making a case for using them in the
On Wed, 20 Oct 2010, Graeme Geldenhuys wrote:
Op 2010-10-19 21:55, Michael Van Canneyt het geskryf:
I applied the patch. I don't know how you managed to compile the code,
but I fixed that as well.
After applying the changes from patch 001, the project compiled without
problems using FPC 2.
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-19 21:55, Michael Van Canneyt het geskryf:
>
> I applied the patch. I don't know how you managed to compile the code,
> but I fixed that as well.
After applying the changes from patch 001, the project compiled without
problems using FPC 2.5.1.
> now. (and 3 of 204 tests fail. I didn'
64 matches
Mail list logo
