michael.vancann...@wisa.be wrote / napísal(a):
On Thu, 15 Mar 2012, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 5:08 AM, wrote:
On Mon, 27 Feb 2012, LacaK wrote:
Hi,
let me share same basic info/ideas about TMSSQLConnection :
On Mon, 19 Mar 2012, LacaK wrote:
michael.vancann...@wisa.be wrote / napísal(a):
On Thu, 15 Mar 2012, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas wrote:
On Mon, Feb 27, 2012 at 5:08 AM, wrote:
On Mon, 27 Feb 2012, LacaK wrote:
Hi,
let me share same basi
Hi Michael,
splitting files into two packages was unavoidable?
Yes.
As you can see for the other databases, we always keep the header
imports separate from the components. Standard time-tested practice.
Hm, although I am not happy with this, I can do nothing with it ;-)
Then I have minor
On Mon, 19 Mar 2012, LacaK wrote:
Hi Michael,
splitting files into two packages was unavoidable?
Yes.
As you can see for the other databases, we always keep the header imports
separate from the components. Standard time-tested practice.
Hm, although I am not happy with this, I can do
Is this an FPC issue or gdb?
Tested with fpc 2.6 / gdb 7.3-2 , win 32
Stabs, seems to have the right sections for fields.
Stabs also shows methods, but they seem to be without any info about
class sections
Dwarf (see below) everything seems to be public:
Dwarf does not seem to show methods
>>
I know -gp works for stabs.
Is there a way for dwarf too?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The algorithm used is called "iterated register coalescing", an
advanced form of graph colouting and was designed by Andrew W. Appel.
He describes in detail in his book "Modern Compiler Implementation in C".
Thanks, I think i'll grab a copy from the uni library tomorrow.
Basically the regi
Okay, it is quite unlikely that the register allocator itself ignores
such an interference, so you may be rigth it tries to spill but
nothing happens.
Ok that wasn't the issue but you were right about not being the register
allocator.
Turns out the actual cause was a one character typo i
S30,$04,$06,$0F,s20,0,0
Should be
S30,$04,$06,$0F,s20,0,0
Doh seems I pasted the wrong line twice, it really should be
S30,$04,$06,$0F,s30,0,0
Please don't change it in trunk at the moment through because my armhf
porting work makes a lot of other changes to armreg.dat and I doubt this
b
