On Sun, 22 Aug 2010, Marco van de Voort wrote:
I still get errors on deallocation in fpdoc from time to time.
The most recent one is related to TPasFunctionType.
I searched a bit, and since the type is not used that much, I suspect
TPasTreeContainer.CreateFunctionType.
Since in both cases
In our previous episode, Michael Van Canneyt said:
> > Since in both cases the resultparent is an already used reference, shouldn't
> > it be increfed ?
>
> Probably.
>
> Till you told me, I wasn't even aware that there was a refcounting mechanism.
> I see no reason why there should be one, so I'
On Sun, 22 Aug 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
Since in both cases the resultparent is an already used reference, shouldn't
it be increfed ?
Probably.
Till you told me, I wasn't even aware that there was a refcounting mechanism.
I see no r
In our previous episode, Michael Van Canneyt said:
> > It might be the various TPasModule sections already double as something like
> > this, but that has to be validated.
>
> Each element should deallocate it's "children".
> Since an element tree is always a strict tree, this is unambiguous.
Hi,
In the following bug report, I attached a minor patch for the pascal
scanner in fcl-passrc.
http://bugs.freepascal.org/view.php?id=17237
I introduced two new tokens. Without this it is not possible to
rebuild a source code unit from
a token list.
--
Regards,
- Graeme -
_
If ref-counting mechanism is already implemented, i'd prefer to keep
and debug it.
thanks,
dmitry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Sun, 22 Aug 2010, Graeme Geldenhuys wrote:
Hi,
In the following bug report, I attached a minor patch for the pascal
scanner in fcl-passrc.
http://bugs.freepascal.org/view.php?id=17237
I introduced two new tokens. Without this it is not possible to
rebuild a source code unit from
a token l
On Sun, 22 Aug 2010, dmitry boyarintsev wrote:
If ref-counting mechanism is already implemented, i'd prefer to keep
and debug it.
And why do you want this ? refcounting is always a pain,
and should be avoided when possible.
Michael.
___
fpc-deve
In our previous episode, Michael Van Canneyt said:
> I cannot accept this patch as it is.
>
> It breaks the parser, more specifically NextToken.
> The parser ignores whitespace. It should also ignore the new tokens.
> Other than that, I doubt the usefulness of this patch.
> You are on the wrong
On Sun, Aug 22, 2010 at 11:32 AM, Michael Van Canneyt
wrote:
> And why do you want this ? refcounting is always a pain, and should be
> avoided when possible.
Rewriting code might produce even more bugs. I prefer to make as less
changes as possible.
thanks,
dmitry
___
On 22 August 2010 13:31, Michael Van Canneyt wrote:
>
> I cannot accept this patch as it is.
>
> It breaks the parser, more specifically NextToken.
> The parser ignores whitespace. It should also ignore the new tokens.
Oh, I'll take another look. Let me explain what I'm doing - maybe it
makes mor
On 22 August 2010 13:35, Marco van de Voort wrote:
>
> He wants the source as a kind of DOM model. That is IMHO a valid use, but I
> doubt it is unifiable with the current parser.
Not nearly as complicated as a DOM model really. I just want to insert
some timing calls and a new entry to the uses c
On 22 August 2010 13:31, Michael Van Canneyt wrote:
>
> It breaks the parser, more specifically NextToken.
> The parser ignores whitespace. It should also ignore the new tokens.
I attached a parser patch to that bug report in Mantis. I tested the
scanner and parser over various units of mine, and
On Sun, 22 Aug 2010, Graeme Geldenhuys wrote:
On 22 August 2010 13:31, Michael Van Canneyt wrote:
I cannot accept this patch as it is.
It breaks the parser, more specifically NextToken.
The parser ignores whitespace. It should also ignore the new tokens.
Oh, I'll take another look. Let m
On Sun, 22 Aug 2010, dmitry boyarintsev wrote:
On Sun, Aug 22, 2010 at 11:32 AM, Michael Van Canneyt
wrote:
And why do you want this ? refcounting is always a pain, and should be
avoided when possible.
Rewriting code might produce even more bugs. I prefer to make as less
changes as possibl
On Sun, Aug 22, 2010 at 4:27 PM, Michael Van Canneyt
wrote:
> We would not be rewriting the parser; merely the TPasElement nodes.
>
> I'll do it myself, this is not a problem.
Ok then. No more refcounting.
So TPasExpr classes doesn't require changes. Currently they free sub
expressions instead
On 22 August 2010 18:25, Michael Van Canneyt wrote:
>
> Why ? To the compiler there is no difference between EOL and whitespace.
>
> If you want to generate it with the exact layout, then, yes.
> But for profiling I don't see the need.
Maybe to the compiler it doesn't matter, but to a human trying
On 21 Aug 2010, at 00:19, Mark Morgan Lloyd wrote:
> Jonas Maebe wrote:
>> On 20 Aug 2010, at 22:38, Mark Morgan Lloyd wrote:
>>> What should I be doing here- using both -Cf and -d?
>> Yes, that should solve the problem. For the resulting EABI compiler, -Cfsoft
>> will be the default.
>
> Thank
Hello,
I've generated a new help snapshot. (chm files)
The archive still is at
http://www.stack.nl/~marcov/doc-chm.zip
and contains rtl,fcl,lcl ,fpdoc,ref,user,prog.chm
This release benefits from several improvements in the fpdoc generation,
specially links between packages, and links in clas
- "Graeme Geldenhuys" schreef:
> On 22 August 2010 13:35, Marco van de Voort wrote:
> >
> > He wants the source as a kind of DOM model. That is IMHO a valid
> use, but I
> > doubt it is unifiable with the current parser.
>
> Not nearly as complicated as a DOM model really. I just want to
>
Jonas Maebe wrote:
Supported ABI targets:
DEFAULT
..
but it doesn't actually say what the default is.
To check whether or not you have an ARM EABI compiler, compile any file with
-vei and verify that the output contains the line:
Target OS: Linux for ARMEL
(rather than "Linux for ARM")
On 22 August 2010 20:50, Dimitri Smits wrote:
>
> Anyway, if so, would this "profiling" stuff be optional, on/off all or on/off
> for a specific method/class/unit/package/program?
fpprofiler (which I now switched to instead of my own) is optional.
Profiling is applied per unit, and then "attaches
Graeme Geldenhuys schrieb:
If no NewLine characters are inserted into the newly generated units,
a compiler error on line 1 doesn't help the developer much. Line 1
could be 50k bytes or more long.
The FPC scanner uses a flag (EolFound?), to signal an EOL to the
preprocessor.
DoDi
_
On Sun, 22 Aug 2010, Graeme Geldenhuys wrote:
Well, does it hurt having them tokenized?
Of course.
It slows the code. Marginally, I agree, but nevertheless.
If anybody other than me comes up with a new idea/way of using the
fcl-passrc parser on tokenizer - maybe they would like to rebu
2010/8/23 Michael Van Canneyt :
>> I don't see why introducing such new tokens is bad? It can only make
>> the tokenizer and parser more useful in the long term.
>
> I never said it is bad; I just don't see why you need it.
I guess one wants the line numbers between the orginal source to be
the sa
Op 2010-08-23 01:17, Michael Van Canneyt het geskryf:
>> Well, does it hurt having them tokenized?
>
> Of course.
> It slows the code. Marginally, I agree, but nevertheless.
Sorry, but I disagree here. Before it got tokenized as a tkWhitespace; now
it gets tokenized as tkLineEnding or tkTab. It'
26 matches
Mail list logo
