Hi,
I'm trying out vertigo and hoping you can help me figure out what I am
missing, I get an error when I use get-in:
; nREPL 0.1.8-preview
user (use 'vertigo.structs)
nil
user (def-typed-struct ints-and-floats :ints (array uint32 10) :floats
(array float32 10))
#'user/ints-and-floats
user (def
Hi Ezra,
This is admittedly a little confusing, but you're hinting 's' with the type
of the *element*. Here you've created a sequence containing a single
'ints-and-floats' struct, so you'd want to do this:
user (v/get-in s [0 :floats 4])
4.0
user (v/get-in s [0])
{:ints (0 1 2 3 4 5 6 7 8 9),
Actually, looking at the readme, I can see the code you were trying to use.
Sorry, I'm not sure how I didn't catch that before, but I've fixed it.
Zach
On Wed, Jul 31, 2013 at 10:17 AM, Zach Tellman ztell...@gmail.com wrote:
Hi Ezra,
This is admittedly a little confusing, but you're
Zach,
it might be interesting to keep an eye on the newly-announced ObjectLayout
project by Gil Tene and Martin Thompson. Discussion/overview is on this
mail thread
https://groups.google.com/forum/m/#!topic/mechanical-sympathy/9PNuQKuWVa4
and the project is here
How did this affect performance in your Go AI?
On Tuesday, July 9, 2013 10:56:03 PM UTC-5, Zach Tellman wrote:
Last year, I gave a talk at the Conj on my attempt to write an AI for the
board game Go. Two things I discovered is that it was hard to get
predictable performance, but even once
I actually haven't applied it yet. I'll post results once I have.
On Wed, Jul 17, 2013 at 11:49 AM, Daniel doubleagen...@gmail.com wrote:
How did this affect performance in your Go AI?
On Tuesday, July 9, 2013 10:56:03 PM UTC-5, Zach Tellman wrote:
Last year, I gave a talk at the Conj on
Yeah, one nice property of this is that all the underlying objects play
nicely with byte-streams [1], so it's trivial to do something like:
---
(def s (vertigo.core/wrap type some-huge-file))
(let [indices (sort-by #(vertigo.core/get-in s [% :foo :bar]) (range (count
s))]
(doseq [idx indices]
Hi Zach, this looks very interesting indeed and a great next step
after Gloss. For my SimpleCL[1] project I needed something v.similar,
but went a slightly different way to represent clj data as byte
buffers and compile them from specs parsed from C (header) files[2]. I
will give Vertigo a try
If you (vertigo.core/wrap a-file-name), that will use mmap under the
covers, so if no one's tried it, it's easy enough to start.
With respect to non-fixed data layouts, that could be supported by a
library which parses the framing information, and then layers Vertigo atop
the actual data. In
Interesting. This seems like a pretty promising direction for the bottom of
the big-data stack.
A use case on my mind is sorting a big list of datastructures by key (or
some set of keys/paths) .
Once the data gets big, you need to do an external sort, which means tons
of serialization round
This is pretty neat.
Anyone try using this in conjunction with mmap?
It would be nice to have some way to deal with strings other
variable-length data.
I'm also curious if its possible to make the analog of this for fressian,
basically to avoid unpacking objects that are not necessary for the
Last year, I gave a talk at the Conj on my attempt to write an AI for the
board game Go. Two things I discovered is that it was hard to get
predictable performance, but even once I made sure I had all the right type
hints, there was still a lot of room at the bottom for performance
12 matches
Mail list logo
