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
http://lists.freepascal.
Am Sat, 14 May 2011 00:36:17 +0200
schrieb Jonas Maebe :
> (via str(), write() and writestr())
Sorry, a misunderstanding, they deliver compile time information to me.
Jörg
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.f
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 can actually be removed at some time in
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',
>
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
>
Am Fri, 13 May 2011 20:27:30 +0200
schrieb Florian Klämpfl :
> >> 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.
> > What if yo
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 20:29:32 +0200
schrieb Florian Klämpfl :
> 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 - inlining
not pos
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}
>
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 bu
Am Fri, 13 May 2011 15:00:26 +0200
schrieb Hans-Peter Diettrich :
>
> 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 compiler directive,
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
> associa
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
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 DEBU
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 sy
Am Thu, 12 May 2011 09:32:28 +0200
schrieb Michael Schnell :
> > I would introduce a macro expansion trough a compiler directive.
> What a bout a compiler directive to optionally call the gnu C
> preprocessor ? I would have wanted used this some time ago for a very
> special project.
Yesterda
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 th
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
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 d
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 unproces
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
Am 13.05.2011 14:28, schrieb Joerg Schuelke:
> Am Fri, 13 May 2011 14:05:43 +0200
> schrieb Florian Klaempfl :
>
>> 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 sma
Am Fri, 13 May 2011 14:05:43 +0200
schrieb Florian Klaempfl :
> 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 support is integrated
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt :
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
Am Fri, 13 May 2011 12:11:06 +0200 (CEST)
schrieb Mattias Gaertner :
> 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 the fcl parser or the
Am 13.05.2011 13:45, schrieb Joerg Schuelke:
> Am Fri, 13 May 2011 11:47:54 +0200
> schrieb Florian Klaempfl :
>
>> 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 ob
Am Fri, 13 May 2011 13:43:52 +0200 (CEST)
schrieb Michael Van Canneyt :
> 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
not ask to put parame
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
> >
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 a
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 vi
Am Fri, 13 May 2011 11:47:54 +0200
schrieb Florian Klaempfl :
> 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 debugging code all the tim
On Fri, 13 May 2011, Joerg Schuelke wrote:
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt :
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
Am Fri, 13 May 2011 11:25:36 +0200 (CEST)
schrieb Michael Van Canneyt :
> 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 macros. It keeps co
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 format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to e
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 format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to extend it to include a
On Fri, 13 May 2011, Darius Blaszyk wrote:
All this info is supposed to be output in XML format from fpmake
--manifest. fppkg picks it up and stores it in the repository.
If you want to extend it to include a category and keywords, be my guest.
Thanks, that was the class indeed I was lookin
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 th
On May 10, 2011, at 9:07 AM,
wrote:
> On Tue, 10 May 2011 08:30:28 +0200 (CEST), Michael Van Canneyt
> wrote:
>> On Tue, 10 May 2011, Darius Blaszyk wrote:
>>
>>> Hi,
>>>
>>> I've created a trivial front end for fppkg (see lazarus mailing list) but
>>> working on this I realized that they
Joerg Schuelke 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 Macros.
>
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 portin
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.
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 change
42 matches
Mail list logo
