Daniel Hartwig mand...@gmail.com writes:
On 11 June 2012 12:37, David Kastrup d...@gnu.org wrote:
What is a vlist?
vlist is a data type introduced around guile 2.0. You will find it
documented in the Guile Reference under Compound Data Types.
They are growable and provide vector-like
() David Kastrup d...@gnu.org
() Sat, 09 Jun 2012 14:32:28 +0200
Suggestions?
Guile-SDL implements (in C) collections of enums using both a C array
(static, used also for init) and a Scheme hash table for backing store:
http://git.savannah.gnu.org/cgit/guile-sdl.git/tree/src/sdlenums.c#n66
On 11 June 2012 15:25, David Kastrup d...@gnu.org wrote:
Yes, but then it will actually be quite rare that the structure is
extended while it is read rather often. It would probably do fine to
just do the extension lazily by exception, but then wrapping a catch
around every access is likely
Hi David,
You raise an interesting issue. But first, a nitpick :)
On Sat 09 Jun 2012 14:32, David Kastrup d...@gnu.org writes:
Scheme hashtable
To be very pedantic, there are no hashtables in R5RS Scheme. SRFI-69
and R6RS specify them (in different ways), but do not mandate that they
grow.
On 11 June 2012 17:01, Daniel Hartwig mand...@gmail.com wrote:
For reference, attached is a growable vector I use in several
projects, adapted to support the length operation similar to Lua (i.e.
first unset numerical index). There is no catching of exceptions
here, every access to the data
Andy Wingo wi...@pobox.com writes:
You raise an interesting issue. But first, a nitpick :)
On Sat 09 Jun 2012 14:32, David Kastrup d...@gnu.org writes:
Scheme hashtable
To be very pedantic, there are no hashtables in R5RS Scheme. SRFI-69
and R6RS specify them (in different ways), but do
Any thoughts on this patch?
From 711ca0a5ed7351d6fde360f9b451600e77403522 Mon Sep 17 00:00:00 2001
From: Andy Wingo wi...@pobox.com
Date: Mon, 11 Jun 2012 12:25:24 +0200
Subject: [PATCH] scandir: select? takes basenames, operates on (sub)dirs also
* module/ice-9/ftw.scm (scandir): Run the
Hi,
On Mon 11 Jun 2012 11:55, David Kastrup d...@gnu.org writes:
Tables are a superset of what I need here. I need the growable vector
aspect, not the hash part aspect. Guile 1.8 only offers subsets:
growable does not come together with vector.
Why not just make your own growable vectors,
Hi!
Andy Wingo wi...@pobox.com skribis:
* module/ice-9/ftw.scm (scandir): Run the select? procedure on all
items, including subdirs and the `.' and `..' entries.
Since the goal was to mimic scandir(3), I double-checked:
#include stdlib.h
#include unistd.h
#include dirent.h
int
main ()
{
On 11 June 2012 18:38, David Kastrup d...@gnu.org wrote:
Well, considering the cost of dynvector-grow!, doing the growth in a
loop rather then just the determination of the new size seems a bit
expensive:
Only if you are repeatedly setting values at indices far beyond the
current capacity.
Hi,
Andy Wingo wi...@pobox.com skribis:
On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen t...@gnuvola.org writes:
If you want to make a case for such a facility, why not
show some code, both without (status quo) and with (proposed)?
It should be clear what expressiveness is gained, and how.
For
Andy Wingo wi...@pobox.com writes:
Hi,
On Mon 11 Jun 2012 11:55, David Kastrup d...@gnu.org writes:
Tables are a superset of what I need here. I need the growable vector
aspect, not the hash part aspect. Guile 1.8 only offers subsets:
growable does not come together with vector.
Why
Hi David,
David Kastrup d...@gnu.org skribis:
Scheme/Guile vectors are fixed size. Now I have a situation where I
have a basic type lattice with records stored in vectors, and this type
lattice may be extended dynamically (which typically happens at the
start of a whole file, for
Fine to me. ;-)
On Mon, Jun 11, 2012 at 6:26 PM, Andy Wingo wi...@pobox.com wrote:
Any thoughts on this patch?
--
http://wingolog.org/
David Kastrup d...@gnu.org writes:
Andy Wingo wi...@pobox.com writes:
Hi,
On Mon 11 Jun 2012 11:55, David Kastrup d...@gnu.org writes:
Tables are a superset of what I need here. I need the growable vector
aspect, not the hash part aspect. Guile 1.8 only offers subsets:
growable does
Hello,
vlist is a data type introduced around guile 2.0. You will find it
documented in the Guile Reference under Compound Data Types.
They are growable and provide vector-like access performances and
memory locality.
Ah, too bad. This needs to run under 1.8 as well.
If you need to
On 11 June 2012 20:00, David Kastrup d...@gnu.org wrote:
I guess to summarize: if you want an abstraction like tables, you would
build it out of vectors and hash tables. But vectors and hash tables
themselves are the lower-level building blocks.
Not low-level enough: they are already
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
Andy Wingo wi...@pobox.com writes:
Hi,
On Mon 11 Jun 2012 11:55, David Kastrup d...@gnu.org writes:
Tables are a superset of what I need here. I need the growable vector
aspect, not the hash part aspect. Guile 1.8
Noah Lavine noah.b.lav...@gmail.com writes:
vlist is a data type introduced around guile 2.0. You will find it
documented in the Guile Reference under Compound Data Types.
They are growable and provide vector-like access performances and
memory locality.
Ah, too bad. This needs to run
Daniel Hartwig mand...@gmail.com writes:
On 11 June 2012 20:00, David Kastrup d...@gnu.org wrote:
I guess to summarize: if you want an abstraction like tables, you would
build it out of vectors and hash tables. But vectors and hash tables
themselves are the lower-level building blocks.
Not
On 11 June 2012 20:20, David Kastrup d...@gnu.org wrote:
P.S.: I still need to look at vlists. They might already address this
issue, though I can't use them in Guile 1.8.
No, the immutable angle would make them unsuitable again.
Note that vlists are only immutable in the sense that
On Mon 11 Jun 2012 13:55, l...@gnu.org (Ludovic Courtès) writes:
What about using copying (or rather, copy-on-write) sub-bytevectors to
start with? That would avoid the aliasing issue; OTOH COW would make
the implementation more complex.
Not a bad idea. The FFI can still introduce aliasing,
Daniel Hartwig mand...@gmail.com writes:
On 11 June 2012 20:20, David Kastrup d...@gnu.org wrote:
P.S.: I still need to look at vlists. They might already address this
issue, though I can't use them in Guile 1.8.
No, the immutable angle would make them unsuitable again.
Note that
Maybe this could be a first stub for a table structure that is uses both an
array and a hash-table. I do think that implementing this might need fine
tuning in order
to have good defaults and so on. So in that sense one probably need to
check out reference
implementations. But this is for
On Mon 11 Jun 2012 16:19, David Kastrup d...@gnu.org writes:
Are you even reading what you are replying to?
Please be civil. People are trying to help you.
Thanks,
Andy
--
http://wingolog.org/
Hi,
Andy Wingo wi...@pobox.com skribis:
On Mon 11 Jun 2012 13:55, l...@gnu.org (Ludovic Courtès) writes:
What about using copying (or rather, copy-on-write) sub-bytevectors to
start with? That would avoid the aliasing issue; OTOH COW would make
the implementation more complex.
Not a bad
Andy Wingo wi...@pobox.com writes:
On Mon 11 Jun 2012 16:19, David Kastrup d...@gnu.org writes:
Are you even reading what you are replying to?
Please be civil. People are trying to help you.
More like telling me off. Of course, I am perfectly able to implement
my own moderately efficient
Hi David,
David Kastrup d...@gnu.org writes:
I don't think I need yet another data structure deficient in some
respects. We have vectors that can't grow, hashtables that can grow but
only index through a hash function, vlists that can grow but have
immutable content...
[...]
Why not just
28 matches
Mail list logo
