Re: [9fans] request for more GSoC project suggestions

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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

[9fans] request for more GSoC project suggestions

[Charles Forsyth]

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.

Re: [9fans] request for more GSoC project suggestions

[Paul Lalonde]

-----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-----

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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-----
>
>

Re: [9fans] request for more GSoC project suggestions

[erik quanstrom]

> Gogo reimplementation of cfront.

i'm pretty sure c++ has "advanced" to the point where
the cfront implementation technique is unworkable.

- erik

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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
>
>

Re: [9fans] request for more GSoC project suggestions

[Chris Brannon]

> > 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

Re: [9fans] request for more GSoC project suggestions

[Paul Lalonde]

-----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-----

Re: [9fans] request for more GSoC project suggestions

[James Tomaschke]

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.

Re: [9fans] request for more GSoC project suggestions

[Charles Forsyth]

>A modern cfront is nearly impossible.  Templates make it hella-hard.

really? how is that?

Re: [9fans] request for more GSoC project suggestions

[Paul Lalonde]

-----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-----

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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

Re: [9fans] request for more GSoC project suggestions

[erik quanstrom]

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

Re: [9fans] request for more GSoC project suggestions

[Federico G. Benavento]

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

Re: [9fans] request for more GSoC project suggestions

[erik quanstrom]

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

Re: [9fans] request for more GSoC project suggestions

[Chris Brannon]

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

Re: [9fans] request for more GSoC project suggestions

[Roman V. Shaposhnik]

[-- 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 --]

Re: [9fans] request for more GSoC project suggestions

[Paul Lalonde]

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?
>

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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

Re: [9fans] request for more GSoC project suggestions

[Roman Shaposhnik]

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.

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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?
>>
>
>
>

Re: [9fans] request for more GSoC project suggestions

[Roman Shaposhnik]

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.

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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

Re: [9fans] request for more GSoC project suggestions

[Roman Shaposhnik]

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.

Re: [9fans] request for more GSoC project suggestions

[erik quanstrom]

> 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

Re: [9fans] request for more GSoC project suggestions

[lucio]

> 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

Re: [9fans] request for more GSoC project suggestions

[Charles Forsyth]

>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.

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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
>
>
>

Re: [9fans] request for more GSoC project suggestions

[Joel C. Salomon]

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

Re: [9fans] request for more GSoC project suggestions

[lucio]

> 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

Re: [9fans] request for more GSoC project suggestions

[Juan M. Mendez]

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

Re: [9fans] request for more GSoC project suggestions

[lucio]

> 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

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

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
>
>

[9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions)

[Joel C. Salomon]

[-- 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 --]