Running fpdoc over fpGUI code, the Linear Output Writer (LaTeX and new IPF
output) for constants do not contain the full declaration.
The problem is detected inside the TLinearWriter.WriteConsts() method.
Debugging the fpdoc code inside WriteConsts(), it retrieves the declaration
as shown in
Here is another screenshot showing the content of the ConstDecl: TPasConst
variable inside TLinearWriter.WriteConsts() method.
Graeme.
attachment: Screenshot-1.png___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Wed, 4 Aug 2010, Graeme Geldenhuys wrote:
Running fpdoc over fpGUI code, the Linear Output Writer (LaTeX and new IPF
output) for constants do not contain the full declaration.
The problem is detected inside the TLinearWriter.WriteConsts() method.
Debugging the fpdoc code inside
Op 2010-08-04 09:48, Michael Van Canneyt het geskryf:
The bug is due to a fcl-passrc bug in pastree: each element should be able to
output itself.
The HTML code does not use this feature, but the linear output engine does.
If you don't have time to look at it, any hints of where in the
On Wed, 4 Aug 2010, Graeme Geldenhuys wrote:
Op 2010-08-04 09:48, Michael Van Canneyt het geskryf:
The bug is due to a fcl-passrc bug in pastree: each element should be able to
output itself.
The HTML code does not use this feature, but the linear output engine does.
If you don't have
On 08/04/2010 03:57 AM, Hans-Peter Diettrich wrote:
Getting the linear address of a threadvar depends on the OS/FPC
implementation.
Of course the compilker needs to adhere to what the OS provides.
As already said multiple times, Win32 for each thread provides a block
of user space memory
In our previous episode, Michael Van Canneyt said:
No, since we use the version in the fixes branch. That should not have the
bug.
It is the new expression support which creates the bug...
I hopefully fixed most of the deprecated bugs yesterday evening (mantis
16342).
I was planning to have
On Wed, 4 Aug 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
No, since we use the version in the fixes branch. That should not have the bug.
It is the new expression support which creates the bug...
I hopefully fixed most of the deprecated bugs yesterday
On 04/08/10 03:34, Hans-Peter Diettrich wrote:
I've some problems with building and testing an new compiler.
1) The buildfaq mentions both PP= and FPC= for the compiler, to be used
by Make. It should be made clear whether these are equivalent, or
(better) only one option should be used across
In our previous episode, Hans-Peter Diettrich said:
I've some problems with building and testing an new compiler.
1) The buildfaq mentions both PP= and FPC= for the compiler, to be used
by Make. It should be made clear whether these are equivalent, or
(better) only one option should be
On 04/08/10 11:31, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
3) Is it possible to give the new compiler an specific name, during
Make, so that the original compiler is not inadvertently overwritten by
a buggy version?
IIRC EXENAME=pp_party
It looks like
Op 2010-08-04 11:29, Michael Van Canneyt het geskryf:
Writing it out is not a problem.
If you take care of the const node, I'll handle the writing.
Thanks guys, this is much appreciated. I'll take a close look at the last
few commits of fpdoc and fcl-passrc to learn some of the code. I'll be
In our previous episode, Graeme Geldenhuys said:
Writing it out is not a problem.
If you take care of the const node, I'll handle the writing.
Thanks guys, this is much appreciated. I'll take a close look at the last
few commits of fpdoc and fcl-passrc to learn some of the code. I'll
Florian Klaempfl schrieb:
4) How does FPC handle different targets? IMO every target is
implemented in a specific executable, so how does pp or fpc proceed when
it is invoked with an target specifier, that it cannot handle itself?
fpc is only a wrapper, it tries to find the right compiler.
2010/8/4 Marco van de Voort mar...@stack.nl:
In our previous episode, Graeme Geldenhuys said:
Writing it out is not a problem.
If you take care of the const node, I'll handle the writing.
Thanks guys, this is much appreciated. I'll take a close look at the last
few commits of fpdoc and
On 04 Aug 2010, at 14:39, Hans-Peter Diettrich wrote:
But fpc now complains that it cannot run ppc386.exe - why?
It should be ppcx64, of course, so why does fpc choose the wrong
compiler?
It means that the fpc.exe that you are executing is an i386 binary. By
default, it looks for a ppc
2010/8/4 Marco van de Voort mar...@stack.nl:
In our previous episode, Graeme Geldenhuys said:
Writing it out is not a problem.
If you take care of the const node, I'll handle the writing.
Thanks guys, this is much appreciated. I'll take a close look at the last
few commits of fpdoc and
Henry Vermaak schrieb:
2) An unqualified reference (PP=mypp) most proably fails - where exactly
does Make search for that compiler?
See Makefile from line 109 onwards. It first looks for fpc(.exe) on the
path. If it finds that, it gets the real compiler exe with -PB. If
fpc(.exe) isn't
Marco van de Voort schrieb:
2) An unqualified reference (PP=mypp) most proably fails - where exactly
does Make search for that compiler?
Works for me. It searches in the PATH. It might not look in the current dir
though, is that what you mean? That is a make gotcha though.
So it's not
On 4 August 2010 14:30, Hans-Peter Diettrich drdiettri...@aol.com wrote:
Henry Vermaak schrieb:
2) An unqualified reference (PP=mypp) most proably fails - where exactly
does Make search for that compiler?
See Makefile from line 109 onwards. It first looks for fpc(.exe) on the
path. If it
On 08/04/2010 12:04 PM, Hans-Peter Diettrich wrote:
Well, different thread implementations exist for Linux. And the
threadvar implementation is fully up to the compiler - so that FPC
could use a Linux threadvar that holds the address of the FPC
threadvar block - just like implemented for
On 08/04/2010 03:30 PM, Hans-Peter Diettrich wrote:
I'm not very familiar with the make syntax :-(
There is a book by O'Reily on GNU MAKE sitting on my shelf.
I did not yet dare to open it
-Michael
___
fpc-devel maillist -
Henry Vermaak schrieb:
I'm not very familiar with the make syntax :-(
Heh, prepare to lose your mind.
It's like with the universe - once somebody will figure out, how it
works, it will turn immediately into something even more weird.
Some years ago I tried to install autobloat C packages
Michael Schnell schrieb:
I'm not very familiar with the make syntax :-(
There is a book by O'Reily on GNU MAKE sitting on my shelf.
I did not yet dare to open it
It's quite useless, since the C coder community does not accept most of
the extensions. Instead they insist in using
Von: Michael Schnell mschn...@lumino.de:
As Pascal (other than C) does not provide a means to define that a
pointer type is a pointer to a threadvar rather than to a normal var,
Pascal alway uses DS to access any variable.
JFTR, plain vanilla C (i.e. ISO C99) does not even have a notion of
Michael Schnell mschn...@lumino.de:
I fail to understand what LEA is supposed to do if a (single) segment
register is given :(.
Ignoring it, because it is not part of the effective address which it is
supposed to calculate?
Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
In whichever way you are used to debug: with a debugger, with
writeln's, ... The compiler is no different than any other program in
that respect.
While I can use Lazarus to debug the compilation of a single source
file, no such feature exists
27 matches
Mail list logo
