Joseph,
That would be Ron, not I -- yet anyway, and it will be some time before
I can break out any time to play with this... But it looks like Ron has
some pointers.
On Tue, 2 Aug 2011 00:50:39 -0400, Joseph Stewart wrote:
Hey Ron/EBo,
Do y'all have any libixp examples you could share?
-
There is server and client code in the repo. We've been using it for
some time now at sandia and other places.
Writing a synthetic to work for libixp is pretty easy.
ron
Hey Ron/EBo,
Do y'all have any libixp examples you could share?
-j
On Sat, Jul 30, 2011 at 6:12 PM, ron minnich wrote:
> I'm still a big fan of libixp. It's written in a way that I feel is a
> good fit if you're used to Plan 9 C style. I've made a number of uses
> of it.
>
> ron
>
>
On 7/31/11, Jacob Todd wrote:
> Acme has Mail. It doesn't do threading like mutt or anything, but it works.
Robert Raschke coded a threaded version of Acme's News.
But that depends on the filesystem hierarchy of messages
in nntpfs. (n)upasfs does not thread messages at the level
of the fs. Indeed
> mk in 8l
> 8c -I/go/include -I/go/386/include -FTVw asm.c
> 8c -I/go/include -I/go/386/include -FTVw ../ld/data.c
> mk: no recipe to make 'goos.8' in directory /go/src/cmd/8l
> mk: # bind -b ... : exit status=rc 308216: rc 308218: mk 308220: error
goos.c is meant to be in src/lib9, I need to st
On Tue, 2 Aug 2011 00:19:32 +0100, Charles Forsyth wrote:
ron, by contrast, was timing a particular short interaction, which
might be repeated
a great many times (and thus mount up),
where non-trivial overhead of taking the measurement could easily
hide significant differences
between two impleme
On Mon, 1 Aug 2011 16:06:11 -0700, ron minnich wrote:
For 12 seconds, nsec is fine. I'm with charles on this one.
Even if/when I scale up to the entire machine I doubt that it will be
more a minute.
Eric was concerned about using get time of day because it can skew the
results. For now I'l
> puts it ``One nanosecond is to one second as one second is to 31.7 years.''
it would be somewhat less poetic if we kept time in metric. :-)
- erik
ron, by contrast, was timing a particular short interaction, which might be
repeated
a great many times (and thus mount up),
where non-trivial overhead of taking the measurement could easily hide
significant differences
between two implementations, hence the use of a timer provided directly by
h
12 seconds is rather bigger in magnitude than a nanosecond,
so i think you're fairly safe. or, as wikipedia more poetically
puts it ``One nanosecond is to one second as one second is to 31.7 years.''
if you get to the stage where it's a matter of nanoseconds between the
systems, there's not much be
For 12 seconds, nsec is fine. I'm with charles on this one.
ron
On Mon, 1 Aug 2011 23:25:34 +0100, Charles Forsyth wrote:
what are you measuring? i suspect you don't need the processor
counter.
(you're anyway not going to be wired to a single processor.)
I'm measuring how much time it takes for the system to come up, reserve
a number of tasks, run them, c
what are you measuring? i suspect you don't need the processor counter.
(you're anyway not going to be wired to a single processor.)
On Mon, 1 Aug 2011 10:17:13 -0700, ron minnich wrote:
if nsec on whatever platform reads from /dev/bintime, my suggestion
is
you not use it. Read from the processor counter instead.
Yes, nsec does call bintime from devcons. Can you point to an example
that uses the process counter? I was tr
> mk ROOT=$home/go
mk 'ROOT='^$home/go
seems better, if uglier :-)
++L
There's a recipe in src/cmd/mkone (../mkone)?
I hope I haven't overlooked any of the mkfiles, it's been a bit of a
swamp for a while.
Have a look at each mkfile's first few lines, you can change ROOT
there or
mk ROOT=$home/go
but I'm not always propagating (ever?) MKFLAGS.
Let me know,
Thanks!
what's a good recipe for making goose? :)
bigtop% mk
# bind -b /go/$objtype/include /$objtype/include
for(i in 8l 8a cc 8c gc 8g) @{
cd $i
echo mk in $i
mk $MKFLAGS
}
mk in 8l
8c -I/go/include -I/go/386/include -FTVw asm.c
8c -I/go/include -I/go/386/include -FTVw .
if nsec on whatever platform reads from /dev/bintime, my suggestion is
you not use it. Read from the processor counter instead.
ron
On Mon, 1 Aug 2011 08:57:13 -0700, ron minnich wrote:
What kind of timing tests? What kind of accuracy are you looking for?
What platform?
It is for the HARE project (Plan 9 on the BG/P). I am basically
running direct comparisons against Brazil, which also used nsec. I need
to calc the time
What kind of timing tests? What kind of accuracy are you looking for?
What platform?
ron
On Mon, 1 Aug 2011 08:36:22 -0400, erik quanstrom wrote:
if nsec(2) is wrapping around then time(2) will also wrap around.
i have not seen nsec do anything like that. it sounds to me like
you may be having integer truncation problems. are you using a
(u)vlong variable to store the results of n
On Mon Aug 1 08:19:23 EDT 2011, e...@sandien.com wrote:
> I am setting up some timing tests and am currently dumping the
> timestamps using nsec(). When I post-process the data I find that the
> it is wrapping around, but I have not found anything that clearly states
> when it does that.
I am setting up some timing tests and am currently dumping the
timestamps using nsec(). When I post-process the data I find that the
it is wrapping around, but I have not found anything that clearly states
when it does that. From the code I am guessing that is on the second
boundary. Is that
On Sun, 31 Jul 2011 22:00:57 +0200
Rudolf Sykora wrote:
> (I at least want to e.g. know, that using a web-client, although it is
> a pain, is probably the way to go, and that I should perhaps have a
> look for a quicker / simpler browser...)
>
Indeed. I find Firefox seems to run javascript abou
On /n/sources/contrib/lucio/go there is a fresh version of my efforts.
It is a bit ahead of my submissions to the Go Authors and could
benefit from inspection from the Plan 9 perspective. Also, this
inevitably means that there will be changes required by the code
reviewers.
At this point, it ough
25 matches
Mail list logo
