Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik ido...@gmail.com:
Why not to create something like:
*macro* Macro_Name(Param)
*begin*
*end*;
The Pascal way ? It's more readable. But then what do you gain with
that Macro ?
-Doing it this way would not be acceptable by any developer,
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martin f...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no answer for that, you know. But you can
On 17/05/2011 12:19, Joerg Schuelke wrote:
Am Mon, 16 May 2011 15:35:24 +0100
schrieb Martinf...@mfriebe.de:
{$EXPAND ProcFoo(1)}
// the code in thr try finally block
{$EXPAND ProcFooEnd}
I can see that happen very easy?
And there we are, Pascal would be down to where C is now.
There is no
Am Tue, 17 May 2011 12:59:57 +0100
schrieb Martin f...@mfriebe.de:
Based on this. The question is does the benefits really outweigh the
cost ?
Of course not. The much writing shows there is only Hans-Peter possibly
for a try. I thought that some of the reasons where only educational ;-)
On 17/05/2011 13:19, Joerg Schuelke wrote:
Am Tue, 17 May 2011 12:59:57 +0100
schrieb Martinf...@mfriebe.de:
Based on this. The question is does the benefits really outweigh the
cost ?
Of course not. The much writing shows there is only Hans-Peter possibly
for a try. I thought that some of
Am Tue, 17 May 2011 13:38:35 +0100
schrieb Martin f...@mfriebe.de:
Going for educational.. or theoretical...
You understand, it is not even easy for someone to have a need ore a
valid use for an macro, after 30 years without? Then crutch macro
support that fpc has, makes that not better. It
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
We extend the small enumeration example:
Think of it, as
Am 16.05.2011 02:30, schrieb Joerg Schuelke:
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
We
Am Sun, 15 May 2011 20:06:02 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
Those three ways also have data overhead, because you have to store
the string representation somewhere. Whether this initialised data is
part of a predefined format called RTTI or not does not change that.
Good
On Sun, May 15, 2011 at 21:22, Joerg Schuelke joerg.schue...@gmx.de wrote:
Am Sun, 15 May 2011 20:06:02 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
Those three ways also have data overhead, because you have to store
the string representation somewhere. Whether this initialised
Am Mon, 16 May 2011 11:16:39 +0300
schrieb ik ido...@gmail.com:
So what that I'm trying to say is that Macro in C and C++ are there
as a hack to do things you can not do properly
in any other way. And I can not find any real reason for using it in
Pascal.
An macro represents the concept of
Am Mon, 16 May 2011 08:37:12 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
Thats true, I hate macros too. So I did it not the hack way. It was not
my object to show how you
On Mon, May 16, 2011 at 12:23, Joerg Schuelke joerg.schue...@gmx.de wrote:
Am Mon, 16 May 2011 11:16:39 +0300
schrieb ik ido...@gmail.com:
So what that I'm trying to say is that Macro in C and C++ are there
as a hack to do things you can not do properly
in any other way. And I can not
On 16/05/2011 10:23, Joerg Schuelke wrote:
My debug system gives me what I want:
- FILE info from build-in macro
- FUNC info from build-in macro (patched by myself)
- LINE info from build-in macro
- the additional info I request
And now it is time to say that a real discussion is not possible
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martin f...@mfriebe.de:
Lots of code is written n teams. ...
...
Making the feature available, forces others to deal with it.
Yes, I agree. But if you really doing team work, the team should
find a common way of coding. Look at some piece of very
Am Mon, 16 May 2011 13:01:39 +0300
schrieb ik ido...@gmail.com:
procedure toLog(const S : String); --
{$IFDEF DEBUG} |
|
{$ENDIF} |
end; |
Am Mon, 16 May 2011 08:37:12 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
You still need to keep infoarr and callenum in sync so simple macros
are only half of a solution in this case.
If it should be done, maybe this way:
But, I have no clue about macro writing
Thats a
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martin f...@mfriebe.de:
2) But a macro also weakens the fundamental concept of how a language
is defined. A macro allows you do define a new syntax. To create
something, ...
I do prefer not to make it possible to extend the language, thats why
the
On 16/05/2011 13:53, Joerg Schuelke wrote:
Am Mon, 16 May 2011 11:11:39 +0100
schrieb Martinf...@mfriebe.de:
2) But a macro also weakens the fundamental concept of how a language
is defined. A macro allows you do define a new syntax. To create
something, ...
I do prefer not to make it
On 16/05/2011 11:37, Joerg Schuelke wrote:
Yes. If it is used. But most true-pascalian say, it would never be used,
because it is useless ;-)
I think it is not that tragic, the real use cases you will find in
bigger projects are rare.
If use case are so rare, then it raises the bigger
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martin f...@mfriebe.de:
{$MyProc (Name) := procedure %Name%; begin}
...
{$Expand MyProc(Foo)} writeln(1); end;
Thats a point worth thinking about, but you say that it even can be done
today, do you think there is more harm extending the
On 16/05/2011 01:30, Joerg Schuelke wrote:
const
infoarr:array[callenum] of inforec={
{id:proc1;name:'proc1';address:@cb_proc1},
{id:proc2;name:'proc2';address:@cb_proc2},
{id:proc3;name:'proc3';address:@cb_proc3},
{id:proc4;name:'proc4';address:@cb_proc4},
On 16/05/2011 14:30, Joerg Schuelke wrote:
Am Mon, 16 May 2011 14:07:54 +0100
schrieb Martinf...@mfriebe.de:
{$MyProc (Name) := procedure %Name%; begin}
...
{$Expand MyProc(Foo)} writeln(1); end;
Thats a point worth thinking about, but you say that it even can be done
today, do
Am Mon, 16 May 2011 14:36:29 +0100
schrieb Martin f...@mfriebe.de:
I have seen that in C, macros generating macros.
As the result, even if you knew you where looking at a macro, you had
no way to find where it was declared. Because the declaration did not
contain it's name (but
Am Mon, 16 May 2011 14:41:35 +0100
schrieb Martin f...@mfriebe.de:
The more support there is for macros, the more likely people will
start whole libraries of macros.
first just a lort of small harmless helpers. Then combinations there
of... it grows, and then it becomes cancer (grows to
On 16/05/2011 15:18, Joerg Schuelke wrote:
It is not only
the weakness, it is the power too. Will think about.
weakness and power are not necessary opposites, or exclusive.
and btw, allow me the rhetoric (though not as the means of an argument,
since it isn't good style):
you know what
Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
Wherever you can!
If I do some low level system work, it is possibly better to do it with
a
Op Sun, 15 May 2011, schreef Joerg Schuelke:
Am Sat, 14 May 2011 20:46:30 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Inlining is better that doing the same with macro's, so is the use of
str/val better than macro tricks.
Wherever you can!
If I do some low level
Am Sun, 15 May 2011 13:26:03 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
Feel free to come up with examples and convince us. They need to be
examples of code that is much more awkward to write without macro's.
There are no examples. For one reason. If you program
Am Sun, 15 May 2011 00:30:38 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
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,
On 15 May 2011, at 17:53, Joerg Schuelke wrote:
The example with that small enumeration is not that bad, you think. The
overhead is what?, somehow 52 bytes data and maybe hundert of code. You
say its low, I say the example is very small too!
The same can be done with 0 bytes additional
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
On Sat, 14 May 2011, Joerg Schuelke wrote:
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
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
Am Sat, 14 May 2011 01:23:08 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
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
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 me if
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
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
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.
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 had to be
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
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
Am 14.05.2011 15:07, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpflflor...@freepascal.org:
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
Am Sat, 14 May 2011 15:12:46 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
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.
Am Sat, 14 May 2011 14:36:33 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
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
Op Sat, 14 May 2011, schreef Joerg Schuelke:
Am Sat, 14 May 2011 12:14:52 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
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
Am Sat, 14 May 2011 16:29:15 +0200 (CEST)
schrieb Daniël Mantione daniel.manti...@freepascal.org:
... 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
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
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
Am 14.05.2011 17:30, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
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:
Am Sat, 14 May 2011 17:38:27 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Am 14.05.2011 17:30, schrieb Joerg Schuelke:
Am Sat, 14 May 2011 17:04:45 +0200
schrieb Joerg Schuelke joerg.schue...@gmx.de:
I repeat, I have really nothing against RTTI, but I state that it
comes
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 see
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,
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.
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 thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
Why doing it? There are IDE Macros.
People do not use all the same IDE, some do not use any. The
IDE
On Fri, 13 May 2011, Joerg Schuelke wrote:
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
In short: No, it is better to keep that particular box of pandora closed.
I could live with something similiar you proposed, maybe with other
preprocessor keywords like $macro and $expand instead so that it's clear
it's something new. But I fear this is not what most people being pro
macro want: they want something like C and think this will solve all the
C header
Joerg Schuelke joerg.schue...@gmx.de hat am 13. Mai 2011 um 02:07
geschrieben:
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
Why doing it? There are IDE
In our previous episode, Joerg Schuelke said:
The thoughts about further improvement of the macro capabilities of the
compiler are now so far along that I can post this paper. But it is not
that short, about three pages.
I'm with Michael with this. While I see some valid usecases, I think the
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good reason.
Pascal has always existed without
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
In short: No, it is better to keep that particular box of pandora
closed.
None of the more modern languages implement macros, and this is for
good
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish from the object file. I like it, to have
my
On 13 May 2011, at 13:43, Michael Van Canneyt wrote:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
They were introduced for Mac Pascal compiler compatibility, and are
used quite regularly in that context
On Fri, 13 May 2011, Jonas Maebe wrote:
On 13 May 2011, at 13:43, Michael Van Canneyt wrote:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
They were introduced for Mac Pascal compiler compatibility, and
In our previous episode, Michael Van Canneyt said:
The Mac OS X universal interfaces would also need quite some rewriting to
remove all macro usage. While most could probably be changed into either
conditional defines or constants, I'm not certain whether that would work
for
all of
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
Thats a clear position. If there is no macro support at all, I would
Am 13.05.2011 13:45, schrieb Joerg Schuelke:
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
procedure dp(const x : string;y : array of const);inline;
begin
dbgstr(x,y);
end;
Nothing is wrong with that. Except:
- the code will never vanish
Am Fri, 13 May 2011 12:11:06 +0200 (CEST)
schrieb Mattias Gaertner nc-gaert...@netcologne.de:
Compiler errors in macros are often confusing/misleading, because
the user does not see the expanded code. Same for debugger positions
and handling.
Macros can confuse other parsers. For example
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt mich...@freepascal.org:
If I had my way, I would remove the existing ones alltogether.
The one use case they have in FPC sources could easily be remedied.
Thats a clear
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
Thats a unit? I`m a small man voting for a small solution. If some kind
of macro
Am 13.05.2011 14:28, schrieb Joerg Schuelke:
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl flor...@freepascal.org:
Extending dump_stack is imo a much better approach, it even doesn't
duplicated information already available in debugging info.
Thats a unit? I`m a small man
Am Fri, 13 May 2011 12:18:48 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
I'm with Michael with this. While I see some valid usecases, I think
the way to introduce a solution (macros) is worse than the problem.
Also I want to stress again what Florian said, namely that macro
Marco van de Voort schrieb:
For large scale and/or specialistic use, simply preprocess the sources
before compiling.
This doesn't help in any way, when it comes to updates of such code :-(
Eventual error messages refer to the preprocessed code, but corrections
should be applied to the
Mattias Gaertner schrieb:
Compiler errors in macros are often confusing/misleading, because the
user does not see the expanded code.
That's where a compiler listing comes into the play, generated e.g. by
the preprocessor option (-m).
Same for debugger positions and handling.
Not really
Michael Van Canneyt schrieb:
In short: No, it is better to keep that particular box of pandora closed.
It may be worth a try.
None of the more modern languages implement macros, and this is for
good reason.
Right, preprocessor support can be *added* to every language,
introducing macros,
Joerg Schuelke schrieb:
So, why not? In the further reading the main thesis.
1. As far as possible simple syntax, which fits into the up to
date implemented language.
2. Maximal implementation of this syntax. No needless
restrictions.
3. Effectiveness in view of
Florian Klaempfl schrieb:
I really thing we should first collect use cases and maybe improve
existing solutions if needed instead of opening another can.
ACK. Here a first example:
We often have enumerated types, with arrays of strings or other
associated information, that must be kept in
On 13/05/2011 15:19, Hans-Peter Diettrich wrote:
Replacement of $IFs. (Around DebugLn...)
That one is solved already, with existing macros.
rtl\inc\lnfodwrf.pp
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define DEBUG_WRITELN := WriteLn}
{$else}
{$define
In our previous episode, Hans-Peter Diettrich said:
For large scale and/or specialistic use, simply preprocess the sources
before compiling.
This doesn't help in any way, when it comes to updates of such code :-(
Eventual error messages refer to the preprocessed code, but corrections
In our previous episode, Hans-Peter Diettrich said:
I really thing we should first collect use cases and maybe improve
existing solutions if needed instead of opening another can.
ACK. Here a first example:
We often have enumerated types, with arrays of strings or other
associated
Am Fri, 13 May 2011 15:00:26 +0200
schrieb Hans-Peter Diettrich drdiettri...@aol.com:
A general decision is required: do we *want* explicit or implicit
macro expansion?
Yes, I see this point too, i thought it is better to have a restricted
form of macro processing introduced by means of an
Am 13.05.2011 20:09, schrieb Joerg Schuelke:
Any example where it makes really a difference?
The same effect can be achieved by an invocation like
dp(x,[y,z]);
just as in Format().
I think only in this special case, because of the ellipsis in that
array of const, which is build-in.
Am 13.05.2011 17:41, schrieb Martin:
On 13/05/2011 15:19, Hans-Peter Diettrich wrote:
Replacement of $IFs. (Around DebugLn...)
That one is solved already, with existing macros.
rtl\inc\lnfodwrf.pp
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define
Am Fri, 13 May 2011 20:29:32 +0200
schrieb Florian Klämpfl flor...@freepascal.org:
Or just use an inline function with ifdef as mentioned previously. An
inline function with an empty procedure body shouldn't cause any
additional code.
- I believe to remember that the compiler complains about
On 13/05/2011 19:29, Florian Klämpfl wrote:
Am 13.05.2011 17:41, schrieb Martin:
{$MACRO ON}
//{$DEFINE DEBUG_DWARF_PARSER}
{$ifdef DEBUG_DWARF_PARSER}
{$define DEBUG_WRITELN := WriteLn}
{$else}
{$define DEBUG_WRITELN := //}
{$endif}
and then
DEBUG_WRITELN('Skipping directory : ',
Am Fri, 13 May 2011 18:19:24 +0200 (CEST)
schrieb mar...@stack.nl (Marco van de Voort):
We often have enumerated types, with arrays of strings or other
associated information, that must be kept in sync (array dimension
and content). Macros with parameters would allow to create these
On 14 May 2011, at 00:06, Joerg Schuelke wrote:
{ definition contains the informations about a type }
tdeftyp = (abstractdef,
arraydef,recorddef,pointerdef,orddef,
typName : array[tdeftyp] of string[12] = (
'abstractdef','arraydef','recorddef','pointerdef','orddef',
The
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
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 can actually be
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe jonas.ma...@elis.ugent.be:
(via str(), write() and writestr())
Sorry, a misunderstanding, they deliver compile time information to me.
Jörg
___
fpc-devel maillist -
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?
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
89 matches
Mail list logo
