Op Sat, 14 May 2011, schreef Joerg Schuelke:
2) This is the solution? Making the compiler to store somewhere a
string representation in my object file and then give it back to me if
I request it by str(enumerate)???
All types (not just enums) have runtime type information that is stored in
t
On Sat, 14 May 2011, Joerg Schuelke wrote:
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe :
1) the compiler automatically makes you keep them in sync, because
adding/removing an element form the enumeration will cause a
compilation error for the array if it's not updated
2) the array
Latest FPC SVN
"make clean" results in:
.
.
.
make -C fppkg distclean
make[2]: Entering directory `/fpc_svn/packages/fppkg'
make[2]: *** No rule to make target `distclean'. Stop.
make[2]: Leaving directory `/fpc_svn/packages/fppkg'
make[1]: *** [fppkg_distclean] Error 2
make[1]: Leaving directory
Fixed.
Michael.
On Fri, 13 May 2011, ABorka wrote:
Latest FPC SVN
"make clean" results in:
.
.
.
make -C fppkg distclean
make[2]: Entering directory `/fpc_svn/packages/fppkg'
make[2]: *** No rule to make target `distclean'. Stop.
make[2]: Leaving directory `/fpc_svn/packages/fppkg'
make[1]:
Am Sat, 14 May 2011 01:23:08 +0200
schrieb Joerg Schuelke :
> A third one.
>
> It is a further single and isolated solution to prevent the use of a
> macro. How many of them are there around? A hundert, a thousand in 5
> years?
>
I will explain what is the problem with this. If I have a similar
In our previous episode, Joerg Schuelke said:
> > some bugs in this functionality in 2.4.x on some platforms though, so
> > it can't be used yet in the compiler
>
> 2) This is the solution? Making the compiler to store somewhere a
> string representation in my object file and then give it back to
Am 14.05.2011 01:23, schrieb Joerg Schuelke:
> A third one.
>
> It is a further single and isolated solution to prevent the use of a
> macro. How many of them are there around? A hundert, a thousand in 5
> years?
It simply shows that in a modern programming language macros has few
real use cases
Op Sat, 14 May 2011, schreef Marco van de Voort:
2) This is the solution? Making the compiler to store somewhere a
string representation in my object file and then give it back to me if
I request it by str(enumerate)??? Thats so completely ... overhead,
Not really, if the RTTI is too slow fo
Am 14.05.2011 00:06, schrieb Joerg Schuelke:
>
> A macro processor is the simplest way to generate such pieces of source
> code. If it is that simple doing it another way you say, why can I
> find in the compiler sources more then one example of this.
Because a lot of code in the compiler is very
On Fri, 2011-05-13 at 13:18 +0200, Michael Van Canneyt wrote:
>
> On Fri, 13 May 2011, Darius Blaszyk wrote:
>
> >
> > On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote:
> >
> >>
> >>
> >> On Fri, 13 May 2011, Darius Blaszyk wrote:
> >>
> > All this info is supposed to be output in XML f
Florian Klämpfl schrieb:
It simply shows that in a modern programming language macros has few
real use cases because there are a lot of other constructs which serve a
similiar purpose.
ACK
Nonetheless I wonder which efforts had to be made, to mimic only some of
the many macro usages.
While
Am 14.05.2011 14:43, schrieb Hans-Peter Diettrich:
> Florian Klämpfl schrieb:
>
>> It simply shows that in a modern programming language macros has few
>> real use cases because there are a lot of other constructs which serve a
>> similiar purpose.
>
> ACK
>
> Nonetheless I wonder which efforts
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl :
> Because a lot of code in the compiler is very old (remember, it was
> started in 1993 using TP) and writestr for enums is new compare with
> this time span. Nobody rewrote the code yet.
And it should not been rewritten this way, becau
Am 14.05.2011 15:07, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl:
Because a lot of code in the compiler is very old (remember, it was
started in 1993 using TP) and writestr for enums is new compare with
this time span. Nobody rewrote the code yet.
And it
Am Sat, 14 May 2011 15:12:46 +0200
schrieb Florian Klaempfl :
> Since the compiler uses classes, it uses rtti already heavily so I
> miss the point.
OK, you need the RTTI for simple storing and recovering the informations
to ppu files or whatever, thats a point to use it. Under normal
circumstanc
Am Sat, 14 May 2011 14:36:33 +0200
schrieb Florian Klämpfl :
> so any new feature
> makes this worse without more people doing the dirty work of bug
> fixing.
>
> That's why I'am currently very carefull with new featuers.
I see this point and it is one reason for me to think very careful
about:
Op Sat, 14 May 2011, schreef Joerg Schuelke:
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl :
Because a lot of code in the compiler is very old (remember, it was
started in 1993 using TP) and writestr for enums is new compare with
this time span. Nobody rewrote the code yet.
An
Am Sat, 14 May 2011 16:29:15 +0200 (CEST)
schrieb Daniël Mantione :
> ... will cause 52 bytes of RTTI data to be inserted in your
> executable. Any do-it-yourself solution will consume more space.
> Therefore the RTTI not only helps to keep the source code compact and
> therefore readable, it woul
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke :
>
> I repeat, I have really nothing against RTTI, but I state that it
> comes from a high level language extension.
>
By the way this RTTI thing comes from the argument: Do not use a
macro, instead do it this way. But this forces me to
Am 14.05.2011 17:30, schrieb Joerg Schuelke:
> Am Sat, 14 May 2011 17:04:45 +0200
> schrieb Joerg Schuelke :
>
>>
>> I repeat, I have really nothing against RTTI, but I state that it
>> comes from a high level language extension.
>>
> By the way this RTTI thing comes from the argument: Do not use
Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl :
> Am 14.05.2011 17:30, schrieb Joerg Schuelke:
> > Am Sat, 14 May 2011 17:04:45 +0200
> > schrieb Joerg Schuelke :
> >
> >>
> >> I repeat, I have really nothing against RTTI, but I state that it
> >> comes from a high level language ext
Am 14.05.2011 19:02, schrieb Joerg Schuelke:
> I do not understand this C argument, I swear I am an pascal man! ;(
> Again, nothing against RTTI, but I do not like to be forced to use it.
What's wrong with it?
> By the way the RTTI approach do not solve the problem, if there is one,
> we did not
Op Sat, 14 May 2011, schreef Joerg Schuelke:
I think of this a little different. Maybe more from an other
perspective. For me RTTI is a level of language extension. Like OOP, or
generics, or inheritance. Macros are very low level (if you have them).
RTTI *allows* for language extensions, lik
Latest FPC SVN 17459:
Doing a "make all OS_TARGET=win64 CPU_TARGET=x86_64" crosscompiling with
32bit FPC gives the following error:
=
make -C fpmkunit bootstrap
make[3]: Entering directory `c:/fpc_svn/packages/fpmkunit'
C:/pp/bin/i386-win32/gmkdir.exe -p units_bs/i386-win32
C:\pp\bi
On May 14, 2011, at 12:26 PM, Joost van der Sluis wrote:
> On Fri, 2011-05-13 at 13:18 +0200, Michael Van Canneyt wrote:
>>
>> On Fri, 13 May 2011, Darius Blaszyk wrote:
>>
>>>
>>> On May 13, 2011, at 1:01 PM, Michael Van Canneyt wrote:
>>>
On Fri, 13 May 2011, Darius Blaszyk
On Sat, 2011-05-14 at 11:47 -0700, ABorka wrote:
> Latest FPC SVN 17459:
> Doing a "make all OS_TARGET=win64 CPU_TARGET=x86_64" crosscompiling with
> 32bit FPC gives the following error:
>
> =
> make -C fpmkunit bootstrap
> make[3]: Entering directory `c:/fpc_svn/packages/fpmkunit'
>
Joerg Schuelke schrieb:
I see this point and it is one reason for me to think very careful
about: "Is it possible to do it without touching the scanner?"
Is the rest interesting enough to make it worth a further thinking.
If not, trash it.
The macro definition and expansion has to be changed.
Florian Klämpfl schrieb:
Look at the bug count graph (important part attached, one gray line is
100 open bugs) and you will see that we're currently even not able due
to lacking resources to maintain the current features so any new feature
makes this worse without more people doing the dirty wor
On 13.05.2011 15:55, Hans-Peter Diettrich wrote:
Traditional Pascal added compiler directives, hidden inside comments.
It's only a matter of performance, whether these directives should be
handled immediately at detection of a comment, or after a comment has
been fully recognized (skipped) by the
29 matches
Mail list logo
