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'd be in
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
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.
I don't
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 -
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
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.
___
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
mich...@freepascal.org 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 more
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
On Sun, 22 Aug 2010, dmitry boyarintsev wrote:
On Sun, Aug 22, 2010 at 11:32 AM, Michael Van Canneyt
mich...@freepascal.org 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
On Sun, Aug 22, 2010 at 4:27 PM, Michael Van Canneyt
mich...@freepascal.org 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
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 to
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.
Thanks Jonas,
- Graeme Geldenhuys graemeg.li...@gmail.com 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
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 to
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
21 matches
Mail list logo
