Hello,
I've changed the TProcess.WaitOnExit return type to boolean;
A return value of True means success, a return value of False
means failure.
This is a conscious break with the old DWord return value, which
returned a highly inconsistent, system-dependent return value.
The current solution is
peter green schreef:
Well, the linked list would be freed (or the first item of it enlarged
to the total size, depending on implementation details).
Still, the peak memory use will twice the size, won't it?
sure but unless you are very lucky a call to reallocmem also means alocate-copy-deallocat
> > Well, the linked list would be freed (or the first item of it enlarged
> > to the total size, depending on implementation details).
>
> Still, the peak memory use will twice the size, won't it?
sure but unless you are very lucky a call to reallocmem also means
alocate-copy-deallocate.
Micha Nelissen schreef:
Vincent Snijders wrote:
A (maybe shortsighted) drawback would be that it doubles the amount of
needed memory, once for the list and once for the memory pointed to with
Memory?
Well, the linked list would be freed (or the first item of it enlarged
to the total size, depe
Vincent Snijders wrote:
> A (maybe shortsighted) drawback would be that it doubles the amount of
> needed memory, once for the list and once for the memory pointed to with
> Memory?
Well, the linked list would be freed (or the first item of it enlarged
to the total size, depending on implementatio
Micha Nelissen schreef:
Vincent Snijders wrote:
Hi,
Currently the TMemoryStream grows in steps of 4096 bytes.
Very nice would be a linked list of 8KB blocks or so, and when you
access .Memory, then it's copied into an array.
A (maybe shortsighted) drawback would be that it doubles the am
On Mon, 11 Dec 2006, Micha Nelissen wrote:
> Vincent Snijders wrote:
> > Hi,
> >
> > Currently the TMemoryStream grows in steps of 4096 bytes.
>
> Very nice would be a linked list of 8KB blocks or so, and when you access
> .Memory, then it's copied into an array.
I think you can create a sepa
Vincent Snijders wrote:
Hi,
Currently the TMemoryStream grows in steps of 4096 bytes.
Very nice would be a linked list of 8KB blocks or so, and when you
access .Memory, then it's copied into an array.
Micha
___
fpc-devel maillist - fpc-devel@lis
On Mon, 11 Dec 2006, Vincent Snijders wrote:
> Hi,
>
> Currently the TMemoryStream grows in steps of 4096 bytes.
>
> When writing 10 chunks of say 80 bytes to it, this causes a lot of
> reallocations. I think it is better to grow at least a quarter for example.
>
> The new code could look
Hi,
Currently the TMemoryStream grows in steps of 4096 bytes.
When writing 10 chunks of say 80 bytes to it, this causes a lot of
reallocations. I think it is better to grow at least a quarter for example.
The new code could look something like:
function TMemoryStream.Realloc(var NewCapaci
Aleš Katona schreef:
Hi, I recently changed TReader and TWriter to be delphi compatible (they
were missing a virtual "read" and a virtual "write".
It might be related, best idea is to see if all TWriter/TReader
descendants which add "read" and "write" have them use override.
As for the concrete
The docs at
http://lazarus-ccr.sourceforge.net/docs/fcl/process/tprocess.exitstatus.html
say:
The value of this property is only meaningful when the process is no longer
running. If it is not running then the value is zero.
I think "not" in the last sentence must be removed.
Vincent
___
Am 11. Dez 2006 um 14:13 schrieb Jonas Maebe:
On 11 dec 2006, at 13:59, Jonas Maebe wrote:
Hard to do with i386-darwin, no ;)?
I didn't break the cycle when starting with 2.1.1 :)
Besides, this person is using ppc anyway:
/usr/local/bin/ppcppc -dNOMOUSE -dFPC_USE_LIBC -Fi../inc -Fi../
po
On 11 dec 2006, at 13:59, Jonas Maebe wrote:
Hard to do with i386-darwin, no ;)?
I didn't break the cycle when starting with 2.1.1 :)
Besides, this person is using ppc anyway:
/usr/local/bin/ppcppc -dNOMOUSE -dFPC_USE_LIBC -Fi../inc -Fi../
powerpc -Fi../unix -Fi../bsd -Fi../bsd/powerpc -F
On 11 dec 2006, at 13:10, Florian Klaempfl wrote:
Start the cycle with 2.0.4. Building is always only /guaranteed/
to work
when starting with the latest release compiler.
Hard to do with i386-darwin, no ;)?
I didn't break the cycle when starting with 2.1.1 :) Anyway, for that
one you in
Jonas Maebe schrieb:
>
> On 11 dec 2006, at 06:58, Jan Ruzicka wrote:
>
>> make cycle in fpc/compiler directory on OS X ends in an error.
>>
>> I did make clean, make and make cycle.
>> The "make clean" and "make" runs without error.
>> Am I doing something wrong?
>
> Start the cycle with 2.0.4
On 11 dec 2006, at 06:58, Jan Ruzicka wrote:
make cycle in fpc/compiler directory on OS X ends in an error.
I did make clean, make and make cycle.
The "make clean" and "make" runs without error.
Am I doing something wrong?
Start the cycle with 2.0.4. Building is always only /guaranteed/ to
17 matches
Mail list logo
