Caerwyn B Jones | 28 Mar 17:09 2005

Re: file2chan


> in order to achieve the behavior I want, I would have to process the
> styx messages myself (i.e., there is no intermediate layer of
> abstraction available)

you could use the styxservers(2) module. there is an example in
styxservers-nametree(2).

i think acme uses a pure "follow mouse" policy by default.

-caerwyn

Russ Cox | 28 Mar 18:00 2005
Picon

Re: file2chan

> As an unrelated question, the focus behavior in Inferno acme is
> different from the Plan9/Unix version.  Supplying the -b or -B options
> seems to perturb it, but in no case do I truly understand who gets the
> focus when and why.  Is there a rationale for the focus policy, and is
> there some way to set it a pure "follow mouse" policy?

the bug is probably in some graphics layer on the way to acme.
if acme doesn't see enough of the motion events it won't see
you moving your mouse from one window to the other.
i'm at a loss for what might be causing that now, but i've seen it
before when the mouse buffering code in libdraw was screwed up.

russ

Charles Forsyth | 1 Mar 01:11 2005
Picon

RE: [long] emu hangs on FreeBSD 5.3

>>I was thinking about smthg around thread libs, as they're moving targets
>>these days on FBSD 5.x..

the good news is that emu doesn't use any other thread lib on freebsd or linux,
so there is less to get in the way (and historically, they do).

the bad news is that emu doesn't use any other thread lib on freebsd or linux,
so the implementation is sensitive to changes in the system primitives from release to release, and
for whatever reason the clone/rfork interfaces have been subject to a fair amount
of small, sometimes undocumented change.

i test the implementation on two different levels of FreeBSD, but i see that
both are now fairly old, so i'll update at least one.  i'd do that more often but i use them
both for other things (partly to keep the machines useful when not doing builds or testing).

as a quick check until i do that, you might see whether the parameters to
rfork_thread make sense to you against the current documentation,
particularly as regards signal handling (eg, do threads have separate signal handlers?).

i'm assuming it's not `just' some strange interaction between something emu
does and (say) job control.

Jack Johnson | 1 Mar 01:33 2005
Picon

Re: tkwreq

On Mon, 28 Feb 2005 11:08:09 -0500, Russ Cox <russcox@...> wrote:
> i was porting libtk to plan 9 c again.

Hi Russ,

Just out of curiosity, where are you headed with this port?  Anything
specific in mind?

-Jack

Russ Cox | 1 Mar 01:57 2005
Picon

Re: tkwreq

> Just out of curiosity, where are you headed with this port?  Anything
> specific in mind?

nothing too specific.  i ported an earlier version of the
library and i used it successfully in a handful of little guis.
it worked really well and i wanted it for a couple other
little interfaces.  libcontrol is too fussy, as is gtk.

russ

Charles Forsyth | 1 Mar 02:10 2005
Picon

Re: tkwreq

> > i can just call allocwindow, etc. myself
> > to implement tkwreq.
>>there's no window manager.  just libtk and libdraw libthread and c.
>>at least that's the plan.  

it might still be worthwhile having a fairly simple
thread (in the libthread sense) to do the work
in reponse to messages on the channel and to multiplex
input across the tk windows, so that implementation could be replaced
by something else in applications that could use more control
over internal/external window placement, size, etc.

the original tk and window manager structure
was replaced because having window management
decisions made by code in the library/kernel was
inflexible.  (it used to call allocwindow directly, for instance.)

the aim in part was to open up some of the possibilities
in the `concurrent window system' paper.
generally, it worked out.  admittedly there are a few
control channels as it stands, which sometimes surprises.

Caerwyn Jones | 1 Mar 03:03 2005
Picon

Re: tkwreq

> generally, it worked out.  admittedly there are a few
> control channels as it stands, which sometimes surprises.

it took me a while to figure it out. it is quite complicated.
but then i started to have fun with it.

a slightly different look for wm:
http://caerwyn.com/screenshots/lnf.gif

and another:
http://caerwyn.com/screenshots/wm.gif

tk makes it easy to experiment with stuff. 
here's embedding graphs in a shell window (a trick borrowed from brutus)
http://caerwyn.com/screenshots/embedgraph.gif

Caerwyn

rog | 1 Mar 03:29 2005
rema soussou | 3 Mar 09:03 2005
Picon

limbo concepts

hello experts,

I am new to concurrent os inferno/plan9 and even to
programming distributivy. I'll like any help to these
questions

1 How is type inference defined in limbo.
2 Could you please post an url or documents comparing
limbo to oz and erlang.

Many thanks

	

	
		
D€couvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Cr€ez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Abhey Shah | 7 Mar 17:32 2005
Picon

bug in acme when using -c1


I start up inferno using the wm script with the c1 option, then middle 
click on the limbo button on a limbo program from within Acme. Acme 
opens up the Errors window then hangs. On the console that I started 
Inferno is printed ; [Textm] Broken: "e"
I'm using the 20041217 version of Inferno on a Fedora Core 3 machine 
with a 2.6.10 smp kernel.
I get the correct behaviour when I start emu with c0.

thanks

Abhey


Gmane