Hi David,
David Kastrup 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 have a sup
Andy Wingo writes:
> On Mon 11 Jun 2012 16:19, David Kastrup 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 version in Guile using
Hi,
Andy Wingo 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 idea.
On Mon 11 Jun 2012 16:19, David Kastrup writes:
> Are you even reading what you are replying to?
Please be civil. People are trying to help you.
Thanks,
Andy
--
http://wingolog.org/
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 discussio
Daniel Hartwig writes:
> On 11 June 2012 20:20, David Kastrup 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 i
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 aliasin
On 11 June 2012 20:20, David Kastrup 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 you can
Daniel Hartwig writes:
> On 11 June 2012 20:00, David Kastrup 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 enoug
Noah Lavine 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 under 1
David Kastrup writes:
> David Kastrup writes:
>
>> Andy Wingo writes:
>>
>>> Hi,
>>>
>>> On Mon 11 Jun 2012 11:55, David Kastrup 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:
>>
On 11 June 2012 20:00, David Kastrup 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 specialized
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 n
David Kastrup writes:
> Andy Wingo writes:
>
>> Hi,
>>
>> On Mon 11 Jun 2012 11:55, David Kastrup 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
Fine to me. ;-)
On Mon, Jun 11, 2012 at 6:26 PM, Andy Wingo wrote:
> Any thoughts on this patch?
>
>
>
> --
> http://wingolog.org/
>
Hi David,
David Kastrup 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 potentially multi-f
Andy Wingo writes:
> Hi,
>
> On Mon 11 Jun 2012 11:55, David Kastrup 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 m
Hi,
Andy Wingo skribis:
> On Sat 09 Jun 2012 17:16, Thien-Thi Nguyen 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 example, let's say I
On 11 June 2012 18:38, David Kastrup 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. This does no
Hi!
Andy Wingo 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
#include
#include
int
main ()
{
int count;
struct dirent **list;
Hi,
On Mon 11 Jun 2012 11:55, David Kastrup 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, th
Daniel Hartwig writes:
> On 11 June 2012 17:01, Daniel Hartwig 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 acc
Any thoughts on this patch?
>From 711ca0a5ed7351d6fde360f9b451600e77403522 Mon Sep 17 00:00:00 2001
From: Andy Wingo
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 select? procedure on
Andy Wingo writes:
> You raise an interesting issue. But first, a nitpick :)
>
> On Sat 09 Jun 2012 14:32, David Kastrup 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 t
On 11 June 2012 17:01, Daniel Hartwig 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 is through the
Hi David,
You raise an interesting issue. But first, a nitpick :)
On Sat 09 Jun 2012 14:32, David Kastrup 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. Guile's do
On 11 June 2012 15:25, David Kastrup 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 to be slow
() David Kastrup
() 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
This is not
Daniel Hartwig writes:
> On 11 June 2012 12:37, David Kastrup 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 access performances and
>
29 matches
Mail list logo
