Re: [9fans] Ogg/Vorbis ported
For the record, libogg and libvorbis are now hosted in anothy's contrib as well. /n/sources/contrib/anothy/ufo/ Thanks anothy. Mathieu
Re: [9fans] actionfs
to make score i converted over 30,000 frames from mpg to tiff, using
inferno. it took a while, as it was 10 years ago, but nice to wake up
to.
brucee
On Mon, Feb 23, 2009 at 11:13 AM, mattmob...@proweb.co.uk wrote:
Hi,
this one was an experiment
/n/sources/contrib/maht/actionfs.c
invoked with a regex like actionfs (file.mpg).([0-9]+).(ppm)
if you then
cat /n/actionfs/file.mpg.100.ppm
actionfs responds with the output from executing
/bin/action-read $fd file.mpg.100.ppm file.mpg 100 ppm
where $fd will be an fd to write to
i.e. trivially action-read would be something like
#!/bin/rc
fd = $1
shift
echo $* /fd/$fd
-
The coresponding action-write also works
#!/bin/rc
fd = $1
shift
cat /fd/$fd /dev/null # or whatever
-
I wrote it specifically to extract individual frames from video files using
ffmpeg on Linux and
bring them into Plan9 for processing but generalized the arguments in case I
thought of something
interesting later.
My first round of experiment went like this
cpu% cat /bin/action-read
#!/bin/rc
# expect fd fullname videoname frameno
fname = `{echo -n $3 | tr ! '/'}
{
ssh storm single_frame $fname $4
} /fd/$1
cpu% cat /n/storm/home/maht/bin/single_frame
#!/usr/local/plan9/bin/rc
# expect filename frameno
timer = `{echo $2 | awk ' { printf %d.%02d\n, $1/ 25, 4 * ($1 % 25) }'}
{
ffmpeg -i $1 -t 00.001 -ss $timer /tmp/frame_$pid ^_%d.ppm
cat /tmp/frame_$pid ^_1.ppm
rm -f frame_$pid ^_1.ppm
rm -f frame_$pid ^_2.ppm # stupid ffmpeg outputs 2 frames (sometimes)
} [2] /dev/null
I was then using imgfs to calculate the average rgb value to look for black
frames but (unsurprisingly) it was taking too long (4 secs per frame) esp. as
the Plan9 I was using is in Qemu, cue installing Plan 9 on my terminal.
The ffmpeg part on the Linux side (2Ghz Opteron) was taking 1 second on its
own so I have to come up with some sort of look ahead cache which is contrary
to the idea, I may as well just convert the whole file to ppms at the start!
I've not looked if it is I/O or CPU - perhaps a bit of both.
I've not got round to doing it on my fresh terminal yet. I've got a new
3.2Ghz Dual Xeon server to migrate to and a Quad Core terminal to play with
so we'll see how that works out.
I was hoping to get Xcpu in there but I couldn't see how to get the Plan9
part working though I have the Linux bits up.
I have a couple of decent OSX boxes available too (one PPC one Intel) but I
gave up getting it to compile :)
too many projects .
matt
Re: [9fans] actionfs
2009/2/23 Bruce Ellis bruce.el...@gmail.com: to make score i converted over 30,000 frames from mpg to tiff, using inferno. it took a while, as it was 10 years ago, but nice to wake up to. what's score?
[9fans] Wrong email address in patch
I submitted a patch for acme this morning, wheel-chording, and I'm sorry but I wrote the wrong email address, is there any way I could change it? My system time was also wrong. (This is my first patch and, I promise, the last one I submit before breakfast...) I should also have written in the description that I'm not sure this patch will work for you, I sent it to Russ some time ago, when I had tested it only in plan9port's acme, and this was his response: 2008/3/19, Russ Cox r...@swtch.com: i don't think this is a good idea, for two reasons. the first is that pushing most mouse wheels down emits a middle button click already (at least on the microsoft and logitech mice). the second is more fundamental: wheel mice don't send up/down events for the scroll wheel like they do for normal buttons, so it doesn't work to treat those button bits the same way as a normal button. with your code, if i highlight and then push the scroll wheel more than one click, it will cut and then scroll. that's pretty weird. do you have a mouse without a clickable scroll wheel? russ I have been using the patch in 9vx.Linux (and plan9ports's acme) with different mouses and it has worked so far without any problem, YMMV. I find it more comfortable in general and very convenient to chord with touchpads, where many times you have a wheel, but not a middle button. Regards, -- - yiyus || JGL .
Re: [9fans] actionfs
Score! http://www.chunder.com/stuff/score.html On Tue, Feb 24, 2009 at 12:41 AM, roger peppe rogpe...@gmail.com wrote: 2009/2/23 Bruce Ellis bruce.el...@gmail.com: to make score i converted over 30,000 frames from mpg to tiff, using inferno. it took a while, as it was 10 years ago, but nice to wake up to. what's score?
[9fans] spreding the word
Well, I made an obvious mistake and sent the last email to the wrong address. I apologize for that. -- Saludos Hugo
Re: [9fans] spreding the word
this seems dated to me #w, #H and #b no longer exist and the install is now quite different. - erik
Re: [9fans] spreding the word
It's got a whole chapter on alef, and the UI is still in B/W. Definitly for an older edition of Plan 9. 'Tis a shame there's absolutley no attribution to be found. I wonder who wrote the book? Seems to be quite readable. Robby
Re: [9fans] spreding the word
hugo rivera wrote: Hi Maulesel, I just ran into this book and I am sending it to you for two reasons: 1.- It's in german. 2.- It's about Plan 9. 3. You sell hard drives to server operators for a living.
Re: [9fans] spreding the word
On Mon Feb 23 12:20:19 EST 2009, w...@authentrus.com wrote: hugo rivera wrote: Hi Maulesel, I just ran into this book and I am sending it to you for two reasons: 1.- It's in german. 2.- It's about Plan 9. 3. You sell hard drives to server operators for a living. relax. it would take 583166 of these messages to fill a tb drive. tb drives go for about $100 these days. - erik
[9fans] nupas failure
Hugo Rivera's (uai...@gmail.com) latest post to 9fans on Feb 23, 07:42 PDT, repeatedly causes nupas (using nupas/Mail in Acme) to crash with unexpected line: messages. ak
Re: [9fans] page(1)
If you get to debugging it, that'd be great. For everyone else, the
still useful png is in /n/sourcesdump/2009/0201/plan9/386/bin/png.
Everything works fine now, thanks FGB.
ak
---BeginMessage---
hola,
I haven't had the time to debug it, but readpng() changed
in the last days and it doesn't work correctly anymore.
I jdid yesterday -c /386/bin/png and everything went
back to normal.
On Fri, Feb 20, 2009 at 10:49 PM, erik quanstrom quans...@quanstro.net wrote:
On Fri Feb 20 20:29:55 EST 2009, aku...@mail.nanosouffle.net wrote:
Neither works for me.
term% hget http://9grid.es/screens/screen1.png|page
reading through graphics...
warning: couldn't read image: readimage: read count 32400 not 64800: screen
id in use
you should also try running png directly from sources.
assuming that this does not work, ...
it seems that here:
/sys/src/libdraw/readimage.c:103
m = readn(fd, tmp, n);
if(m != n){
werrstr(readimage: read count %d not %d: %r, m, n);
Err:
if(dolock)
lockdisplay(d);
things are getting confused. i think it would
be easier to debug if you added
werrstr();
right before the readn() and recompiled png.
i can't quite see how that error message could
result from reading an image.
- erik
--
Federico G. Benavento
---End Message---
Re: [9fans] page(1)
On Mon Feb 23 15:16:16 EST 2009, aku...@mail.nanosouffle.net wrote: If you get to debugging it, that'd be great. For everyone else, the still useful png is in /n/sourcesdump/2009/0201/plan9/386/bin/png. Everything works fine now, thanks FGB. i did see that the changes to png.c didn't make any difference. the changes to readpng do. there's a lot of changes to readpng, so i didn't chase that thread. - erik
Re: [9fans] spreding the word
On Mon, Feb 23, 2009 at 11:01, Robert Raschke rtrli...@googlemail.com wrote: 'Tis a shame there's absolutley no attribution to be found. I wonder who wrote the book? Seems to be quite readable. pdfinfo sheds some light on the subject: Title: P9.pdf Author: Wellhoefer Creator:PScript5.dll Version 5.2 Producer: Acrobat Distiller 5.0 (Windows) CreationDate: Mon Aug 21 20:32:06 2006 ModDate:Mon Aug 21 20:32:06 2006 Tagged: no Pages: 237 Encrypted: no Page size: 595 x 842 pts (A4) File size: 1279189 bytes Optimized: yes PDF version:1.3 googling wellhoefer plan 9 found this on wikipedia: German book about Plan 9: Hans-Peter Bischof, Gunter Imeyer, Bernhard Wellhöfer (born as Kühl), Axel-Tobias Schreiner: Das Netzbetriebssystem Plan 9. 1999, ISBN 3-446-18881-9. The book is out of print, but available for free at the print-on-demand service provider Lulu.com.
Re: [9fans] spreding the word
On Mon, Feb 23, 2009 at 11:01, Robert Raschke rtrli...@googlemail.com wrote: 'Tis a shame there's absolutley no attribution to be found. I wonder who wrote the book? Seems to be quite readable. pdfinfo sheds some light on the subject: Title: P9.pdf Author: Wellhoefer Creator:PScript5.dll Version 5.2 Producer: Acrobat Distiller 5.0 (Windows) CreationDate: Mon Aug 21 20:32:06 2006 ModDate:Mon Aug 21 20:32:06 2006 Tagged: no Pages: 237 Encrypted: no Page size: 595 x 842 pts (A4) File size: 1279189 bytes Optimized: yes PDF version:1.3 googling wellhoefer plan 9 found this on wikipedia: German book about Plan 9: Hans-Peter Bischof, Gunter Imeyer, Bernhard Wellhöfer (born as Kühl), Axel-Tobias Schreiner: Das Netzbetriebssystem Plan 9. 1999, ISBN 3-446-18881-9. The book is out of print, but available for free at the print-on-demand service provider Lulu.com. Yeah, looking at it I was thinking that the only Plan 9 book I know of in German was co-authored by Axel Schreiner, who teaches at my school :) Now if only I could read German... John Floren
Re: [9fans] spreding the word
Hello Hugo, 2009/2/23 hugo rivera uai...@gmail.com: Well, I made an obvious mistake and sent the last email to the wrong address. I apologize for that. Some mistakes can be usefull, at least for other people. ;-) In my case I welcome your mistake, because I didn't know that a german document covering Plan 9 exists. Plan 9 is fascinating, but understanding the documents can be quite difficult. At least it was for me as a non native speaker. This is why I keep on lurking around on this list, gathering information mostly, instead of working with Plan 9. This document might be old and even outdated to some degree, but I guess it's still worth reading. It would be great to have the source of the book, maybe it would be worth it to create a community based 2nd release. But I guess with all the copyright issues involved this will be next to impossible. Cheers Christian Walther
Re: [9fans] spreding the word
erik quanstrom wrote: On Mon Feb 23 12:20:19 EST 2009, w...@authentrus.com wrote: hugo rivera wrote: Hi Maulesel, I just ran into this book and I am sending it to you for two reasons: 1.- It's in german. 2.- It's about Plan 9. 3. You sell hard drives to server operators for a living. relax. it would take 583166 of these messages to fill a tb drive. tb drives go for about $100 these days. - erik I forgot the smileys :-) :-)
Re: [9fans] spreding the word
relax. it would take 583166 of these messages to fill a tb drive. tb drives go for about $100 these days. - erik I forgot the smileys :-) :-) i guess we're even then. i forgot my sense of humor today. - erik
Re: [9fans] spreding the word
It would be great to have the source of the book, maybe it would be worth it to create a community based 2nd release. But I guess with all the copyright issues involved this will be next to impossible. i can't think of any advantages of 2e over 4e. perhaps others disagree. if you're after the historical progression of how the structure of the kernel evolved, the file server kernel is much more interesting. - erik
Re: [9fans] spreding the word
if you're after the historical progression of how the structure of the kernel evolved, the file server kernel is much more interesting. Any bits in particular? Any reason why? -- vs
Re: [9fans] spreding the word
On Mon Feb 23 17:02:29 EST 2009, m...@acm.jhu.edu wrote: if you're after the historical progression of how the structure of the kernel evolved, the file server kernel is much more interesting. Any bits in particular? Any reason why? port/proc.c is very interesting, as are pc/lock.c and pc/trap.c. they are all very interesting as they illustrate the same concepts the pc kernel deals with, but they are substatially simplier. i fear i've complicated things a bit. hardware is more complicated these days. naturally, the fs kernel is less capable. it lacks dynamic memory, for example. but the beauty is that it doesn't need those things. i think it's an interesting study in tradeoffs. einstein said make everything as simple as possible, but not simpler. i think ken's take is that if it's not simple enough, you're solving the wrong problem. - erik
[9fans] spreading the word
No discussion involving Einstein and Ken should have spelling mistakes in the topic. It complicates the understanding ak ---BeginMessage--- On Mon Feb 23 17:02:29 EST 2009, m...@acm.jhu.edu wrote: if you're after the historical progression of how the structure of the kernel evolved, the file server kernel is much more interesting. Any bits in particular? Any reason why? port/proc.c is very interesting, as are pc/lock.c and pc/trap.c. they are all very interesting as they illustrate the same concepts the pc kernel deals with, but they are substatially simplier. i fear i've complicated things a bit. hardware is more complicated these days. naturally, the fs kernel is less capable. it lacks dynamic memory, for example. but the beauty is that it doesn't need those things. i think it's an interesting study in tradeoffs. einstein said make everything as simple as possible, but not simpler. i think ken's take is that if it's not simple enough, you're solving the wrong problem. - erik ---End Message---
Re: [9fans] spreading the word
No discussion involving Einstein and Ken should have spelling mistakes in the topic. It complicates the understanding as does changing the Subject: . there are always tradeoffs. - erik
[9fans] R G Loeliger meets Glenda
My first stab at a TIL was in AVR assembler but it was more fun to write the code than to find a way to use it. I still don't have a use but at least I don't have to run it on the AVR anymore to experiment first an example run cpu% /n/sources/contrib/maht/rc/til abc¯def 123 emit abc def 123 : emit4 emit emit emit emit 1 2 3 emit4 321 1 swp 3 2 swp dup dup drop emit4 emit 3321 As you may see gets converted to newlines and ¯ (alt__ in plan9, alt0175 on the numpad in windows drawterm) gets converted to a space (any better ideas?) It's the fruit of an evening's playing, so I've got a few features to add yet (saving the words will be trivial as you should see from the code) I should give props to BashForth for giving me the idea, but I've not looked at any of it's code (ugh). matt
[9fans] (no subject)
oops I forgot carriage returns get converted in email imagine # is a ^m pu% /n/sources/contrib/maht/rc/til abc¯def#123# emit abc def 123 : emit4 emit emit emit emit # 1 2 3 emit4 321 1 # swp 3 2 swp dup dup drop emit4 emit 3321 does this make sense / of interest to anyone :) matt
Re: [9fans] (no subject)
On Mon, Feb 23, 2009 at 4:29 PM, mattmob...@proweb.co.uk wrote: oops I forgot carriage returns get converted in email imagine # is a ^m pu% /n/sources/contrib/maht/rc/til abc¯def#123# emit abc def 123 : emit4 emit emit emit emit # 1 2 3 emit4 321 1 # swp 3 2 swp dup dup drop emit4 emit 3321 does this make sense / of interest to anyone :) sure but what's the point? Couldn't you grab one of the forth interpreters? ron
Re: [9fans] (no subject)
On Feb 23, 2009, at 6:48 PM, ron minnich rminn...@gmail.com wrote: sure but what's the point? Couldn't you grab one of the forth interpreters? Forth on Plan 9? That would be great. Then I'd have a bit more leverage in getting a new PIC based board to talk with Plan 9. (brucee's recent 9p example's notwithstanding) -jas
Re: [9fans] (no subject)
Jeff Sickel wrote: On Feb 23, 2009, at 6:48 PM, ron minnich rminn...@gmail.com wrote: sure but what's the point? Couldn't you grab one of the forth interpreters? Forth on Plan 9? That would be great. Then I'd have a bit more leverage in getting a new PIC based board to talk with Plan 9. (brucee's recent 9p example's notwithstanding) -jas Someone in freenode #forth said they'd just ported 4tH to Plan 9. I don't log IRC, wish I'd payed more attention. Maybe they've shared it by now. I don't doubt them, as 4tH's source comes with instructions on how to build with no libs and only 2 syscalls (1 is 'printf' replacement). sixforty
Re: [9fans] spreding the word
erik wrote: // i can't think of any advantages of 2e over 4e. perhaps others disagree. not advantages, no, but there are bits and pieces that were interesting ideas, even if they didn't pan out, that are overlooked. the whole streams idea is really educational. nonet was neat. having datakit code in there made the network transparency feel a bit more real (different world, i know). i often wish GraphicsMagick or ImageMagick were as easy to use as the fb tools. oh, and since there's some people on this list at a company that makes a map program: 2e's 'roads' was great. being able to specify a particular road or roads and have only those displayed was super useful. i'd love to see that in a certain map-like program. still, you'd give up a lot to go back in time. better to identify any bits worth the effort and bring them forward.
Re: [9fans] (no subject)
fgb has ported 4th; it's in his contrib dir, both as a tar file and a contrib package. i thought i remembered seeing another, but it's not on the contrib index page.
Re: [9fans] Calling vac from C
On Fri, 20 Feb 2009, erik quanstrom wrote: On Fri Feb 20 11:18:41 EST 2009, urie...@gmail.com wrote: One of the main costs of dynamic linking is making fork much slower. Even on linux statically linked binaries fork a few magnitude orders faster than dynamically linked ones. The main source of anti-fork FUD turns out to be the alleged 'solution' to a problem that didn't exist until the geniuses at Sun decided dynamic linking was such a wonderful idea. very generally, i agree with the direction of your post. but i do remember things a bit differently. iirc, this went the other way 'round. fork itself was very expensive on sun hardware in the early 90s if one had some memory mapped. sun mmus had issues. i benchmarked a vax 11/780 vs a sun 670mp. the 4x50mhz 670mp was scheduled to replace the 1x5mhz (?) vaxen. the vax forked maybe 10x faster when no memory was allocated. however, when a moderate amount of memory was allocated, the vax pounded the sun by many (3, i think) of magnitude. about 5 years ago i took a class on performance tuning Solaris. The instructor claimed that fork was expensive because accounting is never really turned off, just piped to /dev/null. there is no accounting overhead for threads. I never bothered to verify this, but now that this comes up, I'd tempted. - erik
