Anyone porting ruby? Would anyone besides me use it? I have about five months of free time to work on projects. -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin
I was actually thinking that on my way home today. Perhaps I could
make a subset of the language - I already have a good knowledge of
implementing interpreters, so how hard would it be to make an object-
oriented language? :-)
On Nov 11, 2007, at 3:44 PM, Christopher Nielsen wrote:
> Anyone porting ruby? Would anyone besides me use it?
>
> I have about five months of free time to work on projects.
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin
On 11/11/07, Christopher Nielsen <cnielsen@pobox.com> wrote:
> Anyone porting ruby? Would anyone besides me use it?
>
depends on how far you want to dig. I think Ruby might be neat, but if
there is any one thing that a number of us think is desperately
needed, it is a blessed gcc port for plan 9 -- a gcc port that is
integrated back into the gcc tree.
Or, same thing for python. Or, sure, ruby. But what's most needed is
the port, plus, integration back into mainline. At least I think so.
ron
On Nov 11, 2007 9:28 PM, ron minnich <rminnich@gmail.com> wrote: > On 11/11/07, Christopher Nielsen <cnielsen@pobox.com> wrote: > > Anyone porting ruby? Would anyone besides me use it? > > > > depends on how far you want to dig. I think Ruby might be neat, but if > there is any one thing that a number of us think is desperately > needed, it is a blessed gcc port for plan 9 -- a gcc port that is > integrated back into the gcc tree. Anyone looked into LLVM with the gcc front end? There's a non-gcc front-end for it as well. > > Or, same thing for python. Or, sure, ruby. But what's most needed is > the port, plus, integration back into mainline. At least I think so. > > ron >
At least it needs c++ compiler to compile. This could be possible with
ported gcc/g++. but LLVM site quote many versions of gcc miscompiling
LLVM
It is nice to see gcc 4.x in the gcc for plan9 ( my guess it doesn't
exists and nobody is bothered to do it ). It would be really nice to
see LLVM on Plan9
> Anyone looked into LLVM with the gcc front end? There's a non-gcc
> front-end for it as well.
On Nov 12, 2007 7:40 AM, prem <prem.mallappa@gmail.com> wrote:
> At least it needs c++ compiler to compile. This could be possible with
> ported gcc/g++. but LLVM site quote many versions of gcc miscompiling
> LLVM
> It is nice to see gcc 4.x in the gcc for plan9 ( my guess it doesn't
> exists and nobody is bothered to do it ). It would be really nice to
> see LLVM on Plan9
Fact is gcc is a de-facto standard, and you either have it, and can
run stuff like LLVM, or you don't.
that's life.
ron
> Fact is gcc is a de-facto standard
I'm still trying to understand exactly what you mean by this.
There was talk at one time about a gcc to kenc
preprocessor, this wouldn't solve the C++ problem
but would such a thing be worth attempting?
Have the c99 additions to kenc made such a
translator irrelevnt?
Is the "problem" more the lack of g++ and perhaps
glibc than the gcc C compiler itself or am I
missing somthing.
I'm not trolling, I want to know.
-Steve
in my limited experience, converting programs that are
not excercises in how to use all the possible peculiarities
of posix are reasonably easy to get compiling under ape.
the problem is, nobody wants reasonably easy.
c++ would be very nice too, so there would be one step
less on the road towards firefox. i'm sure ron is more
interested in fortran90.
On Nov 12, 2007 9:39 PM, Steve Simon <steve@quintile.net> wrote:
> > Fact is gcc is a de-facto standard
>
> I'm still trying to understand exactly what you mean by this.
>
> There was talk at one time about a gcc to kenc
> preprocessor, this wouldn't solve the C++ problem
> but would such a thing be worth attempting?
>
> Have the c99 additions to kenc made such a
> translator irrelevnt?
>
> Is the "problem" more the lack of g++ and perhaps
> glibc than the gcc C compiler itself or am I
> missing somthing.
>
> I'm not trolling, I want to know.
>
> -Steve
>
On Nov 12, 2007, at 4:39 PM, Aki Nyrhinen wrote: > in my limited experience, converting programs that are > not excercises in how to use all the possible peculiarities > of posix are reasonably easy to get compiling under ape. > > the problem is, nobody wants reasonably easy. And yet everyone elsewhere wants easy. Did I step into another reality distortion field? > > c++ would be very nice too, so there would be one step > less on the road towards firefox. i'm sure ron is more > interested in fortran90. > People are working on it. In fact, someone said something about an update to the second edition C++ preprocessor a few days/weeks ago. Who uses Fortran 90? I haven't seen any F90 compiler in wide use; the FSF is still working with F77. Who said anything about Firefox? The guy that made abaco also ported the SpiderMonkey JavaScript engine to Plan 9, perhaps we could build off of that? And how easy would it be to add a basic CSS?
> People are working on it. In fact, someone said something about an > update to the second edition C++ preprocessor a few days/weeks ago. That was me - however I must emphasise, cfront is certinly interesting, but not very useful for compiling modern code. It could be made better (more up-to-date libraries) but this would be a significant piece of work, porting another compiler is probably a much better way to get a useful C++ compiler. If somone had the money to throw at the problem an alternative route to g++ might be the Edison Design Group C++ front end, (available from Comeau Computing, who have even implemented it as a C++ to C translator). It claims to support all the modern idioms (including g++isms). This is cheap to buy once ported ($50). Sadly the first port would cost several orders more than that. Just wishful thinking. > Who uses Fortran 90? I beleive the supercomputing crowd use it quite a bit. > Who said anything about Firefox? The guy that made abaco also ported > the SpiderMonkey JavaScript engine to Plan 9, perhaps we could build > off of that? And how easy would it be to add a basic CSS? I should let Federico speak for himself, however my understanding is this is a lot more work than you might expect. -Steve
On Mon, Nov 12, 2007 at 05:39:17PM -0500, Pietro Gagliardi wrote:
> Who uses Fortran 90? I haven't seen any F90 compiler in wide use; the
> FSF is still working with F77.
Actually, a lot of scientists seem to use Fortran 90.
Current versions of gfortran support (most of?) Fortran 95.
On Nov 12, 2007, at 6:55 PM, Charles Forsyth wrote:
>> Actually, a lot of scientists seem to use Fortran 90.
>> Current versions of gfortran support (most of?) Fortran 95.
>
> i'm hoping that eventually there will be good languages
> for scientists to use, but given that many C/C++ users migrated
> to Java, perhaps the traffic is quite often in the wrong direction.
>
> more seriously, what are the statistics for the use of programming
> systems in scientific applications?
>
Hopefully, when I finish it, my hoc will be both a mathematical and a
scientific haven. Sure, it can't compute the atomic mass of an up
quark, but it can eventually be used to calculate orbits of far-away
planetary bodies (once I learn calculus :-))
> Actually, a lot of scientists seem to use Fortran 90.
> Current versions of gfortran support (most of?) Fortran 95.
i'm hoping that eventually there will be good languages
for scientists to use, but given that many C/C++ users migrated
to Java, perhaps the traffic is quite often in the wrong direction.
more seriously, what are the statistics for the use of programming
systems in scientific applications?
On Mon, Nov 12, 2007 at 11:55:02PM +0000, Charles Forsyth wrote:
> > Actually, a lot of scientists seem to use Fortran 90.
> > Current versions of gfortran support (most of?) Fortran 95.
>
> i'm hoping that eventually there will be good languages
> for scientists to use, but given that many C/C++ users migrated
> to Java, perhaps the traffic is quite often in the wrong direction.
>
> more seriously, what are the statistics for the use of programming
> systems in scientific applications?
I haven't a clue as I don't interact much with the scientific
computing crowd. Fortran is still the de facto standard for
a variety of reasons. Despite the plethora of scripting languages,
the barriers to entry for a new programming language are really
quite high.
On Nov 13, 2007 12:39 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Nov 12, 2007, at 4:39 PM, Aki Nyrhinen wrote:
> > the problem is, nobody wants reasonably easy.
> And yet everyone elsewhere wants easy. Did I step into another
> reality distortion field?
distortion or not, i was trying to say reasonably
easy is not easy enough.
On Nov 12, 2007 2:39 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Nov 12, 2007, at 4:39 PM, Aki Nyrhinen wrote:
>
> > in my limited experience, converting programs that are
> > not excercises in how to use all the possible peculiarities
> > of posix are reasonably easy to get compiling under ape.
> >
> > the problem is, nobody wants reasonably easy.
>
> And yet everyone elsewhere wants easy. Did I step into another
> reality distortion field?
>
> >
> > c++ would be very nice too, so there would be one step
> > less on the road towards firefox. i'm sure ron is more
> > interested in fortran90.
> >
>
> People are working on it. In fact, someone said something about an
> update to the second edition C++ preprocessor a few days/weeks ago.
> Who uses Fortran 90? I haven't seen any F90 compiler in wide use; the
> FSF is still working with F77.
>
I'm pretty sure gfortran does F90...
> People are working on it. In fact, someone said something about an > update to the second edition C++ preprocessor a few days/weeks ago. > Who uses Fortran 90? I haven't seen any F90 compiler in wide use; the > FSF is still working with F77. just because it's called g77 doesn't mean it isn't f90. > Who said anything about Firefox? The guy that made abaco also ported > the SpiderMonkey JavaScript engine to Plan 9, perhaps we could build > off of that? And how easy would it be to add a basic CSS? trust me, it's never easy.
On 2007-Nov-12, at 14:39 , Pietro Gagliardi wrote:
> I haven't seen any F90 compiler in wide use; the FSF is still
> working with F77.
Solaris Sun Studio suite includes F90. And as of a few months ago
it's part of the base Solaris Express releases (along with cc, for the
first time since 1990 or so).
--lyndon
wow! if they'd never taken the c compiler out of solaris, do you think gcc would have gotten where it did? - erik
On Nov 12, 2007 6:55 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> more seriously, what are the statistics for the use of programming
> systems in scientific applications?
In school and in one or two places where I've had engineering
internships, MATLAB rules supreme. A port of Octave might possibly be
useful. (In my copious spare time, of course.)
--Joel
One of my plans after completing my hoc is to add a GUI frontend
exclusively for Plan 9 and call the resultant program hog.
On Nov 12, 2007, at 7:53 PM, Joel C. Salomon wrote:
> On Nov 12, 2007 6:55 PM, Charles Forsyth <forsyth@terzarima.net>
> wrote:
>> more seriously, what are the statistics for the use of programming
>> systems in scientific applications?
>
> In school and in one or two places where I've had engineering
> internships, MATLAB rules supreme. A port of Octave might possibly be
> useful. (In my copious spare time, of course.)
>
> --Joel
On 2007-Nov-12, at 11:39 , Steve Simon wrote:
> Is the "problem" more the lack of g++ and perhaps
> glibc than the gcc C compiler itself or am I
> missing somthing.
I find that > 90% of the problem is code that makes use of all the
__(foo)__ attribute crud in function declarations. It shouldn't be
difficult to write a tool to strip that nonsense out.
Alternatively you could teach the compilers to recognize and ignore
those constructs, but my personal preference is to just elide the bits
from the source at import. Even ignoring them lends them more
credibility than my morals allow ;-P
-lyndon
On 2007-Nov-12, at 16:52 , erik quanstrom wrote:
> wow! if they'd never taken the c compiler out of solaris,
> do you think gcc would have gotten where it did?
Nope, GCC would have died a well-deserved death.
I was so pissed off at Sun for doing this (and the follow-on effect as
all the other vendors got greedy) that I never again bought any
hardware or software from them. And this did result in them not
winning a $500K+ bid that they otherwise would probably have won.
Now that they've come to their senses, I've just signed off to buy a
pair of 4200 servers :-)
--lyndon
On Nov 12, 2007, at 7:52 PM, erik quanstrom wrote:
> wow! if they'd never taken the c compiler out of solaris,
> do you think gcc would have gotten where it did?
>
> - erik
I think the thing that got gcc where it is is Linux, because it's
probably the only tool that compiles it! Either that, or Apple's
using it in Xcode.
On 2007-Nov-12, at 16:52 , erik quanstrom wrote:
> wow! if they'd never taken the c compiler out of solaris,
> do you think gcc would have gotten where it did?
In fact, the two events that most changed the face of Unix in the 90's
were Sun's unbundling of cc and AT&T's attack on Net-1. Imagine a
world without lawyers and marketers and gcc and linux. Sigh.
--lyndon
On 2007.11.13 Lyndon Nerenberg pressed the following keys: >On 2007-Nov-12, at 11:39 , Steve Simon wrote: >I find that > 90% of the problem is code that makes use of all the >__(foo)__ attribute crud in function declarations. It shouldn't be >difficult to write a tool to strip that nonsense out. > >Alternatively you could teach the compilers to recognize and ignore >those constructs, but my personal preference is to just elide the bits >from the source at import. Even ignoring them lends them more >credibility than my morals allow ;-P A lot of GNU/Linux packages utilize gcc attributes - maybe the cleaner way is to let decide the compiler what to use or to ignore. It seems less stressful as dropping an additional pre-processor in the build chain. >-lyndon HGN
for (x in gcc/src/*.[chyl7s]) { # All this nonsense is simply to
avoid useful and/or standard things like __FILE__ or __STDC__ */
sed 's/__asm__//g
s/__extension__//g
s/__inline__//g
s/__typeof__//g
s/__restrict__//g
s/__builtin_[a-zA-Z0-9_][a-zA-Z0-9_]*//g
s/__cxa_atexit//g
s/__cxa_get_exception_ptr//g
s/__attribute__//g
s/__null//g
s/__strong//g
s/__weak//g
s/__int64//g' $x > $x^.new # keep going
# note that we need a little extra work for __attribute__
mv $x^.new $x
}
On Nov 12, 2007, at 7:59 PM, Lyndon Nerenberg wrote:
>
> On 2007-Nov-12, at 11:39 , Steve Simon wrote:
>
>> Is the "problem" more the lack of g++ and perhaps
>> glibc than the gcc C compiler itself or am I
>> missing somthing.
>
> I find that > 90% of the problem is code that makes use of all the
> __(foo)__ attribute crud in function declarations. It shouldn't be
> difficult to write a tool to strip that nonsense out.
>
> Alternatively you could teach the compilers to recognize and ignore
> those constructs, but my personal preference is to just elide the
> bits from the source at import. Even ignoring them lends them more
> credibility than my morals allow ;-P
>
> -lyndon
-----Original Message-----
From: Pietro Gagliardi <pietro10@mac.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Date: Mon, 12 Nov 2007 19:57:05 -0500
Subject: Re: [9fans] Re: Ruby port
> One of my plans after completing my hoc is to add a GUI frontend
> exclusively for Plan 9 and call the resultant program hog.
>
> On Nov 12, 2007, at 7:53 PM, Joel C. Salomon wrote:
>
> > On Nov 12, 2007 6:55 PM, Charles Forsyth <forsyth@terzarima.net>
> > wrote:
> >> more seriously, what are the statistics for the use of programming
> >> systems in scientific applications?
> >
> > In school and in one or two places where I've had engineering
> > internships, MATLAB rules supreme. A port of Octave might possibly
> be
> > useful. (In my copious spare time, of course.)
> >
> > --Joel
>
I got a few math libraries ported in my contrib that maybe you can use.
Along with a few more libraries I am trying to port. I will try to
restart an old circuit simulation project. I used octave and matlab
for some simulations for work.
At home I am trying to do the matlab stuff using p9p 8c, hoc and awk.
I would rather see more more plan9 code get ported to linux than linux
code get ported to plan9. In this light a gcc is not the best option, I
guess an 8c tools is best.
> In fact, the two events that most changed the face of Unix in the 90's
> were Sun's unbundling of cc and AT&T's attack on Net-1. Imagine a
> world without lawyers and marketers and gcc and linux. Sigh.
>
> --lyndon
on the other hand, sun's compiler^wtoolchain^whardware at the time
really did suck wind. i can remember a vax 11/780 running circles around
a 670/mp for fork(). sun's mmu was that poor.
- erik
>
> I think the thing that got gcc where it is is Linux, because it's
> probably the only tool that compiles it! Either that, or Apple's
> using it in Xcode.
gcc was well-positioned before linux came around. very early versions
of gcc had some advantages over sun's or xinu's compiler. especially
in groking prototypes and doing more careful typechecking.
that being said, to paraphrase frau prof. dr. baumann, i think in
free software, people get the tools they deserve.
- erik
On 2007-Nov-12, at 17:41 , erik quanstrom wrote:
> sun's mmu was that poor.
So gcc couldn't have helped if it wanted to.
> On 2007-Nov-12, at 17:41 , erik quanstrom wrote:
>
> > sun's mmu was that poor.
>
> So gcc couldn't have helped if it wanted to.
we never had sun's compiler for the 670/mp machines. there
was no way to compare.
- erik
On Mon, Nov 12, 2007 at 07:52:55PM -0500, erik quanstrom wrote:
> wow! if they'd never taken the c compiler out of solaris,
> do you think gcc would have gotten where it did?
(way OT at this point...)
Probably. Face it, Sun's bundled cc was only there to relink the kernel
after diddling ("tuning") its constants. Optimization was not its strong
suit.
We were already using gcc in preference to cc long before Solaris 2.0,
especially on other bloatware like X. The only thing cc was good for
by then was bootstrapping gcc.
Man, you've gotten me all weepy for gcc 1.x. How sick is that?
> On Mon, Nov 12, 2007 at 07:52:55PM -0500, erik quanstrom wrote:
> > wow! if they'd never taken the c compiler out of solaris,
> > do you think gcc would have gotten where it did?
>
> (way OT at this point...)
>
> Probably. Face it, Sun's bundled cc was only there to relink the kernel
> after diddling ("tuning") its constants. Optimization was not its strong
> suit.
>
> We were already using gcc in preference to cc long before Solaris 2.0,
> especially on other bloatware like X. The only thing cc was good for
> by then was bootstrapping gcc.
>
> Man, you've gotten me all weepy for gcc 1.x. How sick is that?
i'm all weepy. but that's because i thought at the time gcc was good software.
i was comparing it to sun's c and the travisty xinu foisted. i had no idea
what good software looked like.
a mind is like a neutrino detector. even big ones wait years for a
clueon event.
the reason for this, however, is different. it's not that the clueon
capture cross section is so small, but there are just so few of them
and so inhibitors. i believe gcc may be one of the largest clueon
flux inhibitors in the universe.
- erik
On Nov 12, 2007 11:39 AM, Steve Simon <steve@quintile.net> wrote:
> > Fact is gcc is a de-facto standard
>
> I'm still trying to understand exactly what you mean by this.
I mean that people exploit its many properties, which makes porting
code to plan 9 painful.
let's see, where's ssh2 again?
ron
AFAIK there is one more unfinished attempt to bring ssh2 to Plan9. I
am not going to mention names ;)
On Nov 14, 2007 11:05 AM, ron minnich <rminnich@gmail.com> wrote:
> On Nov 12, 2007 11:39 AM, Steve Simon <steve@quintile.net> wrote:
> > > Fact is gcc is a de-facto standard
> >
> > I'm still trying to understand exactly what you mean by this.
>
> I mean that people exploit its many properties, which makes porting
> code to plan 9 painful.
>
> let's see, where's ssh2 again?
>
> ron
>
>
Put it another way. There are THOUSANDS of tools that you can't even attempt to compile if you can't run configure. You can't run configure w/out bash. You can't build bash unless you have the gnu toolchain. It's a knot. And the only way out that I can see is gcc. ron
> Put it another way. There are THOUSANDS of tools that you can't even
> attempt to compile if you can't run configure. You can't run configure
> w/out bash. You can't build bash unless you have the gnu toolchain.
>
> It's a knot.
>
> And the only way out that I can see is gcc.
>
> ron
a good number of tools are not that hard to de-configure. i've
had to stoop to that when compiling stuff for which configure is broken.
a good percentage of the stuff configured is not required. configure
spends a lot of energy looking for spiffy optimizations that can safely
be skipped.
- erik
> Put it another way. There are THOUSANDS of tools that you can't even
> attempt to compile if you can't run configure. You can't run configure
> w/out bash. You can't build bash unless you have the gnu toolchain.
>
> It's a knot.
>
> And the only way out that I can see is gcc.
Wouldn't it be far easier to teach plan9 to grok ELF than to
change gcc in any major way or am I missing something very
large and obvious? Wouldn't be the first time.
[-- Attachment #1: Type: text/plain, Size: 282 bytes --] Talking about ports... ImageMagic 6.3.6-10 with jpeg, png, lcms, jbig...: /n/sources/contrib/fgb/magick.tgz needs: /n/sources/contrib/fgb/apelibs.tgz see /n/sources/contrib/fgb/apelibs.txt Federico G. Benavento --- /bin/fortune: There is no gift like the present. [-- Attachment #2: Type: message/rfc822, Size: 4704 bytes --] From: "ron minnich" <rminnich@gmail.com> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Re: Ruby port Date: Wed, 14 Nov 2007 11:19:46 -0800 Message-ID: <13426df10711141119s5433b14cx90615fd0c95404c4@mail.gmail.com> Put it another way. There are THOUSANDS of tools that you can't even attempt to compile if you can't run configure. You can't run configure w/out bash. You can't build bash unless you have the gnu toolchain. It's a knot. And the only way out that I can see is gcc. ron
Making binutils to grok Plan9 aout is not big and is already been done.
On Nov 14, 2007 11:36 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
>
> > Put it another way. There are THOUSANDS of tools that you can't even
> > attempt to compile if you can't run configure. You can't run configure
> > w/out bash. You can't build bash unless you have the gnu toolchain.
> >
> > It's a knot.
> >
> > And the only way out that I can see is gcc.
>
> Wouldn't it be far easier to teach plan9 to grok ELF than to
> change gcc in any major way or am I missing something very
> large and obvious? Wouldn't be the first time.
>
>
I have nothing against gcc. I have everything against the GPL. I have
no idea of Solaris' history, though.
On Nov 14, 2007, at 11:55 AM, plan9@sigint.cs.purdue.edu wrote:
> On Mon, Nov 12, 2007 at 07:52:55PM -0500, erik quanstrom wrote:
>> wow! if they'd never taken the c compiler out of solaris,
>> do you think gcc would have gotten where it did?
>
> (way OT at this point...)
>
> Probably. Face it, Sun's bundled cc was only there to relink the
> kernel
> after diddling ("tuning") its constants. Optimization was not its
> strong
> suit.
>
> We were already using gcc in preference to cc long before Solaris 2.0,
> especially on other bloatware like X. The only thing cc was good for
> by then was bootstrapping gcc.
>
> Man, you've gotten me all weepy for gcc 1.x. How sick is that?
>> attempt to compile if you can't run configure. You can't run configure
>> w/out bash. You can't build bash unless you have the gnu toolchain.
it still won't work because it expects certain things in certain places
where they never will be.
On Nov 14, 2007 8:45 PM, Pietro Gagliardi <pietro10@mac.com> wrote: > I have nothing against gcc. I have everything against the GPL. I have > no idea of Solaris' history, though. Then what are you doing in this mailing list? uriel > On Nov 14, 2007, at 11:55 AM, plan9@sigint.cs.purdue.edu wrote: > > > On Mon, Nov 12, 2007 at 07:52:55PM -0500, erik quanstrom wrote: > >> wow! if they'd never taken the c compiler out of solaris, > >> do you think gcc would have gotten where it did? > > > > (way OT at this point...) > > > > Probably. Face it, Sun's bundled cc was only there to relink the > > kernel > > after diddling ("tuning") its constants. Optimization was not its > > strong > > suit. > > > > We were already using gcc in preference to cc long before Solaris 2.0, > > especially on other bloatware like X. The only thing cc was good for > > by then was bootstrapping gcc. > > > > Man, you've gotten me all weepy for gcc 1.x. How sick is that? > >
On Wed, Nov 14, 2007 at 09:04:00PM +0100, Uriel wrote:
> On Nov 14, 2007 8:45 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> > I have nothing against gcc. I have everything against the GPL. I have
> > no idea of Solaris' history, though.
>
> Then what are you doing in this mailing list?
Last I checked, Plan 9 was not GPL'd.
> Making binutils to grok Plan9 aout is not big and is already been done.
So then what is the big problem in porting gcc to plan9?
Charles Forsyth wrote:
>>> attempt to compile if you can't run configure. You can't run configure
>>> w/out bash. You can't build bash unless you have the gnu toolchain.
>
> it still won't work because it expects certain things in certain places
> where they never will be.
Am I being naive when I ask if this could not be solved with namespaces?
The problem is that you have to go with GNU for everything. You have
to use their assembler, linker, object format, compiler and debugger.
You need two compile every Plan9 library for ?c and gcc separately.
On Nov 14, 2007 12:16 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
> > Making binutils to grok Plan9 aout is not big and is already been done.
>
> So then what is the big problem in porting gcc to plan9?
>
>
On Nov 14, 2007, at 3:16 PM, Bakul Shah wrote:
>>
> So then what is the big problem in porting gcc to plan9?
gcc was ported to Plan 9.
term% 9fs sources
term% cp /n/sources/extra/gcc/gnubin.tgz some_dir # this will take a
long time! :-)
term% cd some_dir
term% gunzip < gnubin.tgz | tar xv
term% gnubin/386/bin/gnu/gcc arguments
Everything said to you so far sums it up. Besides, many UNIX
programs can be compiled with pcc, and some of the libraries (such as
curses) are available from /n/sources/contrib). See /sys/doc/ape.ps.
Examples, you ask? pic(1) and troff(1), oh and GCC itself.
[-- Attachment #1: Type: text/plain, Size: 277 bytes --] no it's not naive. for configure, yes, that will work. unfortunately it then writes those values into the resulting .h files and makefiles and you're now stuck having always to use that name space to run the application. it's a bit like the european acquis communautaire. [-- Attachment #2: Type: message/rfc822, Size: 3869 bytes --] From: Robert William Fuller <hydrologiccycle@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: Ruby port Date: Wed, 14 Nov 2007 15:43:38 -0500 Message-ID: <473B5DFA.1020502@gmail.com> Charles Forsyth wrote: >>> attempt to compile if you can't run configure. You can't run configure >>> w/out bash. You can't build bash unless you have the gnu toolchain. > > it still won't work because it expects certain things in certain places > where they never will be. Am I being naive when I ask if this could not be solved with namespaces?
On Nov 14, 2007 11:25 AM, erik quanstrom <quanstro@coraid.com> wrote:
> a good percentage of the stuff configured is not required. configure
> spends a lot of energy looking for spiffy optimizations that can safely
> be skipped.
You're right. But it doesn't matter. People are not willing to put in the work.
The go/no go decision for Plan 9 in many cases boils down to whether
tools can be built and will run.
With zero effort. I don't like it, it's just what I've seen and heard
of from other sites.
ron
2007/11/13, Charles Forsyth <forsyth@terzarima.net>:
> > Actually, a lot of scientists seem to use Fortran 90.
> > Current versions of gfortran support (most of?) Fortran 95.
>
> i'm hoping that eventually there will be good languages
> for scientists to use, but given that many C/C++ users migrated
> to Java, perhaps the traffic is quite often in the wrong direction.
>
> more seriously, what are the statistics for the use of programming
> systems in scientific applications?
>
>
I'm just starting (this is my first year working after finishing my
studies), but I can tell you what I have seen so far is matlab,
mathematica, and a lot of excel (I think you cannot understand how I
miss awk to do simple things...)
--
- yiyus || JGL .
> On Nov 14, 2007 11:25 AM, erik quanstrom <quanstro@coraid.com> wrote:
>
> > a good percentage of the stuff configured is not required. configure
> > spends a lot of energy looking for spiffy optimizations that can safely
> > be skipped.
>
> You're right. But it doesn't matter. People are not willing to put in the work.
>
> The go/no go decision for Plan 9 in many cases boils down to whether
> tools can be built and will run.
>
> With zero effort. I don't like it, it's just what I've seen and heard
> of from other sites.
>
> ron
is a myth that anything with computers can be done with
zero effort. maintaining linux is a huge resource pig
and that task is getting harder not easier. it's just a
problem people are used to so it's not entered in the
ledger.
- erik
> > Making binutils to grok Plan9 aout is not big and is already been done.
>
> So then what is the big problem in porting gcc to plan9?
>
you first. ☺
- erik
On Nov 14, 2007, at 4:22 PM, ron minnich wrote:
> On Nov 14, 2007 11:25 AM, erik quanstrom <quanstro@coraid.com> wrote:
>
>> a good percentage of the stuff configured is not required. configure
>> spends a lot of energy looking for spiffy optimizations that can
>> safely
>> be skipped.
Configure also screws us up when it's needed. Especially when I'm
having problems compiling software because I'm missing a library I
don't want to take the time to install! DON'T DYNAMICALLY LINK. Good
thing Plan 9 don't (as far as I know).
It also introduces a complication. How automated is autotools when
you have this: see /n/sources/contrib/pietro/Autotools.png
It's how autotools works. The circles are programs you run to get a
configure file! It should be called a portability nightmare!
And how about this in the category of pointless:
Checking for C compiler...
Is that even necessary? Do you think someone compiling a program
written in C would have a C compiler on them? Oh, and when you find
out it's gcc, why does it go on to check whether or not it has
specific flags and header files - especially standard header files,
because I don't think you would need to ensure you have standard
header files anyway anymore because everyone who uses anything made
after 1990 (pretty much 99.024% of the population) use Standard C?
Why not just assume those flags and headers are there?
I once tried to contribute to AbiWord. But Compilation using
autotools held me back. And then I discovered troff, and that's what
I'm using from now on (although I might make a mm to AbiWord
converter one day). Oh how the mighty GNU have fallen.
Do the files in apelibs.tgz collide with any on the default
distribution?
On Nov 14, 2007, at 2:37 PM, Federico G. Benavento wrote:
> Talking about ports...
>
> ImageMagic 6.3.6-10 with jpeg, png, lcms, jbig...:
> /n/sources/contrib/fgb/magick.tgz
>
> needs:
> /n/sources/contrib/fgb/apelibs.tgz
> see /n/sources/contrib/fgb/apelibs.txt
>
> Federico G. Benavento
>
> ---
> /bin/fortune:
> There is no gift like the present.
>
> From: "ron minnich" <rminnich@gmail.com>
> Date: November 14, 2007 2:19:46 PM EST
> To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu>
> Subject: Re: [9fans] Re: Ruby port
> Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
>
>
> Put it another way. There are THOUSANDS of tools that you can't even
> attempt to compile if you can't run configure. You can't run configure
> w/out bash. You can't build bash unless you have the gnu toolchain.
>
> It's a knot.
>
> And the only way out that I can see is gcc.
>
> ron
>
> Do the files in apelibs.tgz collide with any on the default
> distribution?
just /sys/src/ape/lib/mkfile
On Nov 11, 2007, at 1:44 PM, Christopher Nielsen wrote:
> Anyone porting ruby? Would anyone besides me use it?
>
> I have about five months of free time to work on projects.
>
> --
> Christopher Nielsen
> "They who can give up essential liberty for temporary
> safety, deserve neither liberty nor safety." --Benjamin Franklin
>
Sorry for the late post, I have been busy with other things.
Anyway, I am working on a port of Ruby 1.8.6 p111 to Plan 9.
I have the miniruby interpreter compiled and linked. It appears
to work OK but I have not stressed it very much. I will be
working on completing the port of a statically linked Ruby
interpreter.
One feature I like about Ruby is the ability to add libraries
of code that contain C code. Ruby does this through dynamic
linking. Since Plan 9 doesn't support dynamic linking, (and I
am not suggesting that it be added to Plan 9), what is the
general consensus on how to achieve similar functionality without
resorting to dynamic linking?
Kim Shrier
hola,
> One feature I like about Ruby is the ability to add libraries
> of code that contain C code. Ruby does this through dynamic
> linking. Since Plan 9 doesn't support dynamic linking, (and I
> am not suggesting that it be added to Plan 9), what is the
> general consensus on how to achieve similar functionality without
> resorting to dynamic linking?
ron has a hacked 8c with support for dynamic loading, he did it for
python. I recently did an APE port of python with the standard 8c.
if I need/want a new module I just rebuild it, I have
/$objtype/lib/ape/libpython.a and a special mkfile in a Extra/
where I just put .c files in a dir per module, the mkfiles are smart enough
to build everything and add the init fn() calls to some initmodule()
maybe it's a bit overkill, but who knows...
lotte% ls -l /sys/src/cmd/python/Extra/
--rw-r--r-- M 241 fgb fgb 56 Nov 19 04:32 /sys/src/cmd/python/Extra/dummy.c
d-rwxr-xr-x M 241 fgb fgb 0 Dec 2 20:06 /sys/src/cmd/python/Extra/mercurial
--rw-r--r-- M 241 fgb fgb 253 Nov 19 09:36 /sys/src/cmd/python/Extra/mkfile
lotte% ls -l /sys/src/cmd/python/Extra/mercurial/
--rw-r--r-- M 241 fgb fgb 3249 Nov 19 08:03 /sys/src/cmd/python/Extra/mercurial/base85.c
--rw-r--r-- M 241 fgb fgb 7930 Nov 19 08:03 /sys/src/cmd/python/Extra/mercurial/bdiff.c
Federico G. Benavento
---
/bin/fortune:
I taught him everything he knows. Now he knows more. -Randal L. Schwartz
>ron has a hacked 8c with support for dynamic loading, he did it for
>python. I recently did an APE port of python with the standard 8c.
8c and 8l support dynamic loading. (a problem with python is that
up to and including 2.4.x they link together modules that declare
a structure incompatibly -- different offsets for the `same' fields -- which 8l detects
if set up for dynamic loading.)
> 8c and 8l support dynamic loading.
Where and how is this documented/achieved? It would be good to
understand the principles involved. Reading the source, no matter how
salubrious, is hard work unless one is already familiar with it.
++L