Re: [9fans] A newbie question...

[plan9]

On Sun, Feb 03, 2008 at 11:30:03AM +0200, [EMAIL PROTECTED] wrote:
> 
> As another example, check out graphviz.  From version 1 to version 2
> (I think) they moved from a custom configurator to the autotools.
> Beside totally losing Plan 9 portability in the bargain, it is my
> impression that they spent more effort on the autotools details than
> in improving graphviz itself.

Of course they did, that's what most FOSS projects do:

1.  Find a perfectly good software package that has been "stuck" in
version 1.x for years (meaning it's been debugged and already
does everything it needs to do)
2.  Register a SourceForge page for the "next generation" version
3.  Replace the working build system with autoconf crap
4.  Release the new package as version 2.0 (meaning 2.0 times the size)

And of course:

5.  Release version 2.1, now with ANSIfied color output!

Now you too can get the street cred of "maintaining" a well-known software
package without understanding anything about the original code.

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Joel C. Salomon <9fans@cse.psu.edu> wrote:
>On Feb 6, 2008 4:53 AM, Greg Comeau <[EMAIL PROTECTED]> wrote:
>> And my question remains about gcc, either there is or there
>> isn't a port for Plan 9, but it seems clear to me that there
>> is one, so why do people keep saying not?
>
>There is a port of GCC, but it's not maintained much and reports vary
>on how stable it is.

Ok, thanks.  That's a very different statement than what seemed
to be being said, at least recently said.

>Also, 9c-produced 'object files' (basically
>compressed assembler code) are incompatible with GCC's object files,
>so any libraries that must be shared need to be recompiled.

That's not so rare as to be a Plan 9 specific problem,
although I agree, it has issues.  Anyway, thanks again for
the clarifications.

>A '9c++' (actually 2c++, 8c++, kc++, &c.) that compiled through C,
>using the Plan 9 C compilers, should have no problems -- so long as
>the front-end doesn't rely on GCCisms or the nuttier (in the Plan 9
>viewpoint) misfeatures of C99 like dynamically-sized arrays.

That c/w/ould make sense if it does/can not support those.
(We can handle both, at least on some other OSes, so this
could be interesting.)
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Pietro Gagliardi]

The recent flame I mean, discussion on GCC was started with my  
futile attempts to compile that bloke. However, I no longer think we  
need anything POSIX, GNU, or X11, as Plan 9 already comes with most,  
if not all, of the libraries we need:

- rio(1) replaces readline (especially hold mode)
- libdraw, etc. replaces libX/liboldX/etc.
- libcontrol replaces GTK+
- libthread replaces pthreads
and countless more. However, I doubt other systems will want these  
libraries, or use plan9ports internally, so GCC will still be  
victorious in most situations.


The stab it with their steely knives,
But they just can’t kill the beast.
Either Don Henley, Glenn Frey or Don Felder

On Feb 6, 2008, at 8:32 PM, Uriel wrote:

On Feb 6, 2008 8:11 PM, Joel C. Salomon <[EMAIL PROTECTED]>  
wrote:

On Feb 6, 2008 4:53 AM, Greg Comeau <[EMAIL PROTECTED]> wrote:

And my question remains about gcc, either there is or there
isn't a port for Plan 9, but it seems clear to me that there
is one, so why do people keep saying not?


There is a port of GCC, but it's not maintained much and reports vary
on how stable it is.  Also, 9c-produced 'object files' (basically
compressed assembler code) are incompatible with GCC's object files,
so any libraries that must be shared need to be recompiled.


I have yet to see that anyone (that is not dead) has ever got the GCC
port to work at all. (Fgb spent lots of time trying to get it to go,
but to no avail).

That it is (was?) linked from the website seems to add more confusion
than anything else.

uriel

P.S.: I want to make clear that I have a deep respect for dhog and his
work, it is quite impressive what he managed to do, specially having
in mind hideousness and painfulness of the task in question.

Re: [9fans] A newbie question...

[Uriel]

On Feb 6, 2008 8:11 PM, Joel C. Salomon <[EMAIL PROTECTED]> wrote:
> On Feb 6, 2008 4:53 AM, Greg Comeau <[EMAIL PROTECTED]> wrote:
> > And my question remains about gcc, either there is or there
> > isn't a port for Plan 9, but it seems clear to me that there
> > is one, so why do people keep saying not?
>
> There is a port of GCC, but it's not maintained much and reports vary
> on how stable it is.  Also, 9c-produced 'object files' (basically
> compressed assembler code) are incompatible with GCC's object files,
> so any libraries that must be shared need to be recompiled.

I have yet to see that anyone (that is not dead) has ever got the GCC
port to work at all. (Fgb spent lots of time trying to get it to go,
but to no avail).

That it is (was?) linked from the website seems to add more confusion
than anything else.

uriel

P.S.: I want to make clear that I have a deep respect for dhog and his
work, it is quite impressive what he managed to do, specially having
in mind hideousness and painfulness of the task in question.

Re: [9fans] A newbie question...

[Joel C. Salomon]

On Feb 6, 2008 4:53 AM, Greg Comeau <[EMAIL PROTECTED]> wrote:
> And my question remains about gcc, either there is or there
> isn't a port for Plan 9, but it seems clear to me that there
> is one, so why do people keep saying not?

There is a port of GCC, but it's not maintained much and reports vary
on how stable it is.  Also, 9c-produced 'object files' (basically
compressed assembler code) are incompatible with GCC's object files,
so any libraries that must be shared need to be recompiled.

A '9c++' (actually 2c++, 8c++, kc++, &c.) that compiled through C,
using the Plan 9 C compilers, should have no problems -- so long as
the front-end doesn't rely on GCCisms or the nuttier (in the Plan 9
viewpoint) misfeatures of C99 like dynamically-sized arrays.

--Joel

Re: [9fans] A newbie question...

[erik quanstrom]

9fans.net/archive

- erik

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Roman V. Shaposhnik <9fans@cse.psu.edu> wrote:
>On Mon, 2008-02-04 at 21:51 -0500, Pietro Gagliardi wrote:
>> On Feb 4, 2008, at 9:38 PM, erik quanstrom wrote:
>> >> - C99 is still new and although it's in POSIX, not many systems have
>> >> it (Plan 9 doesn't have complete C99)
>> >
>> > c99 is 9 years old!
>> >
>> 
>> Yes, but do all compilers implement 100% of that standard?
>
>  Most of compilers are more or less 100% compatible. There's
>a part that libc has to do to and that is spotty.

There are various compiler (and libraries) with [full] support of C99,
however that's a far cry from most compilers being more or less 100%
compatible.
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Uriel <9fans@cse.psu.edu> wrote:
>> Although I keep hearing different stories about the gcc availble for
>> Plan 9 (it makes little sense to me to hear "it does not work" because
>> something had to be used to compile Plan 9 itself, etc and I figure it's
>> not being done as a cross-compiler).
>
>http://doc.cat-v.org/bell_labs/new_c_compilers/ (I don't know the
>exact date, but this was probably written in the late 80's)
>http://cm.bell-labs.com/sys/doc/compiler.html
>
>But I must be having delusions, because everyone knows there were no C
>compilers in the universe before God RMS gave us the Golden GCC.

Nope, just for whatever reason, a link to gcc for Plan 9 came up
when I looked.  Which is why I asked because
it did not make sense (including what I was told in email,
though not by Steve).
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Filipp Andronov <9fans@cse.psu.edu> wrote:
>Hmmm, may i ask a very stupid question? :)
>I have working with GCC C++ compiler and MS C++ compiler, and i
>suppose that there are another compilers in the world...
>
>But i don't known any other free compiler (yeah, MS compiler is not
>free, but in russia all MS software IS free :D). So question is, if we
>couldn't port GCC because it very big job (any other reason?), maybe
>we could port some other compiler with liberal enough licence?

That's part of what Steve was saying.

And my question remains about gcc, either there is or there
isn't a port for Plan 9, but it seems clear to me that there
is one, so why do people keep saying not?  Or is it that for
some reason on the C language part is operational?

>I'm asking because C++ is very popular language, it have some nice
>benefits (is that word right here?), and there are many software that
>was developed on it.
>Of course C++ could be very ugly in some situations, but Object
>Oriented model is very powerful and C++ is "standard" language for it.
>So modern operation system with out C++ support is something...unusual
>(i don't know right word in english, that describe what i want to say
>:D)?

Every language has problems.  Anyway, there should be no inherent
technical gotchas with C++ and Plan 9 that I know of, that is,
as compared with any other feasible/reasonable/etc OS.

>2008/2/4, Uriel <[EMAIL PROTECTED]>:
>> And when you thought it couldn't get better, from the top of
>> http://www.comeaucomputing.com
>>
>> "Bursting With So Much Language Support It Hurts!"
>>
>> Most fortune-worthy line ever.
>>
>> uriel
>>
>> On Feb 4, 2008 12:52 PM,  <[EMAIL PROTECTED]> wrote:
>> >  > because something had to be used to compile Plan 9 itself, etc and I
>> > figure it's not being done as a cross-compiler.
>> >
>> > I'm sorry my new friend but I think that's the funniest 9fans post I've
>> > ever seen, how ... but  surely you . aw come on
>> >
>> > To redeem myself I shall offer this link to one of the other C compilers
>> > that exist in the world :
>> > http://plan9.bell-labs.com/magic/man2html/1/2c
>> >
>> >
>>


-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Anant Narayanan <9fans@cse.psu.edu> wrote:
>> The fact that the late-adopters, myself included, have had previous  
>> development and/or everyday use experiences with GNU stuff and that  
>> they ask of similarities and differences, unawares of whatever  
>> animosity towards the GNU thing has been brewing in your mind  
>> through the years, should not have anything to do with their need/ 
>> want to learn about Plan 9. They do "not" need your smart-alecky  
>> quoting of Rob Pike. What they need is some guidance in their  
>> transition, regardless of their purpose or previous experiences. If  
>> you are not kind enough to help, you can at least stand by while  
>> others do that.
>
>It helps to search the archives before posting. The issues concerning  
>GNU or C++ have already been discussed several times before -  
>rekindling the flames can only bring the old-timers to respond as they  
>have.

Anybody have a URL link handy?  Thanks.
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,  <9fans@cse.psu.edu> wrote:
> > because something had to be used to compile Plan 9 itself, etc and I 
>figure it's not being done as a cross-compiler.
>
>I'm sorry my new friend but I think that's the funniest 9fans post I've 
>ever seen, how ... but  surely you . aw come on
>
>To redeem myself I shall offer this link to one of the other C compilers 
>that exist in the world :
>http://plan9.bell-labs.com/magic/man2html/1/2c

It might be funny but unfortunately does not address the point
I made from the point that Steve made.  Anyway, that aside,
I'm glad to see that link/list.  Problem is that when I tried to look
a few months ago (actually a few times but also one time from a query
from Steve in email about Comeau C++ on Plan 9) the, um, funny, thing
is that it was -- or at least seemed -- pretty prominent on the site
that gcc was available for Plan 9.  Perhaps due to my unfamiliarity with
the Plan 9 site, I could not easily find the above link, despite feeling
that I was surprised that the Plan 9 team either used gcc or switched
to it not that they couldn't do so, but it seemed to me that when
I originally heard of Plan 9 years ago it was using their own compiler
and I was surprised to feel that wasn't necessarily the case anymore.
Obviously the link corrects that thinking, thanks.
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Federico G. Benavento]

well, I don't get the difference, we have a bunch of standards, my limited
understanding is that now these .org's have joined forces, and
everything gets messy, at least for me.

for instance, APE has lot's of headers with the feature test macro
_POSIX_SOURCE, which has been superseded by _POSIX_C_SOURCE,
which should be the same as _XOPEN_SOURCE == 600, which in turn
is compliant with ISO C!

so, I really don't get this dance, anyways there is a contrib package in
my sources dir "posix-man" with the "posix"/xopen/ieee man pages,
sections 0 and 3.

http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_02.html

On Feb 4, 2008 11:26 PM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> Some other reasons:
> - Some systems (read: Linux) do not have pthreads
> - What if I said I'm running GCC on Microsoft Xenix? Is that POSIX-
> compliant?
> - Curses is not POSIX. It's Single Unix Spec, though.
> - C99 is still new and although it's in POSIX, not many systems have
> it (Plan 9 doesn't have complete C99)
>
>
> On Feb 4, 2008, at 9:23 PM, David Arnold wrote:
>
> > On 03/02/2008, at 8:29 PM, Lyndon Nerenberg wrote:
> >
> >> Autoconf is nothing but a stinking rotten corpse that lives only
> >> because the cult of GNU adherents cannot (no, refuse to) grok the
> >> concept of POSIX.
> >
> > the problem with POSIX is that it doesn't specify enough.
> >
> > for instance, if you have to write some code to list the network
> > interfaces on a (*nix) machine, you have some that provide a
> > specific function to do so (getifaddrs), some where you should use
> > SIOCGIFCONF, another where SIOCGLIFCONF is better and one where
> > your best bet is to hope the /proc filesystem is mounted and read
> > from that.
> >
> > POSIX doesn't help for things like this.  and autoconf, for all its
> > failings, does.
> >
> >
> >
> > d
> >
>
>



-- 
Federico G. Benavento

Re: [9fans] A newbie question...

[Roman V. Shaposhnik]

On Mon, 2008-02-04 at 21:51 -0500, Pietro Gagliardi wrote:
> On Feb 4, 2008, at 9:38 PM, erik quanstrom wrote:
> 
> >> Some other reasons:
> >> - Some systems (read: Linux) do not have pthreads
> >
> > incorrect. http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
> >
> 
> Is that integrated into the Linux source code tree or an add-on?
 
  It is 100% integrated into 2.6.

> 
> >> - C99 is still new and although it's in POSIX, not many systems have
> >> it (Plan 9 doesn't have complete C99)
> >
> > c99 is 9 years old!
> >
> 
> Yes, but do all compilers implement 100% of that standard?

  Most of compilers are more or less 100% compatible. There's
a part that libc has to do to and that is spotty.

Thanks,
Roman.

Re: [9fans] A newbie question...

[Pietro Gagliardi]

On Feb 4, 2008, at 9:38 PM, erik quanstrom wrote:


Some other reasons:
- Some systems (read: Linux) do not have pthreads


incorrect. http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library



Is that integrated into the Linux source code tree or an add-on?


- C99 is still new and although it's in POSIX, not many systems have
it (Plan 9 doesn't have complete C99)


c99 is 9 years old!



Yes, but do all compilers implement 100% of that standard?


- erik

Re: [9fans] A newbie question...

[erik quanstrom]

> Some other reasons:
> - Some systems (read: Linux) do not have pthreads

incorrect. http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library

> - C99 is still new and although it's in POSIX, not many systems have  
> it (Plan 9 doesn't have complete C99)

c99 is 9 years old!

- erik

Re: [9fans] A newbie question...

[erik quanstrom]

> On 03/02/2008, at 8:29 PM, Lyndon Nerenberg wrote:
> 
> > Autoconf is nothing but a stinking rotten corpse that lives only  
> > because the cult of GNU adherents cannot (no, refuse to) grok the  
> > concept of POSIX.
> 
> the problem with POSIX is that it doesn't specify enough.
> 
> for instance, if you have to write some code to list the network  
> interfaces on a (*nix) machine, you have some that provide a specific  
> function to do so (getifaddrs), some where you should use  
> SIOCGIFCONF, another where SIOCGLIFCONF is better and one where your  
> best bet is to hope the /proc filesystem is mounted and read from that.
> 
> POSIX doesn't help for things like this.  and autoconf, for all its  
> failings, does.

sometimes.  you should really look at how russ did p9p.  he's delt
with with exactly this problem by writing a small amount of code
and simply detecting the os in the makefile.  there is very little
os-dependent code in p9p and it is easy to follow what gets
compiled when.

(for those following along at home, src/libip/[A-Z]*.c)

- erik

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Some other reasons:
- Some systems (read: Linux) do not have pthreads
- What if I said I'm running GCC on Microsoft Xenix? Is that POSIX- 
compliant?

- Curses is not POSIX. It's Single Unix Spec, though.
- C99 is still new and although it's in POSIX, not many systems have  
it (Plan 9 doesn't have complete C99)


On Feb 4, 2008, at 9:23 PM, David Arnold wrote:


On 03/02/2008, at 8:29 PM, Lyndon Nerenberg wrote:

Autoconf is nothing but a stinking rotten corpse that lives only  
because the cult of GNU adherents cannot (no, refuse to) grok the  
concept of POSIX.


the problem with POSIX is that it doesn't specify enough.

for instance, if you have to write some code to list the network  
interfaces on a (*nix) machine, you have some that provide a  
specific function to do so (getifaddrs), some where you should use  
SIOCGIFCONF, another where SIOCGLIFCONF is better and one where  
your best bet is to hope the /proc filesystem is mounted and read  
from that.


POSIX doesn't help for things like this.  and autoconf, for all its  
failings, does.




d

Re: [9fans] A newbie question...

[David Arnold]

On 03/02/2008, at 8:29 PM, Lyndon Nerenberg wrote:

Autoconf is nothing but a stinking rotten corpse that lives only  
because the cult of GNU adherents cannot (no, refuse to) grok the  
concept of POSIX.


the problem with POSIX is that it doesn't specify enough.

for instance, if you have to write some code to list the network  
interfaces on a (*nix) machine, you have some that provide a specific  
function to do so (getifaddrs), some where you should use  
SIOCGIFCONF, another where SIOCGLIFCONF is better and one where your  
best bet is to hope the /proc filesystem is mounted and read from that.


POSIX doesn't help for things like this.  and autoconf, for all its  
failings, does.




d

Re: Re: [9fans] A newbie question...

[Michael Andronov]

Checking the archives - definitely a useful step, and should be considered
as step #1 probably in all forums...

Saying that,  I tried it myself. I have spent some time on web trying to
find "C++ and Plan 9 history"...
The most common archive access, I managed to find, is:
   http://9fans.net/archive/
with an option of google search through... I tried that with 'C++ Plan9'
and indeed got  multiple pages from archive... most of which were
interesting from historic point of view, but not too useful from
understanding of what has been done, what has not been done, why, etc...

The point is that above mentioned way to search archive... is not too
useful... If somebody can advise a better way for pre-screening archives,
the advice would be highly appreciated.

Another point is that before I asked the question about c++ under plan 9 as
one the newbies questions a couple of weeks ago ( just before Philipp picked
up the ball), the archive has been searched indeed...  So, Anant  wish is
already granted. :)

Finally, thanks again for all comments and nice discussion on the topic.



On Feb 4, 2008 2:22 PM, Skip Tavakkolian <[EMAIL PROTECTED]> wrote:

> checking the 9fans archives is a good place to start.  many topics
> have already been discussed in great detail.  it also gives new 9fans
> an idea of who to pay attention to and who to ignore.
>
> > On Mon, 04 Feb 2008 13:01:49 -, Uriel <[EMAIL PROTECTED]> wrote:
> >
> >> If you want roman numerals, you know where to find them...
> >>
> >> Inferno... and I hope the shock will send you all the way to the 9fans
> >> archives rather than repeating the same path that has been trodden a
> >> billion times before.
> >>
> >> Some 20 years 'suddenly'...
> >>
> >> uriel
> >
> > I wonder if you are bitter or something about Plan 9, or the people who
> > are trying to learn about it. Because you seem to be trying your best to
> > deter them. What is an "old path" to you, is "the new way" to us, the
> > hobbyists among us particularly, and we need some incentive, some
> > supportive character perhaps, to encourage us along the way.
> >
> > The fact that the late-adopters, myself included, have had previous
> > development and/or everyday use experiences with GNU stuff and that they
> > ask of similarities and differences, unawares of whatever animosity
> > towards the GNU thing has been brewing in your mind through the years,
> > should not have anything to do with their need/want to learn about Plan
> 9.
> > They do "not" need your smart-alecky quoting of Rob Pike. What they need
> > is some guidance in their transition, regardless of their purpose or
> > previous experiences. If you are not kind enough to help, you can at
> least
> > stand by while others do that.
> >
> > The above is not "ad hominem," by the way. I do not mean it to be so, in
> > the least. I am only trying to point out my not-so-positive impression
> of
> > your post.
> >
> > --
> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

When I started Plan 9, I was actually happy that some of the tools I  
wanted (grap, prof) were already available. I wanted to try GCC to  
try to port a web browser, but Abaco is growing fast, and I'll stick  
with that. I'm already porting pico, and that's in my contrib directory.


On Feb 4, 2008, at 11:06 AM, Filipp Andronov wrote:


If you (not *we*) want to port something port it and let us know when
it's done.
sorry, it my mistake, i do not mean that all community should go  
and port GCC :)


The pattern of "I've just downloaded Plan9 and I want my old  
tools" is
very common and we just kind of ignore them :) except for the anti- 
GNU

troll responses.

Ok, i already figure out this. I was not right(?) when start this
discussion if there is no C++ in Plan9, that there are some reasons
for that :)

Thanks to all, i'm really sorry if i disturb anyone with this  
discasion ))



2008/2/4, Alf <[EMAIL PROTECTED]>:

Hi,

if we
couldn't port GCC because it very big job (any other reason?), maybe
we could port some other compiler with liberal enough licence?



If you (not *we*) want to port something port it and let us know when
it's done.
The process goes like this :
"I've done some working code for my  C++ port, it's in my
contrib directory if someone wants to have a go with it"


I'm asking because C++ is very popular language,

This is Plan 9, popularity isn't very high on the list.

The reason there is no native C++ compiler is because of it's  
*lack* of

popularity in the Plan 9 community, both historically and currently.

The pattern of "I've just downloaded Plan9 and I want my old  
tools" is
very common and we just kind of ignore them :) except for the anti- 
GNU

troll responses.

You'll (eventually) notice that *most* of the long time Plan 9 users
don't even join in the discussion, no doubt smiling a "seen it all
before" smile before pressing Del

Re: Re: [9fans] A newbie question...

[Skip Tavakkolian]

checking the 9fans archives is a good place to start.  many topics
have already been discussed in great detail.  it also gives new 9fans
an idea of who to pay attention to and who to ignore.

> On Mon, 04 Feb 2008 13:01:49 -, Uriel <[EMAIL PROTECTED]> wrote:
> 
>> If you want roman numerals, you know where to find them...
>>
>> Inferno... and I hope the shock will send you all the way to the 9fans
>> archives rather than repeating the same path that has been trodden a
>> billion times before.
>>
>> Some 20 years 'suddenly'...
>>
>> uriel
> 
> I wonder if you are bitter or something about Plan 9, or the people who  
> are trying to learn about it. Because you seem to be trying your best to  
> deter them. What is an "old path" to you, is "the new way" to us, the  
> hobbyists among us particularly, and we need some incentive, some  
> supportive character perhaps, to encourage us along the way.
> 
> The fact that the late-adopters, myself included, have had previous  
> development and/or everyday use experiences with GNU stuff and that they  
> ask of similarities and differences, unawares of whatever animosity  
> towards the GNU thing has been brewing in your mind through the years,  
> should not have anything to do with their need/want to learn about Plan 9.  
> They do "not" need your smart-alecky quoting of Rob Pike. What they need  
> is some guidance in their transition, regardless of their purpose or  
> previous experiences. If you are not kind enough to help, you can at least  
> stand by while others do that.
> 
> The above is not "ad hominem," by the way. I do not mean it to be so, in  
> the least. I am only trying to point out my not-so-positive impression of  
> your post.
> 
> -- 
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] A newbie question...

[Steve Simon]

> The reason there is no native C++ compiler is because of it's *lack* of
> popularity in the Plan 9 community, both historically and currently.

"We don't need a C++ compiler because everything is written in C" is just a
self-fulfilling prophecy.

I would really like to be able to compile some large C++ apps and use,
them. I have no interest in writing plan9 versions, the plan9 stuff is what
I want to use them _for_, I just want some tools which happen to be
written in C++.

-Steve

Re: [9fans] A newbie question...

[Filipp Andronov]

> If you (not *we*) want to port something port it and let us know when
> it's done.
sorry, it my mistake, i do not mean that all community should go and port GCC :)

> The pattern of "I've just downloaded Plan9 and I want my old tools" is
> very common and we just kind of ignore them :) except for the anti-GNU
> troll responses.
Ok, i already figure out this. I was not right(?) when start this
discussion if there is no C++ in Plan9, that there are some reasons
for that :)

Thanks to all, i'm really sorry if i disturb anyone with this discasion ))


2008/2/4, Alf <[EMAIL PROTECTED]>:
> Hi,
> > if we
> > couldn't port GCC because it very big job (any other reason?), maybe
> > we could port some other compiler with liberal enough licence?
> >
> >
> If you (not *we*) want to port something port it and let us know when
> it's done.
> The process goes like this :
> "I've done some working code for my  C++ port, it's in my
> contrib directory if someone wants to have a go with it"
>
> > I'm asking because C++ is very popular language,
> This is Plan 9, popularity isn't very high on the list.
>
> The reason there is no native C++ compiler is because of it's *lack* of
> popularity in the Plan 9 community, both historically and currently.
>
> The pattern of "I've just downloaded Plan9 and I want my old tools" is
> very common and we just kind of ignore them :) except for the anti-GNU
> troll responses.
>
> You'll (eventually) notice that *most* of the long time Plan 9 users
> don't even join in the discussion, no doubt smiling a "seen it all
> before" smile before pressing Del
>
>
>
>
>

Re: [9fans] A newbie question...

[Alf]

Hi,

if we
couldn't port GCC because it very big job (any other reason?), maybe
we could port some other compiler with liberal enough licence?

  
If you (not *we*) want to port something port it and let us know when 
it's done.

The process goes like this :
   "I've done some working code for my  C++ port, it's in my 
contrib directory if someone wants to have a go with it"



I'm asking because C++ is very popular language,

This is Plan 9, popularity isn't very high on the list.

The reason there is no native C++ compiler is because of it's *lack* of 
popularity in the Plan 9 community, both historically and currently.


The pattern of "I've just downloaded Plan9 and I want my old tools" is 
very common and we just kind of ignore them :) except for the anti-GNU 
troll responses.


You'll (eventually) notice that *most* of the long time Plan 9 users 
don't even join in the discussion, no doubt smiling a "seen it all 
before" smile before pressing Del

Re: [9fans] A newbie question...

[Martin Neubauer]

* Anant Narayanan ([EMAIL PROTECTED]) wrote:
> >The fact that the late-adopters, myself included, have had previous  
> >development and/or everyday use experiences with GNU stuff and that  
> >they ask of similarities and differences, unawares of whatever  
> >animosity towards the GNU thing has been brewing in your mind  
> >through the years, should not have anything to do with their need/ 
> >want to learn about Plan 9. They do "not" need your smart-alecky  
> >quoting of Rob Pike. What they need is some guidance in their  
> >transition, regardless of their purpose or previous experiences. If  
> >you are not kind enough to help, you can at least stand by while  
> >others do that.
> 
> It helps to search the archives before posting. The issues concerning  
> GNU or C++ have already been discussed several times before -  
> rekindling the flames can only bring the old-timers to respond as they  
> have.
> 
> Cheers,
> Anant

Another issue is the implicit assumption that a new environment which
doesn't provide all the familiar things one is grown accustomed to is
automatically defective. It's actually not that hard to just get to know
things for a few weeks (Plan 9 really is pretty accessible) and then attempt
to tackle usability issues that have arisen rather than trying to recreate a
linux environment (particularly as there already is a perfectly adequate
linux environment out there - it's called linux.) Perhaps Andrzej
Rosłanowski put it best (speaking about set theory, though): ``If you want
to read mathematics, first learn its language, get educated, don't complain
about your willies.''

Martin

Re: [9fans] A newbie question...

[Eris Discordia]

On Mon, 04 Feb 2008 13:59:41 -, Anant Narayanan <[EMAIL PROTECTED]> wrote:

It helps to search the archives before posting. The issues concerning  
GNU or C++ have already been discussed several times before - rekindling  
the flames can only bring the old-timers to respond as they have.


Cheers,
Anant


You are in the right, or rather you would have been in the right were the  
original post about the "aesthetical" aspects of the GNU project and/or  
C++, or whether the GNU philosophy is sound. However, Filipp Andronov  
asked about the development options available on Plan 9, how they compared  
to what she/he has already seen, and whether there were equivalents to  
lighten his burden of porting something to Plan 9. A perfectly OK  
question, that can, and even should, be asked every once in a while.


What she/he got from Uriel was this:

GNU is bad...

a. ... because it is not Plan 9.
b. ... because I think so.
c. ... because it has loyal followers.
d. ... because it created autoconf.
e. ... because it is Not UNIX.
f. ... because it has popularized a certain toolchain.
g. ... because it does not measure up to Bell Labs in some respect.

Now, these may be valid or not, but they are certainly irrelevant. And  
Filipp Andronov said that:


On Sun, 03 Feb 2008 08:44:57 -, Filipp Andronov  
<[EMAIL PROTECTED]> wrote:



Hmmm, my question was not about new ideological war "GNU vs Plan9".


Other people posted much better, and more helpful, responses, cf.,

On Mon, 04 Feb 2008 09:46:20 -, <[EMAIL PROTECTED]> wrote:


C++ has not been included in Plan 9 since the third edition, but the
source code is available, and Steve Simon has made some updates.
Once you have abaco the way I said to get it, you also have Federico
Benavento's contrib system. With it, all you need is
contrib/install steve/cfront
Otherwise, get contrib with
/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
and then do the above. Then, to compile a C++ program:
c++/8c x.C # considering .C is the C++ extension
c++/8l -o x x.8
The one thing: don't use
#include 
using namespace std;
You will need
#include 
which does that for you.


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] A newbie question...

[Anant Narayanan]

The fact that the late-adopters, myself included, have had previous  
development and/or everyday use experiences with GNU stuff and that  
they ask of similarities and differences, unawares of whatever  
animosity towards the GNU thing has been brewing in your mind  
through the years, should not have anything to do with their need/ 
want to learn about Plan 9. They do "not" need your smart-alecky  
quoting of Rob Pike. What they need is some guidance in their  
transition, regardless of their purpose or previous experiences. If  
you are not kind enough to help, you can at least stand by while  
others do that.


It helps to search the archives before posting. The issues concerning  
GNU or C++ have already been discussed several times before -  
rekindling the flames can only bring the old-timers to respond as they  
have.


Cheers,
Anant

Re: Re: [9fans] A newbie question...

[Eris Discordia]

On Mon, 04 Feb 2008 13:01:49 -, Uriel <[EMAIL PROTECTED]> wrote:


If you want roman numerals, you know where to find them...

Inferno... and I hope the shock will send you all the way to the 9fans
archives rather than repeating the same path that has been trodden a
billion times before.

Some 20 years 'suddenly'...

uriel


I wonder if you are bitter or something about Plan 9, or the people who  
are trying to learn about it. Because you seem to be trying your best to  
deter them. What is an "old path" to you, is "the new way" to us, the  
hobbyists among us particularly, and we need some incentive, some  
supportive character perhaps, to encourage us along the way.


The fact that the late-adopters, myself included, have had previous  
development and/or everyday use experiences with GNU stuff and that they  
ask of similarities and differences, unawares of whatever animosity  
towards the GNU thing has been brewing in your mind through the years,  
should not have anything to do with their need/want to learn about Plan 9.  
They do "not" need your smart-alecky quoting of Rob Pike. What they need  
is some guidance in their transition, regardless of their purpose or  
previous experiences. If you are not kind enough to help, you can at least  
stand by while others do that.


The above is not "ad hominem," by the way. I do not mean it to be so, in  
the least. I am only trying to point out my not-so-positive impression of  
your post.


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Re: [9fans] A newbie question...

[Uriel]

2008/2/4 Filipp Andronov <[EMAIL PROTECTED]>:
> > Reading 9fans mail list archives you will notice C++ and the "object 
> > oriented model" is not > much appreciated, there are a lot of references 
> > (including great fortunes entries) about this > topic.
> Yeah, i have notice that, but from my point of view, there are very
> many software where object oriented model is perfect way. GUI toolkit
> for example, or file system. I didn't see Plan9 file systems sources
> yet, but linux VFS object oriented and some proprietary database vfs,
> that i have seen are also object oriented. In fact all this stuff was
> written in C, where you have pointers to functions in structures, but
> it would be much simple to develop it with full OO support.

If you want roman numerals, you know where to find them...


> > probably you could say plan9 is not "typical" in this aspect.
> I mean that when you get some operation system and then you are notice
> that it has no C++  (or even worse, C) environment the first filing is
> shock :))

Inferno... and I hope the shock will send you all the way to the 9fans
archives rather than repeating the same path that has been trodden a
billion times before.


> To say the truth, when i've heard about Plan9 at first time, i have
> expect meetings with GCC and it was realy shock for me to see new C
> compile and no C++ support.
> Now i'm understand that it was stupid, but first feeling...No IDE for
> development, no C++ support, no  GCC environment, no autotools...It is
> not bad at all, but it was suddenly :)

Some 20 years 'suddenly'...

uriel

Re: Re: [9fans] A newbie question...

[Filipp Andronov]

> Reading 9fans mail list archives you will notice C++ and the "object oriented 
> model" is not > much appreciated, there are a lot of references (including 
> great fortunes entries) about this > topic.
Yeah, i have notice that, but from my point of view, there are very
many software where object oriented model is perfect way. GUI toolkit
for example, or file system. I didn't see Plan9 file systems sources
yet, but linux VFS object oriented and some proprietary database vfs,
that i have seen are also object oriented. In fact all this stuff was
written in C, where you have pointers to functions in structures, but
it would be much simple to develop it with full OO support.

> Search for the discussions, i think there has been other attemps to build a 
> c++
> environment, (Steve got cfront working, take a look at the contrib software 
> section of the
> wiki)
I does not seen it yet, but cfront is not "modern C++" compiler as far
as i know. So i think that many software that was written with full
C++ features will no work with cfront compiler. Of course i don't know
for sure, and i will explore this later (as far as ьн Plan9 will fly
:D)

> there is people who will love to have a c++ environment, but the preferred 
> way is the plan9 > one, which implies no c++.
Hmm, i think that c++ have right for live in Plan9, just because it
will be very hard to port some soft without it. Of course it is
possible in theory redevelop all modern software stack from
scratch...but in practice it is not something that people could do )

> probably you could say plan9 is not "typical" in this aspect.
I mean that when you get some operation system and then you are notice
that it has no C++  (or even worse, C) environment the first filing is
shock :))

To say the truth, when i've heard about Plan9 at first time, i have
expect meetings with GCC and it was realy shock for me to see new C
compile and no C++ support.
Now i'm understand that it was stupid, but first feeling...No IDE for
development, no C++ support, no  GCC environment, no autotools...It is
not bad at all, but it was suddenly :)


2008/2/4, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hola,
>
> Reading 9fans mail list archives you will notice C++ and the "object oriented 
> model" is not much appreciated, there are a lot of references (including 
> great fortunes entries) about this topic.
>
> Search for the discussions, i think there has been other attemps to build a 
> c++ environment, (Steve got cfront working, take a look at the contrib 
> software section of the wiki)
>
> there is people who will love to have a c++ environment, but the preferred 
> way is the plan9 one, which implies no c++.
>
>
> >So modern operation system with out C++ support is something...unusual
> >(i don't know right word in english, that describe what i want to say
> >:D)?
> >
>
> probably you could say plan9 is not "typical" in this aspect.
>
> slds.
>
> gabi
>

Re: Re: [9fans] A newbie question...

[gdiaz]

Hola,

Reading 9fans mail list archives you will notice C++ and the "object oriented 
model" is not much appreciated, there are a lot of references (including great 
fortunes entries) about this topic.

Search for the discussions, i think there has been other attemps to build a c++ 
environment, (Steve got cfront working, take a look at the contrib software 
section of the wiki)

there is people who will love to have a c++ environment, but the preferred way 
is the plan9 one, which implies no c++.


>So modern operation system with out C++ support is something...unusual
>(i don't know right word in english, that describe what i want to say
>:D)?
>

probably you could say plan9 is not "typical" in this aspect.

slds.

gabi

Re: [9fans] A newbie question...

[Filipp Andronov]

Hmmm, may i ask a very stupid question? :)
I have working with GCC C++ compiler and MS C++ compiler, and i
suppose that there are another compilers in the world...

But i don't known any other free compiler (yeah, MS compiler is not
free, but in russia all MS software IS free :D). So question is, if we
couldn't port GCC because it very big job (any other reason?), maybe
we could port some other compiler with liberal enough licence?

I'm asking because C++ is very popular language, it have some nice
benefits (is that word right here?), and there are many software that
was developed on it.
Of course C++ could be very ugly in some situations, but Object
Oriented model is very powerful and C++ is "standard" language for it.
So modern operation system with out C++ support is something...unusual
(i don't know right word in english, that describe what i want to say
:D)?

2008/2/4, Uriel <[EMAIL PROTECTED]>:
> And when you thought it couldn't get better, from the top of
> http://www.comeaucomputing.com
>
> "Bursting With So Much Language Support It Hurts!"
>
> Most fortune-worthy line ever.
>
> uriel
>
> On Feb 4, 2008 12:52 PM,  <[EMAIL PROTECTED]> wrote:
> >  > because something had to be used to compile Plan 9 itself, etc and I
> > figure it's not being done as a cross-compiler.
> >
> > I'm sorry my new friend but I think that's the funniest 9fans post I've
> > ever seen, how ... but  surely you . aw come on
> >
> > To redeem myself I shall offer this link to one of the other C compilers
> > that exist in the world :
> > http://plan9.bell-labs.com/magic/man2html/1/2c
> >
> >
>

Re: [9fans] A newbie question...

[Uriel]

And when you thought it couldn't get better, from the top of
http://www.comeaucomputing.com

"Bursting With So Much Language Support It Hurts!"

Most fortune-worthy line ever.

uriel

On Feb 4, 2008 12:52 PM,  <[EMAIL PROTECTED]> wrote:
>  > because something had to be used to compile Plan 9 itself, etc and I
> figure it's not being done as a cross-compiler.
>
> I'm sorry my new friend but I think that's the funniest 9fans post I've
> ever seen, how ... but  surely you . aw come on
>
> To redeem myself I shall offer this link to one of the other C compilers
> that exist in the world :
> http://plan9.bell-labs.com/magic/man2html/1/2c
>
>

Re: [9fans] A newbie question...

[Uriel]

> Although I keep hearing different stories about the gcc availble for
> Plan 9 (it makes little sense to me to hear "it does not work" because
> something had to be used to compile Plan 9 itself, etc and I figure it's
> not being done as a cross-compiler).

http://doc.cat-v.org/bell_labs/new_c_compilers/ (I don't know the
exact date, but this was probably written in the late 80's)
http://cm.bell-labs.com/sys/doc/compiler.html

But I must be having delusions, because everyone knows there were no C
compilers in the universe before God RMS gave us the Golden GCC.

And of course ken never did anything after writing ed... not that
anyone remembers ed anymore, the other day I found the Debian
installer doesn't have ed... but it has nano! oh joy of progress! and
if the linux tty gets seriously confused, oh, nano is so much more
effective at filling your screen with funny characters!

uriel

> --
> Greg Comeau / 4.3.9 with C++0xisms now in beta!
> Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
> World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
> Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
>

Re: [9fans] A newbie question...

[mattmobile]

> because something had to be used to compile Plan 9 itself, etc and I 
figure it's not being done as a cross-compiler.


I'm sorry my new friend but I think that's the funniest 9fans post I've 
ever seen, how ... but  surely you . aw come on


To redeem myself I shall offer this link to one of the other C compilers 
that exist in the world :

http://plan9.bell-labs.com/magic/man2html/1/2c

Re: [9fans] A newbie question...

[Greg Comeau]

In article <[EMAIL PROTECTED]>,
Steve Simon <9fans@cse.psu.edu> wrote:
>> - is there a C++ compiler? Any plans for it?
>...
>Getting g++ to work would be the best way to get a modern
>C++ compiler on plan9 for free.
>
>If you have money the Comeau computing supply both a portable
>compiler and a GCC compliant C++ to C translator (both based
>on the EDG front-end), however there is no plan9 port, yet.
>
>   http://www.comeaucomputing.com/
>   http://www.edg.com/

We would love to be able to do such a port.  However, as you mentioned,
it's an economic problem rather than a technical one.  As a point
of clarification, we could provide a full port of Comeau C++ which
uses gcc (assuming one comes with it and/or is available for it).
Although I keep hearing different stories about the gcc availble for
Plan 9 (it makes little sense to me to hear "it does not work" because
something had to be used to compile Plan 9 itself, etc and I figure it's
not being done as a cross-compiler).
-- 
Greg Comeau / 4.3.9 with C++0xisms now in beta!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

Re: [9fans] A newbie question...

[Filipp Andronov]

> 3D stuff on *nix is very fat.
Yeah. In my point of view modern window system should be build on top
of OpenGL, but X11 build on top of kernel driver and OpenGL add to X11
with "hacks" :)

> DRI is something which should be far hidden behind clients
> not even exist within within an client process
In my point of view DRI should be dead :)
If you look at driver sources you could find many "hacks" and even
code duplications(!). DRI was perfect some years ago, but now it's
something that should stay in history :)


> Maybe you could start modeling the API's functionality into an
> filesystem
I'm not sure now how it should be. There are coupe a questions, so
after some results i will create project on some public host with all
my results and questions about architecture :)

> As an intermediate step you could develop an server
> for this (maybe using libmixp) on *nix/GNU platforms and connect
> it from an Plan9 environment (either remotely or from plan9port).
I'm even have no Plan9 running setup right now, yesterday i was try to
start it in VMWare, but i failed, today will be new try :)
But it's good thing, try to do it remotely, i'll try this way, thanks :)

> So you can develop the Plan9 userland side w/o having the actual
> drivers ported to Plan9. Once this works and the interface specs
> are fixed, you could move to native Plan9.
As far as i think now, in kernel will be only core graphics chip
functions, DRI part and OpenGL implementation should be in users pace.
But Linux goes in different way, so this is point of discussions too
:)

> 2008/2/4, Enrico Weigelt <[EMAIL PROTECTED]>:
> * Filipp Andronov <[EMAIL PROTECTED]> wrote:
>
> > Some graphics chip, actually i want port OpenGL to Plan9,
> > but DRI hasugly architecture and Mesa with X11 are overload
> > by unnecessary code,as far as i know it is because of historical
> > reasons.
>
> ACK. 3D stuff on *nix is very fat.
>
> I wouldn't suggest porting the whole thing, but just leaving
> the client API. Maybe you could start with specifying an
> synthetic filesystem which provides the client side
> functionality, so it's easy to develop an libGL replacement
> upon that.
>
> Feel free to use the OSS-QM resources (eg. the wiki) for that :)
>
> BTW: I'm currently doing similar things on the audio front.
> Maybe you've already seen my posting on the mixer-fs. I'm also
> working on an Audio-IO-FS. This one should provide an platform
> and device agnostic interface to audio io devices, so all these
> APIs out there (alsa userland, esound, ...) can become small
> and simple adapters to it.
>
> > I have experience with X11 and OpenGL specifications and device
> > driver development, so my plan was port general parts of mesa
> > (not all of course), but with out DRI on Intel graphics chip
> > (i have that card) with hardware acceleration.
>
> DRI is something which should be far hidden behind clients
> not even exist within within an client process. AFAIK it's
> far from being portable (but maybe I'm wrong).
>
> > When i start dig problem i have found DRI replacement known as
> > Gallium3D, it is completely new project (from Mesa community as
> > far asi know) and it small enough for try to port it.
>
> I don't have any experience with this. But from a quick look
> it might be worth thinking of.
>
> Maybe you could start modeling the API's functionality into an
> filesystem. As an intermediate step you could develop an server
> for this (maybe using libmixp) on *nix/GNU platforms and connect
> it from an Plan9 environment (either remotely or from plan9port).
> So you can develop the Plan9 userland side w/o having the actual
> drivers ported to Plan9. Once this works and the interface specs
> are fixed, you could move to native Plan9.
>
> At least that's the way *I* would go.
>
>
> cu
> --
> -
>  Enrico Weigelt==   metux IT service - http://www.metux.de/
> -
>  Please visit the OpenSource QM Taskforce:
> http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
> http://patches.metux.de/
> -
>

Re: [9fans] A newbie question...

[Enrico Weigelt]

* Filipp Andronov <[EMAIL PROTECTED]> wrote:

> Some graphics chip, actually i want port OpenGL to Plan9, 
> but DRI hasugly architecture and Mesa with X11 are overload 
> by unnecessary code,as far as i know it is because of historical 
> reasons.

ACK. 3D stuff on *nix is very fat. 

I wouldn't suggest porting the whole thing, but just leaving
the client API. Maybe you could start with specifying an 
synthetic filesystem which provides the client side 
functionality, so it's easy to develop an libGL replacement
upon that.

Feel free to use the OSS-QM resources (eg. the wiki) for that :)

BTW: I'm currently doing similar things on the audio front. 
Maybe you've already seen my posting on the mixer-fs. I'm also
working on an Audio-IO-FS. This one should provide an platform
and device agnostic interface to audio io devices, so all these
APIs out there (alsa userland, esound, ...) can become small
and simple adapters to it. 

> I have experience with X11 and OpenGL specifications and device 
> driver development, so my plan was port general parts of mesa 
> (not all of course), but with out DRI on Intel graphics chip 
> (i have that card) with hardware acceleration. 

DRI is something which should be far hidden behind clients
not even exist within within an client process. AFAIK it's 
far from being portable (but maybe I'm wrong). 

> When i start dig problem i have found DRI replacement known as 
> Gallium3D, it is completely new project (from Mesa community as 
> far asi know) and it small enough for try to port it. 

I don't have any experience with this. But from a quick look
it might be worth thinking of.

Maybe you could start modeling the API's functionality into an 
filesystem. As an intermediate step you could develop an server
for this (maybe using libmixp) on *nix/GNU platforms and connect
it from an Plan9 environment (either remotely or from plan9port).
So you can develop the Plan9 userland side w/o having the actual 
drivers ported to Plan9. Once this works and the interface specs
are fixed, you could move to native Plan9.

At least that's the way *I* would go.


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Enrico Weigelt]

* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

> Plan 9 becomes the proof thereof, if autotools were as successful as
> claimed, it ought to be trivial to port them to a different platform.
> It isn't, nor is it necessary.  In porting the code for libtiff and
> geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools,
> png, gd and eventually libtiff and geotiff.  The sum total of these
> mkfiles is probably less than two thousand lines.  But it is
> impossible to feed these back to the developers, because they do not
> fit into their philosophical scheme.

Feel free to post the patches to the OSS-QM project:

http://oss-qm.metux.de/


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Enrico Weigelt]

* Pawe?? Lasek <[EMAIL PROTECTED]> wrote:

> The best thing about autotools is I think the scheme of running
> configure - AFAIK mplayer doesn't even use configure for it's script,
> instead
> they use their own, which looks the same to end user. And saves a lot
> of time :-)

ACK. The fact that there's such an script with an standardized
command line interface is quite good. I which there were more
packages providing this interface (instead there a lots of packages
providing an ./configure script which isn't only incompatible
but even more crap than autoconf stuff, eg. Perl's).

BTW: mplayer's configure script is hand-written (in principle
a good thing ;-p), but it's incompatible with the GNU style.
Rich Felker's comment on this: "we dont want people to mix it
up with this autoconf crap"
Last time I checked, it also didn't make consequent use of 
pkg-config (but used it a few times). Rich Felker's comment:
"we dont want to require this pkg-config crap"

well ...


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Enrico Weigelt]

* erik quanstrom <[EMAIL PROTECTED]> wrote:

> part of the issue is that autotool solves a problem that doesn't
> exist on plan 9 systems.  one doesn't need to test for compilers,
> exotic library problems or portability issues.  

Actually, often for problems that don't exist at all 
(on sane systems). For example, why each individual package
should check for the toolchain commands ?! That's completely
insane! There are standard variables for that, which can 
be assumed to point to the right commands. Checking if the
toolchain's not broken should clealy NOT be the job of an
individual package. 

Another point are imported libraries: there's really no need
to run any compile test (or even worse: try to run some code).
Just ask an database tool (->pkg-config) to tell you the right
flags and make sure the required version is installed. 
Yeah, there are working autoconf macros for that, but many
many packages still don't use them (sometimes with really 
stupid cop-out's ;-o)

Older versions of autoconf had been even more insane: 
Lot's of "detection" macros (X11 stuff was such an bad 
candidate) pulled in hard-coded and absolute (!) pathes. 
It's obvious that this clearly breaks any crosscompile attemt.

BTW: one thing I never understood in the autoconf world:
Why's the term "support" so badly abused ?!
Imagine: in many packages you can switch whether some other
package is used - they call this "supported". 
For example I'm currently compiling VLC: there's an flag
for "gnutls" support. WTH shall this mean ?!
The right way would be an "enable TLS" option, stating this
requires GNU-TLS as dependency. 
Seems like autoconf people tend to turn things upside down ;-O

> another problem with autoconf is it encourages a style of
> programming that exploits every last nook and cranny of
> a system's & compiler's capabilities when the vast majority
> of applications will do just fine with the least common
> denominator.  if one's goal is to run on a variety of unix
> systems, this just is poor engineering.

As already said: autoconf has *NOTHING* to do with real 
portability, just working around lots of system/target
differences. ACK, this is really poor engineering.
 
> as a case in point, my sacrificial linux machine is a 993mhz
> pIII.  mplayer, an application one would think would benefit
> from fancy optimizations on such a slow machine, shows absolutely
> no visible performance benefit from sse2 instructions.  it
> is fast enough already.

Well, I'm really happy with those optimizations (eg. on 
number crunching applications, properly optimized code *can*
give an heaviy boost). But there's really *no* need for such 
an complex and unstable oracle like autoconf - there are clean
ways to fix this, eg. passing the right CFLAGS and using the
compiler's/preprocessor's symbols.

> one last gripe: autotools often take longer to ./configure
> than to compile with gcc.  curious that gcc is famed for
> slowness.

Yep, *rofl* ;-O


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Lyndon Nerenberg]

On 2008-Feb-3, at 17:19 , Enrico Weigelt wrote:


One of the major problem of autoconf is that It tries to guess around
lots of things, and this often fails or is very unclean (it requires
*really great* care to produce good code with it). In fact this has
nothing to do with portable programming, but working around  
uncountable

of target specifics.


Autoconf is nothing but a stinking rotten corpse that lives only  
because the cult of GNU adherents cannot (no, refuse to) grok the  
concept of POSIX.


The last time I ever had the requirement to use 'configure' -- that's  
'configure', not 'autoconf' in all its splendor -- was circa 1992. And  
that was solely thanks to Sun unbundling the C compiler, leading to  
the insane collection of command invocations needed to build something  
as simple as cat.c.

Re: [9fans] A newbie question...

[Enrico Weigelt]

* Filipp Andronov <[EMAIL PROTECTED]> wrote:

Hi,

> And the first one looks like this: does GNU build system (autoconf,
> automake, e.t.c) has been ported in Plan9?  Or maybe there is some
> alternative?  :)

If you got Java running, you might risk a look at unitool and treebuild:

* http://unitool.metux.de/
* http://treebuild.metux.de/

One of the major problem of autoconf is that It tries to guess around
lots of things, and this often fails or is very unclean (it requires
*really great* care to produce good code with it). In fact this has
nothing to do with portable programming, but working around uncountable
of target specifics. 

Unitool goes an different approach: real abstraction with clear and
*strict* interfaces. The individual target configuration is now the job 
of unitool and the one who sets it up - not the job of an individual
application. For example it provides an target/platform agnostic 
toolchain interface - there is now only ONE way to call the toolchain,
no matter what target you're building for and which toolchain you're
actually using.

Another big problem of most buildsystems (including all make-based)
is they're modeling rules for building instead of the software's
structure. Treebuild goes an different approach: modeling just
the structure of certain package, leaving the build process itself
out of scope of the package.

> I want port some software from linux to Plan9, but couldn't find any
> documentation about how i should do this in "plan9 style" )

hmm, "plan9 style" ?

Maybe a few hints:

* keep the code simple
* common things belong to their own libs
* autonomous things belong to their own fileserver

What packages are you going to port ?


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Pietro Gagliardi]

A perfect example: Windows security! :-)

On Feb 3, 2008, at 8:02 PM, Enrico Weigelt wrote:


* Uriel <[EMAIL PROTECTED]> wrote:

Autotools badness is way beyond most peoples wildest imagination...


Actually, It helped me enlarging my imagination capabilities ;-P

BTW: there are even far worse things out there ;-O


cu
--
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Enrico Weigelt]

* Uriel <[EMAIL PROTECTED]> wrote:
> Autotools badness is way beyond most peoples wildest imagination...

Actually, It helped me enlarging my imagination capabilities ;-P

BTW: there are even far worse things out there ;-O


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[Enrico Weigelt]

* Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> 
> On Jan 31, 2008, at 7:22 PM, Michael Andronov wrote:
> 
> >Hi,
> >
> >I'm a new to Plan9, and I am trying to understand the current  
> >status of the system.
> >In particular, I am wondering about the list of application available=
> >- is there  email reader?
> 
> Several ways to do this, but to set up:
> http://plan9.bell-labs.com/wiki/plan9/Mail_configuration/index.html

BTW: I'm currently designing an new mail filesystem which should should 
allow directly mounting many kind of mail storages and similar things
(eg. rss-feeds, nttp-servers, etc, etc).

http://oss-qm.metux.de/index.php/9forge/mailfs-ng

Maybe you'd like to help a bit :)

> >In other words, I am wondering if it is possible to switch to Plan  
> >9 system, and to use it as 'everyday machine'?

Actually, I'm personally not using native Plan9 at all. Instead I'm 
very interested in doing things the "Plan9-way" on *nix platforms.
(eg. using synthethic filesystems for a lot of things and splitting
large applications into smaller, independent parts, speaking 9P).


BTW: plan9port allows building/running Plan9 programs on *nix
systems (eg Linux). Always woth to look at :)


cu
-- 
-
 Enrico Weigelt==   metux IT service - http://www.metux.de/
-
 Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
-

Re: [9fans] A newbie question...

[kokamoto]

C++ has not been included in Plan 9 since the third edition, but the  
source code is available, and Steve Simon has made some updates.

Once you have abaco the way I said to get it, you also have Federico  
Benavento's contrib system. With it, all you need is

contrib/install steve/cfront

Otherwise, get contrib with

/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib

and then do the above. Then, to compile a C++ program:

c++/8c x.C # considering .C is the C++ extension
c++/8l -o x x.8

The one thing: don't use

#include 
using namespace std;

You will need

#include 

which does that for you.

On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:

> Another question from newbie :
>
> I have noticed some discussion(s) on Internet about C++ language  
> for  Plan9;
> I'm wondering what is a bottom line of the story:
> - is there a C++ compiler? Any plans for it?
> - has it been 'banned' from Plan9?
> - has gcc been ported to Plan9? ( as was suggested in one of the  
> messages I saw)...
>
> Thank for your attention.
> Michael.
>

Re: [9fans] A newbie question...

[Filipp Andronov]

Just in this minute i'm trying to start Plan9 in VMWare :D

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> Okay, that's fine. What I'm saying is that you don't have to write
> something from scratch to get something else working. If you actually
> do get one of the other OpenGL implementations to work, then porting
> Gallium3D is a lot easier.
>
> Either way, you won't need direct hardware manipulation on Plan 9.
> Just run it from a virtual machine and see where you go from there.
>
> On Feb 3, 2008, at 11:33 AM, Filipp Andronov wrote:
>
> >> There were many attempts to port OpenGL to Plan 9, none of which I
> >> got to work. I started working on a ground-up 3D library but lost it
> >> to a faulty Plan 9 partition.
> > I have no plan to start serious works about OpenGL porting. I just
> > want to play with Plan9, if i port Gallium3D if will be great success.
> >
> > Actually i have no working Plan9 yet (!), so i just looking around,
> > reading documentation and asking about some questions that i have in
> > my mind :)
> >
> > So my plans is not something serious, i just looking for somethings
> > for fun :)
> >
> > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> There were many attempts to port OpenGL to Plan 9, none of which I
> >> got to work. I started working on a ground-up 3D library but lost it
> >> to a faulty Plan 9 partition.
> >>
> >> On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote:
> >>
> >>> Some graphics chip, actually i want port OpenGL to Plan9, but DRI
> >>> has
> >>> ugly architecture and Mesa with X11 are overload by unnecessary
> >>> code,
> >>> as far as i know it is because of historical reasons.
> >>>
> >>> I have experience with X11 and OpenGL specifications and device
> >>> driver
> >>> development, so my plan was port general parts of mesa (not all of
> >>> course), but with out DRI on Intel graphics chip (i have that card)
> >>> with hardware acceleration.
> >>> When i start dig problem i have found DRI replacement known as
> >>> Gallium3D, it is completely new project (from Mesa community as
> >>> far as
> >>> i know) and it small enough for try to port it. Intel chips has very
> >>> good documentation and linux driver what i know very well. So plan
> >>> was:
> >>> 1. Port Gallium3D, pieces by piece
> >>> 2. Port some features from Linux Intel driver to Plan9 if necessary
> >>> 3. Try to port some pieces Mesa
> >>>
> >>> Of course it is a very big work, and i know that, but it is
> >>> interesting enough to be fun. I have no target to create completely
> >>> OpenGL implementation or port of Mesa, i just want to play with
> >>> Plan9
> >>> kernel, Mesa and Intel card :))
> >>>
> >>> 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
>  Out of curiosity, what hardware do you need to get working?
> 
>  On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:
> 
> > I'm not sure that "project fork" is a best way. Because hardware
> > problem is a little piece of work and it's lays it separate
> > module.
> > The biggest part of application is a some computations and some
> > algorithms implementation...As far, as application was port in
> > many
> > different Linux platforms, it's almost impossible to find some
> > function with out #ifdef :))
> >
> > Ok, any way, it looks like "project fork" is simplest way to do
> > port,
> > so any other waysis not very interesting. I think that this
> > way is
> > most correct, because in that case i could redesign many parts of
> > this
> > application in "plan9 style", do some soft services like, files
> > for
> > example  :)
> >
> > Thanks to all for your help :)
> >
> > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> You need to do direct hardware manipulation? Then "project
> >> fork" is
> >> probably best.
> >>
> >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
> >>
> >>> Heh, i try to "port" my program, and it's really not possible
> >>> in my
> >>> point of view :)
> >>>
> >>> Actually, i don't have working Plan9 right now, reason is quite
> >>> simple, on my hardware plan9 does do not work (PC emulators
> >>> couldn't
> >>> help because my program should work with some special hardware),
> >>> so i
> >>> try to create PC  from "supported hardware" list, but it take
> >>> some
> >>> time to get all pieces, put they together, install, configure
> >>> plan9
> >>> and so on ))
> >>>   Ok, i have no Plan9, but i have my application that i want to
> >>> port,
> >>> so i try to remove all autotools macros from it and try to do
> >>> some
> >>> preparations, like new abstraction layer for threads
> >>> creation...and
> >>> i'm completely failed, just because too much autotools stuff in
> >>> sources. And it too complicated to figure out what exactly i
> >>> should
> >>> remove in every case...
> >>> A

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Okay, that's fine. What I'm saying is that you don't have to write  
something from scratch to get something else working. If you actually  
do get one of the other OpenGL implementations to work, then porting  
Gallium3D is a lot easier.


Either way, you won't need direct hardware manipulation on Plan 9.  
Just run it from a virtual machine and see where you go from there.


On Feb 3, 2008, at 11:33 AM, Filipp Andronov wrote:


There were many attempts to port OpenGL to Plan 9, none of which I
got to work. I started working on a ground-up 3D library but lost it
to a faulty Plan 9 partition.

I have no plan to start serious works about OpenGL porting. I just
want to play with Plan9, if i port Gallium3D if will be great success.

Actually i have no working Plan9 yet (!), so i just looking around,
reading documentation and asking about some questions that i have in
my mind :)

So my plans is not something serious, i just looking for somethings  
for fun :)


2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:

There were many attempts to port OpenGL to Plan 9, none of which I
got to work. I started working on a ground-up 3D library but lost it
to a faulty Plan 9 partition.

On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote:

Some graphics chip, actually i want port OpenGL to Plan9, but DRI  
has
ugly architecture and Mesa with X11 are overload by unnecessary  
code,

as far as i know it is because of historical reasons.

I have experience with X11 and OpenGL specifications and device  
driver

development, so my plan was port general parts of mesa (not all of
course), but with out DRI on Intel graphics chip (i have that card)
with hardware acceleration.
When i start dig problem i have found DRI replacement known as
Gallium3D, it is completely new project (from Mesa community as  
far as

i know) and it small enough for try to port it. Intel chips has very
good documentation and linux driver what i know very well. So plan
was:
1. Port Gallium3D, pieces by piece
2. Port some features from Linux Intel driver to Plan9 if necessary
3. Try to port some pieces Mesa

Of course it is a very big work, and i know that, but it is
interesting enough to be fun. I have no target to create completely
OpenGL implementation or port of Mesa, i just want to play with  
Plan9

kernel, Mesa and Intel card :))

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:

Out of curiosity, what hardware do you need to get working?

On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:


I'm not sure that "project fork" is a best way. Because hardware
problem is a little piece of work and it's lays it separate  
module.

The biggest part of application is a some computations and some
algorithms implementation...As far, as application was port in  
many

different Linux platforms, it's almost impossible to find some
function with out #ifdef :))

Ok, any way, it looks like "project fork" is simplest way to do
port,
so any other waysis not very interesting. I think that this
way is
most correct, because in that case i could redesign many parts of
this
application in "plan9 style", do some soft services like, files  
for

example  :)

Thanks to all for your help :)

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
You need to do direct hardware manipulation? Then "project  
fork" is

probably best.

On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:


Heh, i try to "port" my program, and it's really not possible
in my
point of view :)

Actually, i don't have working Plan9 right now, reason is quite
simple, on my hardware plan9 does do not work (PC emulators
couldn't
help because my program should work with some special hardware),
so i
try to create PC  from "supported hardware" list, but it take  
some

time to get all pieces, put they together, install, configure
plan9
and so on ))
  Ok, i have no Plan9, but i have my application that i want to
port,
so i try to remove all autotools macros from it and try to do  
some

preparations, like new abstraction layer for threads
creation...and
i'm completely failed, just because too much autotools stuff in
sources. And it too complicated to figure out what exactly i
should
remove in every case...
And my application much smaller that mesa for example. Or X11  
(by

the
way, how X11 was ported?), and i do not touсh such problems  
like

different library, kernel interfaces and so, and so...

So it looks like "project fork" is only way :(

2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:

On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]>
wrote:

Circular cause and consequence is funny. Let me add to this
list:
- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
GNU software is good, except for GNU development  
tools,

which,
except for the gcc program itself, are mediocre and break
compatibility (try using a Bell Labs makefile with GNU make).

Re: [9fans] A newbie question...

[Filipp Andronov]

> There were many attempts to port OpenGL to Plan 9, none of which I
> got to work. I started working on a ground-up 3D library but lost it
> to a faulty Plan 9 partition.
I have no plan to start serious works about OpenGL porting. I just
want to play with Plan9, if i port Gallium3D if will be great success.

Actually i have no working Plan9 yet (!), so i just looking around,
reading documentation and asking about some questions that i have in
my mind :)

So my plans is not something serious, i just looking for somethings for fun :)

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> There were many attempts to port OpenGL to Plan 9, none of which I
> got to work. I started working on a ground-up 3D library but lost it
> to a faulty Plan 9 partition.
>
> On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote:
>
> > Some graphics chip, actually i want port OpenGL to Plan9, but DRI has
> > ugly architecture and Mesa with X11 are overload by unnecessary code,
> > as far as i know it is because of historical reasons.
> >
> > I have experience with X11 and OpenGL specifications and device driver
> > development, so my plan was port general parts of mesa (not all of
> > course), but with out DRI on Intel graphics chip (i have that card)
> > with hardware acceleration.
> > When i start dig problem i have found DRI replacement known as
> > Gallium3D, it is completely new project (from Mesa community as far as
> > i know) and it small enough for try to port it. Intel chips has very
> > good documentation and linux driver what i know very well. So plan
> > was:
> > 1. Port Gallium3D, pieces by piece
> > 2. Port some features from Linux Intel driver to Plan9 if necessary
> > 3. Try to port some pieces Mesa
> >
> > Of course it is a very big work, and i know that, but it is
> > interesting enough to be fun. I have no target to create completely
> > OpenGL implementation or port of Mesa, i just want to play with Plan9
> > kernel, Mesa and Intel card :))
> >
> > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> Out of curiosity, what hardware do you need to get working?
> >>
> >> On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:
> >>
> >>> I'm not sure that "project fork" is a best way. Because hardware
> >>> problem is a little piece of work and it's lays it separate module.
> >>> The biggest part of application is a some computations and some
> >>> algorithms implementation...As far, as application was port in many
> >>> different Linux platforms, it's almost impossible to find some
> >>> function with out #ifdef :))
> >>>
> >>> Ok, any way, it looks like "project fork" is simplest way to do
> >>> port,
> >>> so any other waysis not very interesting. I think that this
> >>> way is
> >>> most correct, because in that case i could redesign many parts of
> >>> this
> >>> application in "plan9 style", do some soft services like, files for
> >>> example  :)
> >>>
> >>> Thanks to all for your help :)
> >>>
> >>> 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
>  You need to do direct hardware manipulation? Then "project fork" is
>  probably best.
> 
>  On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
> 
> > Heh, i try to "port" my program, and it's really not possible
> > in my
> > point of view :)
> >
> > Actually, i don't have working Plan9 right now, reason is quite
> > simple, on my hardware plan9 does do not work (PC emulators
> > couldn't
> > help because my program should work with some special hardware),
> > so i
> > try to create PC  from "supported hardware" list, but it take some
> > time to get all pieces, put they together, install, configure
> > plan9
> > and so on ))
> >   Ok, i have no Plan9, but i have my application that i want to
> > port,
> > so i try to remove all autotools macros from it and try to do some
> > preparations, like new abstraction layer for threads
> > creation...and
> > i'm completely failed, just because too much autotools stuff in
> > sources. And it too complicated to figure out what exactly i
> > should
> > remove in every case...
> > And my application much smaller that mesa for example. Or X11 (by
> > the
> > way, how X11 was ported?), and i do not touсh such problems like
> > different library, kernel interfaces and so, and so...
> >
> > So it looks like "project fork" is only way :(
> >
> > 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
> >> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]>
> >> wrote:
> >>> Circular cause and consequence is funny. Let me add to this
> >>> list:
> >>> - jpg
> >>> - png
> >>> - tiff
> >>> - PostScript
> >>> - TeX (tpic)
> >>> - HTML
> >>> - Mahjongg, sokoban, sudoku, tetris (games/4s)
> >>> - SPARC, MIPS, x64
> >>> - MP3, PCM, OGG (PAC was made at Bell Labs)
> >>> - SoundBlaster 16
> >>>
> >>> Let me put it this way:
> >>>   

Re: [9fans] A newbie question...

[Pietro Gagliardi]

There were many attempts to port OpenGL to Plan 9, none of which I  
got to work. I started working on a ground-up 3D library but lost it  
to a faulty Plan 9 partition.


On Feb 3, 2008, at 10:56 AM, Filipp Andronov wrote:


Some graphics chip, actually i want port OpenGL to Plan9, but DRI has
ugly architecture and Mesa with X11 are overload by unnecessary code,
as far as i know it is because of historical reasons.

I have experience with X11 and OpenGL specifications and device driver
development, so my plan was port general parts of mesa (not all of
course), but with out DRI on Intel graphics chip (i have that card)
with hardware acceleration.
When i start dig problem i have found DRI replacement known as
Gallium3D, it is completely new project (from Mesa community as far as
i know) and it small enough for try to port it. Intel chips has very
good documentation and linux driver what i know very well. So plan
was:
1. Port Gallium3D, pieces by piece
2. Port some features from Linux Intel driver to Plan9 if necessary
3. Try to port some pieces Mesa

Of course it is a very big work, and i know that, but it is
interesting enough to be fun. I have no target to create completely
OpenGL implementation or port of Mesa, i just want to play with Plan9
kernel, Mesa and Intel card :))

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:

Out of curiosity, what hardware do you need to get working?

On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:


I'm not sure that "project fork" is a best way. Because hardware
problem is a little piece of work and it's lays it separate module.
The biggest part of application is a some computations and some
algorithms implementation...As far, as application was port in many
different Linux platforms, it's almost impossible to find some
function with out #ifdef :))

Ok, any way, it looks like "project fork" is simplest way to do  
port,
so any other waysis not very interesting. I think that this  
way is
most correct, because in that case i could redesign many parts of  
this

application in "plan9 style", do some soft services like, files for
example  :)

Thanks to all for your help :)

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:

You need to do direct hardware manipulation? Then "project fork" is
probably best.

On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:

Heh, i try to "port" my program, and it's really not possible  
in my

point of view :)

Actually, i don't have working Plan9 right now, reason is quite
simple, on my hardware plan9 does do not work (PC emulators  
couldn't

help because my program should work with some special hardware),
so i
try to create PC  from "supported hardware" list, but it take some
time to get all pieces, put they together, install, configure  
plan9

and so on ))
  Ok, i have no Plan9, but i have my application that i want to
port,
so i try to remove all autotools macros from it and try to do some
preparations, like new abstraction layer for threads  
creation...and

i'm completely failed, just because too much autotools stuff in
sources. And it too complicated to figure out what exactly i  
should

remove in every case...
And my application much smaller that mesa for example. Or X11 (by
the
way, how X11 was ported?), and i do not touсh such problems like
different library, kernel interfaces and so, and so...

So it looks like "project fork" is only way :(

2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]>  
wrote:
Circular cause and consequence is funny. Let me add to this  
list:

- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
GNU software is good, except for GNU development tools,
which,
except for the gcc program itself, are mediocre and break
compatibility (try using a Bell Labs makefile with GNU make).



I'd add to it the fact that autotools source files are hard to
make, so
many people who are to lazy to do it properly just put the famous
(in)sanity check and checks for libs they use. The effect?

A simple C program that doesn't rely on anything except for
example libpng
will check for C, C++, FORTRAN 77 compilers, check if those are
from
GCC and various other things.

Imagine my surprise when I had seen a configure script (for
EmacsLisp
utility) that only checked for Emacs version
and few EmacsLisp files it used - a rare thing IMHO, when >80% of
configure running time is for checking for not used
software.

"CPU cycles are cheap, programmer time is expensive" <--- This
doesn't
mean that total laziness is appropriate.

The best thing about autotools is I think the scheme of running
configure - AFAIK mplayer doesn't even use configure for it's
script,
instead
they use their own, which looks the same to end user. And saves
a lot
of time :-)

--
Paul Lasek

Re: [9fans] A newbie question...

[erik quanstrom]

it would help to have intel and amd drivers based on published
documentation.  i don't have the amd (ati) link handy, but here's
the link matt offered the other day:

http://intellinuxgraphics.org/documentation.html

- erik

Re: [9fans] A newbie question...

[Filipp Andronov]

2008/2/3, Filipp Andronov <[EMAIL PROTECTED]>:
> Some graphics chip, actually i want port OpenGL to Plan9, but DRI has
> ugly architecture and Mesa with X11 are overload by unnecessary code,
> as far as i know it is because of historical reasons.
>
> I have experience with X11 and OpenGL specifications and device driver
> development, so my plan was port general parts of mesa (not all of
> course), but with out DRI on Intel graphics chip (i have that card)
> with hardware acceleration.
> When i start dig problem i have found DRI replacement known as
> Gallium3D, it is completely new project (from Mesa community as far as
> i know) and it small enough for try to port it. Intel chips has very
> good documentation and linux driver what i know very well. So plan
> was:
> 1. Port Gallium3D, pieces by piece
> 2. Port some features from Linux Intel driver to Plan9 if necessary
> 3. Try to port some pieces Mesa
>
> Of course it is a very big work, and i know that, but it is
> interesting enough to be fun. I have no target to create completely
> OpenGL implementation or port of Mesa, i just want to play with Plan9
> kernel, Mesa and Intel card :))
>
> 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> > Out of curiosity, what hardware do you need to get working?
> >
> > On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:
> >
> > > I'm not sure that "project fork" is a best way. Because hardware
> > > problem is a little piece of work and it's lays it separate module.
> > > The biggest part of application is a some computations and some
> > > algorithms implementation...As far, as application was port in many
> > > different Linux platforms, it's almost impossible to find some
> > > function with out #ifdef :))
> > >
> > > Ok, any way, it looks like "project fork" is simplest way to do port,
> > > so any other waysis not very interesting. I think that this way is
> > > most correct, because in that case i could redesign many parts of this
> > > application in "plan9 style", do some soft services like, files for
> > > example  :)
> > >
> > > Thanks to all for your help :)
> > >
> > > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> > >> You need to do direct hardware manipulation? Then "project fork" is
> > >> probably best.
> > >>
> > >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
> > >>
> > >>> Heh, i try to "port" my program, and it's really not possible in my
> > >>> point of view :)
> > >>>
> > >>> Actually, i don't have working Plan9 right now, reason is quite
> > >>> simple, on my hardware plan9 does do not work (PC emulators couldn't
> > >>> help because my program should work with some special hardware),
> > >>> so i
> > >>> try to create PC  from "supported hardware" list, but it take some
> > >>> time to get all pieces, put they together, install, configure plan9
> > >>> and so on ))
> > >>>   Ok, i have no Plan9, but i have my application that i want to
> > >>> port,
> > >>> so i try to remove all autotools macros from it and try to do some
> > >>> preparations, like new abstraction layer for threads creation...and
> > >>> i'm completely failed, just because too much autotools stuff in
> > >>> sources. And it too complicated to figure out what exactly i should
> > >>> remove in every case...
> > >>> And my application much smaller that mesa for example. Or X11 (by
> > >>> the
> > >>> way, how X11 was ported?), and i do not touсh such problems like
> > >>> different library, kernel interfaces and so, and so...
> > >>>
> > >>> So it looks like "project fork" is only way :(
> > >>>
> > >>> 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
> >  On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> > > Circular cause and consequence is funny. Let me add to this list:
> > > - jpg
> > > - png
> > > - tiff
> > > - PostScript
> > > - TeX (tpic)
> > > - HTML
> > > - Mahjongg, sokoban, sudoku, tetris (games/4s)
> > > - SPARC, MIPS, x64
> > > - MP3, PCM, OGG (PAC was made at Bell Labs)
> > > - SoundBlaster 16
> > >
> > > Let me put it this way:
> > > GNU software is good, except for GNU development tools,
> > > which,
> > > except for the gcc program itself, are mediocre and break
> > > compatibility (try using a Bell Labs makefile with GNU make).
> > >
> > 
> >  I'd add to it the fact that autotools source files are hard to
> >  make, so
> >  many people who are to lazy to do it properly just put the famous
> >  (in)sanity check and checks for libs they use. The effect?
> > 
> >  A simple C program that doesn't rely on anything except for
> >  example libpng
> >  will check for C, C++, FORTRAN 77 compilers, check if those are
> >  from
> >  GCC and various other things.
> > 
> >  Imagine my surprise when I had seen a configure script (for
> >  EmacsLisp
> >  utility) that only checked for Emacs version
> >  and few EmacsLisp files it used - a rare th

Re: [9fans] A newbie question...

[Filipp Andronov]

Some graphics chip, actually i want port OpenGL to Plan9, but DRI has
ugly architecture and Mesa with X11 are overload by unnecessary code,
as far as i know it is because of historical reasons.

I have experience with X11 and OpenGL specifications and device driver
development, so my plan was port general parts of mesa (not all of
course), but with out DRI on Intel graphics chip (i have that card)
with hardware acceleration.
When i start dig problem i have found DRI replacement known as
Gallium3D, it is completely new project (from Mesa community as far as
i know) and it small enough for try to port it. Intel chips has very
good documentation and linux driver what i know very well. So plan
was:
1. Port Gallium3D, pieces by piece
2. Port some features from Linux Intel driver to Plan9 if necessary
3. Try to port some pieces Mesa

Of course it is a very big work, and i know that, but it is
interesting enough to be fun. I have no target to create completely
OpenGL implementation or port of Mesa, i just want to play with Plan9
kernel, Mesa and Intel card :))

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> Out of curiosity, what hardware do you need to get working?
>
> On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:
>
> > I'm not sure that "project fork" is a best way. Because hardware
> > problem is a little piece of work and it's lays it separate module.
> > The biggest part of application is a some computations and some
> > algorithms implementation...As far, as application was port in many
> > different Linux platforms, it's almost impossible to find some
> > function with out #ifdef :))
> >
> > Ok, any way, it looks like "project fork" is simplest way to do port,
> > so any other waysis not very interesting. I think that this way is
> > most correct, because in that case i could redesign many parts of this
> > application in "plan9 style", do some soft services like, files for
> > example  :)
> >
> > Thanks to all for your help :)
> >
> > 2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> You need to do direct hardware manipulation? Then "project fork" is
> >> probably best.
> >>
> >> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
> >>
> >>> Heh, i try to "port" my program, and it's really not possible in my
> >>> point of view :)
> >>>
> >>> Actually, i don't have working Plan9 right now, reason is quite
> >>> simple, on my hardware plan9 does do not work (PC emulators couldn't
> >>> help because my program should work with some special hardware),
> >>> so i
> >>> try to create PC  from "supported hardware" list, but it take some
> >>> time to get all pieces, put they together, install, configure plan9
> >>> and so on ))
> >>>   Ok, i have no Plan9, but i have my application that i want to
> >>> port,
> >>> so i try to remove all autotools macros from it and try to do some
> >>> preparations, like new abstraction layer for threads creation...and
> >>> i'm completely failed, just because too much autotools stuff in
> >>> sources. And it too complicated to figure out what exactly i should
> >>> remove in every case...
> >>> And my application much smaller that mesa for example. Or X11 (by
> >>> the
> >>> way, how X11 was ported?), and i do not touсh such problems like
> >>> different library, kernel interfaces and so, and so...
> >>>
> >>> So it looks like "project fork" is only way :(
> >>>
> >>> 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
>  On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> > Circular cause and consequence is funny. Let me add to this list:
> > - jpg
> > - png
> > - tiff
> > - PostScript
> > - TeX (tpic)
> > - HTML
> > - Mahjongg, sokoban, sudoku, tetris (games/4s)
> > - SPARC, MIPS, x64
> > - MP3, PCM, OGG (PAC was made at Bell Labs)
> > - SoundBlaster 16
> >
> > Let me put it this way:
> > GNU software is good, except for GNU development tools,
> > which,
> > except for the gcc program itself, are mediocre and break
> > compatibility (try using a Bell Labs makefile with GNU make).
> >
> 
>  I'd add to it the fact that autotools source files are hard to
>  make, so
>  many people who are to lazy to do it properly just put the famous
>  (in)sanity check and checks for libs they use. The effect?
> 
>  A simple C program that doesn't rely on anything except for
>  example libpng
>  will check for C, C++, FORTRAN 77 compilers, check if those are
>  from
>  GCC and various other things.
> 
>  Imagine my surprise when I had seen a configure script (for
>  EmacsLisp
>  utility) that only checked for Emacs version
>  and few EmacsLisp files it used - a rare thing IMHO, when >80% of
>  configure running time is for checking for not used
>  software.
> 
>  "CPU cycles are cheap, programmer time is expensive" <--- This
>  doesn't
>  mean that total laziness is appropriate.
> 
>  The bes

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Out of curiosity, what hardware do you need to get working?

On Feb 3, 2008, at 10:28 AM, Filipp Andronov wrote:


I'm not sure that "project fork" is a best way. Because hardware
problem is a little piece of work and it's lays it separate module.
The biggest part of application is a some computations and some
algorithms implementation...As far, as application was port in many
different Linux platforms, it's almost impossible to find some
function with out #ifdef :))

Ok, any way, it looks like "project fork" is simplest way to do port,
so any other waysis not very interesting. I think that this way is
most correct, because in that case i could redesign many parts of this
application in "plan9 style", do some soft services like, files for
example  :)

Thanks to all for your help :)

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:

You need to do direct hardware manipulation? Then "project fork" is
probably best.

On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:


Heh, i try to "port" my program, and it's really not possible in my
point of view :)

Actually, i don't have working Plan9 right now, reason is quite
simple, on my hardware plan9 does do not work (PC emulators couldn't
help because my program should work with some special hardware),  
so i

try to create PC  from "supported hardware" list, but it take some
time to get all pieces, put they together, install, configure plan9
and so on ))
  Ok, i have no Plan9, but i have my application that i want to  
port,

so i try to remove all autotools macros from it and try to do some
preparations, like new abstraction layer for threads creation...and
i'm completely failed, just because too much autotools stuff in
sources. And it too complicated to figure out what exactly i should
remove in every case...
And my application much smaller that mesa for example. Or X11 (by  
the

way, how X11 was ported?), and i do not touсh such problems like
different library, kernel interfaces and so, and so...

So it looks like "project fork" is only way :(

2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:

On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:

Circular cause and consequence is funny. Let me add to this list:
- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
GNU software is good, except for GNU development tools,
which,
except for the gcc program itself, are mediocre and break
compatibility (try using a Bell Labs makefile with GNU make).



I'd add to it the fact that autotools source files are hard to
make, so
many people who are to lazy to do it properly just put the famous
(in)sanity check and checks for libs they use. The effect?

A simple C program that doesn't rely on anything except for
example libpng
will check for C, C++, FORTRAN 77 compilers, check if those are  
from

GCC and various other things.

Imagine my surprise when I had seen a configure script (for  
EmacsLisp

utility) that only checked for Emacs version
and few EmacsLisp files it used - a rare thing IMHO, when >80% of
configure running time is for checking for not used
software.

"CPU cycles are cheap, programmer time is expensive" <--- This
doesn't
mean that total laziness is appropriate.

The best thing about autotools is I think the scheme of running
configure - AFAIK mplayer doesn't even use configure for it's  
script,

instead
they use their own, which looks the same to end user. And saves  
a lot

of time :-)

--
Paul Lasek

Re: [9fans] A newbie question...

[Filipp Andronov]

I'm not sure that "project fork" is a best way. Because hardware
problem is a little piece of work and it's lays it separate module.
The biggest part of application is a some computations and some
algorithms implementation...As far, as application was port in many
different Linux platforms, it's almost impossible to find some
function with out #ifdef :))

Ok, any way, it looks like "project fork" is simplest way to do port,
so any other waysis not very interesting. I think that this way is
most correct, because in that case i could redesign many parts of this
application in "plan9 style", do some soft services like, files for
example  :)

Thanks to all for your help :)

2008/2/3, Pietro Gagliardi <[EMAIL PROTECTED]>:
> You need to do direct hardware manipulation? Then "project fork" is
> probably best.
>
> On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:
>
> > Heh, i try to "port" my program, and it's really not possible in my
> > point of view :)
> >
> > Actually, i don't have working Plan9 right now, reason is quite
> > simple, on my hardware plan9 does do not work (PC emulators couldn't
> > help because my program should work with some special hardware), so i
> > try to create PC  from "supported hardware" list, but it take some
> > time to get all pieces, put they together, install, configure plan9
> > and so on ))
> >   Ok, i have no Plan9, but i have my application that i want to port,
> > so i try to remove all autotools macros from it and try to do some
> > preparations, like new abstraction layer for threads creation...and
> > i'm completely failed, just because too much autotools stuff in
> > sources. And it too complicated to figure out what exactly i should
> > remove in every case...
> > And my application much smaller that mesa for example. Or X11 (by the
> > way, how X11 was ported?), and i do not touсh such problems like
> > different library, kernel interfaces and so, and so...
> >
> > So it looks like "project fork" is only way :(
> >
> > 2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
> >> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> >>> Circular cause and consequence is funny. Let me add to this list:
> >>> - jpg
> >>> - png
> >>> - tiff
> >>> - PostScript
> >>> - TeX (tpic)
> >>> - HTML
> >>> - Mahjongg, sokoban, sudoku, tetris (games/4s)
> >>> - SPARC, MIPS, x64
> >>> - MP3, PCM, OGG (PAC was made at Bell Labs)
> >>> - SoundBlaster 16
> >>>
> >>> Let me put it this way:
> >>> GNU software is good, except for GNU development tools,
> >>> which,
> >>> except for the gcc program itself, are mediocre and break
> >>> compatibility (try using a Bell Labs makefile with GNU make).
> >>>
> >>
> >> I'd add to it the fact that autotools source files are hard to
> >> make, so
> >> many people who are to lazy to do it properly just put the famous
> >> (in)sanity check and checks for libs they use. The effect?
> >>
> >> A simple C program that doesn't rely on anything except for
> >> example libpng
> >> will check for C, C++, FORTRAN 77 compilers, check if those are from
> >> GCC and various other things.
> >>
> >> Imagine my surprise when I had seen a configure script (for EmacsLisp
> >> utility) that only checked for Emacs version
> >> and few EmacsLisp files it used - a rare thing IMHO, when >80% of
> >> configure running time is for checking for not used
> >> software.
> >>
> >> "CPU cycles are cheap, programmer time is expensive" <--- This
> >> doesn't
> >> mean that total laziness is appropriate.
> >>
> >> The best thing about autotools is I think the scheme of running
> >> configure - AFAIK mplayer doesn't even use configure for it's script,
> >> instead
> >> they use their own, which looks the same to end user. And saves a lot
> >> of time :-)
> >>
> >> --
> >> Paul Lasek
> >>
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

You need to do direct hardware manipulation? Then "project fork" is  
probably best.


On Feb 3, 2008, at 10:13 AM, Filipp Andronov wrote:


Heh, i try to "port" my program, and it's really not possible in my
point of view :)

Actually, i don't have working Plan9 right now, reason is quite
simple, on my hardware plan9 does do not work (PC emulators couldn't
help because my program should work with some special hardware), so i
try to create PC  from "supported hardware" list, but it take some
time to get all pieces, put they together, install, configure plan9
and so on ))
  Ok, i have no Plan9, but i have my application that i want to port,
so i try to remove all autotools macros from it and try to do some
preparations, like new abstraction layer for threads creation...and
i'm completely failed, just because too much autotools stuff in
sources. And it too complicated to figure out what exactly i should
remove in every case...
And my application much smaller that mesa for example. Or X11 (by the
way, how X11 was ported?), and i do not touсh such problems like
different library, kernel interfaces and so, and so...

So it looks like "project fork" is only way :(

2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:

On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:

Circular cause and consequence is funny. Let me add to this list:
- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
GNU software is good, except for GNU development tools,  
which,

except for the gcc program itself, are mediocre and break
compatibility (try using a Bell Labs makefile with GNU make).



I'd add to it the fact that autotools source files are hard to  
make, so

many people who are to lazy to do it properly just put the famous
(in)sanity check and checks for libs they use. The effect?

A simple C program that doesn't rely on anything except for  
example libpng

will check for C, C++, FORTRAN 77 compilers, check if those are from
GCC and various other things.

Imagine my surprise when I had seen a configure script (for EmacsLisp
utility) that only checked for Emacs version
and few EmacsLisp files it used - a rare thing IMHO, when >80% of
configure running time is for checking for not used
software.

"CPU cycles are cheap, programmer time is expensive" <--- This  
doesn't

mean that total laziness is appropriate.

The best thing about autotools is I think the scheme of running
configure - AFAIK mplayer doesn't even use configure for it's script,
instead
they use their own, which looks the same to end user. And saves a lot
of time :-)

--
Paul Lasek

Re: [9fans] A newbie question...

[Filipp Andronov]

Heh, i try to "port" my program, and it's really not possible in my
point of view :)

Actually, i don't have working Plan9 right now, reason is quite
simple, on my hardware plan9 does do not work (PC emulators couldn't
help because my program should work with some special hardware), so i
try to create PC  from "supported hardware" list, but it take some
time to get all pieces, put they together, install, configure plan9
and so on ))
  Ok, i have no Plan9, but i have my application that i want to port,
so i try to remove all autotools macros from it and try to do some
preparations, like new abstraction layer for threads creation...and
i'm completely failed, just because too much autotools stuff in
sources. And it too complicated to figure out what exactly i should
remove in every case...
And my application much smaller that mesa for example. Or X11 (by the
way, how X11 was ported?), and i do not touсh such problems like
different library, kernel interfaces and so, and so...

So it looks like "project fork" is only way :(

2008/2/3, Paweł Lasek <[EMAIL PROTECTED]>:
> On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> > Circular cause and consequence is funny. Let me add to this list:
> > - jpg
> > - png
> > - tiff
> > - PostScript
> > - TeX (tpic)
> > - HTML
> > - Mahjongg, sokoban, sudoku, tetris (games/4s)
> > - SPARC, MIPS, x64
> > - MP3, PCM, OGG (PAC was made at Bell Labs)
> > - SoundBlaster 16
> >
> > Let me put it this way:
> > GNU software is good, except for GNU development tools, which,
> > except for the gcc program itself, are mediocre and break
> > compatibility (try using a Bell Labs makefile with GNU make).
> >
>
> I'd add to it the fact that autotools source files are hard to make, so
> many people who are to lazy to do it properly just put the famous
> (in)sanity check and checks for libs they use. The effect?
>
> A simple C program that doesn't rely on anything except for example libpng
> will check for C, C++, FORTRAN 77 compilers, check if those are from
> GCC and various other things.
>
> Imagine my surprise when I had seen a configure script (for EmacsLisp
> utility) that only checked for Emacs version
> and few EmacsLisp files it used - a rare thing IMHO, when >80% of
> configure running time is for checking for not used
> software.
>
> "CPU cycles are cheap, programmer time is expensive" <--- This doesn't
> mean that total laziness is appropriate.
>
> The best thing about autotools is I think the scheme of running
> configure - AFAIK mplayer doesn't even use configure for it's script,
> instead
> they use their own, which looks the same to end user. And saves a lot
> of time :-)
>
> --
> Paul Lasek
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

That someone had the time and the will to do something like this?

On Feb 3, 2008, at 10:01 AM, [EMAIL PROTECTED] wrote:


On 3 Feb 2008, at 00:17, Robert William Fuller wrote:
An alternative interpretation is that the facts are skewed by the  
Bell Labs reality distortion field.  The syllogism goes something  
like this:


All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad


Hello children.  Today's word is "ad hominem".  Can you say "ad  
hominem"?


"We are the knights who say 'NIH'".  Not.

Nobody's mentioned the antecedents of autoconf&co.
other than genealogically.

The criticism has been (IMO) well-reasoned.

If the appraisals appear somewhat vituperative at times,
that is probably because the writers thereof constitute some of the  
sorry
band of unfortunates (myself included) who have been persuaded by  
circumstance

to engage in bootless battle with the autoconf hydra.

We eagerly await ingenious and novel counter-arguments explicating the
intrinsic intellectual beauty and universal utility of a so-called  
portability system
consisting of 10K+SLOCs of convoluted, inscrutable and non-portable  
configuration scripts

intertwined with a twisty maze of twisted #ifdefs.

DaveL

Re: [9fans] A newbie question...

[dave . l]

On 3 Feb 2008, at 00:17, Robert William Fuller wrote:
An alternative interpretation is that the facts are skewed by the  
Bell Labs reality distortion field.  The syllogism goes something  
like this:


All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad


Hello children.  Today's word is "ad hominem".  Can you say "ad  
hominem"?


"We are the knights who say 'NIH'".  Not.

Nobody's mentioned the antecedents of autoconf&co.
other than genealogically.

The criticism has been (IMO) well-reasoned.

If the appraisals appear somewhat vituperative at times,
that is probably because the writers thereof constitute some of the  
sorry
band of unfortunates (myself included) who have been persuaded by  
circumstance

to engage in bootless battle with the autoconf hydra.

We eagerly await ingenious and novel counter-arguments explicating the
intrinsic intellectual beauty and universal utility of a so-called  
portability system
consisting of 10K+SLOCs of convoluted, inscrutable and non-portable  
configuration scripts

intertwined with a twisty maze of twisted #ifdefs.

DaveL

Re: [9fans] A newbie question...

[Paweł Lasek]

On Feb 3, 2008 2:55 AM, Pietro Gagliardi <[EMAIL PROTECTED]> wrote:
> Circular cause and consequence is funny. Let me add to this list:
> - jpg
> - png
> - tiff
> - PostScript
> - TeX (tpic)
> - HTML
> - Mahjongg, sokoban, sudoku, tetris (games/4s)
> - SPARC, MIPS, x64
> - MP3, PCM, OGG (PAC was made at Bell Labs)
> - SoundBlaster 16
>
> Let me put it this way:
> GNU software is good, except for GNU development tools, which,
> except for the gcc program itself, are mediocre and break
> compatibility (try using a Bell Labs makefile with GNU make).
>

I'd add to it the fact that autotools source files are hard to make, so
many people who are to lazy to do it properly just put the famous
(in)sanity check and checks for libs they use. The effect?

A simple C program that doesn't rely on anything except for example libpng
will check for C, C++, FORTRAN 77 compilers, check if those are from
GCC and various other things.

Imagine my surprise when I had seen a configure script (for EmacsLisp
utility) that only checked for Emacs version
and few EmacsLisp files it used - a rare thing IMHO, when >80% of
configure running time is for checking for not used
software.

"CPU cycles are cheap, programmer time is expensive" <--- This doesn't
mean that total laziness is appropriate.

The best thing about autotools is I think the scheme of running
configure - AFAIK mplayer doesn't even use configure for it's script,
instead
they use their own, which looks the same to end user. And saves a lot
of time :-)

-- 
Paul Lasek

Re: [9fans] A newbie question...

[Pietro Gagliardi]

No one remembers the Windows development tools!

Actually, I have a clear memory of Visual Studio 2005 Express, as I  
used to develop in C#. That system was one of the (cough - only -  
cough) good things Microsoft made.


On Feb 3, 2008, at 7:49 AM, [EMAIL PROTECTED] wrote:

So if i want port some big linux application to Plan9 i need start  
new

project and copy parts of code from original one. From one side it is
sad, because it's very ugly development model (for example if  
original
project will be update, i need update my project too, so there are  
two

"targets" for every update).  On another hand i could concentrate on
new Pla9 techniques and create more powerful analogous of linux
software.


Eventually, you'd think the autotools will fade, but reality sometimes
turns out illogical.  I think the "Plan 9 Way" will only become
dominant if there is a major change to the present status.

Strangely, no one criticises the Windows development tools...

++L

Re: [9fans] A newbie question...

[Pietro Gagliardi]

You don't need to do all that if you know what libraries your program  
depends on. Libraries like pdcurses, libtiff, zlib, etc. have been  
ported to APE, so once you have them installed, all you need to do is  
run the configure file and then make from within ape/psh. However, if  
you need autoconf/automake before a configure file, you're out of luck.


On Feb 3, 2008, at 3:44 AM, Filipp Andronov wrote:


Hmmm, my question was not about new ideological war "GNU vs Plan9". ))
I think that my bad English does not allow me to ask my question in
correct form, so i will show some sample :)

For example, in Linux i have some big application.
This application using autotools, so if a want to port it, for example
on different OS (of course if this OS has autotools) or hardware all i
need is go throw sources and put something like:
#ifdef RUN_IN_CYGWIN
 // some specific code
#endif
After that i need to add extra tests in configure and autotools will
do all magic for me :)
The main trouble is that all sources has really many pieces of #ifdef
code, so it could be very painful to drop out "portability in GNU
way".  But it's ok, until that is a only way.

Ok, for me "porting" to plan9 looks like:
1. Drop out autotools from project
2. Replace all OS specific code to Plan9 equivalent
3. Replace all libs to it's equivalent for plan9
4. and so on

Main trouble in 1 step. Because after that i couldn't post in project
mail list, "Hey gays, i have create Plan9 port of your application,
please check it out and put in CVS trunk". If i "port" some
application in that way, that mean that I've start new one, "from
scratch" and just copy & paste some code from original project :((

I hope that i have logical mistakes in my example, and you show me
that, because if not it could be very sad  :))



2008/2/3, Eris Discordia <[EMAIL PROTECTED]>:
On Sun, 03 Feb 2008 00:30:38 -, Rob Pike <[EMAIL PROTECTED]>  
wrote:


 An alternative interpretation is that the facts are skewed by  
the Bell
 Labs reality distortion field.  The syllogism goes something  
like this:


 All things not made at Bell Labs are bad
 GNU is not made at Bell Labs
 Therefore, GNU is bad



If you think about what the letters of GNU stand for, you might
appreciate
that the forms are in mutual opposition.  They provide completely
different
approaches to software.  "Good" and "Bad" are value judgments.  If
you think GNU is the right way to build things, Plan 9 is  
probably not

for you, and vice versa.

-rob


Is that "the" Rob Pike? "The R?"

If so, please accept me humble reverence, sire! Hallowed be thy  
practice

(of programming)!

P. S. Down here in my country, Iran, we have this tradition of  
inventing
sacred things out of thin air. A considerable proportion of "the  
divine
and the sacred" spilled all over the globe began with that frailty  
of ours

:-D

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] A newbie question...

[Filipp Andronov]

> Strangely, no one criticises the Windows development tools...
I do, it's horrible and even more, i just don't know such words on
English, to describe all my feelings about windows build system  :

Perhaps i do not known it very well, but i have some experience of
development under windows, and that experience told me do not do such
mistake (development under windows) once again :)))

2008/2/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > So if i want port some big linux application to Plan9 i need start new
> > project and copy parts of code from original one. From one side it is
> > sad, because it's very ugly development model (for example if original
> > project will be update, i need update my project too, so there are two
> > "targets" for every update).  On another hand i could concentrate on
> > new Pla9 techniques and create more powerful analogous of linux
> > software.
>
> Eventually, you'd think the autotools will fade, but reality sometimes
> turns out illogical.  I think the "Plan 9 Way" will only become
> dominant if there is a major change to the present status.
>
> Strangely, no one criticises the Windows development tools...
>
> ++L
>
>

Re: [9fans] A newbie question...

[lucio]

> So if i want port some big linux application to Plan9 i need start new
> project and copy parts of code from original one. From one side it is
> sad, because it's very ugly development model (for example if original
> project will be update, i need update my project too, so there are two
> "targets" for every update).  On another hand i could concentrate on
> new Pla9 techniques and create more powerful analogous of linux
> software.

Eventually, you'd think the autotools will fade, but reality sometimes
turns out illogical.  I think the "Plan 9 Way" will only become
dominant if there is a major change to the present status.

Strangely, no one criticises the Windows development tools...

++L

Re: [9fans] A newbie question...

[Filipp Andronov]

Thanks, this is very similar to my thoughts.

So if i want port some big linux application to Plan9 i need start new
project and copy parts of code from original one. From one side it is
sad, because it's very ugly development model (for example if original
project will be update, i need update my project too, so there are two
"targets" for every update).  On another hand i could concentrate on
new Pla9 techniques and create more powerful analogous of linux
software.

thanks for replies )

2008/2/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> > Main trouble in 1 step. Because after that i couldn't post in project
> > mail list, "Hey gays, i have create Plan9 port of your application,
> > please check it out and put in CVS trunk".
>
> There's no cure for this.  The touted portability of the autotools is
> restricted to the GNU environment and the moment you step outside of
> it, this is what occurs.  It's a philosophy that has turned into a
> religion largely by losing its focus or, if you prefer, shifting its
> objective.
>
> Plan 9 becomes the proof thereof, if autotools were as successful as
> claimed, it ought to be trivial to port them to a different platform.
> It isn't, nor is it necessary.  In porting the code for libtiff and
> geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools,
> png, gd and eventually libtiff and geotiff.  The sum total of these
> mkfiles is probably less than two thousand lines.  But it is
> impossible to feed these back to the developers, because they do not
> fit into their philosophical scheme.
>
> As another example, check out graphviz.  From version 1 to version 2
> (I think) they moved from a custom configurator to the autotools.
> Beside totally losing Plan 9 portability in the bargain, it is my
> impression that they spent more effort on the autotools details than
> in improving graphviz itself.
>
> ++L
>
>

Re: [9fans] A newbie question...

[lucio]

> Main trouble in 1 step. Because after that i couldn't post in project
> mail list, "Hey gays, i have create Plan9 port of your application,
> please check it out and put in CVS trunk".

There's no cure for this.  The touted portability of the autotools is
restricted to the GNU environment and the moment you step outside of
it, this is what occurs.  It's a philosophy that has turned into a
religion largely by losing its focus or, if you prefer, shifting its
objective.

Plan 9 becomes the proof thereof, if autotools were as successful as
claimed, it ought to be trivial to port them to a different platform.
It isn't, nor is it necessary.  In porting the code for libtiff and
geotiff to Plan 9 I added a few "mkfiles" to zlib, the jpeg tools,
png, gd and eventually libtiff and geotiff.  The sum total of these
mkfiles is probably less than two thousand lines.  But it is
impossible to feed these back to the developers, because they do not
fit into their philosophical scheme.

As another example, check out graphviz.  From version 1 to version 2
(I think) they moved from a custom configurator to the autotools.
Beside totally losing Plan 9 portability in the bargain, it is my
impression that they spent more effort on the autotools details than
in improving graphviz itself.

++L

Re: [9fans] A newbie question...

[Filipp Andronov]

Hmmm, my question was not about new ideological war "GNU vs Plan9". ))
I think that my bad English does not allow me to ask my question in
correct form, so i will show some sample :)

For example, in Linux i have some big application.
This application using autotools, so if a want to port it, for example
on different OS (of course if this OS has autotools) or hardware all i
need is go throw sources and put something like:
#ifdef RUN_IN_CYGWIN
 // some specific code
#endif
After that i need to add extra tests in configure and autotools will
do all magic for me :)
The main trouble is that all sources has really many pieces of #ifdef
code, so it could be very painful to drop out "portability in GNU
way".  But it's ok, until that is a only way.

Ok, for me "porting" to plan9 looks like:
1. Drop out autotools from project
2. Replace all OS specific code to Plan9 equivalent
3. Replace all libs to it's equivalent for plan9
4. and so on

Main trouble in 1 step. Because after that i couldn't post in project
mail list, "Hey gays, i have create Plan9 port of your application,
please check it out and put in CVS trunk". If i "port" some
application in that way, that mean that I've start new one, "from
scratch" and just copy & paste some code from original project :((

I hope that i have logical mistakes in my example, and you show me
that, because if not it could be very sad  :))



2008/2/3, Eris Discordia <[EMAIL PROTECTED]>:
> On Sun, 03 Feb 2008 00:30:38 -, Rob Pike <[EMAIL PROTECTED]> wrote:
>
> >>  An alternative interpretation is that the facts are skewed by the Bell
> >>  Labs reality distortion field.  The syllogism goes something like this:
> >>
> >>  All things not made at Bell Labs are bad
> >>  GNU is not made at Bell Labs
> >>  Therefore, GNU is bad
> >>
> >
> > If you think about what the letters of GNU stand for, you might
> > appreciate
> > that the forms are in mutual opposition.  They provide completely
> > different
> > approaches to software.  "Good" and "Bad" are value judgments.  If
> > you think GNU is the right way to build things, Plan 9 is probably not
> > for you, and vice versa.
> >
> > -rob
>
> Is that "the" Rob Pike? "The R?"
>
> If so, please accept me humble reverence, sire! Hallowed be thy practice
> (of programming)!
>
> P. S. Down here in my country, Iran, we have this tradition of inventing
> sacred things out of thin air. A considerable proportion of "the divine
> and the sacred" spilled all over the globe began with that frailty of ours
> :-D
>
> --
> Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
>

Re: [9fans] A newbie question...

[Eris Discordia]

On Sun, 03 Feb 2008 00:30:38 -, Rob Pike <[EMAIL PROTECTED]> wrote:


 An alternative interpretation is that the facts are skewed by the Bell
 Labs reality distortion field.  The syllogism goes something like this:

 All things not made at Bell Labs are bad
 GNU is not made at Bell Labs
 Therefore, GNU is bad



If you think about what the letters of GNU stand for, you might  
appreciate
that the forms are in mutual opposition.  They provide completely  
different

approaches to software.  "Good" and "Bad" are value judgments.  If
you think GNU is the right way to build things, Plan 9 is probably not
for you, and vice versa.

-rob


Is that "the" Rob Pike? "The R?"

If so, please accept me humble reverence, sire! Hallowed be thy practice  
(of programming)!


P. S. Down here in my country, Iran, we have this tradition of inventing  
sacred things out of thin air. A considerable proportion of "the divine  
and the sacred" spilled all over the globe began with that frailty of ours  
:-D


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: [9fans] A newbie question...

[john]

>> An alternative interpretation is that the facts are skewed by the Bell 
>> Labs reality distortion field.  The syllogism goes something like this:
>> 
>> All things not made at Bell Labs are bad
>> GNU is not made at Bell Labs
>> Therefore, GNU is bad
> 
> if this holds, then
> 
>   plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
>   these were not invented at bell labs
>   thus using plan 9 is bad.
> 
> - erik

I don't know that x86 qualifies as non-bad.

John

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Circular cause and consequence is funny. Let me add to this list:
- jpg
- png
- tiff
- PostScript
- TeX (tpic)
- HTML
- Mahjongg, sokoban, sudoku, tetris (games/4s)
- SPARC, MIPS, x64
- MP3, PCM, OGG (PAC was made at Bell Labs)
- SoundBlaster 16

Let me put it this way:
	GNU software is good, except for GNU development tools, which,  
except for the gcc program itself, are mediocre and break  
compatibility (try using a Bell Labs makefile with GNU make).


On Feb 2, 2008, at 8:42 PM, erik quanstrom wrote:

An alternative interpretation is that the facts are skewed by the  
Bell
Labs reality distortion field.  The syllogism goes something like  
this:


All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad


if this holds, then

plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
these were not invented at bell labs
thus using plan 9 is bad.

- erik

Re: [9fans] A newbie question...

[erik quanstrom]

> An alternative interpretation is that the facts are skewed by the Bell 
> Labs reality distortion field.  The syllogism goes something like this:
> 
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad

if this holds, then

plan 9 uses ip, smtp, dns, ntp, ethernet, x86, &c.
these were not invented at bell labs
thus using plan 9 is bad.

- erik

Re: [9fans] A newbie question...

[Uriel]

Except that Bell Labs has shown much more appreciation for things
invented outside than anyone else. Some of the best ideas in Unix were
lifted from Multics, the genius was to drop all the cruft. CSP is
another good example, ignored by a world that thinks pthreads is the
only way to write concurrent applications... and there are many other
examples that anyone that has done even the most cursory reading of
the Plan 9 will already know about.

Now, can you point to *anything* gnu has ever produced that is not at
best a hideously grotesque copy of something that might have made
sense thirty years ago.

uriel

P.S.: Sorry for being so easily trolled, but seems that I'm not the only one ;)

On Feb 3, 2008 2:17 AM, Robert William Fuller <[EMAIL PROTECTED]> wrote:
>
> Juan M. Mendez wrote:
> > On 02/02/2008, Martin Neubauer <[EMAIL PROTECTED]> wrote:
> >> * Uriel ([EMAIL PROTECTED]) wrote:
> >>> Autotools badness is way beyond most peoples wildest imagination...
> >> Unfortunately, you don't have to imagine.
> >
> > So what are the facts to back up so many posts regarding autotools badness?
> > Just curious.
>
> An alternative interpretation is that the facts are skewed by the Bell
> Labs reality distortion field.  The syllogism goes something like this:
>
> All things not made at Bell Labs are bad
> GNU is not made at Bell Labs
> Therefore, GNU is bad
>

Re: [9fans] A newbie question...

[Rob Pike]

>  An alternative interpretation is that the facts are skewed by the Bell
>  Labs reality distortion field.  The syllogism goes something like this:
>
>  All things not made at Bell Labs are bad
>  GNU is not made at Bell Labs
>  Therefore, GNU is bad
>

If you think about what the letters of GNU stand for, you might appreciate
that the forms are in mutual opposition.  They provide completely different
approaches to software.  "Good" and "Bad" are value judgments.  If
you think GNU is the right way to build things, Plan 9 is probably not
for you, and vice versa.

-rob

Re: [9fans] A newbie question...

[Robert William Fuller]

Juan M. Mendez wrote:

On 02/02/2008, Martin Neubauer <[EMAIL PROTECTED]> wrote:

* Uriel ([EMAIL PROTECTED]) wrote:

Autotools badness is way beyond most peoples wildest imagination...

Unfortunately, you don't have to imagine.


So what are the facts to back up so many posts regarding autotools badness?
Just curious.


An alternative interpretation is that the facts are skewed by the Bell 
Labs reality distortion field.  The syllogism goes something like this:


All things not made at Bell Labs are bad
GNU is not made at Bell Labs
Therefore, GNU is bad

Re: [9fans] A newbie question...

[ron minnich]

On Feb 2, 2008 11:22 AM, Juan M. Mendez <[EMAIL PROTECTED]> wrote:

> So what are the facts to back up so many posts regarding autotools badness?
> Just curious.

1. it's not needed. See plan9 ports and lots of other tools that
somehow get by without it.
2. a 150,000 line configure shell script? That right there should tell
you something's seriously wrong.
   but it happens.
3. it's not portable. Since the goal is portability, something has
been lost here.
4. Warning from the openib stack: you have version 1.59 (or some such)
of autotools, and I need 1.60
Oh, ok, there's a version of the configuration tools? What's wrong
with this picture?

It would all be funny but people actually use this stuff, and that's sad.

ron

Re: [9fans] A newbie question...

[Martin Neubauer]

* Pietro Gagliardi ([EMAIL PROTECTED]) wrote:
> Autotools increases portability by 57%, but then decreases  

Actually, they increase the _impression_ of portability by 57%. The other
effects are real, though.

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Autotools increases portability by 57%, but then decreases  
portability by 75% (mv -f, ls -i not available in Plan 9), decreases  
usability by 750%, and decreases sanity by 7500%. I wanted to  
contribute to AbIWord but it took me a long time before I got it  
built. :-( Then I discovered troff in the back of Kernighan/Pike and  
am much happier :-)


On Feb 2, 2008, at 1:27 PM, Martin Neubauer wrote:


* Uriel ([EMAIL PROTECTED]) wrote:

Autotools badness is way beyond most peoples wildest imagination...


Unfortunately, you don't have to imagine.

Re: [9fans] A newbie question...

[erik quanstrom]

> 
> So what are the facts to back up so many posts regarding autotools badness?
> Just curious.
> 

part of the issue is that autotool solves a problem that doesn't
exist on plan 9 systems.  one doesn't need to test for compilers,
exotic library problems or portability issues.  

(small rant: unfortunately, porting a lot of gnu stuff to plan 9 makes some
sort of compatability goo necessary again.)

another problem with autoconf is it encourages a style of
programming that exploits every last nook and cranny of
a system's & compiler's capabilities when the vast majority
of applications will do just fine with the least common
denominator.  if one's goal is to run on a variety of unix
systems, this just is poor engineering.

as a case in point, my sacrificial linux machine is a 993mhz
pIII.  mplayer, an application one would think would benefit
from fancy optimizations on such a slow machine, shows absolutely
no visible performance benefit from sse2 instructions.  it
is fast enough already.

imho, p9p and russ' unix extracts from p9p show a much
cleaner way to port unix stuff.  his method requires about 10
lines of system-specific stuff and about 75 lines
of Makefile.  

one last gripe: autotools often take longer to ./configure
than to compile with gcc.  curious that gcc is famed for
slowness.

- erik

Re: [9fans] A newbie question...

[Anthony Sorace]

On Feb 2, 2008 2:22 PM, Juan M. Mendez <[EMAIL PROTECTED]> wrote:

> So what are the facts to back up so many posts regarding autotools badness?

I mostly manage to avoid working on things where I've had to use them
as a producer, so I don't have the whole toolchain lying around. I'm
more than happy to judge them on their output, though. Just to pick
the first gnu* directory i spotted in my src directory in my $home,
gnutls:

: vav; wc config* Make*
15004928   44208 config.guess
 6223005   17933 config.h
 6212773   16967 config.h.in
6769   26859  211980 config.log
 5711566   14869 config.rpath
15485795   57952 config.status
16084255   32448 config.sub
   46730  159658 1393861 configure
 6321709   19218 configure.in
 8383222   27923 Makefile
  59 3332210 Makefile.am
 8383158   27552 Makefile.in
   62336  217261 1867121 total

That's an awful lot of work just to get the thing to build. Oh, but
it's all in the service of portability, I hear you say! Well, let's
contrast this to what we see on Plan 9:

: root; pwd
/sys/src
: root; wc mkfile mkfile.proto 9/*/mkfile cmd/mkfile cmd/mklib
cmd/mkmany cmd/mkone cmd/mksyslib cmd/*/mkfile | tail -1
   53238409   78037 total

That's for nearly every command, plus al the kernels. Every
architecture. Less than a tenth the size. And there's nothing magical
about Plan 9 here. Once can build things on Unix in just the same way;
some packages manage to resist the temptation.

That level of gluttony would, perhaps, be forgivable if it worked
reliably. But god forbid you try to do something slightly farther
afield than the packager anticipated (which, frequently, is Linux/386
plus maybe a BSD or two), or that the versions of the tools used
anticipated. Things will break, badly, in arbitrary places in an
incomprehensible mess of interconnected dependencies.

It's just the wrong solution to portability.
Anthony

Re: [9fans] A newbie question...

[Juan M. Mendez]

On 02/02/2008, Martin Neubauer <[EMAIL PROTECTED]> wrote:
> * Uriel ([EMAIL PROTECTED]) wrote:
> > Autotools badness is way beyond most peoples wildest imagination...
>
> Unfortunately, you don't have to imagine.

So what are the facts to back up so many posts regarding autotools badness?
Just curious.

-- 
Fidonet: 2:345/432.2

Re: [9fans] A newbie question...

[Martin Neubauer]

* Uriel ([EMAIL PROTECTED]) wrote:
> Autotools badness is way beyond most peoples wildest imagination...

Unfortunately, you don't have to imagine.

Re: [9fans] A newbie question...

[Uriel]

Autotools badness is way beyond most peoples wildest imagination...

uriel

On Feb 2, 2008 6:10 PM, Charles Forsyth <[EMAIL PROTECTED]> wrote:
> > But if autotools could "fly" under Plan9 it is not so bad as i think :))
>
> autotools is every bit as bad as one could think.
>
>

Re: [9fans] A newbie question...

[Filipp Andronov]

Thanks! ))

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> An implementation of Kaffe, a FOSS Java virtual machine, is available
> for Plan 9. I have never gotten it to work.
>
> http://plan9.aichi-u.ac.jp/netlib/kaffe/
>
> On Feb 2, 2008, at 10:48 AM, Filipp Andronov wrote:
>
> > Thanks, it is great news. Actually i have been shocked, may first
> > point of view was that it is too much for me, try to port some
> > software without gnu autotools support.
> > But if autotools could "fly" under Plan9 it is not so bad as i
> > think :))
> >
> > I have forgot, another one question: what about Java under Plan9? Is
> > it possible to have JVM? Or no suitable package available? ))
> >
> > 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> If the archive actually has a configure script, the best way to start
> >> configuring is with:
> >>
> >> % ape/psh
> >> # ./configure --prefix=$home --build=i386 --bindir=$home/bin/
> >> $objtype --lib=$home/lib
> >>
> >> On Feb 2, 2008, at 10:30 AM, Filipp Andronov wrote:
> >>
> >>> Thanks for a fast reply )
> >>> I'll check out documents about APE, if my questions will be actual
> >>> after that, i will post thous here.
> >>>
> >>> 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
>  Autotools is in the GCC package. However, there is a nice and clean
>  way to port alien software using APE:
> 
>  page /sys/doc/ape.ps
> 
>  On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:
> 
> > Hello everyone :)
> > I'm newbie in Plan9 system, so i have a couple of questions about
> > it :)
> >
> > And the first one looks like this: does GNU build system
> > (autoconf,
> > automake, e.t.c) has been ported in Plan9?  Or maybe there is some
> > alternative?  :)
> >
> > I want port some software from linux to Plan9, but couldn't
> > find any
> > documentation about how i should do this in "plan9 style" )
> >
> > PS: sorry for my horrible English :)
> >
> > 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >>
> >> And yes, gcc has been ported. I have never gotten it to work,
> >> though.
> >>
> >> On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:
> >>
> >>
> >> Another question from newbie :
> >>
> >> I have noticed some discussion(s) on Internet about C++ language
> >> for  Plan9;
> >> I'm wondering what is a bottom line of the story:
> >> - is there a C++ compiler? Any plans for it?
> >>  - has it been 'banned' from Plan9?
> >> - has gcc been ported to Plan9? ( as was suggested in one of the
> >> messages I
> >> saw)...
> >>
> >> Thank for your attention.
> >> Michael.
> >>
> >>
> >>
> 
> 
> >>
> >>
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

An implementation of Kaffe, a FOSS Java virtual machine, is available  
for Plan 9. I have never gotten it to work.


http://plan9.aichi-u.ac.jp/netlib/kaffe/

On Feb 2, 2008, at 10:48 AM, Filipp Andronov wrote:


Thanks, it is great news. Actually i have been shocked, may first
point of view was that it is too much for me, try to port some
software without gnu autotools support.
But if autotools could "fly" under Plan9 it is not so bad as i  
think :))


I have forgot, another one question: what about Java under Plan9? Is
it possible to have JVM? Or no suitable package available? ))

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:

If the archive actually has a configure script, the best way to start
configuring is with:

% ape/psh
# ./configure --prefix=$home --build=i386 --bindir=$home/bin/
$objtype --lib=$home/lib

On Feb 2, 2008, at 10:30 AM, Filipp Andronov wrote:


Thanks for a fast reply )
I'll check out documents about APE, if my questions will be actual
after that, i will post thous here.

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:

Autotools is in the GCC package. However, there is a nice and clean
way to port alien software using APE:

page /sys/doc/ape.ps

On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:


Hello everyone :)
I'm newbie in Plan9 system, so i have a couple of questions about
it :)

And the first one looks like this: does GNU build system  
(autoconf,

automake, e.t.c) has been ported in Plan9?  Or maybe there is some
alternative?  :)

I want port some software from linux to Plan9, but couldn't  
find any

documentation about how i should do this in "plan9 style" )

PS: sorry for my horrible English :)

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:


And yes, gcc has been ported. I have never gotten it to work,
though.

On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:


Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language
for  Plan9;
I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
 - has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the
messages I
saw)...

Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Charles Forsyth]

> But if autotools could "fly" under Plan9 it is not so bad as i think :))

autotools is every bit as bad as one could think.

Re: [9fans] A newbie question...

[Filipp Andronov]

Thanks, it is great news. Actually i have been shocked, may first
point of view was that it is too much for me, try to port some
software without gnu autotools support.
But if autotools could "fly" under Plan9 it is not so bad as i think :))

I have forgot, another one question: what about Java under Plan9? Is
it possible to have JVM? Or no suitable package available? ))

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> If the archive actually has a configure script, the best way to start
> configuring is with:
>
> % ape/psh
> # ./configure --prefix=$home --build=i386 --bindir=$home/bin/
> $objtype --lib=$home/lib
>
> On Feb 2, 2008, at 10:30 AM, Filipp Andronov wrote:
>
> > Thanks for a fast reply )
> > I'll check out documents about APE, if my questions will be actual
> > after that, i will post thous here.
> >
> > 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >> Autotools is in the GCC package. However, there is a nice and clean
> >> way to port alien software using APE:
> >>
> >> page /sys/doc/ape.ps
> >>
> >> On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:
> >>
> >>> Hello everyone :)
> >>> I'm newbie in Plan9 system, so i have a couple of questions about
> >>> it :)
> >>>
> >>> And the first one looks like this: does GNU build system (autoconf,
> >>> automake, e.t.c) has been ported in Plan9?  Or maybe there is some
> >>> alternative?  :)
> >>>
> >>> I want port some software from linux to Plan9, but couldn't find any
> >>> documentation about how i should do this in "plan9 style" )
> >>>
> >>> PS: sorry for my horrible English :)
> >>>
> >>> 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> 
>  And yes, gcc has been ported. I have never gotten it to work,
>  though.
> 
>  On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:
> 
> 
>  Another question from newbie :
> 
>  I have noticed some discussion(s) on Internet about C++ language
>  for  Plan9;
>  I'm wondering what is a bottom line of the story:
>  - is there a C++ compiler? Any plans for it?
>   - has it been 'banned' from Plan9?
>  - has gcc been ported to Plan9? ( as was suggested in one of the
>  messages I
>  saw)...
> 
>  Thank for your attention.
>  Michael.
> 
> 
> 
> >>
> >>
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

If the archive actually has a configure script, the best way to start  
configuring is with:


% ape/psh
	# ./configure --prefix=$home --build=i386 --bindir=$home/bin/ 
$objtype --lib=$home/lib


On Feb 2, 2008, at 10:30 AM, Filipp Andronov wrote:


Thanks for a fast reply )
I'll check out documents about APE, if my questions will be actual
after that, i will post thous here.

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:

Autotools is in the GCC package. However, there is a nice and clean
way to port alien software using APE:

page /sys/doc/ape.ps

On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:


Hello everyone :)
I'm newbie in Plan9 system, so i have a couple of questions about
it :)

And the first one looks like this: does GNU build system (autoconf,
automake, e.t.c) has been ported in Plan9?  Or maybe there is some
alternative?  :)

I want port some software from linux to Plan9, but couldn't find any
documentation about how i should do this in "plan9 style" )

PS: sorry for my horrible English :)

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:


And yes, gcc has been ported. I have never gotten it to work,  
though.


On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:


Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language
for  Plan9;
I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
 - has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the
messages I
saw)...

Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Filipp Andronov]

Thanks for a fast reply )
I'll check out documents about APE, if my questions will be actual
after that, i will post thous here.

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> Autotools is in the GCC package. However, there is a nice and clean
> way to port alien software using APE:
>
> page /sys/doc/ape.ps
>
> On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:
>
> > Hello everyone :)
> > I'm newbie in Plan9 system, so i have a couple of questions about
> > it :)
> >
> > And the first one looks like this: does GNU build system (autoconf,
> > automake, e.t.c) has been ported in Plan9?  Or maybe there is some
> > alternative?  :)
> >
> > I want port some software from linux to Plan9, but couldn't find any
> > documentation about how i should do this in "plan9 style" )
> >
> > PS: sorry for my horrible English :)
> >
> > 2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
> >>
> >> And yes, gcc has been ported. I have never gotten it to work, though.
> >>
> >> On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:
> >>
> >>
> >> Another question from newbie :
> >>
> >> I have noticed some discussion(s) on Internet about C++ language
> >> for  Plan9;
> >> I'm wondering what is a bottom line of the story:
> >> - is there a C++ compiler? Any plans for it?
> >>  - has it been 'banned' from Plan9?
> >> - has gcc been ported to Plan9? ( as was suggested in one of the
> >> messages I
> >> saw)...
> >>
> >> Thank for your attention.
> >> Michael.
> >>
> >>
> >>
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Autotools is in the GCC package. However, there is a nice and clean  
way to port alien software using APE:


page /sys/doc/ape.ps

On Feb 2, 2008, at 2:12 AM, Filipp Andronov wrote:


Hello everyone :)
I'm newbie in Plan9 system, so i have a couple of questions about  
it :)


And the first one looks like this: does GNU build system (autoconf,
automake, e.t.c) has been ported in Plan9?  Or maybe there is some
alternative?  :)

I want port some software from linux to Plan9, but couldn't find any
documentation about how i should do this in "plan9 style" )

PS: sorry for my horrible English :)

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:


And yes, gcc has been ported. I have never gotten it to work, though.

On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:


Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language  
for  Plan9;

I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
 - has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the  
messages I

saw)...

Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Steve Simon]

> - is there a C++ compiler? Any plans for it?

Cfront is available but you will be shocked if you expect it
to replace gcc - it is very old now, and though it could be
improved if somone was willing to do the work it would require
quite some dedication.

Getting g++ to work would be the best way to get a modern
C++ compiler on plan9 for free.

If you have money the Comeau computing supply both a portable
compiler and a GCC compliant C++ to C translator (both based
on the EDG front-end), however there is no plan9 port, yet.

http://www.comeaucomputing.com/
http://www.edg.com/

-Steve

Re: [9fans] A newbie question...

[Filipp Andronov]

Hello everyone :)
I'm newbie in Plan9 system, so i have a couple of questions about it :)

And the first one looks like this: does GNU build system (autoconf,
automake, e.t.c) has been ported in Plan9?  Or maybe there is some
alternative?  :)

I want port some software from linux to Plan9, but couldn't find any
documentation about how i should do this in "plan9 style" )

PS: sorry for my horrible English :)

2008/2/2, Pietro Gagliardi <[EMAIL PROTECTED]>:
>
> And yes, gcc has been ported. I have never gotten it to work, though.
>
> On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:
>
>
> Another question from newbie :
>
> I have noticed some discussion(s) on Internet about C++ language for  Plan9;
> I'm wondering what is a bottom line of the story:
> - is there a C++ compiler? Any plans for it?
>  - has it been 'banned' from Plan9?
> - has gcc been ported to Plan9? ( as was suggested in one of the messages I
> saw)...
>
> Thank for your attention.
> Michael.
>
>
>

Re: [9fans] A newbie question...

[Pietro Gagliardi]

And yes, gcc has been ported. I have never gotten it to work, though.

On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:


Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language  
for  Plan9;

I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
- has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the  
messages I saw)...


Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Pietro Gagliardi]

C++ has not been included in Plan 9 since the third edition, but the  
source code is available, and Steve Simon has made some updates.


Once you have abaco the way I said to get it, you also have Federico  
Benavento's contrib system. With it, all you need is


contrib/install steve/cfront

Otherwise, get contrib with

/n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib

and then do the above. Then, to compile a C++ program:

c++/8c x.C # considering .C is the C++ extension
c++/8l -o x x.8

The one thing: don't use

#include 
using namespace std;

You will need

#include 

which does that for you.

On Feb 1, 2008, at 11:43 PM, Michael Andronov wrote:


Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language  
for  Plan9;

I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
- has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the  
messages I saw)...


Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Michael Andronov]

Another question from newbie :

I have noticed some discussion(s) on Internet about C++ language for  Plan9;

I'm wondering what is a bottom line of the story:
- is there a C++ compiler? Any plans for it?
- has it been 'banned' from Plan9?
- has gcc been ported to Plan9? ( as was suggested in one of the messages I
saw)...

Thank for your attention.
Michael.

Re: [9fans] A newbie question...

[Michael Andronov]

Thank you everyone for your speedy and informative replies.

In my everyday work, I'm using gcc, web browser, instant messenger to
communicate with the rest of the team,
and  occasionally office suite to provide reports to the customers...

It seems like Plan9 can handle the tasks ( at least most of them ),  so I am
tempting to try it ...

Thanks once again for info.

Michael.

Re: [9fans] A newbie question...

[John Stalker]

> I'm a new to Plan9, and I am trying to understand the current status of the
> system.
> In particular, I am wondering about the list of application available
> - is there  email reader?
> - Web browser?
> - office like suite = document editor, spreadsheet?
> - is it possible to run Linux software under plan9?
> 
> In other words, I am wondering if it is possible to switch to Plan 9 system,
> and to use it as 'everyday machine'?

Most of what's worth saying has already bee said, but I would note three things:
1) Various people metioned troff.  TeX is also supported, and is better at
   some things, though worse at others.  Personally I use TeX.
2) For things other people do with spreadsheets I use awk.  If you keep the data
   as csv, i.e. text fields separated by commas, then awk can manipulate them 
easily
   and you still have the option of importing into Excel if you ever need to.  
I do
   everything this way: students grades, financial accounts, etc.  The editor 
sam
   has a simple facility for piping a file through a command, in this case awk, 
so
   you can update everything with a few mouse clicks.
3) Consider running plan9ports rather than a full plan9 installation.  I've done
   both.  Which is better depends on what you are doing.
-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] A newbie question...

[Pietro Gagliardi]

Do you know how to use the Acme editor? You use abaco in a similar  
fashion.


If you mean a full office suite like Microsoft Word/Excel/PowerPoint  
with a GUI interface, then no. But troff is easy to learn. Here's a  
rough tutorial for troff: troff documents are text files sent through  
the troff program and its preprocessors to get a document. For  
example, if you have a file named mydoc, the command

troff mydoc | page
lets you preview your document, and
troff mydoc | lp -dmyprinter
sends it to your printer, replacing myprinter with the device name,

troff is commonly used with a macro set, which defines formatting.  
The most common macro set is ms, created by Mike Lesk. To format a  
document with ms support:

troff -ms mydoc | [output command]
Here is the structure of an ms document:
.TL
Title
.AU
Author
.AB
Abstract
.AE
.NH
Numbered heading
.PP
Paragraph
.IP \(bu
Bulleted paragraph
.IP 1.
Numbered paragraph
.IP 2.
List item number 2
.LP
Left-aligned paragraph
.SH
Section heading
.NH 2
Level 2 numbered heading (1.1)
.PP
Text in
.B bold
and
.I italic .

Lines beginning with a . are troff/ms commands. If your document has  
no abstract, use


.AB no
.AE

A preprocessor is filtered through before troff. For example, a  
document with tables, equations, and pictures uses the command line

pic mydoc | tbl | eqn | troff -ms | [output program]
tbl, also by Mike Lesk, creates tables.
.TS
center, box;
c s
r l.
Title of table
_
A   B
C   D
E   F
.TE
The line
center, box;
is obvious - it affects the whole table.
c s
tells the first row to be centered and all columns spanned, and
r l.
tells the rest of the rows to have a right-adjusted column and a left- 
adjusted column. Column data is separated by tabs. If a line is

_
then a horizontal line is placed.

eqn formats equations.
.EQ
	sum from n=1 to infinity { x sup 2 } ~ -> ~ { infinity sub n sup 2 }  
over 4n

.EN
The ~ gives an explicit space, and { } perform grouping. Embedded  
equations are also supported:

.EQ
delim @@
.EN
.PP
... the conversion factor from radians to degrees is @180 / pi@

pic is a simple picture language.
.PS
box "hello"
arrow
box "how" "are you?"
box wid 2 "widths are" "in inches"
arrow <->
ellipse
.PE

pic and eqn are by Brian Kernighan, and eqn was co-written by Lorinda  
Cherry. The official documentation for many of these tools can be  
found at:

- http://cm.bell-labs.com/cm/cs/cstr.html
- http://cm.bell-labs.com/cm/cs/papers.html
And again, see troff.org for more information:
abaco http://www.troff.org/

To download a paper from the above,
1) Snarf the link. Snarf is to Plan 9 as copy is to Windows/Mac OS X/ 
Linux.

2) In a command line, type "hget " without hitting Enter.
3) Middle-click and choose "paste".
4) If the file is .ps.gz, type "| gunzip > x.ps" replacing x with the  
document's intended name. Otherwise, just say "> x.ps" or "> x.pdf".

5) Run page on the ps/pdf file.

On Jan 31, 2008, at 7:22 PM, Michael Andronov wrote:


Hi,

I'm a new to Plan9, and I am trying to understand the current  
status of the system.

In particular, I am wondering about the list of application available=
- is there  email reader?
- Web browser?
- office like suite = document editor, spreadsheet?
- is it possible to run Linux software under plan9?

In other words, I am wondering if it is possible to switch to Plan  
9 system, and to use it as 'everyday machine'?


Thank you for your kind attention to this matter.

have a great day,
Michael.

Re: [9fans] A newbie question...

[john]

>> I'm a new to Plan9, and I am trying to understand the current status of the
>> system.
>> In particular, I am wondering about the list of application available=
>> - is there  email reader?
>> - Web browser?
>> - office like suite = document editor, spreadsheet?
>> - is it possible to run Linux software under plan9?
> 
> yes, not really, no, no.
> 

You could, of course, use troff to make documents.
And linuxemu seems able to provide both Linux software capability
and a web browser...

>> 
>> In other words, I am wondering if it is possible to switch to Plan 9 system,
>> and to use it as 'everyday machine'?
> 
> i use plan 9 as my everyday machine both at home and at work.
> 
> - erik

I use Plan 9 at work every day, it's pretty good.

Re: [9fans] A newbie question...

[Pietro Gagliardi]

On Jan 31, 2008, at 7:22 PM, Michael Andronov wrote:


Hi,

I'm a new to Plan9, and I am trying to understand the current  
status of the system.

In particular, I am wondering about the list of application available=
- is there  email reader?


Several ways to do this, but to set up:
http://plan9.bell-labs.com/wiki/plan9/Mail_configuration/index.html



- Web browser?


The most actively developed is abaco. Type, on the command line:
9fs sources
/n/sources/contrib/fgb/root/rc/contrib/install fgb/contrib
contrib/install fgb/abaco
Then type
abaco http://website.com/
You will need the http://.



- office like suite = document editor, spreadsheet?


Document editor is troff. There is no built-in spreadsheet, just  
maintain a text database. There are resources for learning troff;  
http://www.troff.org/ is a good place to start.




- is it possible to run Linux software under plan9?


Yes, there is an in-development program called linuxemu. I don't have  
much info on it, though.





In other words, I am wondering if it is possible to switch to Plan  
9 system, and to use it as 'everyday machine'?


Thank you for your kind attention to this matter.

have a great day,
Michael.