Re: [9fans] Independent study topic
Frederik: Thanks! I hadn't seen the list of gsoc ideas before. Tim: That is excellent advice indeed. -Justin
Re: [9fans] iwp9-bondi
meggie to you. On 1/21/10, Rob Pike wrote: > margaret > > -rob > >
Re: [9fans] Independent study topic
I agree. ++pac > want to use. If its useful to you, chance are it is useful > and interesting to someone else, too. > > Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com > >
Re: [9fans] Independent study topic
Hello Justin You might pick-up something interesting from [0]. Also general advice: use the system, find out what you like an don't like, pick something about the system you wish was different and make it so. Make sure its something you actually want to use. If its useful to you, chance are it is useful and interesting to someone else, too. Tim Newsham | www.thenewsh.com/~newsham | thenewsh.blogspot.com
Re: [9fans] Now with authentication
The Jan5 binaries were broken, thanks for those who reported the problem. I've uploaded new binaries and updated the README to include instructions on installing OpenSSL binaries. On Jan 5, 10:16 am, Tim Newsham wrote: > I added p9sk1/p9any authentication support to npfs and added support > for authentication to ninefs. The README has been updated with new > build instructions (OpenSSL is now a dependency) and an updated binary > has been put in the downloads area.
Re: [9fans] Independent study topic
Hello Justin You might pick-up something interesting from [0]. Best regards, F. Caulier [0] http://gsoc.cat-v.org/ideas/
Re: [9fans] dataflow programming from shell interpreter
> Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit one > possible answer to the video processing question? Filter graphs can be > generated by any program, GUI or CLI, and fed to DirectShow provided one > learns the in and out of generating them. DirectShow is COM; source/mux/transform/sink filters must provide a number of interfaces (e.g. IFileSinkFilter); other components (e.g. GraphBuilder) are there to make it easier to hook them together. i don't think a direct mapping of COM to Plan 9 fs model is unnecessary. for example, instead of mapping every control or configuration interface and method to synthetic directories and files, a single ctl file will do. something like this seems sufficient: /ctl# e.g. accepts run, stop, etc. returns: paused, #outputs, config, etc. /event # instead of callback notification /ipin/clone /ipin/n/ctl /ipin/n/event /ipin/n/data /opin/clone /opin/n/ctl /opin/n/event /opin/n/data for a special purpose kernel one could add a driver and a fancy new hook syscall (similar to pushssl and '#D') that would hook two fd's together to eliminate the need for a user proc to transfer between ipin/?/data and opin/?/data.
Re: [9fans] Independent study topic
> I'm going to quote a fellow 9fan to you, it gets upvotes whenever I post it > on reddit / slashdot / ycombinator so it must be true :) > > You want to make your way in the CS field? Simple. Calculate rough time of > amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the > dusty archives, dig out something fun, and go for it. It's worked for many > people, and it can work for you. > > — Ron Minnich > That's great. I'm keeping that one. I've actually been following the "dataflow programming from shell interpreter" thread on the list with great interest...I think there's a glimmer of hope there.
Re: [9fans] dataflow programming from shell interpreter
On 20/01/2010 21:13, Eris Discordia wrote: Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit one possible answer to the video processing question? Filter graphs can be generated by any program, GUI or CLI, and fed to DirectShow provided one learns the in and out of generating them. I don't know much about those but video processing sometimes needs two passes, one to decompose and one to compose at the required bitrate, DVD mpeg I'm looking at you. Straying off the topic a bit wrt plan9 but here's an interesting read http://x264dev.multimedia.cx/?p=249
Re: [9fans] Independent study topic
I've been lurking for the past few months and I've really enjoyed reading the messages from this list. I'm looking for some ideas or advice---here's the story: I'm pursuing a Master's degree in computer science at a small school with limited options for classes. I'm enrolled in a graduate-level course in distributed systems, but the material isn't on my level. The professor understands my predicament and might allow me to do an independent study on the subject, but I would need something specific to work on. I would love to do something with Plan 9...I'm just not sure what. Compare and contrast it with other systems? Find a novel use for 9P? Hi Justin, I'm going to quote a fellow 9fan to you, it gets upvotes whenever I post it on reddit / slashdot / ycombinator so it must be true :) You want to make your way in the CS field? Simple. Calculate rough time of amnesia (hell, 10 years is plenty, probably 10 months is plenty), go to the dusty archives, dig out something fun, and go for it. It's worked for many people, and it can work for you. — Ron Minnich
Re: [9fans] iwp9-bondi
margaret -rob
Re: [9fans] dataflow programming from shell interpreter
i had some ideas along these sorts of lines which i put into a tool in inferno that i called "alphabet". it works (with a few rough edges). http://www.vitanuova.com/inferno/man/1/sh-alphabet.html for an example of something it can do that's not possible with a conventional shell pipeline, see http://www.vitanuova.com/inferno/man/1/alphabet-fs.html one of these days i intend to dust it off and take it to the next level - i've had a few ideas in the meantime. don't hold your breath though. 2010/1/20 Patrick Kelly : > > > On Jan 20, 2010, at 4:13 PM, Eris Discordia > wrote: > >> Aren't DirectShow filter graphs and programs like GraphStudio/GraphEdit >> one possible answer to the video processing question? Filter graphs can be >> generated by any program, GUI or CLI, and fed to DirectShow provided one >> learns the in and out of generating them. >> >> The OP's question, too, finds one answer in MS PowerShell where instead of >> byte streams .NET objects are passed between various tools and a C#-like >> shell language is used for manipulating them. .NET objects can at any point >> be serialized/deserialized to/from XML using stock classes and routines in >> System.Xml.Serialization namespace. > > Why XML? Surely there are better options. >> >> Just a note that at least some implementations of both ideas exist in >> production settings. >> >> >> --On Tuesday, January 19, 2010 15:40 + Steve Simon >> wrote: >> The PBM utilities (now net pbm) did something similar for bitmaps. I think V10 also had some pipeline utils for manipulating images. >>> >>> Indeed, however I make a firsm distinction between image proccessing (2d) >>> and video processing (3d). >>> >>> In Video processing the image sequences can be of arbitary length, the >>> processing is often across several fields, and, because we want our >>> results ASAP tools should present the minimum delay possible (e.g. a >>> gain control only needs a one pixel buffer). >>> >>> Aditionally image processing pipelines often have nasty things like >>> feedback loops and mixing different paths with differing delays which all >>> need special care. >>> >>> We have a package of good old unix tools developed jointly by us and the >>> BBC which works as you might expect >>> >>> cat video-stream | interpolate -x 0.7 -y 0.3 | rpnc - 0.5 '*' | display >>> >>> however this can get quite ugly when the algorithm gets complex. >>> >>> We need to cache intermediate results - processing HD (let alone 2k 3d) >>> can get time consuming so we want an environment which tee's off >>> intermediate results automagicially and uses them if possible - sort of >>> mk(1) combined with rc(1). >>> >>> It is also a pain that its not easy to work at different scales i.e. >>> writing expressions to operate at the pixel level and using large blocks >>> like interpolate, the rpnc is an attempt to do this but its interpreted >>> (slow). >>> >>> a restricted rc(1)-like language which supports pipelines, >>> and scalar (configuration) variables combined with a JIT compiler >>> (in the vein of popi) looks like a solution but I have never go further >>> than wishful thinking. >>> >>> -Steve >>> >> >> >> >> >> > >
