I'm having a hard time with GDB and debugging threads on a OSX 10.7.4 with
fpc/trunk
The shipped gdb worked great with the exception of threads calling methods
via synchronize (so I can debug).
I'm in the process of building GDB from download and configure set gdb to
x64 darwin. Configure detect
On 19 May 2012, at 17:36, Marco van de Voort wrote:
> I'm not sure if the *rec records can handle pointers, one probably can't use
> reference types in them, because the standard filedescriptions are
> threadvars.
>
> Think what happens if those are simply "cloned".
Threadvars are never cloned.
On Sat, May 19, 2012 at 7:54 PM, Jorge Aldo G. de F. Junior <
jagf...@gmail.com> wrote:
> but i cant imagine someone
> creating a helper class for TObject).
>
It is in the example above but in real it base class of mine,
TmncCustomField in fact
But it fail for me, because there is overridden func
So basically they are in the same branch (Well you could argue that
every object inherits from TObject, but i cant imagine someone
creating a helper class for TObject).
> Please not that the extended classes (in this case T_B1 and T_B2) need to
> inherited from T_A, otherwise the compiler will com
On 19.05.2012 18:59, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
Think what happens if those are simply "cloned".
Why shouldn't reference types work in threadvard records? As long as the
reference count mechanism does it's work correctly it should work.
Afaik because
In our previous episode, Sven Barth said:
> > Think what happens if those are simply "cloned".
> >
>
> Why shouldn't reference types work in threadvard records? As long as the
> reference count mechanism does it's work correctly it should work.
Afaik because the ref count mechanism doesn't. The
On 19.05.2012 13:12, Jürgen Hestermann wrote:
2.) The Assign routine in \fpc\rtl\inc\file.inc overwrites the
whole file data structure with zeros (using fillchar). The
name has to be omitted from this action because it is now
managed automatically. So Assign needs to be changed to:
-
On 19.05.2012 17:47, Jürgen Hestermann wrote:
> Also you need to keep in mind that do_open is used by platform
independant code
> so you would need to change the declarations/handling for all other
platforms as well.
Yes. It can be a can of worms. ;-)
Although, as said: Only very few functions
On 19.05.2012 18:22, Sven Barth wrote:
On 19.05.2012 17:36, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
While I can not comment on the changes you listed (though they sound
more or less valid)
I'm not sure if the *rec records can handle pointers, one probably
can't use
On 19.05.2012 17:36, Marco van de Voort wrote:
In our previous episode, Sven Barth said:
While I can not comment on the changes you listed (though they sound
more or less valid)
I'm not sure if the *rec records can handle pointers, one probably can't use
reference types in them, because the st
Marco van de Voort schrieb:
> I'm not sure if the *rec records can handle pointers, one probably
can't use
> reference types in them, because the standard filedescriptions are
> threadvars.
> Think what happens if those are simply "cloned".
Of course, all "cloning" needs to be changed too so th
On Sat, May 19, 2012 13:12, JĂźrgen Hestermann wrote:
.
.
> 1.) The 2 fundamental file types filerec and textrec (for standard files
> and
> text files) are defined in
> fpc\fpc\rtl\inc\filerec.inc and
> fpc\fpc\rtl\inc\textrec.inc
> Both differ only by some buffer structures at the end but share
Sven Barth schrieb:
> If you change do_open to support Unicode you should do this for the
other functions (e.g. write,
> read) as well so that only the *W functions are used for them.
I think read/write only work on the file handle and don't use the file name.
So no changes are needed here (I t
In our previous episode, Sven Barth said:
> While I can not comment on the changes you listed (though they sound
> more or less valid)
I'm not sure if the *rec records can handle pointers, one probably can't use
reference types in them, because the standard filedescriptions are
threadvars.
Thin
On 19.05.2012 16:28, Zaher Dirkey wrote:
On Sat, May 19, 2012 at 2:10 AM, Jorge Aldo G. de F. Junior
mailto:jagf...@gmail.com>> wrote:
You simply cant do it. Not even multiple inheritance would help you in
this case.
You will have to extend each class by hand.
Multiple inherita
On 19.05.2012 13:12, Jürgen Hestermann wrote:
3.) Of course, there are lots of places where the file data structures
filerec and textrec are used in the code. But in most cases only
non-changed
record elements are used (so no changes are required) and only seldomly
the name is used/changed or the
On Sat, May 19, 2012 at 2:10 AM, Jorge Aldo G. de F. Junior <
jagf...@gmail.com> wrote:
> You simply cant do it. Not even multiple inheritance would help you in
> this case.
>
> You will have to extend each class by hand.
>
> Multiple inheritance would allow you to join back branches in the
> clas
> Given that, it doesn't really make sense to use the *A versions at all
> in Windows (Unless you want to support very old Windows versions).
> Thus the approach for Windows should be the opposite of Unix, I suppose.
> UTF8 or ANSI gets converted to UTF16 and call the *W functions.
That's true. I
In our previous episode, Bernd said:
> > So use functions from 2.0.x like sysutils.extract*
>
> Found it, thank you.
>
> I was a little bit impatient yesterday, I should have searched a
> little longer on my own.
>
> Due to the extraordinarily high quality of FPC and Lazarus I have
> begun to t
19 matches
Mail list logo
