Re: [9fans] acme and sam - mouse suggestions?
On Tue, 1 Feb 2022, at 04:25, Ben Hancock wrote: > Do you find you're able to sweep lines as easily using it in acme as with a > physical mouse? can't really say: i'm not a heavy acme user, and i haven't had a mouse in years. shinobi does feel pretty close to a thinkpad, so you should be able to test with a latter. acme feels comfortable to me in my setup, but you should really check whether you are fine with having to use both thumbs to chord. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Mf589a7afdf27dd56da6be881 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] acme and sam - mouse suggestions?
for a little change of pace, my only desktop input device is https://tex.com.tw/products/shinobi it's a fairly faithful recreation of https://support.lenovo.com/solutions/pd005137-thinkpad-usb-keyboard-with-trackpoint-overview but with mechanical keys and other accommodations one expects from a contemporary 'enthusiast' mechanical keyboard. despite the funny look of the mouse buttons (repurposed keycaps), the whole trackpoint setup is very ergonomic and chording works well (albeit requiring both thumbs, but unless you are using the computer one-handed they should already be close by on the spacebar). -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T49f3cceea70d2b61-Md3320db314950a73e15c3ddb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] Re: [inferno-os] sources of Alef language
> the sources of Alef language? 9fans is probably a better mailing list for this. alef was included in the plan9 second edition; that would be a good place to start. see https://seh.dev/plan9-2e/ for some pointers and a complete iso (including alef sources) in the 'archive'. you can mount that iso with 9660srv (either in plan9 or with plan9port) to recover original filenames. i remember there was an ongoing effort to update alef to run on modern plan9; 9fans will know more about this. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T7a4d9d7ff7642ef8-Mebbe449efc0d25ea8d570ca2 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] linux 9p: uid & gid
On Thu, Jun 20, 2019 at 05:34:03PM +0100, Charles Forsyth wrote: > 4294967294 probably started off as -2, which some systems used for user > "nobody" Yes. I understand that linux kernel try to keep work in this case and choose this uid and gid. But it would be great if i can manage permissions as usual. I need to give access to files based on uid and gid. -- Олег Неманов (Oleg Nemanov)
[9fans] linux 9p: uid & gid
Hi, all. I wrote a 9p fs with help of libixp and after mounting i see strange uid and gid numbers for files: ~# mount -t 9p -o trans=unix,noextend q t ~# ls -l t -rw-rw-rw- 1 4294967294 4294967294 1 Jan 1 1970 conf -rw-rw-rw- 1 4294967294 4294967294 1 Jan 1 1970 data -rw-rw-rw- 1 4294967294 4294967294 1 Jan 1 1970 stat If i do mount with dfltuid and dfltgid, i get normal values: ~# mount -t 9p -o trans=unix,noextend,trans=unix,noextend,dfltuid=0,dfltgid=0 q t ~# ls -l t -rw-rw-rw- 1 root root 1 Jan 1 1970 conf -rw-rw-rw- 1 root root 1 Jan 1 1970 data -rw-rw-rw- 1 root root 1 Jan 1 1970 stat But in any case chown call to these files sends empty uid and gid strings in wstat T-message. Is there any way to make uid & gid works as expected? Thanks. -- Олег Неманов (Oleg Nemanov)
Re: [9fans] enc64() vs dec64()
On Mon, Jun 22, 2015 at 11:10:04AM +0100, Charles Forsyth wrote: On 22 June 2015 at 10:05, Oleg lego12...@yandex.ru wrote: May be a stupid question. enc64() returns a null terminated string. But dec64() not doing the same. What is the reason for it? enc: binary - string dec: string - binary binary is just an array of bytes, and there isn't a special terminating value You're right. I use base64 to mask a white space symbols in strings and i completely forgot about the main base64 purpose :-). Thank you! -- Неманов Олег (Nemanov Oleg)
[9fans] enc64() vs dec64()
Hi, all. May be a stupid question. enc64() returns a null terminated string. But dec64() not doing the same. What is the reason for it? Thanks. -- Неманов Олег (Nemanov Oleg)
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 08:17:55AM +0100, k...@shike2.com wrote: perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. and it doesn't seem like a great idea to depend on atexits running things in a particular order. POSIX says they must be called in reverse order. plan9 isn't POSIX OS :-).
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 08:19:05AM +, Charles Forsyth wrote: On 6 November 2014 21:05, Oleg lego12...@yandex.ru wrote: I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. It might have been to avoid malloc in a fairly low-level function (and of something that will never be freed), If malloc works like in linux (at first invocation allocate more bytes than requested and then each malloc() use this already allocated by kernel area of memory), i think this isn't a big performance impact. or just because it was easier and, frankly, atexit let alone atexitdont aren't used that much. I'd be surprised if any use of atexit alone relied on any particular order, which is why your problem hasn't been noticed. The reverse order makes sense and atexit already does that. It's atexitdont that's wrong. The functions are unlikely to be called from any hot-spot. I'd just make atexitdont copy down the entries after the one deleted. This is according to manual. Because now if we use atexit() with atexitdont() we see the wrong behaviour from manual point of view.
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 11:49:08AM +, Charles Forsyth wrote: On 7 November 2014 10:57, Steffen Nurpmeso sdao...@yandex.com wrote: Safety against asynchronous un-/registration can't be it, anyway. No, there's a lock. I meant avoiding too many possible interactions between low-level run-time functions and the rest of the library. (I'd consider atexit and exit to be lower-level functions than malloc.) Since atexit is already used by profile, and is called by _profmain, which is called very early on, putting a call to malloc in that chain means you have to think that much harder about interactions that are already quite subtle. This is an interesting. With this info the array reordering in atexitdont() looks good comparing to malloc in atexit().
[9fans] acme mouse wheel
Hi. Does anybody known how to use mouse wheel to scroll acme window?
Re: [9fans] acme mouse wheel
On Fri, Nov 07, 2014 at 05:25:51PM +, tre...@india.com wrote: Have you set the mouse to ps2intellimouse? No. Thank you for the hint!
Re: [9fans] acme mouse wheel
On Fri, Nov 07, 2014 at 10:28:18AM -0700, andrey mirtchovski wrote: http://plan9.bell-labs.com/wiki/plan9/mouse_scrolling/ Thank you! That has helped me.
Re: [9fans] atexit() atexitdont()
On Fri, Nov 07, 2014 at 02:53:11PM -0500, erik quanstrom wrote: On Fri Nov 7 07:26:55 EST 2014, charles.fors...@gmail.com wrote: Not for atexit, but for some other functions, I've had to follow various trails in glibc, and it's just an intricate convoluted nightmare, so that probably colours my view. calling malloc from the atexit path will pull malloc() into every executable. i think this is the real reason not to do this. That's interesting. Is malloc() so huge to worry about it?
[9fans] atexit() atexitdont()
Hi, all.
I looked at atexit() and atexitdont() and i don't understand why these
functions are implemented with a static array instead of singly linked list?
May be somebody with a greater plan9 experience can help me with my question.
If i do:
#include u.h
#include libc.h
void f1(void)
{
print(f1\n);
}
void f2(void)
{
print(f2\n);
}
void main(int, char**)
{
atexit(f1);
atexit(f2);
atexit(f1);
atexitdont(f2);
atexit(f2);
exits(nil);
}
i get:
f1
f2
f1
instead of:
f1
f1
f2
because of atexit.c source code.
Thanks.
Re: [9fans] atexit() atexitdont()
On Thu, Nov 06, 2014 at 04:26:04PM -0500, erik quanstrom wrote: On Thu Nov 6 16:07:56 EST 2014, lego12...@yandex.ru wrote: Hi, all. I looked at atexit() and atexitdont() and i don't understand why these functions are implemented with a static array instead of singly linked list? May be somebody with a greater plan9 experience can help me with my question. perhaps a linked list would make sense, but atexits(2) doesn't say which order the functions will be run in. It say - in reverse order. and it doesn't seem like a great idea to depend on atexits running things in a particular order. Why? There are various situations...
Re: [9fans] GPLv2
On Fri, Feb 14, 2014 at 12:28:30AM +0100, Aram H??v??rneanu wrote: On Thu, Feb 13, 2014 at 10:00 PM, Peter Hull peterhul...@gmail.com wrote: On the other hand, I???ve never heard of akaros. How similar is it to Plan9? Let's see... GNU libc, POSIX threads, asynchronous I/O, bash, makefiles, #ifdefs. I'd say it has nothing to do with Plan 9. This is not surprising. Berkeley has a long story of unix non-understading. Well, now it came to plan9 :-).
[9fans] cat /dev/mouse | xd
Hello all. Is it normal that i can't see any output of cat /dev/mouse | xd? I see cat /dev/mouse output, cat anyfile | xd output, but no cat /dev/mouse | xd output.
Re: [9fans] cat /dev/mouse | xd
On Mon, Jan 20, 2014 at 07:15:45PM +0100, cinap_len...@felloff.net wrote: xd does output buffering. only when the buffer is full or it gets to the end of the file (never in case of /dev/mouse) it writes to the output. you can disable buffering with the -u flag, see xd(1) in the manual. Thank you! I completely forgot about buffering.
Re: [9fans] Ideas from Plan-9
On Sun, Dec 15, 2013 at 11:05:53AM -0600, Blake McBride wrote: In spite of some really great ideas, I think we'd all agree that Plan-9 has no real future. On the other hand, I believe that some of the best ideas Plan-9 brings us can and should be a part of the future. I think the best, most practical way to bring those ideas to wide-spread use and availability is to implement those ideas in the Linux kernel. I understand that, since Hm. The most progressive ideas in plan9 kernel. So, replacing plan9 kernel with linux kernel, you will get something strange and not very useful at all.
Re: [9fans] Ideas from Plan-9
On Sun, Dec 15, 2013 at 01:13:38PM -0600, Blake McBride wrote: All of this talk sound like someone saying: imagine the hurdles of sending a man to the moon. how can man fly when his weight to strength ratio is so poor No. This sounds like: why do much of useless work? To not lose plan9 benefits, we better will grow (or porting) many of useful and non-existent now software. Linux already has many good things, like a namespaces, sysfs and normal procfs (comparing to bsd). May be in the feature it will eliminate ioctl() and other ugly syscalls and introduce /dev/ttyctl + /dev/tty instead of this. But when will this happen? We have it all now in plan9.
Re: [9fans] Ideas from Plan-9
On Sun, Dec 15, 2013 at 09:43:27PM +0100, Bence F??bi??n wrote: Linux already has many good things, like a namespaces, Have you tried using *CLONE_NEWNS* in Linux? I did. It's a joke. I didn't say that this things are implemented well :-). I just say that linux has good things in direction of plan9, but it's not plan9. And this is a thankless job to make plan9 kernel from linux kernel.
Re: [9fans] iwp9 proceedings
they're now properly linked from iwp9.org as a minor note, it seems that anchor names on the page sometimes disagree with links in the navigation strip.
[9fans] running abaco (Was: Re: Nemo book)
./abaco.sh: 7: webfs: not found ./abaco.sh: 10: abaco.bin: not found abaco.sh expects those two bits to be in $path. try mk install. - Leonard oleg
Re: [9fans] Mousing is faster than typing but users do not believe it
[...] I'd like to point out that mice (or rather, pointing devices) come in different flavours. IBM's trackpoint, is, in my view, rather different device from usability perspective, and most of the mouse critique in this thread or elsewhere doesn't apply to it, while many of the stated benefits do. I've recently gotten Lenovo's trackpoint keyboard, which, while not being the greatest one I used, lets me use a trackpoint on a desktop machine, which is rather nice. Plan 9 interface in general seems to be very suitable for trackpoint devices.
Re: [9fans] Making read(1) an rc(1) builtin?
... creating a general-purpose Acme event parser in C. you may want to look at plan9port's acmeevent[1]. -- oleg [1] http://swtch.com/plan9port/man/man1/acmeevent.html
Re: [9fans] plan9 compatible notebook
can anybody recommend any plan9 compatible notebook? Based on 9fans' suggestions, I got an IBM T23. This machine is great, both for plan9 and generally. T23 (and other thinkpads from its era) also has the most plan9-friendly input devices I've seen. I can perform all the chords with just my thumb (later models have less useful button layout), and I never have to get my hands off the home row while using plan9. I can't say I tried every device, but I haven't yet come across anything that doesn't work. Of course you don't get wifi with T23, you probably need to get a supported pcmcia card.
Re: [9fans] plan9 compatible notebook
Most ThinkPad T23 (included mine) were sold with a WaveLAN mini-PCI card [1]. Oh, so I just was unlucky. Sorry for the confusion.
Re: [9fans] Has Anyone compiled 9vx on snow leopard ?
I am trying to get 9vx compiled on SnowLeopard 10.6.2 Andre has some problems posting to 9fans, but he says this should fix your problem: http://qcx.be/attic/9vx-osx-fix.patch -Oleg
[9fans] venti icachewriteproc going past isect
hi, i've had this behavior some time ago and haven't solved that, and now Akshat Kumar is experiencing exactly the same, but as the venti at faul is running on his mail server, he's unable to post here. as soon as venti starts, an icachewriteproc can be observed which produces high load, making the whole system unresponsive: bootes 130:00 0:2742392K Pwrite venti [icachewriteproc:/dev/sdC0/isect] from /proc/13/fd it can be seen that its offset into /dev/sdC0/isect keeps increasing, even past the partition size: % ls -l /dev/sdC0/isect --rw-r- S 0 bootes bootes 3175279616 Aug 22 23:38 /dev/sdC0/isect % cat /proc/13/fd 8 rw S0 (04300066 1 00) 0 3223880192 /dev/sdC0/isect this always reproduces after a restart. killing icachewriteproc renders fossil unresponsive, essentially making system unusable. fshalt -r hangs at 'syncing.../srv/fscons...', so the machine can't be rebooted cleanly. any hints? thanks, oleg
