Re: [9fans] GSoC proposal: Replace language for wikifs
On 2014-03-20, 1950, Szymon Olewniczak wrote: Hi, I've just published a Summer of Code proposal for Replace language for wikifs.[1] What do you think about my candidature. Maybe should I explain something more? BR, Szymon [1]https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/hafron/5629499534213120 +1 for markdown (pandoc or multimarkdown specifically) -- Derek signature.asc Description: OpenPGP digital signature
[9fans] GSoC proposal: Replace language for wikifs
Hi, I've just published a Summer of Code proposal for Replace language for wikifs.[1] What do you think about my candidature. Maybe should I explain something more? BR, Szymon [1]https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/hafron/5629499534213120
[9fans] GSoC proposal: Alternative window system
Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
Cohesive compilation of hacks? On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián beg...@gmail.com wrote: We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
It would be nice to have something like old Oberon OS had; I think acme was inspired in part by it (I may be wrong). Some time ago, I had some ideas on windowing design; were anyone interested, they're here: http/www.gli.cas.cz/home/cejchan/plan9/newUI.pdf http/www.gli.cas.cz/home/cejchan/plan9/newUI+page.pdf http/www.gli.cas.cz/home/cejchan/plan9/newUI+page-fullscreen.pdf Best regards, Peter. On Wed, Mar 19, 2014 at 10:01 AM, Shane Morris edgecombe...@gmail.comwrote: Cohesive compilation of hacks? On Wed, Mar 19, 2014 at 7:56 PM, Bence Fábián beg...@gmail.com wrote: We already have a lot of hacks to make rio tiling. In my opinion the most interesting/worthwhile projects mentioned on that wiki is to make things touchscreen friendly. 2014-03-19 9:36 GMT+01:00 Caleb Malchik cmalc...@gmail.com: Greetings, I am a student interested in participating in GSoC under Plan 9. My project would involve writing a new window manager as an alternative to rio: http://www.plan9.bell-labs.com/wiki/plan9/alternative_ window_system/index.html I thought I'd say a few words informally as my proposal is not yet ready for upload, and it would be good to get some feedback in the remaining days before the deadline. I have experience with C and Linux, but plan9port is the extent of my first-hand experience with Plan 9. I've read some of the papers and other resources and I am intrigued by the ideas behind Plan 9 and the clean implementation of those ideas. I intend to start using Plan 9 natively or in a VM soon, and I am confident I could get comfortable with the environment before the start of the summer. For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. Let me know if this sounds like a good summer-sized project for someone who is not yet well acquainted with Plan 9. Regards, Caleb Malchik
Re: [9fans] GSoC proposal: Alternative window system
What did old Oberon have? -- Aram Hăvărneanu
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik
Re: [9fans] GSoC proposal: Alternative window system
I think Plan B / Octopus's omero does these things already. I'm still voting for touch interface 2014-03-19 15:17 GMT+01:00, erik quanstrom quans...@quanstro.net: On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:01:54 EDT 2014, beg...@gmail.com wrote: I think Plan B / Octopus's omero does these things already. I'm still voting for touch interface we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. next year if there is such a hardware driver, and we're accepted into gsoc, it might be interesting. especially if a student signs up for it. - erik
Re: [9fans] GSoC proposal: Alternative window system
we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. If someone were interested in doing this in the short term, the best option is likely tying it to reviving the iOS drawterm port. One could also do some interesting UI experiments with drawterm from laptops with multitouch devices; that would be less ambitious, but you'd get past step 0 quicker. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:33:58 EDT 2014, a...@9srv.net wrote: I'm still voting for touch interface Not to be pedantic, but note that there isn't any voting here. Students come up with a proposal for something they'd be interested in working on for the summer, and the prospective mentors order them and fill however many slots we get (short version). I'd love a touch interface, too, but if a student is interested in doing a dwm-like interface but not interested in touch, they should write a proposal for a dwm-like interface. thanks, i was too subtile about this point. - erik
Re: [9fans] GSoC proposal: Alternative window system
I'm still voting for touch interface Not to be pedantic, but note that there isn't any voting here. Students come up with a proposal for something they'd be interested in working on for the summer, and the prospective mentors order them and fill however many slots we get (short version). I'd love a touch interface, too, but if a student is interested in doing a dwm-like interface but not interested in touch, they should write a proposal for a dwm-like interface. Anthony signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [9fans] GSoC proposal: Alternative window system
On Wed Mar 19 11:36:39 EDT 2014, a...@9srv.net wrote: we don't drive any touch hardware, so in the interest of success, i would not be interested in a gsoc project that required as step 0: identify, purchase and write driver for enabling hardware. If someone were interested in doing this in the short term, the best option is likely tying it to reviving the iOS drawterm port. One could also do some interesting UI experiments with drawterm from laptops with multitouch devices; that would be less ambitious, but you'd get past step 0 quicker. given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. - erik
Re: [9fans] GSoC proposal: Alternative window system
given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. Certainly. It doesn't currently build. Old binaries start up but quickly crash. From memory, I don't believe keyboard input currently works. It's still a substantial step 0. signature.asc Description: Message signed with OpenPGP using GPGMail
[9fans] GSoC proposal - Improvements to the HTML5 draw server
Hello 9fans, I'm applying to the Plan 9 GSoC again this year. I propose to continue work on the HTML5 drawterm I started in last year's GSoC, in the hope of making it a usable alternative to the native drawterm. I have identified three major areas for improvement: * cleaning up and fixing bugs in the graphics and input code * using the authenticated and encrypted cpu(1) protocol * multithreading the 9p library If you would like to read my proposal, I have posted it here: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/drh/5662278724616192 -- David
Re: [9fans] GSoC proposal: Alternative window system
On Wed, Mar 19, 2014 at 3:17 PM, erik quanstrom quans...@quanstro.net wrote: On Wed Mar 19 10:14:26 EDT 2014, ara...@mgk.ro wrote: What did old Oberon have? http://en.wikipedia.org/wiki/Oberon_(operating_system) - erik Yes, I know what Oberon is, I even used it. Peter mentioned something old Oberon had, which suggests it is something new Oberon doesn't have. Even if that isn't the case (why mention old then?), wanting Oberon features in rio means nothing unless it is specified what features that are. -- Aram Hăvărneanu
Re: [9fans] GSoC proposal: Alternative window system
On Mar 19, 2014, at 10:49 AM, Anthony Sorace a...@9srv.net wrote: given that that port was done many releases of ios ago, it is likly that a different step 0 would be required: bring the ios drawterm port back to life. Certainly. It doesn't currently build. Old binaries start up but quickly crash. From memory, I don't believe keyboard input currently works. It's still a substantial step 0. The GSOC 2010 iOS drawterm port does build and run on iOS 7+: https://bitbucket.org/jas/drawterm Pull it, open iphone/drawterm.xcodeproj in the latest Xcode 5.x, and you should be able to build and install it on an iOS device. It actually works a bit better on iPads since the keyboard doesn’t cover up everything you need in rio. -jas
Re: [9fans] GSoC proposal: Alternative window system
On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik cmalc...@gmail.com wrote: For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. I will throw out some rio/acme related ideas. Hope people find them interesting enough to want to experiment. - display size aware (when attached to an external display vs the builtin one of a laptop). - dpi aware (pick the right size font) - borderless windows (adjoining windows have different color) (but edges are sensitive to resizing etc) - auto splitting of windows. The idea is to see if window size fiddling can be minimized (ideally it should /learn/ personal preferences) - allow the window with focus to be made much much larger to help a user's focus (make other windows less distracting -- IIRC there was a web based spreadsheet that did that. Don't recall its name). - allow windows to be scrolled in lockstep (in x, y or both directions) - support for multiple displays - allow programmatic control of all this via a synthetic FS Not sure if there exists a usable unification of acme + rio but that would be nice.
Re: [9fans] GSoC proposal - Improvements to the HTML5 draw server
On Wed, Mar 19, 2014 at 1:07 PM, David Hoskin r...@davidrhoskin.com wrote: Hello 9fans, I'm applying to the Plan 9 GSoC again this year. I propose to continue work on the HTML5 drawterm I started in last year's GSoC, in the hope of making it a usable alternative to the native drawterm. I have identified three major areas for improvement: * cleaning up and fixing bugs in the graphics and input code * using the authenticated and encrypted cpu(1) protocol * multithreading the 9p library If you would like to read my proposal, I have posted it here: http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/drh/5662278724616192 I'd like to see this proposal get priority since David is a returning student and last year's effort was a success. Steve
Re: [9fans] GSoC proposal: Alternative window system
Multiple displays and display dpi awareness in acme would make my day! Multi-display looks easy - we just need handling for adding a new row, which is already handily abstracted. Fitt's law aware mouse movement would be nice too, particularly on large screens. You could slightly trap the mouse on narrow edges (scroll bars and resize edges in particular) when the mouse is moving slowly. Probably a pain to tune, but would make acme much easier to use on large screens. Paul On Wed, Mar 19, 2014 at 12:02 PM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik cmalc...@gmail.com wrote: For my project, I would build a tiling window manager similar to dwm (what I use on Linux). I think a dwm-style interface that could be controlled from the keyboard would provide a nice contrast to what we already have with rio, and as we see from dwm the implementation of such an interface needn't be complex. Development would involve modifying the rio source code to implement the basic functions of a tiling/keyboard-controlled window manager one by one. I will throw out some rio/acme related ideas. Hope people find them interesting enough to want to experiment. - display size aware (when attached to an external display vs the builtin one of a laptop). - dpi aware (pick the right size font) - borderless windows (adjoining windows have different color) (but edges are sensitive to resizing etc) - auto splitting of windows. The idea is to see if window size fiddling can be minimized (ideally it should /learn/ personal preferences) - allow the window with focus to be made much much larger to help a user's focus (make other windows less distracting -- IIRC there was a web based spreadsheet that did that. Don't recall its name). - allow windows to be scrolled in lockstep (in x, y or both directions) - support for multiple displays - allow programmatic control of all this via a synthetic FS Not sure if there exists a usable unification of acme + rio but that would be nice.
Re: [9fans] GSoC proposal: Ventilator or Access to host's devices
On 11 March 2014 08:39, tuchalia tucha...@gmail.com wrote: If it isn't, I may still be interested on working on Access to host's devices**, so where can I start looking with that? The old way way was to add an internal virtual device to Inferno's emu or 9vx or drawterm. I think the best way to implement that access now is by writing a separate program that provides a name space representing the devices which it serves using 9P. That program can be host-specific where necessary. For example, Linux systems provide a fairly uniform interface across Linux platforms (except for embedded Linux such as Android), and the interface program would mainly need to be recompiled for each host platform; the BSD systems will be similar in effect to Linux but often different in detail; and Apple and WIndows are distinct targets different from them all. The name space exported for a particular type of service (audio, or serial ports, say) should be the same across all hosts, even when the different host systems have themselves got different interfaces. It should ideally support many clients at once. The advantage over an internal virtual device is that the same 9P-serving program can be used by Inferno, 9vx and drawterm, even simultaneously, and exported directly or indirectly to a network. Also, as we've found especially with graphics, the internal concurrent programming environment of a virtual operating system written in C often clashes with the programming environment required by the host to access its services. It's most obvious with Apple, where Objective C is needed, but it has turned out to be true for X11 as well. In some cases, it might be convenient to take the result and make it an internal virtual device after all, when that works, but separate development initially will still be convenient.
Re: [9fans] GSOC proposal for plan9
[3]. Should avoid the patent issue of the K42 system. [Yan] For this problem, I do not have any idea right now. Do we need to propose a different solution (from K42's MCS lock), but solve the same problem (do not need to pass node data structure in the parameter)? of course the simplist version of this is allocating Qnodes internally. this can be done locklessly because held locks cannot switch Mach. alternatively, since we *can* modify the definition of the the structure Lock, MAXMACH Qnodes could be part of the lock. i'm sure that you'll have good ideas on this, too. - erik
[9fans] GSOC proposal for plan9
Dear all, I have noticed the comments of Anthony Sorace and Quanstro in my GSOC proposal. Thanks very much! Basically, there are three problems. [1]. The timeline has the time of reading related documents and source codes, but Anthony thinks it should be solved before the coding stage. [Yan] I have removed the reading stage from the timeline and use the time to write code and do some testing. [2]. I did not add the considerations of testing and measurements. [Yan] in the updated proposal, I add my idea of testing in the timeline part. Basically, I plan to write some code to stress the MCS lock in different contention degree and see whether the MCS lock works as expected. In addition, I plan to run some macro-benchmarks to test the performance of MCS lock, and compared with the original TAS (test and set) implementation. Quanstro, is that enough? [3]. Should avoid the patent issue of the K42 system. [Yan] For this problem, I do not have any idea right now. Do we need to propose a different solution (from K42's MCS lock), but solve the same problem (do not need to pass node data structure in the parameter)? Please provide comments, and I will update my proposal accordingly. Best Wishes! Yan -- Think big; Dream impossible; Make it happen.
[9fans] GSoC proposal: Ventilator or Access to host's devices
Hi everyone! I'm trying to get to work on the Ventilator project during the GSoC, and in order to have a good proposal I'm asking for some information here. Where should I start looking? Also, I have just seen this: http://www.vitanuova.com/inferno/man/2/venti.html Is it still possible to get to work on this as a SoC project? If it isn't, I may still be interested on working on Access to host's devices**, so where can I start looking with that? -- Daniel
Re: [9fans] GSOC proposal
This is really too late for the GSoC bits. But possibly of interests for later developments... On Mar 25, 2010, at 6:03 AM, yy wrote: Would such a project be interesting for this year gsoc? Is any mentor interested in Forth? I really think acme would make a great environment for Forth development. I have not used 4th except to play a bit with it, but I have spent the last months porting the Ngaro VM to Go [1], which is used to run retroForth [2] images, and I think that could be a good starting point too. [1] http://hg.4l77.com/gonga/ [2] http://retroforth.org PS: I'm CCing this to the GSoC list, but since the original message appeared here I'm replying to 9fans too. A viable environment using in Plan 9 or Inferno to develop code for arrayForth and the GA line of chips that use it would be nice. Well, nice for a few of us who may have future board designs using those chips. Getting some Forth-SIM environment for any Plan 9 $objtype would help from having to run Windows IDEs on native x86 hardware or in VMs. Additionally, flashing the GA chips from Plan 9 sure would make development decisions easier. -jas
Re: [9fans] GSOC proposal
2009/3/28 Bruce Ellis bruce.el...@gmail.com: Just a suggestion, A good forth system using acme, probably based on fgb's 4th. The goal is to conquer the Seaforth chip. I know the dev kit is US$500 but their compiler and simulator, written in forth, doesn't need hardware. And at least two 9fans have a kit. brucee Would such a project be interesting for this year gsoc? Is any mentor interested in Forth? I really think acme would make a great environment for Forth development. I have not used 4th except to play a bit with it, but I have spent the last months porting the Ngaro VM to Go [1], which is used to run retroForth [2] images, and I think that could be a good starting point too. [1] http://hg.4l77.com/gonga/ [2] http://retroforth.org PS: I'm CCing this to the GSoC list, but since the original message appeared here I'm replying to 9fans too. -- - yiyus || JGL . 4l77.com
[9fans] GSOC proposal
Just a suggestion, A good forth system using acme, probably based on fgb's 4th. The goal is to conquer the Seaforth chip. I know the dev kit is US$500 but their compiler and simulator, written in forth, doesn't need hardware. And at least two 9fans have a kit. brucee
