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 08/20/2010 12:39 PM, Hans-Peter Diettrich wrote:
The many conditional parts, which are not even properly chained by
{$ELSEIF ...}, make the maintance and refactoring a mess :-(
While moving to OO paradigms could make the code slightly slower, I
suppose that supporting multiple CPUs with a
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,
When you add the -gl (debug line info added to compiled executable)
parameter to a project, which unit does it use to gather the debug
information?
LineInfo (via stab information) or LnfoDwrf (via dwarf information)?
How do you toggle between the two? How do I know which one of the
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.
I can confirm that I can build FPC 2.4.0 to run under Debian Lenny on
On 23 Aug 2010, at 11:03, Sven Barth wrote:
According to the code in compiler\pmodules.pas (~659) (see below)
the compiler decides this depending on the used debug format. I
might be wrong, but for Linux this should be dwarf.
As a rule of the thumb, the default debug informat for 32 bit
Hi,
On Mon, 23 Aug 2010 10:23:52 +0200, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
Hi,
When you add the -gl (debug line info added to compiled executable)
parameter to a project, which unit does it use to gather the debug
information?
LineInfo (via stab information) or
Am 23.08.2010 11:15, schrieb Jonas Maebe:
On 23 Aug 2010, at 11:03, Sven Barth wrote:
According to the code in compiler\pmodules.pas (~659) (see below) the
compiler decides this depending on the used debug format. I might be
wrong, but for Linux this should be dwarf.
As a rule of the thumb,
Op 2010-08-23 11:55, Sven Barth het geskryf:
Is there any comment about the function name restrictions mentioned in
Thomas' mail?
That is rather crucial information that is missing, especially in my
current case where I am trying to do profiling of our projects.
I'm much rather use
Op 2010-08-23 11:24, Thomas Schatzl het geskryf:
A limitation of the current dwarf reader is that it only parses the
so-called debug_line section of the DWARF debug info containing a mapping
from instruction address to a line number. There is no information about
the function (or compilation
Graeme Geldenhuys пишет:
This limitation makes FPCUnit, DUnit2 and fpprofiler under 64-bit platforms
pretty useless. :-(
Well, I don't know about DUnit2 and fpprofiler, but FPCUnit is currently hardcoded to use LineInfo -
so it won't display anything if actual type of debug information is
Op 2010-08-23 14:02, Sergei Gorelkin het geskryf:
Well, I don't know about DUnit2 and fpprofiler, but FPCUnit is currently
hardcoded to use LineInfo -
so it won't display anything if actual type of debug information is DWARF.
While I did my testing I custom compiled it, and changed the uses
Hi,
The following change (r15883) breaks Trunk builds. Compiler error on
line 2086 (openssl.pas). Expected Pointer but got ShortInt.
--
$ git show HEAD
commit fc8a3f5eee1eda9bf82e7e720789c4fab3835785
Author: Felipe Monteiro de Carvalho
On 23 Aug 2010, at 18:27, Graeme Geldenhuys wrote:
The following change (r15883) breaks Trunk builds.
It was already fixed in r15884
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 23 Aug 2010, at 18:32, Jonas Maebe wrote:
On 23 Aug 2010, at 18:27, Graeme Geldenhuys wrote:
The following change (r15883) breaks Trunk builds.
It was already fixed in r15884
Oops, no, it was an error in r15882 and the fix in r15883 causes this problem.
I am somewhat confused. Does it work with the latest subversion?
I took a look and couldn't find any error.
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 22 Aug 10, at 20:26, Marco van de Voort wrote:
Hi Marco,
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
20 matches
Mail list logo
