i'm using two Acmes all the time, with:
<<<'EOF'
#!/usr/bin/env rc
flag e +
NAMESPACE=`{namespace}^-2
mkdir -p `{namespace}
plumber || true
exec acme
EOF;
of course plumber sends to the first copy.
--
dexen deVries
[[[↓][→]]]
Take care of the luxuries and the necessities will take care
the idlehands() on 9front is as follows:
/*
* put the processor in the halt state if we've no processes to run.
* an interrupt will get us going again.
*/
void
idlehands(void)
{
extern int nrdy;
if(conf.nmach == 1)
halt();
else if(m->cpuidcx & Monitor)
I am running a dual core setup. CPU info is:
vendor GenuineIntel
procmodel 00020655 / 00010800
features fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
features pse36 clflush dts mmx fxsr sse sse2 ss
features pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes
hypervisor
ex
> /*
> * put the processor in the halt state if we've no processes to run.
> * an interrupt will get us going again.
> */
> void
> idlehands(void)
> {
> extern int nrdy;
>
> if(conf.nmach == 1)
> halt();
> else if(m->cpuidcx & Monitor)
>
On Dec 16, 2013, at 10:34, erik quanstrom wrote:
>> /*
>> * put the processor in the halt state if we've no processes to run.
>> * an interrupt will get us going again.
>> */
>> void
>> idlehands(void)
>> {
>>extern int nrdy;
>>
>>if(conf.nmach == 1)
>>halt();
> > it won't be "too late"—as causing failures. i've tried testing this and
> > generally found that reduced contention on the dog pile lock means
> > unconditionally halting gives a performance boost.
> >
> > - erik
> >
>
> What are the changes you made to 9atom to facilitate this? Just replac
Well if you can't compile limbo code with GCC, then hey, the idea is the
immortal virus.
> From: dav...@pobox.com
> Date: Mon, 16 Dec 2013 14:54:12 +1000
> To: 9fans@9fans.net
> CC: dav...@pobox.com
> Subject: Re: [9fans] Ideas from Plan-9
>
> On 24/10/2013, at 5:57 PM, Keith wrote:
>
> > Who h
On 16 December 2013 19:51, tyrrell t wrote:
> compile limbo code with GCC
gcc? clang, surely!
On 2013-12-15 18:05 , Blake McBride wrote:
> In spite of some really great ideas, I think we'd all agree that
> Plan-9 has no real future.
I would not agree about that. If you would try to have a look at coming
future tendencies, you would be notified that there is coming what is
now named as "int
I apologize for that statement. I made it before I knew of 9Front and
9Atom. From what I saw, the code hadn't changed in a long time, and
wouldn't boot in any environment I had. All that is false when you take
into account 9Front and 9Atom. I now have 9Front running fine, and, in
fact, I am ren
Quoting Blake McBride :
From what I saw, the code hadn't changed in a long time, and
wouldn't boot in any environment I had.
You are not a statistical universe.
I now have 9Front running fine, and, in
fact, I am renewing a port of an OO language extension to it.
We already have python, unf
On Dec 16, 2013, at 16:47 , Blake McBride wrote:
> All that is false when you take into account 9Front and 9Atom.
I run and highly recommend 9atom, but what you'd said is false even
just taking into account the mainline distribution from Bell Labs. It is
updated regularly, but via internal work
On Dec 15, 2013, at 4:48 PM, Tristan <9p...@imu.li> wrote:
> and then there's chuck moore.
I’m still rooting for GreenArrays as there are a few projects
where they chips would actually do well. But now that they’re
accepting bitcoin, who knows, who knows.
-jas
GreenArrays rocks. I still have no idea what to with all the cores. I've
found that writing a go package that generates fun forth is fun.
brucee
On 17/12/2013 11:32 AM, "Jeff Sickel" wrote:
>
> On Dec 15, 2013, at 4:48 PM, Tristan <9p...@imu.li> wrote:
>
> > and then there's chuck moore.
>
> I’m
14 matches
Mail list logo
