[9fans] Building GCC

[9fans] Building GCC

[Pietro Gagliardi]

Hello. I finally got X11 installed and running - you need to change / 
sys/src/X11/programs/Xserver/Xext/shape.c to the one in my /n/sources/ 
contrib/pietro - and step 2 of my plans is to get GCC up and running.  
I extracted gnubin.tgz and gnusrc.tgz and tried this:

	cd /sys/src/gnu
	gnu/gsh
	mk all

but all I got was, after the configure of autoconf,

	make: Entering directory '/sys/src/gnu/autoconf-2.50'
	make: *** No targets specified and no makefile found. Stop.
	make: Leaving directory '/sys/src/gnu/autoconf-2.50'

and then mk aborts. Am I doing anything wrong? Thanks.

Re: [9fans] Building GCC

[andrey mirtchovski]

> and then mk aborts. Am I doing anything wrong? Thanks.

there's a script in the source directory called p9config, take a look at it.

Re: [9fans] Building GCC

[Pietro Gagliardi]

The mkfile is told to run p9config. I tried that manually on each  
directory, with the same result.

On Jan 20, 2008, at 3:57 PM, andrey mirtchovski wrote:

>> and then mk aborts. Am I doing anything wrong? Thanks.
>
> there's a script in the source directory called p9config, take a  
> look at it.

Re: [9fans] Building GCC

[Federico G. Benavento]

% ../p9config gcc
or something like that

On Jan 20, 2008 6:05 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> The mkfile is told to run p9config. I tried that manually on each
> directory, with the same result.
>
>
> On Jan 20, 2008, at 3:57 PM, andrey mirtchovski wrote:
>
> >> and then mk aborts. Am I doing anything wrong? Thanks.
> >
> > there's a script in the source directory called p9config, take a
> > look at it.
>
>



-- 
Federico G. Benavento

Re: [9fans] Building GCC

[Pietro Gagliardi]

Yes, I realize that. It's more like

	../p9config gcc-3.0

But if you run that from rc, you get

	/bin/sh: not found
	/bin/make: not found

And if you run that from gnu/gsh, you get my original errors after a  
successful config. This time, I'll try

	gnu/gsh
	cp ../p9config .
	p9config gcc-4.0

On Jan 20, 2008, at 5:22 PM, Federico G. Benavento wrote:

> % ../p9config gcc
> or something like that
>
> On Jan 20, 2008 6:05 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
>> The mkfile is told to run p9config. I tried that manually on each
>> directory, with the same result.
>>
>>
>> On Jan 20, 2008, at 3:57 PM, andrey mirtchovski wrote:
>>
>>>> and then mk aborts. Am I doing anything wrong? Thanks.
>>>
>>> there's a script in the source directory called p9config, take a
>>> look at it.
>>
>>
>
>
>
> -- 
> Federico G. Benavento

Re: [9fans] Building GCC

[Pietro Gagliardi]

Didn't work

On Jan 20, 2008, at 6:41 PM, Pietro Gagliardi wrote:

> Yes, I realize that. It's more like
>
> 	../p9config gcc-3.0
>
> But if you run that from rc, you get
>
> 	/bin/sh: not found
> 	/bin/make: not found
>
> And if you run that from gnu/gsh, you get my original errors after  
> a successful config. This time, I'll try
>
> 	gnu/gsh
> 	cp ../p9config .
> 	p9config gcc-4.0
>
> On Jan 20, 2008, at 5:22 PM, Federico G. Benavento wrote:
>
>> % ../p9config gcc
>> or something like that
>>
>> On Jan 20, 2008 6:05 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
>>> The mkfile is told to run p9config. I tried that manually on each
>>> directory, with the same result.
>>>
>>>
>>> On Jan 20, 2008, at 3:57 PM, andrey mirtchovski wrote:
>>>
>>>>> and then mk aborts. Am I doing anything wrong? Thanks.
>>>>
>>>> there's a script in the source directory called p9config, take a
>>>> look at it.
>>>
>>>
>>
>>
>>
>> -- 
>> Federico G. Benavento
>

Re: [9fans] Building GCC

[benavento]

> Didn't work

if I'm not mistaken make is looking for makefile and not Makefile
or the oposite, something like that.

Re: [9fans] Building GCC

[Pietro Gagliardi]

% gnu/gsh
# make -f Makefile
make: No rule for target all-am. Stop.
# grep all-am Makefile
all-am: ...

On Jan 20, 2008, at 6:47 PM, benavento@gmail.com wrote:

>> Didn't work
>
> if I'm not mistaken make is looking for makefile and not Makefile
> or the oposite, something like that.
>

Re: [9fans] Building GCC

[Pietro Gagliardi]

I think I know what the problem is: the problem is with mv.  
Apparently, autotools (the program suite that generates configure  
files) seems to be fixed on the fact that mv has an -f option that  
works just like rm -f. However, Plan 9 mv doesn't, so mv thinks -f is  
a file and will try to make the output a directory. That's bad.  
Anyways, I modified configure and move-if-something (used by some  
configure files) to remove -f. I'll add -f to Plan 9 mv as a no-op  
later.

On Jan 20, 2008, at 6:50 PM, Pietro Gagliardi wrote:

> % gnu/gsh
> # make -f Makefile
> make: No rule for target all-am. Stop.
> # grep all-am Makefile
> all-am: ...
>
> On Jan 20, 2008, at 6:47 PM, benavento@gmail.com wrote:
>
>>> Didn't work
>>
>> if I'm not mistaken make is looking for makefile and not Makefile
>> or the oposite, something like that.
>>
>

Re: [9fans] Building GCC

[erik quanstrom]

> configure files) to remove -f. I'll add -f to Plan 9 mv as a no-op  
> later.

in this case, later should be defined as, for any time t, "later" is at
least one second in the future.

- erik

Re: [9fans] Building GCC

[Kernel Panic]

Pietro Gagliardi wrote:

> I think I know what the problem is: the problem is with mv.  
> Apparently, autotools (the program suite that generates configure  
> files) seems to be fixed on the fact that mv has an -f option that  
> works just like rm -f. However, Plan 9 mv doesn't, so mv thinks -f is  
> a file and will try to make the output a directory. That's bad.  
> Anyways, I modified configure and move-if-something (used by some  
> configure files) to remove -f. I'll add -f to Plan 9 mv as a no-op  
> later.

why not just make a wrapper script that you bind to /bin and that calls 
/$objtype/bin/mv without -f parameter?

cinap

Re: [9fans] Building GCC

[Brantley Coile]

Better yet, why not copy mv somewhere local to Gcc and add it
as a no-op there?  Do we really have to start seeing system
contamination from GCC in the released system?  The slope feels
slippery here.

Pietro Gagliardi wrote:
>I'll add -f to Plan 9 mv as a no-op  later.

Re: [9fans] Building GCC

[Steve Simon]

>>I'll add -f to Plan 9 mv as a no-op  later.
> Better yet, why not copy mv somewhere local to Gcc and add it

There is a precident for adding scripts to massage APE command
line options before envoking the plan9 executable, for example
/rc/bin/ape/ls.

-Steve

Re: [9fans] Building GCC

[Pietro Gagliardi]

However, the problem is that I'm not sure how, or where, to put this  
new mv so that ape/psh and gnu/gsh read this new one instead of the  
old one. I successfully masked ln to cp and head to a modified  
version of /n/sources/contrib/arisawa/misc/head, so everything else  
works.

And now there really is no Makefile! configure says it is producing  
one, but I see none. I'll try the other folders to see what I get.

On Jan 21, 2008, at 3:54 PM, Steve Simon wrote:

>>> I'll add -f to Plan 9 mv as a no-op  later.
>> Better yet, why not copy mv somewhere local to Gcc and add it
>
> There is a precident for adding scripts to massage APE command
> line options before envoking the plan9 executable, for example
> /rc/bin/ape/ls.
>
> -Steve

Re: [9fans] Building GCC

[Pietro Gagliardi]

New question: when was GCC for Plan 9 written? Third edition Plan 9?  
Here's why: I only had to change one file to compile X11 for Plan 9,  
which was developed on Brazil, which became Fourth Edition. I noticed  
that some software I wanted to port uses X11R6, the version  
available. My goal is to port Qt 4 to Plan 9, and then KDE 4. My idea  
is that we can have a lot of Plan 9 software ready for end users in a  
short amount of time.

The problem is, when I try to compile a hello, world C++ program with  
gnu/gcc and gnu/g++, it tells me it can't find the iostream file, so  
I'm thinking that you have to build from source. I tried iostream.h,  
but to no avail.

Another thing I was trying to port was a library for reading ID3  
tags, because the games/mp3tag that I got a while back was ID3v1, and  
my tags are ID3v2.

On Jan 21, 2008, at 3:54 PM, Steve Simon wrote:

>>> I'll add -f to Plan 9 mv as a no-op  later.
>> Better yet, why not copy mv somewhere local to Gcc and add it
>
> There is a precident for adding scripts to massage APE command
> line options before envoking the plan9 executable, for example
> /rc/bin/ape/ls.
>
> -Steve

Re: [9fans] Building GCC

[erik quanstrom]

> The problem is, when I try to compile a hello, world C++ program with  
> gnu/gcc and gnu/g++, it tells me it can't find the iostream file, so  
> I'm thinking that you have to build from source. I tried iostream.h,  
> but to no avail.

the c++ header files <iostream> and <iostream.h> are much different files.

- erik

Re: [9fans] Building GCC

[Fazlul Shahriar]

> Another thing I was trying to port was a library for reading ID3  
> tags, because the games/mp3tag that I got a while back was ID3v1, and  
> my tags are ID3v2.

Maybe you can use this:
	http://swtch.com/juke/mp3info.c
It's written for plan9port but works just fine on Plan 9.

Re: [9fans] Building GCC

[Pietro Gagliardi]

(Almost) perfect. I'll modify it to print in the format required by  
axel's mkmap/du2map.

On Jan 21, 2008, at 6:25 PM, Fazlul Shahriar wrote:

>> Another thing I was trying to port was a library for reading ID3
>> tags, because the games/mp3tag that I got a while back was ID3v1, and
>> my tags are ID3v2.
>
> Maybe you can use this:
> 	http://swtch.com/juke/mp3info.c
> It's written for plan9port but works just fine on Plan 9.
>

Re: [9fans] Building GCC

[Pietro Gagliardi]

After mkmap didn't generate a good enough map file and every  
modification I tried to make ended up in disaster, I decided to just  
generate my map files by hand. But I'd still like to run GCC to  
compile Qt/KDE.

On Jan 21, 2008, at 6:31 PM, Pietro Gagliardi wrote:

> (Almost) perfect. I'll modify it to print in the format required by  
> axel's mkmap/du2map.
>
> On Jan 21, 2008, at 6:25 PM, Fazlul Shahriar wrote:
>
>>> Another thing I was trying to port was a library for reading ID3
>>> tags, because the games/mp3tag that I got a while back was ID3v1,  
>>> and
>>> my tags are ID3v2.
>>
>> Maybe you can use this:
>> 	http://swtch.com/juke/mp3info.c
>> It's written for plan9port but works just fine on Plan 9.
>>
>

Re: [9fans] Building GCC

[Russ Cox]

> New question: when was GCC for Plan 9 written? Third edition Plan 9?  
> Here's why: I only had to change one file to compile X11 for Plan 9,  
> which was developed on Brazil, which became Fourth Edition. I noticed  
> that some software I wanted to port uses X11R6, the version  
> available. My goal is to port Qt 4 to Plan 9, and then KDE 4. My idea  
> is that we can have a lot of Plan 9 software ready for end users in a  
> short amount of time.

why use plan 9 at all?  why not just install linux or freebsd?

russ

Re: [9fans] Building GCC

[Harri Haataja]

On Tue, Jan 22, 2008 at 07:15:29AM -0500, Russ Cox wrote:
> > New question: when was GCC for Plan 9 written? Third edition Plan 9?  
> > Here's why: I only had to change one file to compile X11 for Plan 9,  
> > which was developed on Brazil, which became Fourth Edition. I noticed  
> > that some software I wanted to port uses X11R6, the version  
> > available. My goal is to port Qt 4 to Plan 9, and then KDE 4. My idea  
> > is that we can have a lot of Plan 9 software ready for end users in a  
> > short amount of time.
> 
> why use plan 9 at all?  why not just install linux or freebsd?

So rio and the compiler suite are the only good things in plan9?

-- 
To know what you prefer, instead of humbly saying Amen
to what the world tells you you ought to prefer,
is to have kept your soul alive.
	-- Robert Louis Stevenson

Re: [9fans] Building GCC

[lucio]

> So rio and the compiler suite are the only good things in plan9?

>From purely a user's perspective, that may be a valid opinion.  I use
ACME a lot as my editor of preference, but also as my mail user agent.

But the real power of Plan 9 is not going to be exploited by a user to
whom a private namespace is a mysterious, uninteresting concept.  Nor
is multi-platform portability going to matter or a tight, powerful
shell.

Let them eat cake!

++L

Re: [9fans] Building GCC

[erik quanstrom]

> > > New question: when was GCC for Plan 9 written? Third edition Plan 9?  
> > > Here's why: I only had to change one file to compile X11 for Plan 9,  
> > > which was developed on Brazil, which became Fourth Edition. I noticed  
> > > that some software I wanted to port uses X11R6, the version  
> > > available. My goal is to port Qt 4 to Plan 9, and then KDE 4. My idea  
> > > is that we can have a lot of Plan 9 software ready for end users in a  
> > > short amount of time.
> > 
> > why use plan 9 at all?  why not just install linux or freebsd?
> 
> So rio and the compiler suite are the only good things in plan9?

this is probably the purist in me speaking, but ...

so if you buy a chevy and you add a ford motor, transmission, 
sheet metal, and seats, chevy guys are going to tell you that they
didn't figure you could do worse than ford, but they were wrong.
ford guys are going to tell you that the beauty may be skin deep,
but chevy goes to the bone.

by the way, running kde and x will make running acme and all
other plan 9 graphical applications more difficult.  you'll need
to port p9p draw back from linux.  kde will need an education
to know about plumbing, namespaces. fileservers in the plan9
sense.  maybe you don't use these things.

- erik

Re: [9fans] Building GCC

[Brantley Coile]

Instead of working on porting lots of stuff from a 1980's system, why
not spend the time writing new code to do neat things using the Plan 9
model.  You would learn more than just compiling a mountain of code
and it would help make Plan 9 a better place.  See the wiki for ideas,
or think of something you would like to have and write that.  There's
lots of work to be done.  And you'll find creating more satisfying
than merely compiling.

Brantley

[9fans] Re: Building GCC

[pavlovetsky]

We can not grip the system tightly and prescribe particular
application and use of it; instead, we must allow people to use it for
their own purposes. The more general the system, the better, and this
is the UNIX principle. If someone wants to build an environment he
feels comfortable with, but still, not leaving the splendid grounds of
Plan9 - great! Doesn´t it? This is customisation.

Personally, I would be happy as a child to see, say, web browser built
using native environment and fully copliant. It never will be, though,
for the simple reason - to be fully comliant, web browser must render
flash content and Java Script as a minimum, but there are also many
other web technologies, which are accessible through special,
proprietary plugins. The Flash Player is proprietary and, as a shared
library it is distributed for three mainstream operating systems and a
couple industrial UNIX systems. You will never get it for Plan9 until
it will become either standard industrial and/or mainstream. From the
purist point of view it is bad, because system looses its original
integrity, many flavours evolve and distasteful cruft appears. But, in
the end, this is evolution. This is the only way to survive. The more
people will use Plan9 the better, even if they do it in not so elegant
way.

It is senseless and impossible to reinvent every single weel. People
must port things, it will strengthen the system.

Re: [9fans] Re: Building GCC

[Harri Haataja]

On Wed, Jan 23, 2008 at 09:35:25AM +0000, pavlovetsky@gmail.com wrote:
> The Flash Player is proprietary and, as a shared
> library it is distributed for three mainstream operating systems and a
> couple industrial UNIX systems. You will never get it for Plan9 until
> it will become either standard industrial and/or mainstream. 

btw, re:flash:
http://en.wikipedia.org/wiki/Gnash

Not that it's viable (now), but it doesn't seem completely hopeless.

-- 
On the sixth day, God created the platypus.
And God said: let's see the evolutionists try and figure this one out.

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 23, 1:16 pm, harr...@mail.student.oulu.fi (Harri Haataja)
wrote:
> On Wed, Jan 23, 2008 at 09:35:25AM +0000, pavlovet...@gmail.com wrote:
> > The Flash Player is proprietary and, as a shared
> > library it is distributed for three mainstream operating systems and a
> > couple industrial UNIX systems. You will never get it for Plan9 until
> > it will become either standard industrial and/or mainstream.
>
> btw, re:flash:http://en.wikipedia.org/wiki/Gnash
>
> Not that it's viable (now), but it doesn't seem completely hopeless.
>
> --
> On the sixth day, God created the platypus.
> And God said: let's see the evolutionists try and figure this one out.

In my very personal opinion it is close to impossible to win a race
when the organizer is changing the track all the time in favor to a
particular racer. And in case of Flash the organizer and the racer is
the same entity. I dont want to attract the attention of the audience
to the web browser issue once again in this group, but look - we have,
just for example, web browser, the code of which is open, the
"industry" accepted it and supplies all necessary plugins to it. You
can hate it, but still you can build it and use it. The nuance with
using it, if ever, on Plan 9 system is that you are unable to use
Flash, which I, personally, consider as critical feature (it is 2008,
for God sake, there is Flash everywhere). So, maybe, you can build
mozilla without Flash, but for me it seems a bit pointless; the
solution is to use linuxemu, Xvnc, I think.

Returning to my main point: it is productive to let many Plan 9
appearances to be. If you insist on developing the core technologies
and push forward ideas - fine. If someone wants to use KDE - that is
okay too, because, in the end, everybody wins. The important thing is
to provide real diversity of ways to use the system and to ensure that
there is freedom to choose and there is someone to talk to get help.
Just like the ports in FreeBSD: you can build the system from any
components you fancy and get the unique machine, customized to your
purpose. Nobody forces you to stuck to certain applications and ways
to do work, why the heck somebody would?

I really can understand the reason why people object porting things to
Plan 9. It is like making bazaar in a cathedral, right? This, I think,
means to force the operating system to stay in research form for the
sake of computer scientists themselves! Lets drop web browser and KDE
for a while and say this: there are cool, interactive scientific
visualisation tools I would like to use along with fossil+venti
infrastructure and Plan 9 tools and I would like to see them
integrated with each other really well. As I said, it is absolutely
impossible to reinvent everything again, so the question is how to
integrate the already existing applications for UNIX and Plan 9. I
vote for emulation.

Re: [9fans] Re: Building GCC

[Steve Simon]

Ok, my 2¢ worth.

I turn flash off on all the browsers I use, I find it irritating and
slows things down. All I seem to lose is a few animated jokes and a load
of adverts - maybe its the websites I visit.

I agree linuxemu is the only practical way to get a "fully compliant browser
experience".

Having said this I shall contadict it, If abaco had css (en route) and if
webfs has a good cache then I would be fine for 95% of my needs. In its
present form I use it for (say) 40% of the time. This is actually more to do
with its performance (much of which appears to be the lack of a cache).

I vote 1 for abaco for most stuff, and firefox under linuxemu for accessing my bank.

I want my cake and eat it.

-Steve

Re: [9fans] Re: Building GCC

[benavento]

we've seen this kind discusion before, yesterday I reread
the "gcc on plan 9" thread wich has 245 posts, just for fun.

it seems that slowly, _really_ slowly, we are getting there,
I mean, nowadays you can run opera under linuxemu!

on another note I ported yet another mp3dec, this one
is small, public domain and compiles fine with ken's cc
without APE's help.

/n/sources/contrib/fgb/mp3dec.tgz

Federico G. Benavento

---
/bin/fortune:
Each O atom has two H atoms close to it and the unit of the water molecule is preserved.  Ice Rule

Re: [9fans] Re: Building GCC

[erik quanstrom]

> we've seen this kind discusion before, yesterday I reread
> the "gcc on plan 9" thread wich has 245 posts, just for fun.
> 
> it seems that slowly, _really_ slowly, we are getting there,
> I mean, nowadays you can run opera under linuxemu!
> 
> on another note I ported yet another mp3dec, this one
> is small, public domain and compiles fine with ken's cc
> without APE's help.
> 
> /n/sources/contrib/fgb/mp3dec.tgz

is there any chance the odd looking crash reported
was qemu's fault for not putting the fp registers back?

- erik

Re: [9fans] Re: Building GCC

[benavento]

> is there any chance the odd looking crash reported
> was qemu's fault for not putting the fp registers back?

I don't think so, you don't get to see the fp excetions errors in
other OSes, because they have disabled them

I put a new one that disables the fp excetions.
it's nasty, python, js and others need the same.

Re: [9fans] Re: Building GCC

[lucio]

> /n/sources/contrib/fgb/mp3dec.tgz

No one can deny that your contributions have been invaluable.

I do think there's purists and there's pragmatists (sic to both
there's :-) But there's also whingers and armchair critics who haven't
yet figured out that some things are hard to do.  Maybe we ought to
dedicate wiki space to things no one is willing to tackle.

What would make all the difference would be a valuable application
that is totally dependent on one or more Plan 9 features (private
namespaces, plumbing, distributed processing, etc.).  But until we
extend the field of applications, it is almost impossible and
certainly very unlikely that the next spreadsheet-like idea is going
to be based on Plan 9.

At the same time, porting pseudo-Posix applications to Plan 9 reduces
the pressure to produce Plan 9 native code.  In my opinion, that
defeats the objective of making Plan 9 or its descendants the platform
of the future.

Then again, Linux's first IP networking was a port of KA9Q.  It
sufficed to give impetus to the implementation of a kernel IP stack.
One can't really fault that logic either.

++L

Re: [9fans] Re: Building GCC

[benavento]

>> /n/sources/contrib/fgb/mp3dec.tgz

oops, wrong path... here is the right one:
/n/sources/contrib/fgb/tar/mp3dec.tgz

> I do think there's purists and there's pragmatists (sic to both
> there's :-)

I think I'm in between, it all depends on your needs and of course
needs are very subjective.  Some things don't worth the effort of writing
them natively (gs, antiword, etc) others do, cvsfs comes to my mind.

Talking about my pseudo-needs now, I'd like to have an X server to run
crap in linuxemu, so I don't have to reboot just to see some web page
or whatever.  Of course that doesn't mean that I want kde, gnome, or
whatever.


Changing the subject and talking more about things done in Plan 9 and
maybe in the Plan 9 way, I added changelog functionality to the
contrib tools, when a maintainer does a push the window is put in hold
mode so the he/she/it enters a line explaining the changes.  Also
contrib/list now has a "-c" flag which shows you the changes done
since the last pull if installed, otherwise the whole changelog.


lotte% contrib/list -c fgb/openssl
fgb/openssl: 
    Tue Jan 22 17:24:31 ART 2008
        Updated from 0.9.7e to 0.9.8g.

lotte% 

not much, but something...

Federico G. Benavento

---
/bin/fortune:
Never attribute to malice what can be found in scientific american, under computer recreations.

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 24, 7:33 pm, lu...@proxima.alt.za wrote:

> Maybe we ought to
> dedicate wiki space to things no one is willing to tackle.

Great idea "that leave GUI tainted idolaters agape with fear and
wonder".


> Then again, Linux's first IP networking was a port of KA9Q.  It
> sufficed to give impetus to the implementation of a kernel IP stack.
> One can't really fault that logic either.

Exactly.

Re: [9fans] Re: Building GCC

[Uriel]

There is a webfs with a very rudimentary cache in my contrib dir, it
is a bit ancient so is missing some more recent fixes (some of which
are not integrated into the standard webfs anyway).

It certainly made things *much* more usable, but webfs needs to be
seriously reworked if it is ever going to be really useful, it was
never quite finished, and its design doesn't really fit how the web
works and ends up producing lots of duplicated functionality between
the browser and webfs, I tried to fight this by moving its url parsing
code to a library that abaco and hget could reuse, but there is only
so much time to waste in the hell of web technologies...

In the end I think linuxemu is the way of the future...

uriel

On Jan 24, 2008 11:05 AM, Steve Simon <steve@quintile.net> wrote:
> Ok, my 2¢ worth.
>
> I turn flash off on all the browsers I use, I find it irritating and
> slows things down. All I seem to lose is a few animated jokes and a load
> of adverts - maybe its the websites I visit.
>
> I agree linuxemu is the only practical way to get a "fully compliant browser
> experience".
>
> Having said this I shall contadict it, If abaco had css (en route) and if
> webfs has a good cache then I would be fine for 95% of my needs. In its
> present form I use it for (say) 40% of the time. This is actually more to do
> with its performance (much of which appears to be the lack of a cache).
>
> I vote 1 for abaco for most stuff, and firefox under linuxemu for accessing my bank.
>
> I want my cake and eat it.
>
> -Steve
>

Re: [9fans] Re: Building GCC

[Paulo Pocinho]

Em Thu, 24 Jan 2008 09:41:02 -0000, <pavlovetsky@gmail.com> escreveu:

> Returning to my main point: it is productive to let many Plan 9
> appearances to be. If you insist on developing the core technologies
> and push forward ideas - fine.
  (...)
> I really can understand the reason why people object porting things to
> Plan 9. It is like making bazaar in a cathedral, right? This, I think,
> means to force the operating system to stay in research form for the
> sake of computer scientists themselves! Lets drop web browser and KDE
> for a while and say this: there are cool, interactive scientific
> visualisation tools I would like to use along with fossil+venti
> infrastructure and Plan 9 tools and I would like to see them
> integrated with each other really well. As I said, it is absolutely
> impossible to reinvent everything again, so the question is how to
> integrate the already existing applications for UNIX and Plan 9. I
> vote for emulation.

It's not a question of "reinvent". Let me explain.

I see Plan 9 as a proof of concept that popular technology is obsolete.
Every time I talk to someone about it, there is always some orthodox
defensive.
Why?
Are people blind by the apparent smoothness of a popular system because
it has everything one could expect?

IMO, people should have distance and figure out if there is really
something that should be "reinvented".
Read about why Ken hated tcp when he tried to implement it.
And I can't stop wondering why DMR uses w*ndo*s.
Whatever the reasons, it really doesn't matter. Does it?

If I can imagine seeing things from a Plan 9 user perspective, and
something really bothers me because I am amused to see some youtube
flash, something ought to be wrong.

The system works - nicely. So where's the catch?
Is it because Plan 9 users should want/need/miss pop tech in a system
where everything is state of the art technology?
No.
It is because the first time anyone uses Plan 9 there is this feeling,
a gasp in awe, everything is so simple that makes out brain ache.
We have been brought up spoiled in a pop tech world.
If we want/need/miss anything it is not from pop tech. It is from Plan 9.

There is no need to "reinvent". It's all in there.

(Again, I have that airy feeling that some won't see the point I made
and think I am going in a circle.)

Re: [9fans] Re: Building GCC

[Christopher Nielsen]

Some of us see your point. :-)

On Jan 24, 2008 3:19 AM, Paulo Pocinho <pocinho@gmail.com> wrote:
> Em Thu, 24 Jan 2008 09:41:02 -0000, <pavlovetsky@gmail.com> escreveu:
>
> > Returning to my main point: it is productive to let many Plan 9
> > appearances to be. If you insist on developing the core technologies
> > and push forward ideas - fine.
>   (...)
> > I really can understand the reason why people object porting things to
> > Plan 9. It is like making bazaar in a cathedral, right? This, I think,
> > means to force the operating system to stay in research form for the
> > sake of computer scientists themselves! Lets drop web browser and KDE
> > for a while and say this: there are cool, interactive scientific
> > visualisation tools I would like to use along with fossil+venti
> > infrastructure and Plan 9 tools and I would like to see them
> > integrated with each other really well. As I said, it is absolutely
> > impossible to reinvent everything again, so the question is how to
> > integrate the already existing applications for UNIX and Plan 9. I
> > vote for emulation.
>
> It's not a question of "reinvent". Let me explain.
>
> I see Plan 9 as a proof of concept that popular technology is obsolete.
> Every time I talk to someone about it, there is always some orthodox
> defensive.
> Why?
> Are people blind by the apparent smoothness of a popular system because
> it has everything one could expect?
>
> IMO, people should have distance and figure out if there is really
> something that should be "reinvented".
> Read about why Ken hated tcp when he tried to implement it.
> And I can't stop wondering why DMR uses w*ndo*s.
> Whatever the reasons, it really doesn't matter. Does it?
>
> If I can imagine seeing things from a Plan 9 user perspective, and
> something really bothers me because I am amused to see some youtube
> flash, something ought to be wrong.
>
> The system works - nicely. So where's the catch?
> Is it because Plan 9 users should want/need/miss pop tech in a system
> where everything is state of the art technology?
> No.
> It is because the first time anyone uses Plan 9 there is this feeling,
> a gasp in awe, everything is so simple that makes out brain ache.
> We have been brought up spoiled in a pop tech world.
> If we want/need/miss anything it is not from pop tech. It is from Plan 9.
>
> There is no need to "reinvent". It's all in there.
>
> (Again, I have that airy feeling that some won't see the point I made
> and think I am going in a circle.)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>



-- 
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: [9fans] Re: Building GCC

[Paulo Pocinho]

Em Thu, 24 Jan 2008 11:24:04 -0000, Christopher Nielsen  
<cnielsen@pobox.com> escreveu:

> Some of us see your point. :-)

Lets be honest and face it. We want/need/miss Plan 9 so badly that we
cannot help make wishfull thinking that everything else worked that way.

When we look back, from a Plan 9 user perspective, we crumble in agony
just to realise we have been slaves/dominated by pop tech all these years.

Kudos for Rob Pike when he told "Make the industry want your work."
in "Systems Software Research is Irrelevant".

Some evil twisted words, I'd say. In the end, industry wants pop tech.
It is the user who ends up wanting/needing/missing.

Plan 9 gives us an opportunity of catharsis and makes *you* in charge,  
again.

Re: [9fans] Re: Building GCC

[mattmobile]

>
> When we look back, from a Plan 9 user perspective, we crumble in agony
> just to realise we have been slaves/dominated by pop tech all these 
> years.
Who is this "we" of which you speak?

Re: [9fans] Re: Building GCC

[Paulo Pocinho]

>> When we look back, from a Plan 9 user perspective, we crumble in agony
>> just to realise we have been slaves/dominated by pop tech all these  
>> years.
> Who is this "we" of which you speak?
>

Certainly, not a direct response to Christopher. :)

I aimed to the people, of whom, by using GCC, enter Plan 9 dimension and
seem to have this compulsory impetus to carry their pop tech on their  
backs.

Furthermore, by refering to Rob's statement, I was aiming to the
very essence (and consequence) of bringing that pop tech into Plan 9.

Why spend energy to support existing standards; forget innovation; forget
the propper way to implement/design/use (because we must be "standard";...?

Browsers, flash...? Is that all there is to it? Can there be nothing else?
Can there be no evasion to the complexity of old systems and invent,  
perhaps,
a new interface? Is "WEB 2.0" (HTML 5, etc.) the best thing we can have  
today?
What about tomorrow? Why should *anyone* focus on "re-deploying" popular
technology instead of using Plan 9 to "Make industry want" something else?

Re: [9fans] Re: Building GCC

[lucio]

> (Again, I have that airy feeling that some won't see the point I made
> and think I am going in a circle.)

Let's put it this way: Vincent Van Gogh didn't allow popular demand to
dictate what and how he should paint.  He sold one painting, but today
all his artwork is priceless.  Ironically, a lot of the quality of Van
Gogh's paintings is lost in the common prints that some are willing to
exhibit in their homes.  Fortunately, they do not detract from the
value of the originals.

Should Van Gogh have followed popular trends in art at the time?

++L

Re: [9fans] Re: Building GCC

[ron minnich]

On Jan 24, 2008 7:37 AM,  <lucio@proxima.alt.za> wrote:

> Should Van Gogh have followed popular trends in art at the time?

I'm not van gogh, and I want to use the systems now, not after I'm dead.

ron

Re: [9fans] Re: Building GCC

[andrey mirtchovski]

http://mirtchovski.com/p9/artwork.jpg

Re: [9fans] Re: Building GCC

[erik quanstrom]

is your point that plan 9 is a museum piece or that
if you draw on good paintings with crayons that's a bad thing?

- erik

Re: [9fans] Re: Building GCC

[lucio]

> I'm not van gogh, and I want to use the systems now, not after I'm dead.

And you do, to the best of your abilities and to the extent that you
can.  But have you ever stopped to analyse the mutually exclusive
aspects of GNU and Plan 9 that you require?  How do you propose to
resolve them?

++L

Re: [9fans] Re: Building GCC

[Paulo Pocinho]

>> I'm not van gogh, and I want to use the systems now, not after I'm dead.
>
> And you do, to the best of your abilities and to the extent that you
> can.  But have you ever stopped to analyse the mutually exclusive
> aspects of GNU and Plan 9 that you require?  How do you propose to
> resolve them?
>
> ++L
>

Plan 9 is a model, a research system to provide answers to Unix  
deficiencies.
It is better to take that model and use it than pretend it is a piece of  
art
to hanging on a smelly GNU wall...

Why has it been so dificult to port GNULand to Plan 9 but not the other way
arround?

To apply the model to the unix-like world you use (/procfs, etc.).
Make use of that model in *new* technology. (CLONE_NEWNS is out there...)

Of course, this is my opinion. Nevertheless it does not excuse people who
are stubborn to accept the fact that Plan 9 is a research model (which
happens to allow you to take it as a solid OS).

To bring the Unix model back into Plan 9 is paradoxical.

Re: [9fans] Re: Building GCC

[lucio]

> Why has it been so dificult to port GNULand to Plan 9 but not the other way
> arround?

That is the fundamental question: portability is in the "wrong"
direction.  Plan 9 code is clean and platform independent, GNU code
isn't: it is heavily biased in favour of GCC and is positively riddled
with platform dependencies.

Oh, C++ has much to do with it too.

++L

Re: [9fans] Re: Building GCC

[lucio]

> It is better to take that model and use it than pretend it is a piece of  
> art
> to hanging on a smelly GNU wall...

There's more to an artwork than the aesthetic pleasure of
contemplating it.  With rare exceptions, artistic success builds on
art history, it is unlikely that an unschooled artist will produce a
masterpiece.

The same applies to Plan 9, many of its innovations haven't yet been
absorbed by the artisans in IT design and thus are going unexploited.
For somebody to build a database that exploits Venti for reverting
transactions and deliver a novel application critically based on this
feature, say, requires that the principles on which Venti is based
have achieved sufficient exposure for an inventor to feel at home with
them.  Providing a Plan 9 browser does not seem to me to be the way in
which this familiarity is going to be produced.  On the contrary, the
wintellinux conspiracy is narrowing the familiar selections down to a
very small range and as a result stifling creativity.  I, for one,
feel rather strongly that this is destructive and would prefer to
counter it by focusing my efforts away from the GNU product range.

++L

Re: [9fans] Re: Building GCC

[Joel C. Salomon]

On Jan 24, 2008 6:19 AM, Paulo Pocinho <pocinho@gmail.com> wrote:
> And I can't stop wondering why DMR uses w*ndo*s.

My guess: because he's using it, not programming it.  Less painful
that way (well, until Vista).

Plan 9 is the best programing environment I've used.  Would I like the
option of some other programming languages?  Well, luatex requires a
C++ library to handle PDF, so yes.  I'd like Octave or something
similar too.  But not enough to pollute the system with GNU Autofools.

--Joel

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

Autotools is an abomination. It solves one problem by introducing  
about 3,000. Read page 22 of Rob Pike's Good/Bad/Ugly presentation  
(at the bottom of Plan 9's Wikipedia page) and see why I like the  
system it describes better. But in my version of hoc, you'll see

	#ifdef PLAN9
	USED(something-or-other-because-this-is-a-signal-handler-and-I-do- 
not-care-about-that-necessary-argument-as-this-handler-just-calls- 
exit-or-execerror);
	#endif

and that program uses pcc. Is there a command line option to turn  
that off? I won't need it right now, since my hoc code is lost to  
that broken fossil, but that's not important now.

Here's another programming language: Limbo. I'm starting to like it  
and get used to it's quirks (include "sys.m"; sys : Sys = load Sys  
Sys->PATH; # too much) and someone ported dis to native Plan 9 so we  
can go somewhere. If charon has a CSS module, wouldn't some other  
program have a PDF module?

	term% /n/sources/contrib/fgb/root/rc/bin/contrib/install fgb/contrib
	term% contrib/install steve/cfront

I like fgb's contrib system. It's a heck of a lot cleaner than CVS or  
stuff like that. The only thing I don't like is proto files, but I  
got used to them.

Now I don't know what I'm saying, I'm confused, and I'm going home.

On Jan 24, 2008, at 1:50 PM, Joel C. Salomon wrote:

> On Jan 24, 2008 6:19 AM, Paulo Pocinho <pocinho@gmail.com> wrote:
>> And I can't stop wondering why DMR uses w*ndo*s.
>
> My guess: because he's using it, not programming it.  Less painful
> that way (well, until Vista).
>
> Plan 9 is the best programing environment I've used.  Would I like the
> option of some other programming languages?  Well, luatex requires a
> C++ library to handle PDF, so yes.  I'd like Octave or something
> similar too.  But not enough to pollute the system with GNU Autofools.
>
> --Joel

Re: [9fans] Re: Building GCC

[Russ Cox]

> But in my version of hoc, you'll see
> 
> 	#ifdef PLAN9
> 	USED(something-or-other-because-this-is-a-signal-handler-and-I-do- 
> not-care-about-that-necessary-argument-as-this-handler-just-calls- 
> exit-or-execerror);
> 	#endif
> 
> and that program uses pcc. Is there a command line option to turn  
> that off? I won't need it right now, since my hoc code is lost to  

If you have a function that takes an argument you
don't need to use, then simply delete the name of
the argument.  Instead of

	void nop(int s) { }

you write

	void nop(int) { }

Or you insert USED(s).  
Or you disable all warnings with -w.
Your choice.  

All this is in /sys/doc/comp.ps

Russ

Re: [9fans] Re: Building GCC

[Douglas A. Gwyn]

Russ Cox wrote:
> If you have a function that takes an argument you
> don't need to use, then simply delete the name of
> the argument.  Instead of
>         void nop(int s) { }
> you write
>         void nop(int) { }
> Or you insert USED(s).
> Or you disable all warnings with -w.

Note that you still need the #ifdef PLAN9 ... #endif,
since that isn't standard C.

Re: [9fans] Re: Building GCC

[Martin Neubauer]

* Douglas A. Gwyn (DAGwyn@null.net) wrote:
> Note that you still need the #ifdef PLAN9 ... #endif,
> since that isn't standard C.

Or you compile it with plan9port. Or you steal the ``#define USED...'' from
p9p and put it into a compatibility header. Or...

Re: [9fans] Re: Building GCC

[tlaronde]

On Thu, Jan 24, 2008 at 09:41:02AM +0000, pavlovetsky@gmail.com wrote:
> [...] Lets drop web browser and KDE
> for a while and say this: there are cool, interactive scientific
> visualisation tools I would like to use along with fossil+venti
> infrastructure and Plan 9 tools and I would like to see them
> integrated with each other really well. As I said, it is absolutely
> impossible to reinvent everything again, so the question is how to
> integrate the already existing applications for UNIX and Plan 9. I
> vote for emulation.

I beg to differ. And  I will take a real, named example: Public domain
CERL G.R.A.S.S. (GIS software), transformed in GPL G.R.A.S.S., and,
since 2004, KerGIS, with the core under a BSD like license.

This is a huge beast. The original CERL version did not compile anymore
(it was dropped in 1992). It had a new Motif interface that was more
than 7 MBytes of code---did not compile; was a mess I did even not tried
to fix.

When the software was running, what it does was terrific. Altogether,
the ``conservative'' approach you express has led to GPL GRASS. More and
more, since the code base is huge and since the original worked, and
since it is not admissible to reinvent the wheel, but too difficult to
maintain, they drop part of the system, ``externalize'' parts, relying 
on third parties software.

The motto is: precious but too huge to maintain, so let change the 
minimum and drop what is not understood anymore.

My motto is: reorganize and redevelop it so that it is maintenable
(french origin: able to be held in hand).

On the one hand, the bazaar: so-called tens or hundreds of people
belonging to a ``community'' (really a handful of people really working;
many more discussing).
On the other hand, a single person: myself.

The result is that redoing, thinking about what makes sense and in
particular the split between terminals and CPUs (more and more today,
since a real, heavy computing system is a specialized beast, out of
reach of small entities, unless they can share it, i.e. buy some "shared
time" on some remote computing center), I have remade a lot of things
(not finished yet).

The last in time result is the split between computing and accessing,
with the generation of a 2D interface to _represent_ data and commands
(push a button instead of typing line code) independent of computing,
allowing to use KerGIS not only on Unix, but on any other type of system
(my goal is to allow KerGIS to run natively on Plan 9 or derived systems
or any other system with a C compiler with the minimum of system
dependent stuff).

So KerGIS is now _less code_ than CERL GRASS or GPL GRASS, but with more
features than the original, more than GPL GRASS 5.x (comparison is more
difficult with 6.x that I don't know), more maintainability, more future
potential.

And for the example of the Motif interface, that was
everything melt in CERL GRASS, and just a backend in KerGIS for the GiG
(Graphical interface Generation) numbers are:


CERL GRASS (in Kbytes):

7470	cerl/src/xgrass


KerGIS (in Kbytes):

316	kergis/bin2/monitor

being under KerGIS 4 CWEB files (Donald E. Knuth and Silvio Levy
litterate programming, C for code and TeX for explanations), that is a
great part of documentation: the library, handling geometrical elements
(representations in graphic coordinates and keeping identity of
individual elements---redrawing, changing color etc is local to the
terminal since the informations are kept), a X11 low level back-end, 
a Motif implementation of the toolkit for GiG, and GiG.

One has not to reinvent the wheel if it is a wheel: the best simple
thing. But if this is a wheel, it can be ported easily to other system.

If portability is difficult, this is because what ``works'', nolens 
volens, is not a wheel. This is time to engineer the thing to invent a 
wheel doing the stuff.
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] Re: Building GCC

[Iruata Souza]

On Jan 23, 2008 7:35 AM,  <pavlovetsky@gmail.com> wrote:
> We can not grip the system tightly and prescribe particular
> application and use of it; instead, we must allow people to use it for
> their own purposes. The more general the system, the better, and this
> is the UNIX principle. If someone wants to build an environment he
> feels comfortable with, but still, not leaving the splendid grounds of
> Plan9 - great! Doesn´t it? This is customisation.

you should search the archives and read code like rio and see what do
people find of customisation in Plan 9.

> Personally, I would be happy as a child to see, say, web browser built
> using native environment and fully copliant. It never will be, though,
> for the simple reason - to be fully comliant, web browser must render
> flash content and Java Script as a minimum, but there are also many
> other web technologies, which are accessible through special,
> proprietary plugins.

flash doesn't have anything to do with compliance. nor does javascript.
speaking of the web, you should be compliant with what you choose to implement.
if you only implement html and you're compliant with w3c, you are compliant.

> From the purist point of view it is bad, because system looses its original
> integrity, many flavours evolve and distasteful cruft appears.
s/purist/sane

> But, in the end, this is evolution. This is the only way to survive.
Plan 9 is older than the mainstream systems you are talking about.

> The more people will use Plan9 the better, even if they do it in not
> so elegant way.
s/Plan 9/Microsoft Windows

> It is senseless and impossible to reinvent every single weel. People
> must port things, it will strengthen the system.
>
and why written elegant new code would not?

iru

Re: [9fans] Re: Building GCC

[ron minnich]

On Jan 23, 2008 6:17 AM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> On Jan 23, 2008 7:35 AM,  <pavlovetsky@gmail.com> wrote:

> flash doesn't have anything to do with compliance. nor does javascript.
> speaking of the web, you should be compliant with what you choose to implement.
> if you only implement html and you're compliant with w3c, you are compliant.

and, arguably, useless.

There is spec compliance and de-facto compliance. Or, maybe, spec
compliance and
what people want compliance.

One of the first questions users ask of a new C compiler is "are you
gcc compliant?".

I'm not making this up.

ron

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

On Jan 23, 2008, at 11:13 AM, ron minnich wrote:
>
> One of the first questions users ask of a new C compiler is "are you
> gcc compliant?".
>
>
Nine out of ten times you'll hear "yes" but get "no" from the  
program. To be GCC compatible is to be a masochist. What people  
should be asking is, "is the compiler C99-compliant?" Personally, I  
see no need for most of the junk in C99 - its complex number system  
is unorthodox, it breaks compatibility with C++, and isn't restrict  
like noalias?

Re: [9fans] Re: Building GCC

[Iruata Souza]

On Jan 23, 2008 2:13 PM, ron minnich <rminnich@gmail.com> wrote:
> On Jan 23, 2008 6:17 AM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> > On Jan 23, 2008 7:35 AM,  <pavlovetsky@gmail.com> wrote:
>
> > flash doesn't have anything to do with compliance. nor does javascript.
> > speaking of the web, you should be compliant with what you choose to implement.
> > if you only implement html and you're compliant with w3c, you are compliant.
>
> and, arguably, useless.
>
> There is spec compliance and de-facto compliance. Or, maybe, spec
> compliance and
> what people want compliance.
>
that's true. but it's a little hard to state what is a
what-people-want compliance.

> One of the first questions users ask of a new C compiler is "are you
> gcc compliant?".
>

sadly, that's true.

iru

Re: [9fans] Re: Building GCC

[Uriel]

On Jan 23, 2008 7:36 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> On Jan 23, 2008 2:13 PM, ron minnich <rminnich@gmail.com> wrote:
> > On Jan 23, 2008 6:17 AM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> > > On Jan 23, 2008 7:35 AM,  <pavlovetsky@gmail.com> wrote:
> >
> > > flash doesn't have anything to do with compliance. nor does javascript.
> > > speaking of the web, you should be compliant with what you choose to implement.
> > > if you only implement html and you're compliant with w3c, you are compliant.
> >
> > and, arguably, useless.
> >
> > There is spec compliance and de-facto compliance. Or, maybe, spec
> > compliance and
> > what people want compliance.
> >
> that's true. but it's a little hard to state what is a
> what-people-want compliance.

what-people-want is the Holy Trinity 2.0: Firefox, GCC and Linux.

Anything else will never be 'compliant' (unless you are under the
Job's distortion field...)

uriel

Re: [9fans] Re: Building GCC

[sqweek]

On Jan 23, 2008 11:17 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> flash doesn't have anything to do with compliance. nor does javascript.
> speaking of the web, you should be compliant with what you choose to implement.
> if you only implement html and you're compliant with w3c, you are compliant.

 Screw w3c. Much as it pains me to admit it, to ignore javascript is
to ignore the web.
 A modern web browser is more like a VM. But instead of having some
sort of sane rendering backend it uses HTML/CSS. Javascript/plugins
serve as the "userspace" code, if you will. HTTP exports the local
rendering interface and cpu to remote machines.
 Gecko makes the JVM look sleek.
-sqweek

Re: [9fans] Re: Building GCC

[lucio]

>  A modern web browser is more like a VM. But instead of having some
> sort of sane rendering backend it uses HTML/CSS. Javascript/plugins
> serve as the "userspace" code, if you will. HTTP exports the local
> rendering interface and cpu to remote machines.

I haven't looked at any implementation of an HTML rendering engine, so
I may be totally off the mark, but presumably there is merit in the
ability to take a textual source and turn it into a two-dimensional
graphical representation of the intended document?

Now, HTML may be a poor realisation of the language such a rendering
engine would interpret, but it must be possible to design a mark-up
language (and let's not let "mark-up" or "language" condition our
thinking) that can be used as the human-editable source for a
graphical production.  I don't suggest that there is a "perfect" such
notation, merely that we have had enough experience with word
processors (a long list), text processors (TeX, troff, etc.) and page
layout languages (Postscript, are there any other interesting ones?)
to be able to explore the next generation, together with the tools
they would need to manipulate them.

Given a rendering engine with a powerful and hopefully flexible input
language, one may be able to write compilers or interpreters for the
more popular brands.  Or am I missing the wood for the trees?

If I'm not, I propose that Plan 9 could provide the platform for such
an engine as well as for the various interpreters.  Designing a useful
graphical description language is no small project, but surely there
is some prior art out there than one can draw on?

++L

Re: [9fans] Re: Building GCC

[erik quanstrom]

> Given a rendering engine with a powerful and hopefully flexible input
> language, one may be able to write compilers or interpreters for the
> more popular brands.  Or am I missing the wood for the trees?
> 

i think you're right on the mark.  suppose that acme and rio were built
on "liblayout" and not libframe.  liblayout provides a basic boxes-n-glue
view of the world; acme/rio export /dev/layout.  a box could contain an image or a
text frame.  then acme could display things like images along with text,
static html content (given an educated htmlfmt), etc.

- erik

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

And then we can have raw images as filenames, raw images in plain  
text, text as the stroke style for a line, etc. I'd like raw images  
in text - it makes mpictures and converting to PostScript unnecessary.

According to the wiki page on TODO, it says htmlfmt needs knowledge  
of tables. With this, we could just put the HTML parser and rendering  
in acme/rio and avoid htmlfmt.

Unfortunately, we're about 20 years too late. People have Microsoft  
Word and they don't need an operating system with useful features,  
automated backup at no additional cost, and a wealth of  
documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as  
I use troff now. If you disagree, raise your virtual hands.

Instead of debating on what's the right thing to do to add innovation  
about 10+ years old to a system that should've had it 10 years ago,  
let's focus on how to innovate for the future, shall we? It's not  
that I don't like starting debates (I did start this one), but now my  
original idea sounds unnecessary.

I just wanted Konqueror so I could browse the whole web, but with  
someone adding CSS to abaco and JavaScript in charon, can we merge  
them or add JavaScript to abaco or something? I don't know anymore.  
If you need me, I'll be adding tables to htmlfmt.

Re: [9fans] Re: Building GCC

[lucio]

> If you need me, I'll be adding tables to htmlfmt.

In bocca al lupo!

But you can't add JavaScript to htmlfmt so we're still miles away from
being able to do one's banking in Plan 9.

Personally, I mix VNC and an UBUNTU laptop to get things done, because
I have to.  Perhaps the consolation I can draw from noticing the
sluggishness of these devices is that all exponential growth
eventually exceeds available resources.

When wintelinux comes crashing down through an inability to sustain
growth, Plan 9 will be a good candidate for the next hardware
platform.  There will be others, all of them, hopefully, skinnier than
their predecessors.

In fact, at the current rate, wintelinux ought to be slowing down
relative to Plan 9, if not already, certainly pretty soon.

++L

Re: [9fans] Re: Building GCC

[Gary Wright]

On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:
> When wintelinux comes crashing down through an inability to sustain
> growth, Plan 9 will be a good candidate for the next hardware
> platform.  There will be others, all of them, hopefully, skinnier than
> their predecessors.

I just saw the following in another mailing list. It seems to echo
your sentiments:

Jay Levitt wrote:
> Eclipse (and Java in general) is a great example of what I call
> "stratification" - the re-implementation of lower layers in ever- 
> higher
> layers, because nobody even remembers the lower layer is there  
> anymore.
>
> If you build a mail system that relies on a database, someone will
> inevitably decide that a mail system, with its built-in queueing,  
> routing
> and simplicity, is a great transport for asynchronous replication,  
> which in
> turn, can be used to create a distributed file system.  And once  
> you've got
> a file system, well, wouldn't it be great to get a database running  
> on it?

Gary Wright

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

Grazie, ho finito.

Actually, it might not be what you want, and it isn't perfect. What  
it does is it formats each cell to be the length of the longest of  
the whole table. There's some hooks to get it working. However, a few  
setbacks:
	- it only works with text data (no <img>)
	- no nested tables
I'm working on all of these, as well as changing it so that each  
column is the length of its largest  item rather than the whole  
table's largest item.

On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:

>> If you need me, I'll be adding tables to htmlfmt.
>
> In bocca al lupo!
>
> But you can't add JavaScript to htmlfmt so we're still miles away from
> being able to do one's banking in Plan 9.
>
> Personally, I mix VNC and an UBUNTU laptop to get things done, because
> I have to.  Perhaps the consolation I can draw from noticing the
> sluggishness of these devices is that all exponential growth
> eventually exceeds available resources.
>
> When wintelinux comes crashing down through an inability to sustain
> growth, Plan 9 will be a good candidate for the next hardware
> platform.  There will be others, all of them, hopefully, skinnier than
> their predecessors.
>
> In fact, at the current rate, wintelinux ought to be slowing down
> relative to Plan 9, if not already, certainly pretty soon.
>
> ++L
>

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

Just added:
	- proper column sizing
	- cellpadding and cellspacing support
Planned:
	- nested images, rules, forms, etc.
	- borders (made using either ASCII or Unicode characters; I'll  
discuss the differences later)
	- nested tables
Once at least nested non-text is finished, I'll submit it to patch.

On Jan 24, 2008, at 9:47 PM, Pietro Gagliardi wrote:

> Grazie, ho finito.
>
> Actually, it might not be what you want, and it isn't perfect. What  
> it does is it formats each cell to be the length of the longest of  
> the whole table. There's some hooks to get it working. However, a  
> few setbacks:
> 	- it only works with text data (no <img>)
> 	- no nested tables
> I'm working on all of these, as well as changing it so that each  
> column is the length of its largest  item rather than the whole  
> table's largest item.
>
> On Jan 24, 2008, at 1:37 PM, lucio@proxima.alt.za wrote:
>
>>> If you need me, I'll be adding tables to htmlfmt.
>>
>> In bocca al lupo!
>>
>> But you can't add JavaScript to htmlfmt so we're still miles away  
>> from
>> being able to do one's banking in Plan 9.
>>
>> Personally, I mix VNC and an UBUNTU laptop to get things done,  
>> because
>> I have to.  Perhaps the consolation I can draw from noticing the
>> sluggishness of these devices is that all exponential growth
>> eventually exceeds available resources.
>>
>> When wintelinux comes crashing down through an inability to sustain
>> growth, Plan 9 will be a good candidate for the next hardware
>> platform.  There will be others, all of them, hopefully, skinnier  
>> than
>> their predecessors.
>>
>> In fact, at the current rate, wintelinux ought to be slowing down
>> relative to Plan 9, if not already, certainly pretty soon.
>>
>> ++L
>>
>

Re: [9fans] Re: Building GCC

[lucio]

> I'm working on all of these, as well as changing it so that each  
> column is the length of its largest  item rather than the whole  
> table's largest item.

You also need to know the overall width of the space in which the
table is presented so you can scale each _column_ accordingly.  It's a
tedious operation, but it ought to be possible, I can't say that I
have looked at it myself.

++L

Re: [9fans] Re: Building GCC

[erik quanstrom]

> Unfortunately, we're about 20 years too late. People have Microsoft  
> Word and they don't need an operating system with useful features,  
> automated backup at no additional cost, and a wealth of  
> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as  
> I use troff now. If you disagree, raise your virtual hands.

it's quite a stretch to go from acme being able to handle layouts
to microsoft word.  the oberon system had something like layouts,
but layouts were part of the text module.  thus there was no such
thing as plain text.  the next station had display postscript. but
that's a quite complicated model.   i think text should be text and
images should be images.

but you just can't do graphics or html layout with just text.
you need something to glue (sorry) things together.  it's
fairly annoying that proof text is not selectable and doesn't
work inside acme.

i realize there are holes around the edges.  i don't see how to
edit or select a layout, just the text within layouts.  maybe
select skips non-text bits.

what's so wrong about this idea?

- erik

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

I wish page(1) would do the same. However, I think page operates via  
libdraw, and either:
	- they need to modify libdraw to allow text selection, or
	- they need to use libcontrol instead and write a rich text system  
for libcontrol
Both of them are as difficult as each other. I've seen code for word  
processors (tried to contribute to AbiWord, autotools slowed me down)  
and it's quite big.

On Jan 24, 2008, at 1:52 PM, erik quanstrom wrote:

>> Unfortunately, we're about 20 years too late. People have Microsoft
>> Word and they don't need an operating system with useful features,
>> automated backup at no additional cost, and a wealth of
>> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
>> I use troff now. If you disagree, raise your virtual hands.
>
> it's quite a stretch to go from acme being able to handle layouts
> to microsoft word.  the oberon system had something like layouts,
> but layouts were part of the text module.  thus there was no such
> thing as plain text.  the next station had display postscript. but
> that's a quite complicated model.   i think text should be text and
> images should be images.
>
> but you just can't do graphics or html layout with just text.
> you need something to glue (sorry) things together.  it's
> fairly annoying that proof text is not selectable and doesn't
> work inside acme.
>
> i realize there are holes around the edges.  i don't see how to
> edit or select a layout, just the text within layouts.  maybe
> select skips non-text bits.
>
> what's so wrong about this idea?
>
> - erik

Re: [9fans] Re: Building GCC

[erik quanstrom]

> I wish page(1) would do the same. However, I think page operates via  
> libdraw, and either:
> 	- they need to modify libdraw to allow text selection, or
> 	- they need to use libcontrol instead and write a rich text system  
> for libcontrol
> Both of them are as difficult as each other. I've seen code for word  
> processors (tried to contribute to AbiWord, autotools slowed me down)  
> and it's quite big.

page can't be made to do this.  page manipulates images created by
other programs.

if you're thinking rich text, you're on a different track than i.
think rich text is not worth the cost.  the layout needs to enclose
blocks of text or images.

you also write seperately

> installed, so I have no first-hand experience - more of Wirth's junk  
> in the trunk), people might be reluctant to leave Microsoft Word for  

dr. wirth can not be accused of software bloat nor of poor programming.
is work is excellent.  the oberon system is so spartian there are no directories.
that's just too spartain for me.

you know, i don't feel like i need to get the world using plan 9.
it's enough to change myself.

- erik

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
>>
> dr. wirth can not be accused of software bloat nor of poor  
> programming.
> is work is excellent.  the oberon system is so spartian there are  
> no directories.
> that's just too spartain for me.
>

I can agree Wirth has improved his ways over the past 20 years, but I  
never got Oberon installed. No directories has not been practiced  
ever to my memory; the closest I can think of off the top of my head  
is the first Macintosh only having directories in / and no  
subdirectories.

> you know, i don't feel like i need to get the world using plan 9.
> it's enough to change myself.
>
> - erik

The world doesn't need to use Plan 9 - I doubt there is advertising  
anymore. But if someone else hears about Plan 9 and doesn't want to  
use it because he doesn't find it familiar, he'll probably say the  
same thing. I am perfectly comfortable with Plan 9 the way it is, and  
I enjoy troff, but the rest of the world may think otherwise.

This discussion started with me trying to get GCC to work. Now it's  
run off into about 3,000 different directions and I don't know much  
anymore. I just want to mention that I also tried GCC to see if I  
could build Ruby 1.9.0 with it.

Re: [9fans] Re: Building GCC

[Lorenzo Fernando Bivens de la Fuente]

I think that...

We have to take a look at Plan 9 history to realize that it has more
to offer than to envy.

The whole point of Plan 9, imho, is not to become the everywhere
avaliable "me too" OS... More likely it is the "can you do this?" OS.

The way information is presented to the user has changed a lot.
Everything has become "shiny"... Even writing a boring essay
apparently needs 3d shadows and some wobbly windows... And don't get
me started with web browsing... I would say that I have seen good uses
of interactive animations to show data, regardless of the platform
they are built on. I have also seen good use of web standards...

And of course many abuses.

But anyway... I can't see Plan 9 as an enviroment to "clone" things...
It is more like a confortable greenhouse where you can grow new ideas.
Perhaps there are new ideas around that anyone can freely try to
"plant" inside the greenhouse... But I think that the final purpose
should be doing that same thing in a more efficient, beautiful and
better way....

I personally can't find a reason to port konqueror to plan 9, but I
can think of many reasons to work on abaco... We can learn a lot from
quality challenged/impaired software like firefox or konqueror, and we
can avoid those mistakes with the elegance that characterizes to the
Plan 9 Philosophy.

But I am just a moron talking about things I don't really understand.

Cheers!

On 1/24/08, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
> >>
> > dr. wirth can not be accused of software bloat nor of poor
> > programming.
> > is work is excellent.  the oberon system is so spartian there are
> > no directories.
> > that's just too spartain for me.
> >
>
> I can agree Wirth has improved his ways over the past 20 years, but I
> never got Oberon installed. No directories has not been practiced
> ever to my memory; the closest I can think of off the top of my head
> is the first Macintosh only having directories in / and no
> subdirectories.
>
> > you know, i don't feel like i need to get the world using plan 9.
> > it's enough to change myself.
> >
> > - erik
>
> The world doesn't need to use Plan 9 - I doubt there is advertising
> anymore. But if someone else hears about Plan 9 and doesn't want to
> use it because he doesn't find it familiar, he'll probably say the
> same thing. I am perfectly comfortable with Plan 9 the way it is, and
> I enjoy troff, but the rest of the world may think otherwise.
>
> This discussion started with me trying to get GCC to work. Now it's
> run off into about 3,000 different directions and I don't know much
> anymore. I just want to mention that I also tried GCC to see if I
> could build Ruby 1.9.0 with it.
>
>

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 24, 9:39 pm, pietr...@mac.com (Pietro Gagliardi) wrote:
> On Jan 24, 2008, at 2:27 PM, erik quanstrom wrote:
>
>
>
> > dr. wirth can not be accused of software bloat nor of poor
> > programming.
> > is work is excellent.  the oberon system is so spartian there are
> > no directories.
> > that's just too spartain for me.
>
> I can agree Wirth has improved his ways over the past 20 years, but I
> never got Oberon installed. No directories has not been practiced
> ever to my memory; the closest I can think of off the top of my head
> is the first Macintosh only having directories in / and no
> subdirectories.
>
> > you know, i don't feel like i need to get the world using plan 9.
> > it's enough to change myself.
>
> > - erik
>
> The world doesn't need to use Plan 9 - I doubt there is advertising
> anymore. But if someone else hears about Plan 9 and doesn't want to
> use it because he doesn't find it familiar, he'll probably say the
> same thing. I am perfectly comfortable with Plan 9 the way it is, and
> I enjoy troff, but the rest of the world may think otherwise.
>
> This discussion started with me trying to get GCC to work. Now it's
> run off into about 3,000 different directions and I don't know much
> anymore. I just want to mention that I also tried GCC to see if I
> could build Ruby 1.9.0 with it.

Thinking how to get some piece of alien software work on Plan 9, e.g.
web browser to access the web is certainly not a try of
evangelisation. Web access is normal and legitimate activity and many
people who use  Plan 9 want to access the web and the thing is that it
really does not make any sense to write web browser from the ground
up, if there is a workable version. And it does not mean that people
would use other system instead. So, the initial solution was to use
VNC, it implies network. Now, linuxemu allows to get the result
locally. It is elegant, because you put development effort in one
place and you get many applications work.

Re: [9fans] Re: Building GCC

[Iruata Souza]

On Jan 25, 2008 7:55 AM,  <pavlovetsky@gmail.com> wrote:
> it  really does not make any sense to write web browser from the ground
> up, if there is a workable version.

here we go again...
why use Plan 9 at all if every mainstream operating system is 'workable'?
i guess workable is not the point.

iru

Re: [9fans] Re: Building GCC

[Brantley Coile]

> On Jan 25, 2008 7:55 AM,  <pavlovetsky@gmail.com> wrote:
>> it  really does not make any sense to write web browser from the ground
>> up, if there is a workable version.
> 
> here we go again...
> why use Plan 9 at all if every mainstream operating system is 'workable'?
> i guess workable is not the point.
> 
> iru

Plan 9 is not, and should not in my opinion, be a Linux
replacment, Unix replacement, MS Windows replacement, and
so on.  If you really want Plan 9 to dominate the world
and see all your friends use it every day, invent a killer
application for it.  That's the only way you can shove
existing systems of their pedestals.  Making Plan 9
exactly like Linux, or Windows, or son on, will not
cause people to leave the real Linux or Windows and use
Plan 9.  Lack of a browser is not why only the select
few use Plan 9.  It's a culture thing.

If you want Linux you know where to find it.

Re: [9fans] Re: Building GCC

[Bakul Shah]

On Fri, 25 Jan 2008 09:26:56 EST Brantley Coile <brantley@coraid.com>  wrote:
> Plan 9 is not, and should not in my opinion, be a Linux
> replacment, Unix replacement, MS Windows replacement, and
> so on.  If you really want Plan 9 to dominate the world
> and see all your friends use it every day, invent a killer
> application for it.  That's the only way you can shove
> existing systems of their pedestals.

The zillion dollar question is what app would that be.  And
even if you build a killer app for plan 9, most people would
want it ported to their favorite OS.  Worse, the problem is
that the "platform" that matters to most people now is no
longer an OS (just as battles over which is the best
processor are now mostly past) -- this is why most killer
apps end up
a) being windows or OS X based,
b) being ported to multiple platforms (windows, OS X,
   Linux, FreeBSD, Symbian), or
c) living entirely in a web browser, with a server
   somewhere to provide/store the interesting bits.
d) bundled with a h/w gadget of some sort (iPod, SlingBox
   etc.)

May be Plan9 can be used to provide a webserver backend but
even here you have to work with existing solutions as people
don't want to reinvent everything. The benefits provided by
the plan9 model are simply not enough if you have to reinvent
everything. Working python, ruby, c++, PHP would go some way
toward fixing that.

Another possibilty is to use it in a h/w gadget that everyone
would want (for example building something like the Lego NXT
computer controlled brick so that you can build simple
robotic apps in rc).

All this assuming anyone wants plan9 to be more popular but I
don't know if there is even a majority that wants that (or
wants it badly enough to want to do something about it).

May be the problem is that people are treating plan 9 as a
Van Gogh masterpiece when they should be treating as building
material :-)

Re: [9fans] Re: Building GCC

[lucio]

> May be the problem is that people are treating plan 9 as a
> Van Gogh masterpiece when they should be treating as building
> material :-)

I sincerely hope for your sake that you don't treat your next Van Gogh
masterpiece as building rubble.  Or treat Plan 9 as some sort of Linux
surrogate.  Why not use the real thing, considering how much less
wasteful it would be?

++L

Re: [9fans] Re: Building GCC

[John Floren]

On Jan 25, 2008 10:09 AM,  <lucio@proxima.alt.za> wrote:
> > May be the problem is that people are treating plan 9 as a
> > Van Gogh masterpiece when they should be treating as building
> > material :-)
>
> I sincerely hope for your sake that you don't treat your next Van Gogh
> masterpiece as building rubble.  Or treat Plan 9 as some sort of Linux
> surrogate.  Why not use the real thing, considering how much less
> wasteful it would be?
>
> ++L
>

I think the point is that people talk a big talk about how great Plan
9 is, but then don't do a damn thing with it.
At least, that's how I read it.

John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Re: [9fans] Re: Building GCC

[lucio]

> I think the point is that people talk a big talk about how great Plan
> 9 is, but then don't do a damn thing with it.
> At least, that's how I read it.

Is that what you believe?  And if so, who else believes this?

There are things Plan 9 does exceedingly well, better than any other
OSes in the wild, but they are special features, more or less remote
from the mainstream use of mainstream OSes.  Were Plan 9 more popular,
many if not all of Plan 9's features would eventually become familiar
and users would begin to expect them of other OSes as well, but we're
talking fashion here, not intrinsic value.

In the meantime, Plan 9 users do benefit from features others feel no
need for and it's hard to communicate across that chasm.  Just as hard
as it is to understand that one may have to cope and be able to cope
without a native browser.

If the "novelty" of Plan 9 doesn't get you, then Plan 9 is not for
you; you will not evangelise us users into making Plan 9 the tool you
want, specially when you continue to use as an example the very tool
you already have access to.  And, to add insult to injury, we also do
provide the tools, should you feel that way inclined, for _you_ to
enhance Plan 9 in the direction you prefer, so our sympathy when you
"accuse" us of talking the big talk, is very, very limited.

Consider what you want carefully and decide whether Plan 9 fits into
your life.  If it doesn't, either change it (you have the source) or
move on.

++L

Re: [9fans] Re: Building GCC

[Bakul Shah]

On Fri, 25 Jan 2008 10:29:55 PST "John Floren" <slawmaster@gmail.com>  wrote:
> On Jan 25, 2008 10:09 AM,  <lucio@proxima.alt.za> wrote:
> > > May be the problem is that people are treating plan 9 as a
> > > Van Gogh masterpiece when they should be treating as building
> > > material :-)
> >
> > I sincerely hope for your sake that you don't treat your next Van Gogh
> > masterpiece as building rubble.  Or treat Plan 9 as some sort of Linux
> > surrogate.  Why not use the real thing, considering how much less
> > wasteful it would be?
> 
> I think the point is that people talk a big talk about how great Plan
> 9 is, but then don't do a damn thing with it.
> At least, that's how I read it.

More or less right.  Use it, abuse it, rip it apart and
reconstruct it but *build* something interesting with plan9!
I didn't mean to suggest people are not doing it; just that
I find building stuff is much more fruitful than discussions
about what should people *not* do with plan 9.

A killer app *always* fills some need for a lot of people but
a priori you can't know if your app is going to be the one so
no point in worrying much about it. You might as well build
something *you* find useful. If you want to compile plan9
with gcc, go right ahead!  If you want to build a server
farm, why not?  If you want to port plan9 to a cellphone,
great! If you want to make plan9 look like Linux, sure!  The
more (& different) things get built the better.

Re: [9fans] Re: Building GCC

[Skip Tavakkolian]

> You might as well build
> something *you* find useful.

that's good advice, and too often overlooked.  another benefit is that
software quality is much better if the designer/developer is also a
frequent user of it.  not very scientific, but it seems like IDE's are
always better than the software developed using them.

Re: [9fans] Re: Building GCC

[dave.l]

> I think the point is that people talk a big talk about how great Plan
> 9 is,

That's 'cos it is.

> but then don't do a damn thing with it.

Uh, sorry?

A month or so ago, I sat in a room with a bunch of
like- and unlike-minded people and discussed
everything from linguistics to supercomputing on plan9 and/or inferno.

Lots of people are busy doing various things, damned or otherwise,  
with plan9.

If by "a damn thing" you really mean "a damned thing that some  
particular set of people want",
or  "a damn thing that you want", well, that's a different matter.

> At least, that's how I read it.

Perception is everything.

Another point of view:
as has been said before:
plan9 has been failing for 20 years.
That's longer than most.

DaveL

Re: [9fans] Re: Building GCC

[John Floren]

On 1/25/08, dave.l@mac.com <dave.l@mac.com> wrote:
> > I think the point is that people talk a big talk about how great Plan
> > 9 is,
>
> That's 'cos it is.
>

It is pretty great.

> > but then don't do a damn thing with it.
>
> Uh, sorry?
>
> A month or so ago, I sat in a room with a bunch of
> like- and unlike-minded people and discussed
> everything from linguistics to supercomputing on plan9 and/or inferno.
>

Yeah, I was there too. It was great.

> Lots of people are busy doing various things, damned or otherwise,
> with plan9.
>

I'm currently employed to work on Plan 9 on supercomputers and other
things. When I say some people aren't doing a damn thing, I'm not
referring to everyone. There are some really cool things being done
with Plan 9, but there's also the weekly "Here's an idea for a new
filesystem/program what do you think" that never results in any code.
I'm just saying that there seem to be more than a few 9fans who love
to post and talk on IRC about how great it is, but have yet to do much
more than get a tip9ug account and log in a few times.

> If by "a damn thing" you really mean "a damned thing that some
> particular set of people want",
> or  "a damn thing that you want", well, that's a different matter.
>
> > At least, that's how I read it.
>
> Perception is everything.
>
> Another point of view:
> as has been said before:
> plan9 has been failing for 20 years.
> That's longer than most.
>
> DaveL
>

Actually, Windows, MacOS, UNIX, and VMS have all been failing longer
and harder ;)

John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

On Jan 25, 2008, at 10:08 PM, John Floren wrote:

>>
>
> Actually, Windows, MacOS, UNIX, and VMS have all been failing longer
> and harder ;)
>
> John
> --  
> Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

Windows, UNIX, VMS I can understand. But MacOS? If you mean pre-OS X,  
then I understand :-)

I like both Mac OS X and Plan 9, which is why I run Plan 9 under QEMU  
on Mac OS X.

Re: [9fans] Re: Building GCC

[erik quanstrom]

> I'm currently employed to work on Plan 9 on supercomputers and other
> things. When I say some people aren't doing a damn thing, I'm not
> referring to everyone. There are some really cool things being done
> with Plan 9, but there's also the weekly "Here's an idea for a new
> filesystem/program what do you think" that never results in any code.
> I'm just saying that there seem to be more than a few 9fans who love
> to post and talk on IRC about how great it is, but have yet to do much
> more than get a tip9ug account and log in a few times.

i don't think mentioning an idea on 9fans is a commitment
in blood to finish the project.  not everyone can count a plan 9
day job among their blessings.

- erik

Re: [9fans] Re: Building GCC

[Eric Van Hensbergen]

On Jan 27, 2008 9:11 PM, erik quanstrom <quanstro@coraid.com> wrote:
>
> i don't think mentioning an idea on 9fans is a commitment
> in blood to finish the project.  not everyone can count a plan 9
> day job among their blessings.
>

Yes.

Only Inferno requires blood oaths.

   -Louis Sofer

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

I will do so as soon as I can find out why I get ACPI errors from the  
Linux kernel. Anyways, I am using Plan 9 now for building programs  
that solve some problems in the wiki's TODO page. I added simple  
table borders to htmlfmt and am going on to solve this problem:

	GUI image manipulation program - page(1) crossed with sam(1) which  
calls resample(1) and crop(1) (and other tools) would love to see  
this implemented in Acme.... --[++pac

I dropped the word GUI and am working on porting Bell Labs' pico to  
Plan 9.

On Jan 25, 2008, at 1:09 PM, lucio@proxima.alt.za wrote:

>> May be the problem is that people are treating plan 9 as a
>> Van Gogh masterpiece when they should be treating as building
>> material :-)
>
> I sincerely hope for your sake that you don't treat your next Van Gogh
> masterpiece as building rubble.  Or treat Plan 9 as some sort of Linux
> surrogate.  Why not use the real thing, considering how much less
> wasteful it would be?
>
> ++L
>

Re: [9fans] Re: Building GCC

[erik quanstrom]

> 
> May be the problem is that people are treating plan 9 as a
> Van Gogh masterpiece when they should be treating as building
> material :-)

interestingly, that's the Coraid approach.

- erik

Re: [9fans] Re: Building GCC

[lucio]

>> May be the problem is that people are treating plan 9 as a
>> Van Gogh masterpiece when they should be treating as building
>> material :-)
> 
> interestingly, that's the Coraid approach.

Well, embedded is not what is being advocated here, so I think yours
is the answer to a different question.  At least, I hope it is.

The exciting thing is that Plan 9 (unlike, say, Starry Night) can be
used in embedded appliances as well as in general purpose computing.
Just not in conventional desktop/laptop computing, but, rminnich's
qualms notwithstanding, how important is that to Plan 9's future?

Or, to ask a totally different question, which is preferable: for Plan
9 to resemble the conventional OS offerings or for the conventional OS
offerings to resemble Plan 9?  I'd say you ought to pick one of those
camps and branch off your version of Plan 9 accordingly.  Precisely as
Coraid have apparently done in a socially conscious manner.

++L

Re: [9fans] Re: Building GCC

[Roman Shaposhnik]

On Fri, 2008-01-25 at 09:49 -0800, Bakul Shah wrote:
> On Fri, 25 Jan 2008 09:26:56 EST Brantley Coile <brantley@coraid.com>  wrote:
> > Plan 9 is not, and should not in my opinion, be a Linux
> > replacment, Unix replacement, MS Windows replacement, and
> > so on.  If you really want Plan 9 to dominate the world
> > and see all your friends use it every day, invent a killer
> > application for it.  That's the only way you can shove
> > existing systems of their pedestals.
> 
> The zillion dollar question is what app would that be. 

  My totally non-scientific observation is that talking about
"an app" in this context is quite misleading. May be it is just
me, but somehow "an application" has the connotations of a single
instance of code running on a single box. I don't think that is
interesting anymore. What could be interesting is to talk about,
what I would call for the lack of a better term, a utility function.
One such utility function could be pervasive networking. Gazing
into my crystal ball brings visions of Google finally doing to
cell phones what IBM did to personal computers and opening a floodgate
of software for that platform. Sun used to say "the network is the
computer" I still largely believe this to be true, but what is even
more important is that bringing pervasive networking to those ~3 billion
cell phones worldwide could very well be the killer "utility function"
of Plan 9. If not in terms of the code, at least in term of ideas.

My 2 rubles.

Thanks,
Roman.

Re: [9fans] Re: Building GCC

[John Floren]

On Jan 25, 2008 9:49 AM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
[snip]
>
> Another possibilty is to use it in a h/w gadget that everyone
> would want (for example building something like the Lego NXT
> computer controlled brick so that you can build simple
> robotic apps in rc).
[snip]

Check out Styx-on-a-brick (http://www.vitanuova.com/inferno/rcx_paper.html).

John
-- 
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn

[9fans] importing web browsers (was Building GCC)

[Charles Forsyth]

>> it  really does not make any sense to write web browser from the ground
>> up, if there is a workable version.

>here we go again...
>why use Plan 9 at all if every mainstream operating system is 'workable'?
>i guess workable is not the point.

i assumed he wanted to develop and run things mainly in the plan 9 environment
but would like the added distraction with occasional information of the web world,
for which firefox is adequate (and if something that big feels inadequate, that's a huge neurosis).
so he'd like to get it running under plan 9 somehow.

i use vnc to a big sacrificial linux machine, myself, except on the lenovo where i've been
too lazy to finish the wireless and drawterm from linux to my cpu server.
i get much  more done on a plan9-only system.

if he were interested in doing research into new ways of accessing the web,
perhaps using some clever application of 9-inspired ideas,
then firefox would probably be a waste of time.   if he just wants to browse
successfully, perhaps not.   probably by the time he's finished it will be up
to Web 8.3 but that's not really our problem.   i wouldn't waste time arguing about it (here).

Re: [9fans] importing web browsers (was Building GCC)

[Iruata Souza]

On Jan 25, 2008 12:35 PM, Charles Forsyth <forsyth@terzarima.net> wrote:
> >> it  really does not make any sense to write web browser from the ground
> >> up, if there is a workable version.
>
> i assumed he wanted to develop and run things mainly in the plan 9 environment
> but would like the added distraction with occasional information of the web world,
> for which firefox is adequate (and if something that big feels inadequate, that's a huge neurosis).
> so he'd like to get it running under plan 9 somehow.
>
> i use vnc to a big sacrificial linux machine, myself, except on the lenovo where i've been
> too lazy to finish the wireless and drawterm from linux to my cpu server.
> i get much  more done on a plan9-only system.
>
> if he were interested in doing research into new ways of accessing the web,
> perhaps using some clever application of 9-inspired ideas,
> then firefox would probably be a waste of time.   if he just wants to browse
> successfully, perhaps not.   probably by the time he's finished it will be up
> to Web 8.3 but that's not really our problem.   i wouldn't waste time arguing about it (here).
>
>

I'm not saying using whatever browser under linuxemu is a problem.
I think the problem is not having a good native browser for Plan 9.

iru

Re: [9fans] importing web browsers (was Building GCC)

[lucio]

> I'm not saying using whatever browser under linuxemu is a problem.
> I think the problem is not having a good native browser for Plan 9.

Which is due to the complexity of the task it needs to perform with a
high degree of accuracy.  Given (a) that there aren't enough Plan 9
developers to construct a piece of software of Firefox's magnitude,
(b) that Firefox is not very likely to be ported to Plan 9 because,
again, there aren't enough developers to do it and (c) that the web is
not even remotely likely to stand still long enough to be called a
"standard", whichever aspect you wish to consider it from:

	it just isn't going to happen!

Learn to live with it.  Or show me how you expect it will happen.

++L

Re: [9fans] importing web browsers (was Building GCC)

[Iruata Souza]

On Jan 25, 2008 3:50 PM,  <lucio@proxima.alt.za> wrote:
> Which is due to the complexity of the task it needs to perform with a
> high degree of accuracy.  Given (a) that there aren't enough Plan 9
> developers to construct a piece of software of Firefox's magnitude,
> (b) that Firefox is not very likely to be ported to Plan 9 because,
> again, there aren't enough developers to do it and (c) that the web is
> not even remotely likely to stand still long enough to be called a
> "standard", whichever aspect you wish to consider it from:
>
>         it just isn't going to happen!
>
> Learn to live with it.  Or show me how you expect it will happen.
>

abaco.
I don't expect it to happen. I help writing it.

iru

Re: [9fans] importing web browsers (was Building GCC)

[Iruata Souza]

On Jan 26, 2008 1:47 PM, Iruata Souza <iru.muzgo@gmail.com> wrote:
> On Jan 25, 2008 3:50 PM,  <lucio@proxima.alt.za> wrote:
> > Which is due to the complexity of the task it needs to perform with a
> > high degree of accuracy.  Given (a) that there aren't enough Plan 9
> > developers to construct a piece of software of Firefox's magnitude,
> > (b) that Firefox is not very likely to be ported to Plan 9 because,
> > again, there aren't enough developers to do it and (c) that the web is
> > not even remotely likely to stand still long enough to be called a
> > "standard", whichever aspect you wish to consider it from:
> >
> >         it just isn't going to happen!
> >
> > Learn to live with it.  Or show me how you expect it will happen.
> >
>
> abaco.
> I don't expect it to happen. I help writing it.
>

s/don't expect/not only

iru

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 25, 4:32 pm, brant...@coraid.com (Brantley Coile) wrote:
> > On Jan 25, 2008 7:55 AM,  <pavlovet...@gmail.com> wrote:
> >> it  really does not make any sense to write web browser from the ground
> >> up, if there is a workable version.
>
> > here we go again...
> > why use Plan 9 at all if every mainstream operating system is 'workable'?
> > i guess workable is not the point.
>
> > iru
>
> Plan 9 is not, and should not in my opinion, be a Linux
> replacment, Unix replacement, MS Windows replacement, and
> so on.  If you really want Plan 9 to dominate the world
> and see all your friends use it every day, invent a killer
> application for it.  That's the only way you can shove
> existing systems of their pedestals.  Making Plan 9
> exactly like Linux, or Windows, or son on, will not
> cause people to leave the real Linux or Windows and use
> Plan 9.  Lack of a browser is not why only the select
> few use Plan 9.  It's a culture thing.
>
> If you want Linux you know where to find it.

My main point was that there should be a sort of extension to the core
system in form of, say, linuxemu driven applications and/or ported
applications whatever their origins are. The important part is to keep
the core system independent of these ports. I like the idea behind
linuxemu even more, because there is nothing to port and sometimes you
have just binary without access to the code. This is "applications on
demand" model, when you have it the time you need it, locally. You use
application, get results, write them down and go as usual, in native
Plan 9 environment. Specifically to my situation, it sounds great.

Instead of putting mainstream applications and Plan 9 system in
different boxes and use network to get certain job done, I would like
to see Plan 9 system having elegant way to run non native binaries
when needed locally without integrating them into the core system.
This approach can be pursued either by hardware emulation, like QEMU
does, or by operating system kernel emulation, like linuxemu does,
putting kernel into userspace.

I agree about culture thing, as you put it, and I believe that the
world would be a better place if every computer science student be
given thorough course on it.

Re: [9fans] Re: Building GCC

[lucio]

> why use Plan 9 at all if every mainstream operating system is 'workable'?
> i guess workable is not the point.

I don't get it, why does Plan 9 have to behave like Linux or Windows?
There are tractors, tracks and lamborghinis and no one expects the
first to travel at the speed of sound, the second to pull ploughs or
the last to carry furniture around.

Yet they all use the internal combustion engine and have wheels at the
four corners.  Even the user interface is moderately common amongst
them.

++L

Re: [9fans] Re: Building GCC

[Iruata Souza]

On Jan 25, 2008 4:04 PM,  <lucio@proxima.alt.za> wrote:
> > why use Plan 9 at all if every mainstream operating system is 'workable'?
> > i guess workable is not the point.
>
> I don't get it, why does Plan 9 have to behave like Linux or Windows?
> There are tractors, tracks and lamborghinis and no one expects the
> first to travel at the speed of sound, the second to pull ploughs or
> the last to carry furniture around.
>
> Yet they all use the internal combustion engine and have wheels at the
> four corners.  Even the user interface is moderately common amongst
> them.
>
> ++L
>
>

you got me wrong.

iru

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

I'm also saying that if and when Plan 9 does gets this layout feature  
that works like Oberon (which I tried, but never managed to get  
installed, so I have no first-hand experience - more of Wirth's junk  
in the trunk), people might be reluctant to leave Microsoft Word for  
it. acme does not need to support .doc. However, I don't think people  
would want to have a windowing environment where your commands are  
not accessed via a Start menu or Dock, where you use the right mouse  
button to create windows, and where there is no readily visible close  
button in a familiar place. For Plan 9, it's what we, its users,  
want, not what they, the rest of them that don't see us, want. If  
they do Plan 9, they'll probably get the QEMU module from somewhere  
in /n/sources/contrib to install Windows or go right to Inferno's wm/ 
wm (and Inferno's acme would need to be updated too) and skip all of  
Plan 9's glory.

On Jan 24, 2008, at 1:52 PM, erik quanstrom wrote:

>> Unfortunately, we're about 20 years too late. People have Microsoft
>> Word and they don't need an operating system with useful features,
>> automated backup at no additional cost, and a wealth of
>> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
>> I use troff now. If you disagree, raise your virtual hands.
>
> it's quite a stretch to go from acme being able to handle layouts
> to microsoft word.  the oberon system had something like layouts,
> but layouts were part of the text module.  thus there was no such
> thing as plain text.  the next station had display postscript. but
> that's a quite complicated model.   i think text should be text and
> images should be images.
>
> but you just can't do graphics or html layout with just text.
> you need something to glue (sorry) things together.  it's
> fairly annoying that proof text is not selectable and doesn't
> work inside acme.
>
> i realize there are holes around the edges.  i don't see how to
> edit or select a layout, just the text within layouts.  maybe
> select skips non-text bits.
>
> what's so wrong about this idea?
>
> - erik

Re: [9fans] Re: Building GCC

[lucio]

> i realize there are holes around the edges.  i don't see how to
> edit or select a layout, just the text within layouts.  maybe
> select skips non-text bits.
> 
> what's so wrong about this idea?

Nothing, you need to think out of the box.  Current selection in
sam/acme is linear, even though it is shown as two-dimensional.  Text
is treated as linear (might explain why HTML tabels are treated with
contempt) even though it has some two-dimensional properties, at least
on the screen or on paper.

For layouts (I'm pretty ignorant here, please excuse any blunder I may
utter), you need at least as many dimensions as occur in the
representation, one is not a practical option, two would be normal,
more will no doubt be possible in the future.  My gut feel is that
once one breaks away from the linear interpretation of text, a lot of
things will fall into place.

One thought is that vertical font sizes are an additional dimension,
while images are merely single characters with unusual height and
width.  The horizontal character size is in the first dimension, of
course.

As for mark-ups, they require their own treatment, probably along the
lines of living in a separate layer as would be the case in image
editing.  Using layers seems to me like a good concept to edit
enhanced text.  Perhaps horizontal and vertical dimensions also belong
in layers distinct from the abstract text.

Just a naive idea...

++L

Re: [9fans] Re: Building GCC

[erik quanstrom]

> Nothing, you need to think out of the box.  Current selection in
> sam/acme is linear, even though it is shown as two-dimensional.  Text
> is treated as linear (might explain why HTML tabels are treated with
> contempt) even though it has some two-dimensional properties, at least
> on the screen or on paper.

selection implies you can paste.  if you can paste, you need a Word
Processor™ to edit these layouts.  so i think selection is something to be avoided.

- erik

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 24, 9:24 pm, lu...@proxima.alt.za wrote:
> > i realize there are holes around the edges.  i don't see how to
> > edit or select a layout, just the text within layouts.  maybe
> > select skips non-text bits.
>
> > what's so wrong about this idea?
>
> Nothing, you need to think out of the box.  Current selection in
> sam/acme is linear, even though it is shown as two-dimensional.  Text
> is treated as linear (might explain why HTML tabels are treated with
> contempt) even though it has some two-dimensional properties, at least
> on the screen or on paper.
>
> For layouts (I'm pretty ignorant here, please excuse any blunder I may
> utter), you need at least as many dimensions as occur in the
> representation, one is not a practical option, two would be normal,
> more will no doubt be possible in the future.  My gut feel is that
> once one breaks away from the linear interpretation of text, a lot of
> things will fall into place.
>
> One thought is that vertical font sizes are an additional dimension,
> while images are merely single characters with unusual height and
> width.  The horizontal character size is in the first dimension, of
> course.
>
> As for mark-ups, they require their own treatment, probably along the
> lines of living in a separate layer as would be the case in image
> editing.  Using layers seems to me like a good concept to edit
> enhanced text.  Perhaps horizontal and vertical dimensions also belong
> in layers distinct from the abstract text.
>
> Just a naive idea...
>
> ++L

 Treating image as character (with unusual width and height) means
indefinite number of potential characters and if a machine (not human)
does not able to differentiate between "text characters" and "image
characters" it renders character sets unusable.

Re: [9fans] Re: Building GCC

[lucio]

>  Treating image as character (with unusual width and height) means
> indefinite number of potential characters and if a machine (not human)
> does not able to differentiate between "text characters" and "image
> characters" it renders character sets unusable.

Sure, but the idea is that the actual description of the image lies in
a different layer (no, I don't have any idea how these will be linked)
and only a descriptive placeholder will appear at the relevant
coordinates (recall that I'm advocating a two-dimensional
representation to replace the current linear simplification).

But your point is certainly relevant.  And I'm only tossing ideas
around, no deep theories involved.

++L

Re: [9fans] Re: Building GCC

[Pietro Gagliardi]

We could store the raw data in binary files and have C programs  
access the data with a standard interface.

	/* in libc */
	enum { Achar, Aimage };

	typedef struct Atom {
		int type;
		union {
			char c;
			Image *i;
		};
	} Atom;

	void amamkechar(Atom *a, char c)
	{
		a->type = Achar;
		a->c = c;
	}

	void amakeimage(Atom *a, Image *i)
	{
		a->type = Aimage;
		a->i = i;
	}

	/* in libdraw */	
	void drawatom(Image *d, Atom *a, Point loc, Image *textcolor, Point  
textcolorpt, char *font)
	{
		if (a->type == Atext) {
			char c[2];

			c[0] = a->c;
			c[1] = '\0';
			string(d, loc, textcolor, textcolorpt, font, c);
		} else
			
	}

However, this severely complicates the Unix/Plan 9 philosophy of  
pipes, and only allows for character-at-a-time reads. We could add an  
ability to read a string of characters up to EOF or an image to make  
it (a tiny bit) simpler.

On Jan 25, 2008, at 6:21 AM, lucio@proxima.alt.za wrote:

>>  Treating image as character (with unusual width and height) means
>> indefinite number of potential characters and if a machine (not  
>> human)
>> does not able to differentiate between "text characters" and "image
>> characters" it renders character sets unusable.
>
> Sure, but the idea is that the actual description of the image lies in
> a different layer (no, I don't have any idea how these will be linked)
> and only a descriptive placeholder will appear at the relevant
> coordinates (recall that I'm advocating a two-dimensional
> representation to replace the current linear simplification).
>
> But your point is certainly relevant.  And I'm only tossing ideas
> around, no deep theories involved.
>
> ++L
>

Re: [9fans] Higher level document rendering and editing (Was: Building GCC)

[lucio]

> We could store the raw data in binary files and have C programs  
> access the data with a standard interface.

You want the primary abstraction (layer 0, let's say) to be very
similar to the existing "pure text".  Any mark-up becomes a pointer to
an object in a different layer which conveys additional attributes.

It may be sensible to assign the layers as "classes" so that objects
in a particular layer have common properties.  Defining additional
layers provides for new classes, together with the methods that apply
to them.

I'm not sure how you'd recognise mark-up markers, but it will
hopefully be a single in-band escape.  Or maybe there is a better way,
I know Doug Gwyn makes a good case for avoding in-band signalling...

But I seriously think I'm getting into this deeper than I am competent
to.

I'd like to point out, though, that the P9 synthetic filesystem is a
preferable abstraction to a specialised library and in this particular
instance, I would present a complex, marked-up document specifically
as a collection of files in such a synthetic filesystem.

++L

[9fans] Re: Higher level document rendering and editing (Was

[pavlovetsky]

> I'd like to point out, though, that the P9 synthetic filesystem is a
> preferable abstraction to a specialised library and in this particular
> instance, I would present a complex, marked-up document specifically
> as a collection of files in such a synthetic filesystem.

Groovy. For some time already I am considering bundles of files and
directories as a method of structuring a complex document, and this by
no means is not new to the world, though. There is also structural
regular expressions, which can describe two-dimensional patterns (and
describe tables!).

Re: [9fans] Re: Higher level document rendering and editing (Was

[Federico G. Benavento]

>> I'd like to point out, though, that the P9 synthetic filesystem is a
>> preferable abstraction to a specialised library and in this particular
>> instance, I would present a complex, marked-up document specifically
>> as a collection of files in such a synthetic filesystem.
> 

that's what aux/olefs does with MS Office documents, doc2txt and xls2txt
are scripts that mount the doc in /mnt/doc and use helper programs to
read files in there.



> Groovy. For some time already I am considering bundles of files and
> directories as a method of structuring a complex document, and this by
> no means is not new to the world, though. There is also structural
> regular expressions, which can describe two-dimensional patterns (and
> describe tables!).

Re: [9fans] Re: Building GCC

[lucio]

>> Given a rendering engine with a powerful and hopefully flexible input
>> language, one may be able to write compilers or interpreters for the
>> more popular brands.  Or am I missing the wood for the trees?
>> 
> 
> i think you're right on the mark.  suppose that acme and rio were built
> on "liblayout" and not libframe.  liblayout provides a basic boxes-n-glue
> view of the world; acme/rio export /dev/layout.  a box could contain an image or a
> text frame.  then acme could display things like images along with text,
> static html content (given an educated htmlfmt), etc.

How far away is abaco from all this?  My impression is that it at
least aims in that direction.  Thing is, it always struck me that
abaco and acme ought to be blended, not constructed independently of
each other.

But I must confess that I'm still too scared to look under the larger
Plan 9 applications, I accept them as they come.

++L

[9fans] Re: Building GCC

[pavlovetsky]

On Jan 24, 8:23 pm, pietr...@mac.com (Pietro Gagliardi) wrote:
> And then we can have raw images as filenames, raw images in plain
> text, text as the stroke style for a line, etc. I'd like raw images
> in text - it makes mpictures and converting to PostScript unnecessary.
>
> According to the wiki page on TODO, it says htmlfmt needs knowledge
> of tables. With this, we could just put the HTML parser and rendering
> in acme/rio and avoid htmlfmt.
>
> Unfortunately, we're about 20 years too late. People have Microsoft
> Word and they don't need an operating system with useful features,
> automated backup at no additional cost, and a wealth of
> documentation. I doubt I'll purchase Office:mac 2008 for my iMac, as
> I use troff now. If you disagree, raise your virtual hands.
>
> Instead of debating on what's the right thing to do to add innovation
> about 10+ years old to a system that should've had it 10 years ago,
> let's focus on how to innovate for the future, shall we? It's not
> that I don't like starting debates (I did start this one), but now my
> original idea sounds unnecessary.
>
> I just wanted Konqueror so I could browse the whole web, but with
> someone adding CSS to abaco and JavaScript in charon, can we merge
> them or add JavaScript to abaco or something? I don't know anymore.
> If you need me, I'll be adding tables to htmlfmt.

If I were on your place, I would take a look at linuxemu. It is hot.

Re: [9fans] Building GCC

[Pietro Gagliardi]

No, not really. Rio is one of the best things, and you get used to  
acme very quickly. I'm saying that we can have
.I more
software available at our fingertips.

Example: there is no art program.
Options:
	- 2nd edition Draw (/n/sources/extra/draw.tar.gz)
		I tried this, and I was thoroughly confused by it.
	- /n/sources/contrib/andrey/line.tgz
		Only does lines
	- Write your own
		Good luck
	- Cross-compile another one
		It'll take a bit less work

Thank you Mr. Trickey for APE.

As for email, I like upas/fs, but I never got it to work right with  
faces and I prefer using the folder-based system of Mac OS X Mail.

My attempt to port Qt/KDE is an experiment to see how easily we can  
port other software to Plan 9. If we can port the software untouched,  
we can add features like plumbing, etc. to Plan 9. I also don't want  
to port
.I all
of KDE. My goals right now are Konqueror's web browsing capabilities,  
and stop.

Another option is to convert, line by line, Konqueror from Qt to  
libcontrol or Limbo/Tk and add features that we like.

Avoid emacs and vi at all costs. Acme or bust! I don't want to be in  
RMS' chapel/cathedral.

I give up on GCC and other ports anyways. I'll see what I can do for  
a web browser - possibly add JavaScript/CSS to abaco or add CSS to  
charon. For the latter, I'm having problems with andrey's port of Dis.

Discussion closed, unless anyone wants to bring any ideas up.

Re: [9fans] Building GCC

[Iruata Souza]

On Jan 22, 2008 3:15 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> I give up on GCC and other ports anyways. I'll see what I can do for
> a web browser - possibly add JavaScript/CSS to abaco or add CSS to
> charon. For the latter, I'm having problems with andrey's port of Dis.
>
> Discussion closed, unless anyone wants to bring any ideas up.
>
>

I'm adding CSS to abaco.
already told you on another post: Limbo has a CSS module.

iru

Re: [9fans] Building GCC

[Pietro Gagliardi]

On Jan 22, 2008, at 1:19 PM, Iruata Souza wrote:
>
> I'm adding CSS to abaco.

Good. Do you have it up on a /n/sources/contrib?

> already told you on another post: Limbo has a CSS module.
>
> iru


On Jan 17, 2008, at 3:34 AM, Charles Forsyth wrote:
>> limbo has a css module.
>
> yes, but no one has done the work to get charon (or something else)  
> to use it.
> rather than doing that now, it might be worthwhile trying to skip a  
> generation,
> since people are starting to realise that there might be other  
> possible interfaces to
> the Internet(!).  i've seen a few articles along the lines of  
> ``beyond the browser''.
> such novelty!
>

So my idea was to implement it among Forsyth's better judgement :-)

Re: [9fans] Building GCC

[Iruata Souza]

On Jan 22, 2008 4:28 PM, Pietro Gagliardi <pietro10@mac.com> wrote:
> Good. Do you have it up on a /n/sources/contrib?
>
not yet. for now it's just a port of the limbo parser.

> So my idea was to implement it among Forsyth's better judgement :-)
>
sorry, I've forgotten you had actually answered me.


iru

Re: [9fans] Building GCC

[John Stalker]

> why use plan 9 at all?  why not just install linux or freebsd?
> russ

In fact, I do use FreeBSD and p9p, thanks, most of the time.
The point for me is that plan9 is much nicer as a development
environment, but most of the time I am using software written
by other people, most of whom, sadly, were not Rob Pike.

-- 
John Stalker
School of Mathematics
Trinity College Dublin
tel +353 1 896 1983
fax +353 1 896 2282

Re: [9fans] Building GCC

[ron minnich]

On Jan 22, 2008 4:15 AM, Russ Cox <rsc@swtch.com> wrote:

>
> why use plan 9 at all?  why not just install linux or freebsd?

because, like it or not, lack of some familiar apps is a barrier to
entry for many, if not most, of the people I show Plan 9 to. That
said,
I would probably draw the line at KDE ... but not at emacs.

ron

Re: [9fans] Building GCC

[Eric Van Hensbergen]

On Jan 22, 2008 10:35 AM, ron minnich <rminnich@gmail.com> wrote:
> On Jan 22, 2008 4:15 AM, Russ Cox <rsc@swtch.com> wrote:
>
> >
> > why use plan 9 at all?  why not just install linux or freebsd?
>
> because, like it or not, lack of some familiar apps is a barrier to
> entry for many, if not most, of the people I show Plan 9 to. That
> said,
> I would probably draw the line at KDE ... but not at emacs.
>

Also - some (HPC) apps that we want to run on Plan 9 have silly
dependencies on things like X11.  However, that gets into a different
topic than I think the original poster was talking about.

          -eric

Re: [9fans] Building GCC

[erik quanstrom]

> Also - some (HPC) apps that we want to run on Plan 9 have silly
> dependencies on things like X11.  However, that gets into a different
> topic than I think the original poster was talking about.

they're running X on blue gene?  that's mad.

- erik

Re: [9fans] Building GCC

[Eric Van Hensbergen]

On Jan 22, 2008 11:07 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> > Also - some (HPC) apps that we want to run on Plan 9 have silly
> > dependencies on things like X11.  However, that gets into a different
> > topic than I think the original poster was talking about.
>
> they're running X on blue gene?  that's mad.
>

They aren't.

However, some of the apps may want X hooks to compile (even if the GUI
aspects of the app aren't used).  This is second hand information to
me from Ron, so he can probably portray the actual situation better.

        -eric

Re: [9fans] Building GCC

[ron minnich]

On Jan 22, 2008 9:07 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> > Also - some (HPC) apps that we want to run on Plan 9 have silly
> > dependencies on things like X11.  However, that gets into a different
> > topic than I think the original poster was talking about.
>
> they're running X on blue gene?  that's mad.

So here's a true story. My team at LANL built an incredibly light
weight linux environment for clustering. We could boot 1024 nodes in
2.5 minutes from power off -- less time than it takes most BIOSes to
exit POST. About 2 minutes of that time was Linux saying "look what
hardware I just found" and sleeping on device polling. That scaled
well to large systems -- 2048 nodes took about the same time, since we
used tree-spawn and other nice tricks, such as storing the Myrinet
routes in CMOS so you didn't have to reconfigure the net each and
every time you booted. The compute nodes had one daemon.

You could start a 16 MB MPI image in 2-3 seconds on 1024 nodes, about
the same on 2048, since tree spawn is your friend. The scheduler would
schedule arbitrary groups of nodes in seconds.

This all worked. It's used around the world today, even though our
last release was 2004. It is being turned off, at LANL, in part
because a number of users wish to run xterms and xemacs and similar
apps on a *compute* node. Oh, and because people need Python now, of
course.

So, yes, I expect to see people demanding x11 apps on cluster nodes.
The problem is that all the development nowadays is on the linux
desktop, and people just expect that complete desktop to be there on
each and every cluster node. It's hard to get them to understand that
there is a performance cost to this idea -- or, they just don't care.

ron

Re: [9fans] Building GCC

[erik quanstrom]

> So, yes, I expect to see people demanding x11 apps on cluster nodes.
> The problem is that all the development nowadays is on the linux
> desktop, and people just expect that complete desktop to be there on
> each and every cluster node. It's hard to get them to understand that
> there is a performance cost to this idea -- or, they just don't care.

from the cathdral and the bazzar to the barbarians at the gates.
it's bestseller mashup oss style.

- erik

Re: [9fans] Building GCC

[erik quanstrom]

> >
> > why use plan 9 at all?  why not just install linux or freebsd?
> 
> because, like it or not, lack of some familiar apps is a barrier to
> entry for many, if not most, of the people I show Plan 9 to. That
> said,
> I would probably draw the line at KDE ... but not at emacs.
> 

i'm not arguing with your point.  i think it's a good one, although
not my style.  but on a practical level, how do you get any of the
plan 9 graphical apps to work if you're running x11/kde on top of
plan 9?  conversely, how do you educate kde on the ways of plan 9.

since it's a environment, not just an application, i would think
it a lot harder than your strawman of emacs.  perhaps that's just
my narrow thinking.

- erik

Re: [9fans] Building GCC

[ron minnich]

On Jan 22, 2008 9:07 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> i'm not arguing with your point.  i think it's a good one, although
> not my style.  but on a practical level, how do you get any of the
> plan 9 graphical apps to work if you're running x11/kde on top of
> plan 9?  conversely, how do you educate kde on the ways of plan 9.

stick x11 in a little window, then click 'hide' on it.

ron