On Thu, Sep 10, 2009 at 2:17 AM, ron minnich wrote:
> On Wed, Sep 9, 2009 at 9:27 AM, Fernan Bolando wrote:
>
>> I am trying to port nhc98 the bytecode haskell compiler.
>> I am hoping to avoid changing those definition because I think those
>> are generated by the
>> haskell compiler and then fed
> term% time resample -x 1600 -y 1200 glenda.pic >/dev/null
> 36.07u 0.01s 36.21rresample -x 1600 -y 1200 ...
> term% time resize -b -s 1600 1200 glenda.pic >/dev/null
> 0.91u 0.02s 1.06r resize -b -s 1600 1200 ...
>
> The -b option is for bilinear interpolation. Without that, it goes
>
There is a plan 9 OST?
The leech target contains mostly video game OSTs. For exactitude's sake I
did look for P9fOS. Not there, but if you're really into it (and heed
"piracy" not) that bit of auditory magic, and indeed the visual magic it
accompanied, is a couple clicks away from the Google
> And none of this applies to or concerns Plan 9, which may be a cause for
> regret--or not.
There is a plan 9 OST?
anyone written any software recently?
at this point it probably doesn't matter whether it was for plan 9 or not.
Me did moan. Me did code, too, the retarded way. Wrote a couple score lines
of Perl to extract bits of JavaScript out of pages at a certain site,
slightly modify them, run them, ext
Yes, I did mean thread, and I hadn't realized this would kill all the
threads. I'll try with ioproc then, thanks for the example.
Mathieu
--- Begin Message ---
If you really mean thread and not proc, then what you suggest won't work.
You can't kill a thread that's in the OS without killing the pr
Threads are great for preventing race conditions. I agree.
Many Plan 9 applications (ria, acme, etc.) use a central proc with lots of
threads doing the real work of manipulating the state of the application.
No locks are required, because the threads explicitly yield by doing
channel io or callin
If you really mean thread and not proc, then what you suggest won't work.
You can't kill a thread that's in the OS without killing the proc
conyaining the thread (thereby killing all the other threads as well).
You can have the proc catch notes and send a note to the proc which
will interrupt any s
> it seemed safer at first if I didn't have to worry about the procs
> preempting each other (and appart from that dial() bottleneck, I don't
> need them to), that's why I started with threads. I was thinking of
> sticking to threads and not using procs until I really do need them. But
> yeah, no r
it seemed safer at first if I didn't have to worry about the procs
preempting each other (and appart from that dial() bottleneck, I don't
need them to), that's why I started with threads. I was thinking of
sticking to threads and not using procs until I really do need them. But
yeah, no real good r
On Thu Sep 10 05:37:12 EDT 2009, com...@panix.com wrote:
> In article ,
> erik quanstrom wrote:
> >> gcc happily compiles a definition like
> >> #define CT_v249((void*)startLabel+464)
> >>
> >
> >no it doesn't.
> >
> >$ cat > x.c
> >char *startlab;
> >long long offset = (void*)startlab+464;
>
In article <1d5d51400909090803n4c4d5b7ewba9dfe0573d02...@mail.gmail.com>,
Fernan Bolando wrote:
>On Wed, Sep 9, 2009 at 4:36 PM, Greg Comeau wrote:
>> In article <1d5d51400909080844q1bee4c3s114ccc5e51ce5...@mail.gmail.com>,
>> Fernan Bolando wrote:
>>>...error: initializer is not a constant: F0_P
In article <1d5d51400909090927u2a4e6742k9614b79df841d...@mail.gmail.com>,
Fernan Bolando wrote:
>I am trying to port nhc98 the bytecode haskell compiler.
>I am hoping to avoid changing those definition because I think those
>are generated by the
>haskell compiler and then fed to the C compiler. So
In article <1d5d51400909090843h2905057et1a60474702faf...@mail.gmail.com>,
Fernan Bolando wrote:
>>> gcc happily compiles a definition like
>>> #define CT_v249 =A0 =A0 =A0 ((void*)startLabel+464)
>I may not have posted the appropriate section of the code but, the app
>that I am porting have a bunch
In article ,
roger peppe wrote:
>2009/9/9 erik quanstrom :
>>> gcc happily compiles a definition like
>>> #define CT_v249 =C2=A0 =C2=A0 =C2=A0 ((void*)startLabel+464)
>>
>> no it doesn't.
>
>yes it does:
>
>% cat > x.c
>void *f(void *v){return v + 23;}
>% gcc -Wall -c x.c
>%
use -pedantic:
q.c:1:
In article ,
erik quanstrom wrote:
>> gcc happily compiles a definition like
>> #define CT_v249 ((void*)startLabel+464)
>>
>
>no it doesn't.
>
>$ cat > x.c
>char *startlab;
>long long offset = (void*)startlab+464;
>[...]
>$ gcc -Wall x.c
>x.c:2: error: initializer element is not constant
> I have a bunch of threads, simply scheduled with yield() at the moment
> (I'll use alt later on), and each of them is calling dial() at some
> point. I don't want the other threads to wait for "too long" when one
> of them is blocked on a dial() that will eventually time out.
> So I was thinking
Hello 9fans,
I have a bunch of threads, simply scheduled with yield() at the moment
(I'll use alt later on), and each of them is calling dial() at some
point. I don't want the other threads to wait for "too long" when one
of them is blocked on a dial() that will eventually time out.
So I was thin
18 matches
Mail list logo
