On Tue, 21 Jun 2005, John Briggs wrote:
This is a repost of an earlier response to another thread. I did not recieve
any response so I am posting this in its own thread.
I have several old books (circa 1991), including source code, covering TP6 in
my library.
Perhaps the most interesting one
On Tue, 21 Jun 2005, Vincent Snijders wrote:
Hi,
Sysutil has a function ExceptAddr to current exception address, but no
corresponding functions to get the frame count and the frames of the current
exception.
Are these function just not yet implemented or are the ommitted on purpose?
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Vincent Snijders wrote:
Hi,
Sysutil has a function ExceptAddr to current exception address, but no
corresponding functions to get the frame count and the frames of the
current exception.
Are these function just not yet implemented or are
Vincent Snijders wrote:
Vincent Snijders wrote:
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Vincent Snijders wrote:
Hi,
Sysutil has a function ExceptAddr to current exception address, but
no corresponding functions to get the frame count and the frames of
the current exception.
Vincent Snijders wrote:
Vincent Snijders wrote:
I noticed that tortoisesvn doesn't put a full path into the diff like
tortoisecvs did.
Attached are two patches:
1. except.patch implements ExceptFrameCount and ExceptFrames
This patch is taken from the rtl/objpas/sysutils directory.
2.
Vincent Snijders wrote:
Vincent Snijders wrote:
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Vincent Snijders wrote:
Hi,
Sysutil has a function ExceptAddr to current exception address, but
no corresponding functions to get the frame count and the frames of
the current exception.
John Briggs wrote:
This is a repost of an earlier response to another thread. I did not recieve
any response so I am posting this in its own thread.
I have several old books (circa 1991), including source code, covering TP6 in
my library.
I still remember the Algorithms + Data Structures =
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the nodes in the chains, to have an
The generic functions are very powerful and model closely the C++ STL
library (as fpc does not have generics yet a sort of typecast is still
required when fetching the items from the container). The library was
not designed for speed though, from the first test the DArray class is
twice as
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the nodes in the chains, to have
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Michael Van Canneyt wrote:
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash
Ales Katona wrote:
Ok this patch does the following:
Removes the writeln() in case the library fails to load.
If the whole library is not found, it throws an exception which tell the
library name. If any method within the library is not found it throws an
exception with the given method
I would make that the contnrs unit. I think it belongs more together with
objects such as a stack and queue...
What is the performance difference between a hash() and a binary search on
an ordered list ? I've also been working with an 'associative' stringlist,
but
I was using an
Michael Van Canneyt wrote:
Depends how the hash is parametrized. If you've a big hash array and a
good hash function accessing has a complexity of O(1) while for a binary
search it's O(log(n))
But I assume that calculating the hash becomes harder for 'better' hashes ?
Not always, it
On Tue, 21 Jun 2005, Florian Klaempfl wrote:
Ales Katona wrote:
Ok this patch does the following:
Removes the writeln() in case the library fails to load.
If the whole library is not found, it throws an exception which tell the
library name. If any method within the library is not
Florian Klaempfl wrote:
Ales Katona wrote:
Ok this patch does the following:
Removes the writeln() in case the library fails to load.
If the whole library is not found, it throws an exception which tell the
library name. If any method within the library is not found it throws an
exception
Michael Van Canneyt wrote:
What is the performance difference between a hash() and a binary search on
an ordered list ? I've also been working with an 'associative' stringlist, but
I was using an ordered stringlist to keep the data, so a binary search is done.
The TStringList is a very fast
Depends how the hash is parametrized. If you've a big hash array and a
good hash function accessing has a complexity of O(1) while for a binary
search it's O(log(n))
But I assume that calculating the hash becomes harder for 'better' hashes ?
Only for general purpose hashes. Specific
Joost van der Sluis wrote:
On Mon, 2005-06-20 at 22:12 +0100, Colin Western wrote:
I found two minor problems (so far) on Fedora Core 4 (current svn):
1. The Copyright: tag must be License: in the fpc.spec file.
(Apparently Copyright: has been deprecated for a while).
2. The samplecfg
Marco van de Voort wrote:
The generic functions are very powerful and model closely the C++ STL
library (as fpc does not have generics yet a sort of typecast is still
required when fetching the items from the container). The library was
not designed for speed though, from the first test the
Dean Zobec wrote:
I can immagine, the DObject is a TVarRec. The problem with speed and
memory usage are the things that I don't like in Decal and it still
makes me wonder if it would be better to reimplement a containers
library from scratch, if we had generics to add type checking at compile
Marco van de Voort wrote:
Dean Zobec wrote:
As the project looks like a long term one and I think that fpc urgently
needs a optimized hash table I'll also work on a streamlined hash table
with a chaining technique as a collision resolution scheme and a paging
for the allocation of the
Bram Kuijvenhoven wrote:
Besides using TVarRecs, we could also use pointers (as in
classes.TList) or objects.
Pointers like in TList were the things I had in mind.
This would perhaps be a bit like it is in java.util. Then we would
also need container classes for basic types such as
Florian Klaempfl wrote:
Vincent Snijders wrote:
If these patches are applied in the trunk, wil they be merged into the
fixes branch too?
Applied, I'll merge them too.
I think there was a typo in the merge command. Revision 361 was merged
and not revision 461.
From the logfile:
26 matches
Mail list logo
