Hi,
because i compile constantly the trunk i always wished the version
string to have the svn revision. Looking at the version.pas i found that
the only think i have to do is to define REVINC. But i'm in windows at i
have to export the tree before the build effectively loosing all the
svn's
On 12-11-2010 13:07, Marco van de Voort wrote:
In our previous episode, Thaddy said:
Marco, there has been a Bhoem GC for delphi on my website for many years
Please add it to the wiki, together with whatever experiences you have with
it.
___
fpc-d
On Fri, 2010-11-12 at 09:51 +0200, Graeme Geldenhuys wrote:
> Op 2010-11-11 15:31, Michael Van Canneyt het geskryf:
> > If guarantees are needed:
> > Meanwhile, one can buy a support contract from
> > http://www.lazarussupport.com/.
>
> A applaud them for starting that, but that business is only
Rather than filling up the list with why this particular issue
(something I've never done, and don't care about) behaves differently
than Delphi, could someone instead focus on how to perform the needed
task(s) with FPC?
FPC doesn't work the way Delphi does. Take that as a given. Then
figure out
Hi,
On Fri, 12 Nov 2010 12:26:38 +0100 (CET), Dimitri Smits
wrote:
> - "Thomas Schatzl" schreef:
>> Imo: Jonas already stated, the time of the release for interfaces is
>> not
>> guaranteed - afaik the docs/specs only state that they "will be
>> released if
>> the reference count gets zero"
Am 12.11.2010 08:51, schrieb Graeme Geldenhuys:
>
> Creating developer tools has another problem of it's own. Unlike Delphi,
> there is no stable, long term shipment of compiled units and specific FPC
> version, so in the world of FPC, developers tools must ship as source code.
> This again raise
In our previous episode, Thaddy said:
> Marco, there has been a Bhoem GC for delphi on my website for many years
Please add it to the wiki, together with whatever experiences you have with
it.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Marco, there has been a Bhoem GC for delphi on my website for many years
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
- "Thomas Schatzl" schreef:
> Hi,
>
> On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits
> wrote:
> >
> > it seems that the stackvariables are NOT unloaded in the correct
> order
> > (ie: reverse order of declaration).
> > It shouldn't matter in what order you fill them, but in the o
In our previous episode, Thomas Schatzl said:
> What would be interesting would be how garbage-collected Delphis handle
> this, can anyone help? Other than that, there is imo nothing else to say
> than that Pascal/Delphi(*) does not have explicitly scoped lifetimes with
> automatic destructor call
In our previous episode, Graeme Geldenhuys said:
> Creating developer tools has another problem of it's own. Unlike Delphi,
> there is no stable, long term shipment of compiled units and specific FPC
> version, so in the world of FPC, developers tools must ship as source code.
> This again raise th
Hi,
On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits
wrote:
>
> it seems that the stackvariables are NOT unloaded in the correct order
> (ie: reverse order of declaration).
> It shouldn't matter in what order you fill them, but in the order they
are
> declared. (like good practice in cons
Op 2010-11-11 15:31, Michael Van Canneyt het geskryf:
> If guarantees are needed:
> Meanwhile, one can buy a support contract from http://www.lazarussupport.com/.
A applaud them for starting that, but that business is only related to
Lazarus development as far as I understand, it does not touch/af
Dimitri Smits wrote:
ok, answering my own mail after a small test below
- "Dimitri Smits" schreef:
what I DON'T do is use it like in your example, Graeme. I always
assign the result to a local variable, which goes out of scope in an
implicit finally block at method-exit. Haven't tried if
ok, answering my own mail after a small test below
- "Dimitri Smits" schreef:
> what I DON'T do is use it like in your example, Graeme. I always
> assign the result to a local variable, which goes out of scope in an
> implicit finally block at method-exit. Haven't tried if this does
> (not)
15 matches
Mail list logo
