* [9fans] request for more GSoC project suggestions @ 2009-03-25 15:16 Charles Forsyth 2009-03-25 15:06 ` Devon H. O'Dell ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Charles Forsyth @ 2009-03-25 15:16 UTC (permalink / raw) To: 9fans There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ but I think more are needed, and that it would be especially good to have a further set of useful but simpler and smaller projects. Projects need to be non-trivial for GSoC, but shouldn't be hard enough that many of us would shun them (or indeed, have shunned them). Based on my experience several years ago, I'd also look for projects that are modular, so that the set of deliverables can be extended or reduced depending how things go. That worked well for the projects I was involved with. The problem with ports of the system or device driver writing, in my experience, is that satisfying though they are, and as necessary as they might be, they are typically quite hard to supervise, and will usually be fairly difficult for relative novices. There is quite a bit to learn for most students just to get started and be productive in the programming environment, although 9vx does make that much easier. Application-level projects are typically easier to supervise because they don't need specialised equipment, and many more people on this list and elsewhere can help with plausible advice, and also help debug when students are stuck. (Advice will sometimes be contradictory, but that's not a bad lesson to learn, too.) It's quite hard to help when special hardware or kernel-level debugging is involved. Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at user-level that is done at kernel-level in other systems, that shouldn't narrow the scope much. I wrote "application-level" not just "user-level" earlier because I thought it would be good to have some interesting applications of the system. Of course, I don't mean to preclude system-level things when students are especially keen on that (as indeed I was during my school and university years). I don't know where the best place to suggest or discuss them would be, but I thought this list would reach nearly everyone interested. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 15:16 [9fans] request for more GSoC project suggestions Charles Forsyth @ 2009-03-25 15:06 ` Devon H. O'Dell 2009-03-26 5:19 ` lucio 2009-03-25 19:57 ` Paul Lalonde 2009-03-26 0:09 ` [9fans] request for more GSoC project suggestions Federico G. Benavento 2 siblings, 1 reply; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-25 15:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/25 Charles Forsyth <forsyth@terzarima.net>: [snip] > I don't know where the best place to suggest or discuss them would be, > but I thought this list would reach nearly everyone interested. I've sort of volunteered myself to webmaster the gsoc.cat-v.org page for this year's SoC, so if you have any ideas you'd like to get on there, just mail them to me, or to the plan9-gsoc mailing list and I'll get them plopped up there. I agree with your points, and I think some decent application ideas are in order. --dho ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 15:06 ` Devon H. O'Dell @ 2009-03-26 5:19 ` lucio 2009-03-26 13:18 ` Devon H. O'Dell 0 siblings, 1 reply; 34+ messages in thread From: lucio @ 2009-03-26 5:19 UTC (permalink / raw) To: 9fans > so if you have any ideas you'd like to get on > there, just mail them to me, or to the plan9-gsoc mailing list and > I'll get them plopped up there. I'm actively working on GCC from two directions: a port of the Plan 9 libraries to a cross-compilation environment under NetBSD (I have Ubuntu handy as well, so that becomes an option) and implementing ELF support in the Plan 9 kernel. The latter requires familiarity with Linuxemu which in turns provides two useful extensions besides its own value: ELF and MMAP. MMAP is so ubiquitous, someone ought to be looking into it, but it won't be me until ELF is sorted out. I have no idea whether any of these are potential GSoC projects, but anyone who wants to contribute is welcome in whatever way they like. ++L ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 5:19 ` lucio @ 2009-03-26 13:18 ` Devon H. O'Dell 2009-03-26 15:03 ` lucio 0 siblings, 1 reply; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-26 13:18 UTC (permalink / raw) To: lucio, Fans of the OS Plan 9 from Bell Labs 2009/3/26 <lucio@proxima.alt.za>: >> so if you have any ideas you'd like to get on >> there, just mail them to me, or to the plan9-gsoc mailing list and >> I'll get them plopped up there. > > I'm actively working on GCC from two directions: a port of the Plan 9 > libraries to a cross-compilation environment under NetBSD (I have > Ubuntu handy as well, so that becomes an option) and implementing ELF > support in the Plan 9 kernel. The latter requires familiarity with > Linuxemu which in turns provides two useful extensions besides its own > value: ELF and MMAP. > > MMAP is so ubiquitous, someone ought to be looking into it, but it > won't be me until ELF is sorted out. ^ > I have no idea whether any of these are potential GSoC projects, but > anyone who wants to contribute is welcome in whatever way they like. Alright, sounds good. Are you signed up as a mentor? (I'm not an admin, so I don't know). I'll add this to the ideas page; if you're interested and able to mentor, this would be a great project, I think. --dho > ++L > > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 13:18 ` Devon H. O'Dell @ 2009-03-26 15:03 ` lucio 2009-03-26 15:17 ` lucio 0 siblings, 1 reply; 34+ messages in thread From: lucio @ 2009-03-26 15:03 UTC (permalink / raw) To: 9fans > Alright, sounds good. Are you signed up as a mentor? (I'm not an > admin, so I don't know). > I'm not, but that can be arranged. > I'll add this to the ideas page; if you're interested and able to > mentor, this would be a great project, I think. I would be wary of being the sole mentor here, my theoretical knowledge is a bit thin and students may find it frustrating to deal with me alone. If we can rope in at minimum rminnich and preferably also forsyth, then I will feel a lot less unsure of my skills. ++L ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 15:03 ` lucio @ 2009-03-26 15:17 ` lucio 0 siblings, 0 replies; 34+ messages in thread From: lucio @ 2009-03-26 15:17 UTC (permalink / raw) To: lucio, 9fans > If we can rope in at minimum rminnich and preferably > also forsyth, then I will feel a lot less unsure of my skills. Or equivalent, of course; these are the one _I_ would feel most comfortable with. ++L ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 15:16 [9fans] request for more GSoC project suggestions Charles Forsyth 2009-03-25 15:06 ` Devon H. O'Dell @ 2009-03-25 19:57 ` Paul Lalonde 2009-03-25 20:12 ` Devon H. O'Dell 2009-03-25 20:40 ` James Tomaschke 2009-03-26 0:09 ` [9fans] request for more GSoC project suggestions Federico G. Benavento 2 siblings, 2 replies; 34+ messages in thread From: Paul Lalonde @ 2009-03-25 19:57 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd like to see a 3D graphics protocol. Then I could run the host on some linux or window or mac box to do the display, and run the graphics app in Plan9, or inferno, or ... And (heresy aside) I've love a way to compile C++ programs for plan9. That would give me a reason to get Plan9 up on this scary multi-core part I'm working on. Without C++ support, I can't run the principle application I need :-( Paul On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: > > There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ > but I think more are needed, and that it would be especially good > to have a further set of useful but simpler and smaller projects. > > Projects need to be non-trivial for GSoC, but shouldn't > be hard enough that many of us would shun them (or indeed, have > shunned them). > Based on my experience several years ago, > I'd also look for projects that are modular, so that the set of > deliverables can be extended > or reduced depending how things go. That worked well for the > projects I was involved with. > > The problem with ports of the system or device driver writing, in > my experience, > is that satisfying though they are, and as necessary > as they might be, they are typically quite hard to > supervise, and will usually be fairly difficult for relative novices. > There is quite a bit to learn for most students just to > get started and be productive in the programming environment, > although 9vx does make that much easier. > Application-level projects are typically easier to > supervise because they don't need specialised equipment, > and many more people on this list and elsewhere can help > with plausible advice, and also help debug when students are stuck. > (Advice will > sometimes be contradictory, but that's not a bad lesson to learn, > too.) > It's quite hard to help when special hardware or kernel-level > debugging is involved. > Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at > user-level that is done at kernel-level in other systems, that > shouldn't > narrow the scope much. I wrote "application-level" not just "user- > level" > earlier because I thought it would be good to have some > interesting applications of the system. Of course, I don't mean > to preclude system-level things when students are especially keen > on that (as indeed I was during my school and university years). > > I don't know where the best place to suggest or discuss them would be, > but I thought this list would reach nearly everyone interested. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms o+vaJtOAjx1IxDqCtWskyQY= =FvNd -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 19:57 ` Paul Lalonde @ 2009-03-25 20:12 ` Devon H. O'Dell 2009-03-25 20:19 ` erik quanstrom 2009-03-25 20:39 ` Paul Lalonde 2009-03-25 20:40 ` James Tomaschke 1 sibling, 2 replies; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-25 20:12 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/25 Paul Lalonde <plalonde@telus.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd like to see a 3D graphics protocol. Then I could run the host on some > linux or window or mac box to do the display, and run the graphics app in > Plan9, or inferno, or ... > > And (heresy aside) I've love a way to compile C++ programs for plan9. That > would give me a reason to get Plan9 up on this scary multi-core part I'm > working on. Without C++ support, I can't run the principle application I > need :-( Gogo reimplementation of cfront. > Paul > > On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: > >> >> There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ >> but I think more are needed, and that it would be especially good >> to have a further set of useful but simpler and smaller projects. >> >> Projects need to be non-trivial for GSoC, but shouldn't >> be hard enough that many of us would shun them (or indeed, have shunned >> them). >> Based on my experience several years ago, >> I'd also look for projects that are modular, so that the set of >> deliverables can be extended >> or reduced depending how things go. That worked well for the >> projects I was involved with. >> >> The problem with ports of the system or device driver writing, in my >> experience, >> is that satisfying though they are, and as necessary >> as they might be, they are typically quite hard to >> supervise, and will usually be fairly difficult for relative novices. >> There is quite a bit to learn for most students just to >> get started and be productive in the programming environment, >> although 9vx does make that much easier. >> Application-level projects are typically easier to >> supervise because they don't need specialised equipment, >> and many more people on this list and elsewhere can help >> with plausible advice, and also help debug when students are stuck. >> (Advice will >> sometimes be contradictory, but that's not a bad lesson to learn, too.) >> It's quite hard to help when special hardware or kernel-level debugging is >> involved. >> Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at >> user-level that is done at kernel-level in other systems, that shouldn't >> narrow the scope much. I wrote "application-level" not just "user-level" >> earlier because I thought it would be good to have some >> interesting applications of the system. Of course, I don't mean >> to preclude system-level things when students are especially keen >> on that (as indeed I was during my school and university years). >> >> I don't know where the best place to suggest or discuss them would be, >> but I thought this list would reach nearly everyone interested. >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > > iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms > o+vaJtOAjx1IxDqCtWskyQY= > =FvNd > -----END PGP SIGNATURE----- > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:12 ` Devon H. O'Dell @ 2009-03-25 20:19 ` erik quanstrom 2009-03-25 20:28 ` Devon H. O'Dell 2009-03-25 20:38 ` Chris Brannon 2009-03-25 20:39 ` Paul Lalonde 1 sibling, 2 replies; 34+ messages in thread From: erik quanstrom @ 2009-03-25 20:19 UTC (permalink / raw) To: 9fans > Gogo reimplementation of cfront. i'm pretty sure c++ has "advanced" to the point where the cfront implementation technique is unworkable. - erik ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:19 ` erik quanstrom @ 2009-03-25 20:28 ` Devon H. O'Dell 2009-03-25 20:38 ` Chris Brannon 1 sibling, 0 replies; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-25 20:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/25 erik quanstrom <quanstro@coraid.com>: >> Gogo reimplementation of cfront. > > i'm pretty sure c++ has "advanced" to the point where > the cfront implementation technique is unworkable. So when I say something absolutely absurd on the list, people take it seriously? I've got to work on my sense of humor here. Maybe it would have helped if I had said gogo-gadget. :( --dho > - erik > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:19 ` erik quanstrom 2009-03-25 20:28 ` Devon H. O'Dell @ 2009-03-25 20:38 ` Chris Brannon 2009-03-26 0:47 ` erik quanstrom 1 sibling, 1 reply; 34+ messages in thread From: Chris Brannon @ 2009-03-25 20:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > Gogo reimplementation of cfront. > > i'm pretty sure c++ has "advanced" to the point where > the cfront implementation technique is unworkable. The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is supposed to be very standards-compliant. [1] http://www.comeaucomputing.com -- Chris ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:38 ` Chris Brannon @ 2009-03-26 0:47 ` erik quanstrom 2009-03-26 1:10 ` Chris Brannon 0 siblings, 1 reply; 34+ messages in thread From: erik quanstrom @ 2009-03-26 0:47 UTC (permalink / raw) To: 9fans On Wed Mar 25 16:39:16 EDT 2009, cmbrannon@cox.net wrote: > > > Gogo reimplementation of cfront. > > > > i'm pretty sure c++ has "advanced" to the point where > > the cfront implementation technique is unworkable. > > The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is > supposed to be very standards-compliant. > > [1] http://www.comeaucomputing.com where do they claim this? i see a claim that they accept cfront-isms, but that's a different claim. - erik ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 0:47 ` erik quanstrom @ 2009-03-26 1:10 ` Chris Brannon 2009-03-26 2:02 ` Roman Shaposhnik 0 siblings, 1 reply; 34+ messages in thread From: Chris Brannon @ 2009-03-26 1:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Erik Quanstrom wrote: > On Wed Mar 25 16:39:16 EDT 2009, cmbrannon@cox.net wrote: > > The Comeau C++ compiler [1] uses the cfront technique, doesn't it? It is > > supposed to be very standards-compliant. > > > > [1] http://www.comeaucomputing.com > > where do they claim this? i see a claim that they > accept cfront-isms, but that's a different claim. Quoting http://comeaucomputing.com/faqs/genfaq.html#ccompiler "Input C++ code is translated into internal compiler trees and symbol tables looking nothing like C++ or C. As well, it generates an internal proprietary intermediate form. But instead of using a proprietary back end code generator, Comeau C++ 4.3.3 generates C code as its output." Isn't that what cfront did, more or less? -- Chris ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 1:10 ` Chris Brannon @ 2009-03-26 2:02 ` Roman Shaposhnik 0 siblings, 0 replies; 34+ messages in thread From: Roman Shaposhnik @ 2009-03-26 2:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mar 25, 2009, at 6:10 PM, Chris Brannon wrote: > Erik Quanstrom wrote: >> On Wed Mar 25 16:39:16 EDT 2009, cmbrannon@cox.net wrote: >>> The Comeau C++ compiler [1] uses the cfront technique, doesn't >>> it? It is >>> supposed to be very standards-compliant. >>> >>> [1] http://www.comeaucomputing.com >> >> where do they claim this? i see a claim that they >> accept cfront-isms, but that's a different claim. > > Quoting http://comeaucomputing.com/faqs/genfaq.html#ccompiler > > "Input C++ code is translated into internal compiler trees and > symbol tables > looking nothing like C++ or C. As well, > it generates an internal proprietary intermediate form. > But instead of using a proprietary back end code generator, > Comeau C++ 4.3.3 generates C code as its output." > > Isn't that what cfront did, more or less? Not really, no. In their case, I believe, C language is treated as an intermediate language. It has no traces of the Cisms of the original C++ code. It is as mangled as an assembler would be if you do g++ -S foo.cc. cfront (well, at least the original one) still preserved most of the original code (as do most of thing like cyclone, cilk, etc.). Thanks, Roman. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:12 ` Devon H. O'Dell 2009-03-25 20:19 ` erik quanstrom @ 2009-03-25 20:39 ` Paul Lalonde 2009-03-25 21:12 ` Charles Forsyth 1 sibling, 1 reply; 34+ messages in thread From: Paul Lalonde @ 2009-03-25 20:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A modern cfront is nearly impossible. Templates make it hella-hard. And generics might actually be C++'s best feature, at least in performance-code land. Paul On Mar 25, 2009, at 1:12 PM, Devon H. O'Dell wrote: > > 2009/3/25 Paul Lalonde <plalonde@telus.net>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I'd like to see a 3D graphics protocol. Then I could run the host >> on some >> linux or window or mac box to do the display, and run the graphics >> app in >> Plan9, or inferno, or ... >> >> And (heresy aside) I've love a way to compile C++ programs for >> plan9. That >> would give me a reason to get Plan9 up on this scary multi-core >> part I'm >> working on. Without C++ support, I can't run the principle >> application I >> need :-( > > Gogo reimplementation of cfront. > >> Paul >> >> On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote: >> >>> >>> There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ >>> but I think more are needed, and that it would be especially good >>> to have a further set of useful but simpler and smaller projects. >>> >>> Projects need to be non-trivial for GSoC, but shouldn't >>> be hard enough that many of us would shun them (or indeed, have >>> shunned >>> them). >>> Based on my experience several years ago, >>> I'd also look for projects that are modular, so that the set of >>> deliverables can be extended >>> or reduced depending how things go. That worked well for the >>> projects I was involved with. >>> >>> The problem with ports of the system or device driver writing, in my >>> experience, >>> is that satisfying though they are, and as necessary >>> as they might be, they are typically quite hard to >>> supervise, and will usually be fairly difficult for relative >>> novices. >>> There is quite a bit to learn for most students just to >>> get started and be productive in the programming environment, >>> although 9vx does make that much easier. >>> Application-level projects are typically easier to >>> supervise because they don't need specialised equipment, >>> and many more people on this list and elsewhere can help >>> with plausible advice, and also help debug when students are stuck. >>> (Advice will >>> sometimes be contradictory, but that's not a bad lesson to learn, >>> too.) >>> It's quite hard to help when special hardware or kernel-level >>> debugging is >>> involved. >>> Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at >>> user-level that is done at kernel-level in other systems, that >>> shouldn't >>> narrow the scope much. I wrote "application-level" not just >>> "user-level" >>> earlier because I thought it would be good to have some >>> interesting applications of the system. Of course, I don't mean >>> to preclude system-level things when students are especially keen >>> on that (as indeed I was during my school and university years). >>> >>> I don't know where the best place to suggest or discuss them >>> would be, >>> but I thought this list would reach nearly everyone interested. >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.3 (Darwin) >> >> iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms >> o+vaJtOAjx1IxDqCtWskyQY= >> =FvNd >> -----END PGP SIGNATURE----- >> >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJypaTpJeHo/Fbu1wRAvhqAKDVGdbVdtqRqT811TJ/cixYcadiPwCgy/E8 /SJh8wFz5YXgVSg570Xmlnw= =pomL -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:39 ` Paul Lalonde @ 2009-03-25 21:12 ` Charles Forsyth 2009-03-26 1:11 ` Roman V. Shaposhnik 2009-03-26 1:51 ` Paul Lalonde 0 siblings, 2 replies; 34+ messages in thread From: Charles Forsyth @ 2009-03-25 21:12 UTC (permalink / raw) To: 9fans >A modern cfront is nearly impossible. Templates make it hella-hard. really? how is that? ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 21:12 ` Charles Forsyth @ 2009-03-26 1:11 ` Roman V. Shaposhnik 2009-03-26 1:51 ` Paul Lalonde 1 sibling, 0 replies; 34+ messages in thread From: Roman V. Shaposhnik @ 2009-03-26 1:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 553 bytes --] On 03/25/09 02:12 PM, Charles Forsyth wrote: >> A modern cfront is nearly impossible. Templates make it hella-hard. >> > > really? how is that? > Everything is possible. It is software, after all. But it is not practical. The original cfront was, to some extent, a cpp(1) on steroids. AFAIR, it operated by manipulating C source code. With modern C++ things like inlines, templates and concepts operate at a level of AST. I guess one could use C for an AST representation, but that would be a pretty daring feat. Thanks, Roman. [-- Attachment #2: Type: text/html, Size: 1020 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 21:12 ` Charles Forsyth 2009-03-26 1:11 ` Roman V. Shaposhnik @ 2009-03-26 1:51 ` Paul Lalonde 2009-03-26 2:01 ` Roman Shaposhnik 2009-03-26 2:01 ` Devon H. O'Dell 1 sibling, 2 replies; 34+ messages in thread From: Paul Lalonde @ 2009-03-26 1:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs A cfront-ish approach to templates leads to hellish duplication of template-generated code in each module, and thence to even worse code bloat. Of course, my understanding of what's possible in a cfront translation is perhaps (probably) naive. Paul On 25-Mar-09, at 2:12 PM, Charles Forsyth wrote: >> A modern cfront is nearly impossible. Templates make it hella-hard. > > really? how is that? > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 1:51 ` Paul Lalonde @ 2009-03-26 2:01 ` Roman Shaposhnik 2009-03-26 2:01 ` Devon H. O'Dell 1 sibling, 0 replies; 34+ messages in thread From: Roman Shaposhnik @ 2009-03-26 2:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mar 25, 2009, at 6:51 PM, Paul Lalonde wrote: > A cfront-ish approach to templates leads to hellish duplication of > template-generated code in each module, and thence to even worse > code bloat. That's not the case, really. The compiler (well, at least the conventional one, not the one like we have on Plan9) has very little tricks up its sleeves that can help with that. The best case scenario is to generate everything into .os and hope that "de- duping" will be done by the linker. That's how COMDAT works. cfront-ish approach can do exactly the same. Thanks, Roman. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 1:51 ` Paul Lalonde 2009-03-26 2:01 ` Roman Shaposhnik @ 2009-03-26 2:01 ` Devon H. O'Dell 1 sibling, 0 replies; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-26 2:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs I'd like to note again that I was kidding about cfront <_< 2009/3/25 Paul Lalonde <plalonde@telus.net>: > A cfront-ish approach to templates leads to hellish duplication of > template-generated code in each module, and thence to even worse code bloat. > Of course, my understanding of what's possible in a cfront translation is > perhaps (probably) naive. > > Paul > > On 25-Mar-09, at 2:12 PM, Charles Forsyth wrote: > >>> A modern cfront is nearly impossible. Templates make it hella-hard. >> >> really? how is that? >> > > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 19:57 ` Paul Lalonde 2009-03-25 20:12 ` Devon H. O'Dell @ 2009-03-25 20:40 ` James Tomaschke 2009-03-25 22:48 ` Paul Lalonde 1 sibling, 1 reply; 34+ messages in thread From: James Tomaschke @ 2009-03-25 20:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Paul Lalonde wrote: > I'd like to see a 3D graphics protocol. Then I could run the host on > some linux or window or mac box to do the display, and run the graphics > app in Plan9, or inferno, or ... A port of vmgl to Plan9 would be nice for this. http://www.cs.toronto.edu/~andreslc/xen-gl/ As for native GL, I'm not sure if there is any hardware option that has enough documentation to implement a driver. I was considering digging up my old 3dfx card for a miniGL to play with. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 20:40 ` James Tomaschke @ 2009-03-25 22:48 ` Paul Lalonde 2009-03-25 23:20 ` Devon H. O'Dell 0 siblings, 1 reply; 34+ messages in thread From: Paul Lalonde @ 2009-03-25 22:48 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wouldn't even consider a native GL port; it's device driver hell for an API that I'm hoping will be extinct in the next couple of years. VMGL looks like it might be a good base. I would like to see it speak 9p though :-) Paul On Mar 25, 2009, at 1:40 PM, James Tomaschke wrote: > > Paul Lalonde wrote: >> I'd like to see a 3D graphics protocol. Then I could run the host >> on some linux or window or mac box to do the display, and run the >> graphics app in Plan9, or inferno, or ... > > A port of vmgl to Plan9 would be nice for this. > http://www.cs.toronto.edu/~andreslc/xen-gl/ > > As for native GL, I'm not sure if there is any hardware option that > has enough documentation to implement a driver. I was considering > digging up my old 3dfx card for a miniGL to play with. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFJyrSppJeHo/Fbu1wRAup1AJ0QtVGC9qs/SRfKinhWbfJnhubUYwCdHybx cOf6H3838tDouxzXEvWw1PE= =qRNo -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 22:48 ` Paul Lalonde @ 2009-03-25 23:20 ` Devon H. O'Dell 2009-03-25 23:26 ` erik quanstrom 2009-03-26 16:23 ` [9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions) Joel C. Salomon 0 siblings, 2 replies; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-25 23:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Another student I spoke to on IRC spoke of the possibility of bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. That would give us a whole bunch of different compilers. --dho ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 23:20 ` Devon H. O'Dell @ 2009-03-25 23:26 ` erik quanstrom 2009-03-26 2:03 ` Devon H. O'Dell ` (2 more replies) 2009-03-26 16:23 ` [9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions) Joel C. Salomon 1 sibling, 3 replies; 34+ messages in thread From: erik quanstrom @ 2009-03-25 23:26 UTC (permalink / raw) To: 9fans On Wed Mar 25 19:22:23 EDT 2009, devon.odell@gmail.com wrote: > Another student I spoke to on IRC spoke of the possibility of > bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. > That would give us a whole bunch of different compilers. > > --dho at the risk of being called stupid twice in one day, i have to say i don't see what the payoff would be. doing something with gcc helps with gcc-specific code. what does llvm give us? - erik ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 23:26 ` erik quanstrom @ 2009-03-26 2:03 ` Devon H. O'Dell 2009-03-26 4:43 ` erik quanstrom 2009-03-26 2:05 ` Roman Shaposhnik 2009-03-26 14:21 ` Joel C. Salomon 2 siblings, 1 reply; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-26 2:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/25 erik quanstrom <quanstro@coraid.com>: > On Wed Mar 25 19:22:23 EDT 2009, devon.odell@gmail.com wrote: >> Another student I spoke to on IRC spoke of the possibility of >> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. >> That would give us a whole bunch of different compilers. >> >> --dho > > at the risk of being called stupid twice in one day, i have to say > i don't see what the payoff would be. doing something with > gcc helps with gcc-specific code. what does llvm give us? OMG STOOPID. Just kidding, of course. I think the gist behind LLVM is that compilers can target it as a machine type, and it is able to create native binaries for its own supported machine type for anything that can run on it. So any compiler that can target LLVM would be able to target Plan 9. (Which is several of them) > - erik --dho ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 2:03 ` Devon H. O'Dell @ 2009-03-26 4:43 ` erik quanstrom 0 siblings, 0 replies; 34+ messages in thread From: erik quanstrom @ 2009-03-26 4:43 UTC (permalink / raw) To: 9fans > I think the gist behind LLVM is that compilers can target it as a > machine type, and it is able to create native binaries for its own > supported machine type for anything that can run on it. So any > compiler that can target LLVM would be able to target Plan 9. (Which > is several of them) at what point does indirection become misdirection? but writing a compiler is a small task in comparison to dealing with the platform. (writing drivers, dealing with memory, etc). how does llvm deal with that? if it doesn't, then inferno is superior by providing a virtual platform. - erik ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 23:26 ` erik quanstrom 2009-03-26 2:03 ` Devon H. O'Dell @ 2009-03-26 2:05 ` Roman Shaposhnik 2009-03-26 14:21 ` Joel C. Salomon 2 siblings, 0 replies; 34+ messages in thread From: Roman Shaposhnik @ 2009-03-26 2:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Mar 25, 2009, at 4:26 PM, erik quanstrom wrote: > On Wed Mar 25 19:22:23 EDT 2009, devon.odell@gmail.com wrote: >> Another student I spoke to on IRC spoke of the possibility of >> bootstrapping LLVM for Plan 9 on Linux and getting it to run >> natively. >> That would give us a whole bunch of different compilers. >> >> --dho > > at the risk of being called stupid twice in one day, i have to say > i don't see what the payoff would be. doing something with > gcc helps with gcc-specific code. what does llvm give us? llvm is really a lego kit for not only compiler construction, but also (as the name implies) VMs. Theoretically, it can do to Plan9 what dis did to inferno. Only on a much wider set of h/w platforms. Thanks, Roman. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 23:26 ` erik quanstrom 2009-03-26 2:03 ` Devon H. O'Dell 2009-03-26 2:05 ` Roman Shaposhnik @ 2009-03-26 14:21 ` Joel C. Salomon 2009-03-26 15:09 ` Juan M. Mendez 2 siblings, 1 reply; 34+ messages in thread From: Joel C. Salomon @ 2009-03-26 14:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Mar 25, 2009 at 7:26 PM, erik quanstrom <quanstro@coraid.com> wrote: > On Wed Mar 25 19:22:23 EDT 2009, devon.odell@gmail.com wrote: >> Another student I spoke to on IRC spoke of the possibility of >> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. >> That would give us a whole bunch of different compilers. > > at the risk of being called stupid twice in one day, i have to say > i don't see what the payoff would be. doing something with > gcc helps with gcc-specific code. what does llvm give us? Current versions of LLVM use GCC's front-end for C & C++, so porting the back-end to Plan 9 effectively gives us GCC. When clang is completed, LLVM will be GCC-compatible without including GCC code. —Joel Salomon ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 14:21 ` Joel C. Salomon @ 2009-03-26 15:09 ` Juan M. Mendez 2009-03-26 15:18 ` Devon H. O'Dell 0 siblings, 1 reply; 34+ messages in thread From: Juan M. Mendez @ 2009-03-26 15:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Maybe porting parrot (http://www.parrot.org ) to Plan9 would be an interesting Gsoc project Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. This is the list of languages at different status of support: http://www.parrot.org/languages -- http://vejeta.com/portal Fidonet: 2:345/432.2 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 15:09 ` Juan M. Mendez @ 2009-03-26 15:18 ` Devon H. O'Dell 0 siblings, 0 replies; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-26 15:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/26 Juan M. Mendez <vejeta@gmail.com>: > Maybe porting parrot (http://www.parrot.org ) to Plan9 would be an > interesting Gsoc project My co-worker is the backup org admin for Parrot (but is responsible for the Perl 6 and Parrot programs). If there's real interest here, submit a proposal for a port to Plan 9 to both projects, and we'll work something out to co-mentor. If both projects get an application, the chances of that actually happening do increase. --dho > Parrot is a virtual machine designed to efficiently compile and > execute bytecode for dynamic languages. Parrot currently hosts a > variety of language implementations in various stages of completion, > including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, > APL, and a .NET bytecode translator. > > This is the list of languages at different status of support: > http://www.parrot.org/languages > > > -- > http://vejeta.com/portal > Fidonet: 2:345/432.2 > > ^ permalink raw reply [flat|nested] 34+ messages in thread
* [9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions) 2009-03-25 23:20 ` Devon H. O'Dell 2009-03-25 23:26 ` erik quanstrom @ 2009-03-26 16:23 ` Joel C. Salomon 1 sibling, 0 replies; 34+ messages in thread From: Joel C. Salomon @ 2009-03-26 16:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1566 bytes --] Devon H. O'Dell wrote: > Another student I spoke to on IRC spoke of the possibility of > bootstrapping LLVM for Plan 9 on Linux and getting it to run natively. > That would give us a whole bunch of different compilers. Something to watch out for with such a project: The LLVM back-end for Windows does not support C++ (nicely) because of issues with exception handling; Windows provides a mechanism for stack unwinding—especially across DLL boundaries—that neither GCC nor LLVM handle well. Porting LLVM to Plan 9 may well have some of the same troubles. Those who have dealt with the GCC port can answer this: What does g++ do on Plan 9? Does it add DWARF debugging tables to the executable so that the stack can be unwound? Does it play games with setjmp/longjmp? Does it even work at all? Otherwise, a large part of an LLVM project would be a port of some exception mechanism. Does plan9port’s mach-stack(3) have any precedent in Plan 9? and is that the correct basis for exception-like stack unwinding? (I.e., a program unwinding its own stack, rather than a debugger tracing the stack back.) —Joel Salomon P.s.: I am not raising the question of whether exception handling via stack unwinding is a good idea—which has been done to death on this list; see the “Same Functions Everywhere” thread from 2003 at <http://preview.tinyurl.com/cou63b> and message 56 & responses at <http://preview.tinyurl.com/cun6vg>—just asking how to implement it under Plan 9 using the existing tools as far as possible. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 202 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-25 15:16 [9fans] request for more GSoC project suggestions Charles Forsyth 2009-03-25 15:06 ` Devon H. O'Dell 2009-03-25 19:57 ` Paul Lalonde @ 2009-03-26 0:09 ` Federico G. Benavento 2009-03-26 1:54 ` Devon H. O'Dell 2 siblings, 1 reply; 34+ messages in thread From: Federico G. Benavento @ 2009-03-26 0:09 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs hola, I think we usually ask for drivers because that's what keeps some of us away of using Plan 9 natively or in new hardware, but I also get Charles point, soo.. I'd really like to see p9p for windows and/or 9vx for windows as well. for the first, I heard somewhere that a german fellow even got acme going, but I don't know where that work is, for the latter there is also a port stalled. As for applications for Plan 9, the ones we need (read to cope with the rest of the world) are too big for a soc project, so even if I don't like gcc, a port would help on this matter. right now, one can get by running old linux binaries and linuxemu+ equis, so improving linuxemu is also a project I'm interested. just my opinion On Wed, Mar 25, 2009 at 12:16 PM, Charles Forsyth <forsyth@terzarima.net> wrote: > There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/ > but I think more are needed, and that it would be especially good > to have a further set of useful but simpler and smaller projects. > > Projects need to be non-trivial for GSoC, but shouldn't > be hard enough that many of us would shun them (or indeed, have shunned them). > Based on my experience several years ago, > I'd also look for projects that are modular, so that the set of deliverables can be extended > or reduced depending how things go. That worked well for the > projects I was involved with. > > The problem with ports of the system or device driver writing, in my experience, > is that satisfying though they are, and as necessary > as they might be, they are typically quite hard to > supervise, and will usually be fairly difficult for relative novices. > There is quite a bit to learn for most students just to > get started and be productive in the programming environment, > although 9vx does make that much easier. > Application-level projects are typically easier to > supervise because they don't need specialised equipment, > and many more people on this list and elsewhere can help > with plausible advice, and also help debug when students are stuck. (Advice will > sometimes be contradictory, but that's not a bad lesson to learn, too.) > It's quite hard to help when special hardware or kernel-level debugging is involved. > Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at > user-level that is done at kernel-level in other systems, that shouldn't > narrow the scope much. I wrote "application-level" not just "user-level" > earlier because I thought it would be good to have some > interesting applications of the system. Of course, I don't mean > to preclude system-level things when students are especially keen > on that (as indeed I was during my school and university years). > > I don't know where the best place to suggest or discuss them would be, > but I thought this list would reach nearly everyone interested. > > -- Federico G. Benavento ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 0:09 ` [9fans] request for more GSoC project suggestions Federico G. Benavento @ 2009-03-26 1:54 ` Devon H. O'Dell 2009-03-26 10:41 ` Charles Forsyth 0 siblings, 1 reply; 34+ messages in thread From: Devon H. O'Dell @ 2009-03-26 1:54 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 2009/3/25 Federico G. Benavento <benavento@gmail.com>: [snip] > As for applications for Plan 9, the ones we need (read to cope with > the rest of the world) are too big for a soc project, so even if I don't > like gcc, a port would help on this matter. Yes and no. As long as there are reasonable expectations for the projects, there is no reason an application or application suite cannot be duplicated or ported. GSoC isn't entirely about completing a project: the scope of a project may just be laying groundwork or a foundation for a later project which involves the porting. I think a lot of your sentiment about the GSoC program is a bit short sighted (based on emails in 2 threads now). > right now, one can get by running old linux binaries and linuxemu+ > equis, so improving linuxemu is also a project I'm interested. > > just my opinion Linux emulation can always use work everywhere, especially since those assholes keep changing it every chance they get. More syscalls for more glibc versions = good. FreeBSD's linux compat works great these days (so it may not be a half bad place to start looking for improvements, though, admittedly, I haven't used linuxemu on Plan 9) --dho ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [9fans] request for more GSoC project suggestions 2009-03-26 1:54 ` Devon H. O'Dell @ 2009-03-26 10:41 ` Charles Forsyth 0 siblings, 0 replies; 34+ messages in thread From: Charles Forsyth @ 2009-03-26 10:41 UTC (permalink / raw) To: 9fans >GSoC isn't entirely about completing a >project: the scope of a project may just be laying groundwork or a >foundation for a later project which involves the porting. Based on the experience last time, I think it is better to have simpler projects that are straightforward, self-contained (but modular), and can actually be completed. They should not require a lot of specialised support, or ask a student to do something we haven't normally attempted ourselves. I don't think those characteristics make a project less interesting or challenging, but they do help both with supervision and providing the satisfaction of actually having got something useful done by the end of the summer. The GSoC project is quite a public thing for a student (though last time a few seemed not to realise that), and I know that potential employers look at them. ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2009-03-26 16:23 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-25 15:16 [9fans] request for more GSoC project suggestions Charles Forsyth 2009-03-25 15:06 ` Devon H. O'Dell 2009-03-26 5:19 ` lucio 2009-03-26 13:18 ` Devon H. O'Dell 2009-03-26 15:03 ` lucio 2009-03-26 15:17 ` lucio 2009-03-25 19:57 ` Paul Lalonde 2009-03-25 20:12 ` Devon H. O'Dell 2009-03-25 20:19 ` erik quanstrom 2009-03-25 20:28 ` Devon H. O'Dell 2009-03-25 20:38 ` Chris Brannon 2009-03-26 0:47 ` erik quanstrom 2009-03-26 1:10 ` Chris Brannon 2009-03-26 2:02 ` Roman Shaposhnik 2009-03-25 20:39 ` Paul Lalonde 2009-03-25 21:12 ` Charles Forsyth 2009-03-26 1:11 ` Roman V. Shaposhnik 2009-03-26 1:51 ` Paul Lalonde 2009-03-26 2:01 ` Roman Shaposhnik 2009-03-26 2:01 ` Devon H. O'Dell 2009-03-25 20:40 ` James Tomaschke 2009-03-25 22:48 ` Paul Lalonde 2009-03-25 23:20 ` Devon H. O'Dell 2009-03-25 23:26 ` erik quanstrom 2009-03-26 2:03 ` Devon H. O'Dell 2009-03-26 4:43 ` erik quanstrom 2009-03-26 2:05 ` Roman Shaposhnik 2009-03-26 14:21 ` Joel C. Salomon 2009-03-26 15:09 ` Juan M. Mendez 2009-03-26 15:18 ` Devon H. O'Dell 2009-03-26 16:23 ` [9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions) Joel C. Salomon 2009-03-26 0:09 ` [9fans] request for more GSoC project suggestions Federico G. Benavento 2009-03-26 1:54 ` Devon H. O'Dell 2009-03-26 10:41 ` Charles Forsyth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).