> Why are you surprised? Python is a very, very slow language. My very simple
> unoptimized C++ parsing code is more than 10x faster than Stem (parsing from
> memory). Go has some nice string parsing features, so zoossh should have an
> easy time to get fast and simple parsing code.
Because wit
On Sun, Aug 16, 2015 at 02:44:40PM -0700, Damian Johnson wrote:
> >> > Ideally, zoossh should do the heavy lifting as it's implemented in a
> >> > compiled language.
> >>
> >> This is assuming zoossh is dramatically faster than Stem by virtue of being
> >> compiled. I know we've discussed this befo
> > zoossh's test framework says that it takes 36364357 nanoseconds to
> > lazily parse a consensus that is cached in memory (to eliminate the I/O
> > bottleneck). That amounts to approximately 27 consensuses a second.
> >
> > I used the following simple Python script to get a similar number for
>
>> > Ideally, zoossh should do the heavy lifting as it's implemented in a
>> > compiled language.
>>
>> This is assuming zoossh is dramatically faster than Stem by virtue of being
>> compiled. I know we've discussed this before but I forget the results - with
>> the latest tip of Stem (ie, with laz
Hi Philipp,
First, thank you for the input. I will certainly review your
discussions with other measurement team members. I'm sorry I wasn't
able to attend.
On the subject of databases and why they're a kludge. Databases
represent relationships between data as joins. Joins are a construct
which m
On Fri, Jul 31, 2015 at 10:00:27AM -0700, Damian Johnson wrote:
> Hi Philipp, sorry about the delay! Spread pretty thin right now. Would you
> mind discussing more about the use cases, and give a mockup for what this
> new domain specific language would look like in practice?
>
> My first thought
On Fri, Jul 31, 2015 at 04:22:19PM -0400, l.m wrote:
> I know I've already mentioned some thoughts on this subject. I would
> be interested in your thoughts on the types of challenging questions
> such a hypothetical DSL might answer. I've already put some effort
> into this (forking metrics-lib),
Hi Philipp,
I know I've already mentioned some thoughts on this subject. I would
be interested in your thoughts on the types of challenging questions
such a hypothetical DSL might answer. I've already put some effort
into this (forking metrics-lib), but I'm still new to working with tor
network da
Hi Philipp, sorry about the delay! Spread pretty thin right now. Would you
mind discussing more about the use cases, and give a mockup for what this
new domain specific language would look like in practice?
My first thought is "would such a language be useful enough to be worth
investing time to l
Hi again,
So it's really not a domain specific language at all then? You can do
that without a specific parser and without stem. Just feed the data
subset into your favorite analysis tool. Stem, and parsers by
themselves are basically useless for analysis. Without an integrated
method of performin
On Tue, Jul 28, 2015 at 07:30:02PM -0400, l.m wrote:
> What you need is to properly define this domain-specific language
> using a context-free grammar. Then it doesn't matter how you parse the
> data, or what language, and the semantic analysis phase can be mapped
> to a variety of analysis/viz to
Herrow,
3. Something else you didn't consider.
You're describing something which I've been tinkering with recently so
I'll add some thoughts. I've looked at zoossh and stem for parsing.
They are inadequate alone. What you need is to properly define this
domain-specific language using a context-fr
Hi Damian,
I'm interested in building a lightweight, internal domain-specific
language to explore archived Tor data. The goal is to make it easy to
answer questions like the one that recently came up on tor-relays, "how
many guards shift location significantly across the Internet, and how
often?"
13 matches
Mail list logo
