On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote:
Tried sample project today. Some a comment and a question:
1) I have a strange error when the same file is modified twice (and
afterwards restored twice). One is:
I'm looking at this issue atm. As soon as I have a definite solution I
On Mon, 2010-09-13 at 23:31 +0200, Darius Blaszyk wrote:
On Sat, 2010-08-28 at 22:51 +0300, Žilvinas Ledas wrote:
Tried sample project today. Some a comment and a question:
1) I have a strange error when the same file is modified twice (and
afterwards restored twice). One is:
I'm looking
2010/8/28 Žilvinas Ledas :
Tried sample project today. Some a comment and a question:
1) I have a strange error when the same file is modified twice (and
afterwards restored twice). One is:
A known problem. I had a partial fix, but not 100% yet.
fpp is modifying the same file twice. You
On 2010-08-28 01:38, Graeme Geldenhuys wrote:
Yes, I placed in on GitHub. You can clone the repository as follows:
via git protocol (faster):
git clone git://github.com/graemeg/fpprofiler.git
via http protocol:
git clone http://github.com/graemeg/fpprofiler.git
Alternatively
On 2010-08-28 01:38, Graeme Geldenhuys wrote:
Alternatively (though not tested) - you should be able to download a
zip archive of the latest code via this URL:
http://github.com/graemeg/fpprofiler/zipball/HEAD
Tried sample project today. Some a comment and a question:
1) I have a strange
P. S. I know I didn't have to include
-FuE:\lazarus\components\fpprofiler\fpprof\
This log is from an experiment...
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 2010-08-26 17:24, Graeme Geldenhuys wrote:
I'll find it a new home tomorrow and post the link
Any news? ;)
Regards
Žilvinas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
2010/8/27 Žilvinas Ledas:
I'll find it a new home tomorrow and post the link
Any news? ;)
Yes, I placed in on GitHub. You can clone the repository as follows:
via git protocol (faster):
git clone git://github.com/graemeg/fpprofiler.git
via http protocol:
git clone
On 2010-08-22 16:42, Graeme Geldenhuys wrote:
fpprofiler (it was a bit further along than my own attempt), but it
wasn't touched for over 2 years, so didn't compile. It was also
riddled with memory leaks (sorry Darius Blaszyk). I fixed a lot of
things including memory leaks, removed the custom
Op 2010-08-26 15:50, Žilvinas Ledas het geskryf:
Sorry for OT, but where can I find fpprofiler? I didn't manage to find
svn link to it (some links google gave me were broken...).
Even better would be to have your updated/improved profiler.
It's in the 'fpcprojects' repository.
Graeme,
Can fpprofiler be used to profile code in a shared library (e.g. DLL on
Windows or .so on Linux)? If so, then I'd be very interested in looking at
it as well, and giving it a go.
Thanks much,
Alan Krause
On Thu, Aug 26, 2010 at 7:11 AM, Graeme Geldenhuys
graemeg.li...@gmail.comwrote:
Op 2010-08-26 16:20, Žilvinas Ledas het geskryf:
It's in the 'fpcprojects' repository.
http://svn.freepascal.org/svn/fpcprojects/fpprofiler
Thanks, I'll try it.
Just remember, that's not going to compile.
Please, post a link to it when you have it. I am definately interested
in it!
Op 2010-08-26 16:19, Alan Krause het geskryf:
Can fpprofiler be used to profile code in a shared library (e.g. DLL on
Windows or .so on Linux)? If so, then I'd be very interested in looking
at it as well, and giving it a go.
Yes, it should be able too - as soon as fcl-passrc can parse a
On 2010-08-26 17:24, Graeme Geldenhuys wrote:
Op 2010-08-26 16:20, Žilvinas Ledas het geskryf:
It's in the 'fpcprojects' repository.
http://svn.freepascal.org/svn/fpcprojects/fpprofiler
Thanks, I'll try it.
Just remember, that's not going to compile.
Yes, I understand that.
Please,
Op 2010-08-26 16:31, Žilvinas Ledas het geskryf:
BTW, what is required/preffered version of fpc? I didn't updated it in a
few months (2010/06/09) so I guess I should get an update to use your
improved version of fpprofiler?
I was testing with the latest FPC Trunk (2.5.1) to get the latest
2010/8/23 Michael Van Canneyt mich...@freepascal.org:
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
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's
On Mon, 23 Aug 2010, Graeme Geldenhuys wrote:
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
On Mon, 23 Aug 2010, Michael Van Canneyt wrote:
Anyway, the point is moot; I'll apply the patch.
Patch applied, rev. 15877.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Op 2010-08-23 09:44, Michael Van Canneyt het geskryf:
Patch applied, rev. 15877.
5 minutes after I got a trunk update and rebuild the whole FPC 2.5.1!
Thanks, Michael. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
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
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 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 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
- 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
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
31 matches
Mail list logo
