On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 12:19, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
I can't follow here. There was an undocumented problem in a unit, and now that
it has been identified and sort of made worse, there is no need to tell our
On 14 Nov 2009, at 12:19, Michael Van Canneyt wrote:
> On Sat, 14 Nov 2009, Jonas Maebe wrote:
>
>> I can't follow here. There was an undocumented problem in a unit, and now
>> that it has been identified and sort of made worse, there is no need to tell
>> our users about it?
>
> Well, IMHO w
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 11:30, Michael Van Canneyt wrote:
On Sat, 14 Nov 2009, Jonas Maebe wrote:
At the very least this bug should be documented, and a {$warning ...} should be
added at the appropriate place in the source code so that someone intereste
On 14 Nov 2009, at 11:30, Michael Van Canneyt wrote:
> On Sat, 14 Nov 2009, Jonas Maebe wrote:
>
>> At the very least this bug should be documented, and a {$warning ...} should
>> be added at the appropriate place in the source code so that someone
>> interested in fixing it can do that right
On Sat, 14 Nov 2009, Jonas Maebe wrote:
On 14 Nov 2009, at 11:16, Michael Van Canneyt wrote:
I don't think that the thread-safety is something to worry about at this time;
As you remark, the code was already not thread-safe. But it is something to
keep in mind.
At the very least this bu
On 14 Nov 2009, at 11:16, Michael Van Canneyt wrote:
> I don't think that the thread-safety is something to worry about at this
> time; As you remark, the code was already not thread-safe. But it is
> something to keep in mind.
At the very least this bug should be documented, and a {$warning .
On Sat, 14 Nov 2009, Martin wrote:
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed the
values
Martin wrote:
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
I had that right,, just the debugger confused me the way it displayed
the values.
Attached patch works here, and dump
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
Problem I have is how to deal with the open var param.
I need to be able to address the first (or other) byte of it
function ReadNext
Michael Van Canneyt wrote:
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
The main reason for this slowness is that that implementation (of
mine) reads debug info byte-by-byte from the input stream using
blockread(). I think this I/O the main performance bottleneck.
At that time I did not bothe
Vinzent Höfler wrote:
Vincent Snijders :
Micha Nelissen schreef:
Allocating that buffer on the stack isn't sufficient?
That's not easy when the exception is raised in case of a stack overflow.
In case of a stack overflow *anything* using the stack is doomed. But if we're
Vincent Snijders :
> Micha Nelissen schreef:
> >
> > Allocating that buffer on the stack isn't sufficient?
>
> That's not easy when the exception is raised in case of a stack overflow.
In case of a stack overflow *anything* using the stack is doomed. But if we're
talking about checking the sta
Vincent Snijders wrote:
Micha Nelissen schreef:
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug
input has been encapsuled in the two ReadNext() methods in the file
mentioned. It should be easy to make them to read from a (static?)
buffer that is filled
On 10 Nov 2009, at 11:57, Michael Van Canneyt wrote:
But let's start by improving efficiency, the MT issue can follow
later :-)
I disagree. I think correctness should always be more important than
efficiency, especially for RTL functions (and in particular when it's
about debugging helpe
Micha Nelissen schreef:
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug
input has been encapsuled in the two ReadNext() methods in the file
mentioned. It should be easy to make them to read from a (static?)
buffer that is filled blockwise; note that a st
Schatzl Thomas wrote:
Improving upon that should be trivial, all reading from the debug input has
been encapsuled in the two ReadNext() methods in the file mentioned. It should
be easy to make them to read from a (static?) buffer that is filled blockwise;
note that a static buffer may give hea
On Tue, 10 Nov 2009, Jonas Maebe wrote:
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for functionality that
you hopefully won't need anyway.
Correct.
But let'
On 10 Nov 2009, at 11:32, Michael Van Canneyt wrote:
By making the buffer a threadvar, this should not be an issue ?
It will waste memory for each thread you start though, for
functionality that you hopefully won't need anyway.
Jonas
___
fpc-de
On Tue, 10 Nov 2009, Schatzl Thomas wrote:
Hello,
Von: Martin
Just to make sure I don't to anything silly.
When an application crashes, it usually (at least in Lazarus) dumps a
stacktrace to the console.
I used to use stabs, and the stacktrace was dumped in less than a
second. Now I h
Hello,
> Von: Martin
> Just to make sure I don't to anything silly.
>
> When an application crashes, it usually (at least in Lazarus) dumps a
> stacktrace to the console.
>
> I used to use stabs, and the stacktrace was dumped in less than a
> second. Now I have switched to dwarf and the sa
20 matches
Mail list logo
