> 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
> 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
>>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.
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
> 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
> > 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.
> 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
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/
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
RSS Feed7 | |
|---|---|
6 | |
24 | |
22 | |
14 | |
9 | |
10 | |
4 | |
23 | |
15 | |
1 | |
4 | |
23 | |
8 | |
2 | |
1 | |
43 | |
38 | |
12 | |
24 | |
5 | |
1 | |
2 | |
23 | |
23 | |
27 | |
13 | |
6 | |
56 | |
14 | |
13 | |
5 | |
16 | |
17 | |
15 | |
22 | |
21 | |
36 | |
24 | |
50 | |
43 | |
43 | |
55 | |
72 | |
38 | |
65 | |
73 | |
36 | |
51 | |
41 | |
116 | |
20 | |
38 | |
15 | |
36 | |
59 | |
32 | |
29 | |
55 | |
78 | |
57 | |
54 | |
48 | |
49 | |
109 | |
63 | |
104 | |
213 | |
74 | |
85 | |
36 | |
62 | |
48 | |
85 | |
308 | |
151 | |
72 | |
30 | |
8 | |
72 | |
57 | |
72 | |
37 | |
19 | |
42 | |
63 | |
141 | |
63 | |
70 | |
119 | |
98 | |
19 | |
122 | |
58 | |
19 | |
66 | |
51 | |
133 | |
38 | |
59 | |
46 | |
21 | |
30 | |
72 | |
36 | |
73 | |
60 | |
140 | |
165 | |
180 |
