Re: [9fans] Webbrowser

Re: [9fans] Webbrowser

[Keith Nash]

> " 'Even though some of us used to work on Mozilla, we have to admit that
> the Mozilla code is a gigantic, bloated mess, not to mention slow, and with
> an internal API so flamboyantly baroque that frankly we can't even
> comprehend where to begin. Also did we mention big and slow and
> incomprehensible?'".
>
> sounds nice, doesn't it? :) article here:
>
> http://www.theregister.co.uk/content/39/29183.html

This remarkably frank statement describes the reasons for Apple's choice of khtml over Mozilla as the rendering engine for OSX's new web browser, Safari.

Apple has open-sourced its WebCore library, which includes their modified form of khtml, and a library that replaces khtml's calls to KDE and Qt libraries (presumably with Aqua calls).

http://developer.apple.com/darwin/projects/webcore/index.html

http://www.apple.com/safari/

If anyone is serious about porting a graphical browser to Plan 9, this might be worth a look.

Re: [9fans] Webbrowser

[John Packer]

> Apple has open-sourced its WebCore library, which includes their
> modified form of khtml, and a library that replaces khtml's calls to
> KDE and Qt libraries (presumably with Aqua calls).
>
> http://developer.apple.com/darwin/projects/webcore/index.html
>
> http://www.apple.com/safari/
>
> If anyone is serious about porting a graphical browser to Plan 9, this
> might be worth a look.


Unfortunately ktml is written in C++.

Re: [9fans] Webbrowser

[Skip Tavakkolian]

> Unfortunately ktml is written in C++.

You know that GCC has been ported and is available? Or am I missing
something?

Re: [9fans] Webbrowser

[John Packer]

> You know that GCC has been ported and is available? Or am I missing
> something?

I know. I have actually thought about attempting to port the
khtml library to Plan 9, but I guess I'm prejudiced against
C++, (and gcc). I don't mean to offend anyone.

I agree that khtml is far preferable to Mozilla. It just
seemed a step toward Mozilla/X11 chaos and bloatedness, and
away from the grace of Plan 9.

Re: [9fans] Webbrowser

[Russ Cox]

Having gcc doesn't mean we like it.  I have yet to
use gcc for anything -- even my recent Perl 5.8.0 port
still uses pcc, which is just a wrapper around 8c et al.

The main `benefit' of gcc seems to be that you could
compile C++ code, but you'd still be locked in the APE,
making it harder to integrate well with the rest of the system.

On a related note, I looked at links for a while today.
I did most of the work for a port, but there's a big
select loop at the heart of it that I just didn't want
to deal with cutting through.  I also didn't write the
frame buffer, mouse, and keyboard code, but those
look easy once you kill off select.

In my frustration, I tried i again.  No good.

Then I tried charon again.  It's come along quite
a bit since the last time I used it.  It seems like Charon
is still the best bet for now, though I do wish it were
easier to integrate with the rest of the Plan 9 environment.

There's just no good answer right now.

Russ

Re: [9fans] Webbrowser

[Peter Bosch]

> I know. I have actually thought about attempting to port the
> khtml library to Plan 9, but I guess I'm prejudiced against
> C++, (and gcc). I don't mean to offend anyone.
>
> I agree that khtml is far preferable to Mozilla. It just
> seemed a step toward Mozilla/X11 chaos and bloatedness, and
> away from the grace of Plan 9.

g++ can be used on Plan 9.

pb.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

On Wed, 5 Feb 2003, Russ Cox wrote:

> Having gcc doesn't mean we like it.  I have yet to
> use gcc for anything -- even my recent Perl 5.8.0 port
> still uses pcc, which is just a wrapper around 8c et al.
>

just out of curiosity: what are my chances of using the GCC3.0 port to
compile, say GCC3.2 and switch it as the C++ plan9 compiler?

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

I've actually used gcc to compile something -- a simple cpu and memory
benchmark called 'ubench'.

I strongly desire such that the 'my OS is faster' flamewars continue on this
list, that's why i'm posting a URL to the ubench source and compilation
instructions for Plan9 (using the GCC3.0 port).

Unfortunately I couldn't be bothered rewriting the benchmark for the native
P9 compiler, so 'my compiler is faster' flame warriors will be left
dissatisfied.

The URL for ubench is:
	http://www.phystech.com/download/ubench.html

to compile under plan9:
	% gunzip < ubench-0.32.tar.gz | tar xv
	% cd ubench-0.32
	% # edit ubench.c and comment out syslog.h on line 25
	% gnu/gsh
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c
	(alternatively, to compile with optimizations, do:)
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2
	$ ^D
	% strip ubench
	% ubench

here are the highly scientific results I got:

Celeron 900mhz (average ~40,000 in FreeBSD 4.7 w/ gcc2.95), the machine is a
standalone 9pcdisk/kfs terminal:

no optimizations:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    23072
Ubench MEM:    14221
--------------------
Ubench AVG:    18646
%

with -O2:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    24992
Ubench MEM:    18097
--------------------
Ubench AVG:    21544
%




Pentium 4, 2Ghz (average ~60,000 on FreeBSD 4.7 w/ gcc2.95, now the machine
has FBSD 5.0 w/ gcc3.2 on it, but is booted in p9 so I couldn't test :), the
machine is running as an auth/cpu/kfs server:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    39110
Ubench MEM:    33350
--------------------
Ubench AVG:    36230
cpu%


with -O2:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43528
Ubench MEM:    44170
--------------------
Ubench AVG:    43849
cpu%

And something else: I just checked how ubench is compiled on freebsd (what
optimizations are used) and gave the same arguments to plan9's gcc. The
result is:


$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2 -Wall '-malign-loops=2' '-malign-jumps=2' '-malign-functions=2' -fomit-frame-pointer -s
cpu% strip ubench
cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43863
Ubench MEM:    44170
--------------------
Ubench AVG:    44016
cpu%


as with everything, those results should not be taken too seriously :)

andrey

Re: [9fans] Webbrowser - porting mozilla

[matt]

Mozilla is the name for the renderer and the User interface

The renderer itself is called NGLayout   http://www.mozilla.org/newlayout/

Porting instructions are here : http://www.mozilla.org/newlayout/ngport.html

Reading through them suggests it wouldn't be too hard - ymmv [a lot
probably]

Mind you the bottom of that pages says :  Last modified January 14, 1999.

m

Re: [9fans] Webbrowser - porting mozilla

[Ian Broster]

> Porting instructions are here :
> http://www.mozilla.org/newlayout/ngport.html
> Mind you the bottom of that pages says :  Last modified January 14,
> 1999.

And at the top:

Last updated 8-July-98

...
ian

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

[-- Attachment #1: Type: text/plain, Size: 225 bytes --]

I looked at at the benchmarks.  There are lots of times() calls in
inner loops that are very low cost in Unix but pretty expensive in
Plan 9.  Why not do a run under iostats and post the results.  It
might be enlightening.

[-- Attachment #2: Type: message/rfc822, Size: 5014 bytes --]

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] GCC3.0 [Was; Webbrowser]
Date: Wed, 5 Feb 2003 21:16:59 -0700 (MST)
Message-ID: <Pine.LNX.4.44.0302052038050.7087-100000@csl>

I've actually used gcc to compile something -- a simple cpu and memory
benchmark called 'ubench'.

I strongly desire such that the 'my OS is faster' flamewars continue on this
list, that's why i'm posting a URL to the ubench source and compilation
instructions for Plan9 (using the GCC3.0 port).

Unfortunately I couldn't be bothered rewriting the benchmark for the native
P9 compiler, so 'my compiler is faster' flame warriors will be left
dissatisfied.

The URL for ubench is:
	http://www.phystech.com/download/ubench.html

to compile under plan9:
	% gunzip < ubench-0.32.tar.gz | tar xv
	% cd ubench-0.32
	% # edit ubench.c and comment out syslog.h on line 25
	% gnu/gsh
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c
	(alternatively, to compile with optimizations, do:)
	$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2
	$ ^D
	% strip ubench
	% ubench

here are the highly scientific results I got:

Celeron 900mhz (average ~40,000 in FreeBSD 4.7 w/ gcc2.95), the machine is a
standalone 9pcdisk/kfs terminal:

no optimizations:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    23072
Ubench MEM:    14221
--------------------
Ubench AVG:    18646
%

with -O2:

% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcdisk
Ubench CPU:    24992
Ubench MEM:    18097
--------------------
Ubench AVG:    21544
%




Pentium 4, 2Ghz (average ~60,000 on FreeBSD 4.7 w/ gcc2.95, now the machine
has FBSD 5.0 w/ gcc3.2 on it, but is booted in p9 so I couldn't test :), the
machine is running as an auth/cpu/kfs server:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    39110
Ubench MEM:    33350
--------------------
Ubench AVG:    36230
cpu%


with -O2:

cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43528
Ubench MEM:    44170
--------------------
Ubench AVG:    43849
cpu%

And something else: I just checked how ubench is compiled on freebsd (what
optimizations are used) and gave the same arguments to plan9's gcc. The
result is:


$ gcc -o ubench signals.c cpubench.c membench.c ubench.c -O2 -Wall '-malign-loops=2' '-malign-jumps=2' '-malign-functions=2' -fomit-frame-pointer -s
cpu% strip ubench
cpu% ubench
Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk <sv@phystech.com>
http://www.phystech.com/download/ubench.html
Plan9 1 0 generic pcauth
Ubench CPU:    43863
Ubench MEM:    44170
--------------------
Ubench AVG:    44016
cpu%


as with everything, those results should not be taken too seriously :)

andrey

Re: [9fans] GCC3.0 [Was; Webbrowser]

[andrey mirtchovski]

this is iostats:

read      238369 bytes, 13.02132 Kb/sec
write     1266 bytes, .4715208 Kb/sec
protocol  659280 bytes, 28.10126 Kb/sec
rpc       8876 count

Message    Count   Low  High  Time Averg          in      out
version        1     0     0     0     0 ms       19       19 bytes
attach         1     0     0     0     0 ms       25       20 bytes
flush          1 10000000     0     0     0 ms        9        7 bytes
walk        2544     0   153   551     0 ms    78729    88992 bytes
open        1248     0   117   785     0 ms    14976    29928 bytes
read        1277     0 11179 17877    13 ms    29371   252416 bytes
write         15     0   686  2622   174 ms     1611      165 bytes
clunk       2542     0    44   379     0 ms    27962    17794 bytes
stat        1247     0    50   697     0 ms    13717   103426 bytes

Opens    Reads  (bytes)   Writes  (bytes) File
 1233     1233    88776        0        0 /dev/cputime
    1        0        0        1        5 /proc/10281/note
    1        0        0        1        5 /proc/10282/note
    1        0        0        1        5 /proc/10287/note
    2        0        0        2        9 /proc/10289/note
    1        0        0        1        5 /proc/10295/note
    1        1      172        0        0 /adm/users
    1        2        7        0        0 (stdin)
    1        0        0        7     1227 (stdout)
    1        0        0        2       10 (stderr)
    1        2      579        0        0 /rc/lib/rcmain
    1       24    91459        0        0 /bin/rc
    1       15    57376        0        0 /usr/bootes/ubench-0.32/ubench

and this is what kprof has to say:

total: 492060	in kernel text: 56450	outside kernel text: 435610
KTZERO 80100000
ms	  %	sym
50180	 88.8	halt
3210	  5.6	memmove
420	  0.7	savagewaitidle
410	  0.7	i8259isr
350	  0.6	inb
250	  0.4	drawclip
150	  0.2	runproc
130	  0.2	wbflush
120	  0.2	memset
110	  0.1	chardraw
70	  0.1	rectclip
60	  0.1	memdraw
50	  0.0	drawmesg
50	  0.0	convD2M
50	  0.0	strlen
40	  0.0	syscall
30	  0.0	drawgoodname
30	  0.0	_syscallintr
30	  0.0	dstflush
30	  0.0	memimagedraw
30	  0.0	drawreplxy


interesting tidbit -- iostats filled up the memory on both machines I tried
it on (128 and 512 MB), it's fun to look at in 'stats'

adnrey

On Thu, 6 Feb 2003, David Presotto wrote:

> I looked at at the benchmarks.  There are lots of times() calls in
> inner loops that are very low cost in Unix but pretty expensive in
> Plan 9.  Why not do a run under iostats and post the results.  It
> might be enlightening.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[David Presotto]

Just for a wild guess, I bet the 1200+ open/read/close/strtoui's of
/dev/cputimes skewed the results which would mean that side effects
that wouldn't exist in programs (dominated the results).  The tests
themselves were not at all OS tests, they pretty much test the compiler
and malloc and nothing else.  There's a little pipe stuff in there to implement
locks but they looked like pretty high level locks.

I'm not saying that we're anywhere near as fast as the other OS's,
only that the tests were pretty misdirected.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[William K. Josephson]

On Thu, Feb 06, 2003 at 12:32:52PM -0500, David Presotto wrote:
>themselves were not at all OS tests, they pretty much test the compiler
>and malloc and nothing else. There's a little pipe stuff in there to implement
>locks but they looked like pretty high level locks.

Not to mention that the repeated comparisons with gcc
get tiresome: gcc is really not as great as many proponents
make it out to be, even on the ia32.  I'm very glad to have
it and use it regularly, but it is much slower than either
8c or the vendor compiler and generates substantially slower
code than the vendor compiler, at least in my experience.
It isn't uncommon to see Intel's compiler beat gcc by 30-40%
and I haven't found any non-trivial examples where gcc beats
the Microsoft or Intel compilers, although they may well
exist.  If someone has the time, money, and warm bodies to
invest, great, otherwise I'll port a few assembly routines
when it really matters and get on with my life.  Premature
obfusc^H^H^H^H^Hoptimization is the root of all evil.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, William K. Josephson wrote:

> It isn't uncommon to see Intel's compiler beat gcc by 30-40%
> and I haven't found any non-trivial examples where gcc beats
> the Microsoft or Intel compilers, although they may well
> exist.

Agree with most of your comments re gcc, but the fact is that
counterexamples do in fact exist. In fact I believe that LLNLs latest
LINPACK runs were better with gcc than the intel v7.0 compiler, which I
think surprised *everybody*.

ron

Re: [9fans] GCC3.0 [Was; Webbrowser]

[William K. Josephson]

On Thu, Feb 06, 2003 at 11:16:22AM -0700, Ronald G. Minnich wrote:

> Agree with most of your comments re gcc, but the fact is that
> counterexamples do in fact exist. In fact I believe that LLNLs latest
> LINPACK runs were better with gcc than the intel v7.0 compiler, which I
> think surprised *everybody*.

That does surprise me.  What is the target hardware?
I've found gcc 3.2's support for the Pentium 4 to be
rather atrocious.

Re: [9fans] GCC3.0 [Was; Webbrowser]

[Ronald G. Minnich]

On Thu, 6 Feb 2003, William K. Josephson wrote:

> On Thu, Feb 06, 2003 at 11:16:22AM -0700, Ronald G. Minnich wrote:
>
> > Agree with most of your comments re gcc, but the fact is that
> > counterexamples do in fact exist. In fact I believe that LLNLs latest
> > LINPACK runs were better with gcc than the intel v7.0 compiler, which I
> > think surprised *everybody*.
>
> That does surprise me.  What is the target hardware?
> I've found gcc 3.2's support for the Pentium 4 to be
> rather atrocious.
>

that's the best part. Is a p4@2.4 ghz.

ron

Re: [9fans] webbrowser

[csant]

> there's mothra and abaco.  neither is script or css aware.
and there is a links port and i (a port of the inferno charon) - though at
least the latter isn't maintained anymore, methinks.
/c

Re: [9fans] webbrowser

[erik quanstrom]

there's mothra and abaco.  neither is script or css aware.

	/n/sources/extra/mothra
	/n/sources/contrib/fgb/abaco-test.tgz

i've made some modifications to abaco, most notibly translating
'g query' into a google query.

	/n/sources/contrib//quanstro/abaco.tbz

- erik

[9fans] webbrowser

[jackson john]

em..is there a webbrowser for plan9 ?and how to make my pci soundcard
(soundblaster pci128)sound??

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [9fans] Webbrowser

[Andrey S. Kukhar]

ok (and thanks), but a few hours earlier I found
this all at http://plan9.aichi-u.ac.jp/netlib/
and ftp://ftp.leo.org/pub/comp/os/plan9/

-kyxap

> I added the mothra man page, the html help page
> (/sys/lib/mothra/help.html) and the mothra gifs
> to the /n/sources/contrib/mothra directory.
>
> Russ

Re: [9fans] Webbrowser

[Russ Cox]

I added the mothra man page, the html help page
(/sys/lib/mothra/help.html) and the mothra gifs
to the /n/sources/contrib/mothra directory.

Russ

Re: [9fans] Webbrowser

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

i suppose it amounts to a Third Way--
make Inferno applications such as Charon fit in much better, or even at all,
on most hosted platforms--
and Plan 9 being the closest fit seemed a reasonable place to start.

[-- Attachment #2: Type: message/rfc822, Size: 1494 bytes --]

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Webbrowser
Date: Thu, 6 Feb 2003 09:21:46 -0500
Message-ID: <fec3b8104d0b5d9dddef328d7da60d56@plan9.bell-labs.com>

Are you actually going to try to make a translation to C, or perhaps a free standing
Limbo compiler?

Re: [9fans] Webbrowser

[C H Forsyth]

>>It seems like Charon
>>is still the best bet for now, though I do wish it were
>>easier to integrate with the rest of the Plan 9 environment.

that's our eventual aim.

Re: [9fans] Webbrowser

[David Presotto]

Are you actually going to try to make a translation to C, or perhaps a free standing
Limbo compiler?

Re: [9fans] Webbrowser

[Andrey S. Kukhar]

as for me, in Plan 9 i better like old Duff`s
mothra than charon and "i" (just "because"),
and now i am in searching some info for it:
mothra.1
/sys/lib/cmd/mothra/*.html

and curious about a pair of gifs advertising
`Enhanced for mothra' and `100% mothra-compatible'
earlier were at:
ftp://plan9.bell-labs.com/plan9/mothraenhanced.gif
ftp://plan9.bell-labs.com/plan9/mothracompat.gif

any hints?

Re: [9fans] Webbrowser

[okamoto]

> But installing curses and compiling a curses-based utility as an
> alternative to the above seems too expensive a path to follow.
> Others (masochists?) may differ.

By the way, I'm considering it may be neccessary...

After we wrote marsv, which is a case study of thread(2) and libcontrol(2)
of Plan 9, I feel that we didn't use the heart of Plan 9's benefit to it.
Next target, if I can have a time and students for it, will be to make
plumb and many small graphic programs co-operate.   For that purpose,
we will need a better user interface on acme with cursor addressing
and changing font etc. ☺

Kenji

Re: [9fans] Webbrowser

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

i'd assumed the reason it was `unfortunate'
was that it was written in C++, not because it could not
therefore be compiled on Plan 9.

[-- Attachment #2: Type: message/rfc822, Size: 1715 bytes --]

From: "Skip Tavakkolian" <fst@centurytel.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Webbrowser
Date: Wed, 5 Feb 2003 14:55:40 -0800
Message-ID: <8b300fea709a77690837d12dff799fc5@centurytel.net>

> Unfortunately ktml is written in C++.

You know that GCC has been ported and is available? Or am I missing
something?

Re: [9fans] Webbrowser

[Jack Johnson]

Scott Schwartz wrote:
> By the way, in my opinion the only reason HTML survived at all is because
> of NCSA Mosaic, which was the first fun way for people to look at other
> people's GIFs, and the hacky notation it adopted was simple enough and
> just barely good enough for the crude page layout that people wanted
> to do, with absolutely no consideration for SGML sensibilities until
> long after the fact.

The same could be said of email's roots, where now it's often
encumbered/enhanced by enriched text, HTML formatting, or alternate
character sets that weren't necessarily envisioned previously.

We always try to use our tools for something other than their original
intent.  What you see as HTML's failing is also HTML's strength.  It's
more *our* failing for using it as some kind of panacea.  Plus, HTML
over HTTP beats sucking down PostScript files via gopher, wais or ftp.

After all, where was troff's presence during the gopher years?  What
ever happened to HyperTeX ( http://xxx.lanl.gov/hypertex/ )?  There are
always better alternatives, but more often we're willing to settle for
just good enough.

-Jack

Re: [9fans] Webbrowser

[Scott Schwartz]

| >Frankly, if web browsers interpreted any one of troff macros, ditroff,
| >or dvi (with shell escapes removed), the world would be a better place,
|
| This comment confused me.  I already look at man pages, nicely hyperlinked,
| in my web browser (usually links) all the time.

Sure, if you write all your manpages in html or translate them to html.
My pipe-dream is to delete html (and javascript), and use venerable tools.

| Not just for all three free BSD's, but for plan9 as well.

And they look terrible compared to the troff output. :)

Also, I think it's bad to have multiple competing document formats.
The situation in *nix is that you can never tell what or where any bit
of documentation will be.  Text?  Info?  Docbook?  HTML?  What a mess.

| In general, though, having dvi
| web pages seems like a step in the wrong direction.  The original
| idea of the web was that the writer of a page leaves the business
| of how things are displayed up to the browser.

Some people say that, but my feeling is that almost everyone who builds
a web page wants to do page layout, not structural markup.  Looking at
their work, I don't think that {SG,HT,X}ML style abstraction yields the
right thing very often.  So what you have in practice is horrible html
(plus javascript!) that only displays properly on exactly the same
(huge and complex) software that was used to generate it.

If you let web page droids just publish the dvi, then the output looks
exactly right every time (modulo dpi and font issues).  More enlightened
authors can publish the troff source with standard macros.  If the web
browser can interpret both of those, you've satisfied both imperatives
without recourse to html.

By the way, in my opinion the only reason HTML survived at all is because
of NCSA Mosaic, which was the first fun way for people to look at other
people's GIFs, and the hacky notation it adopted was simple enough and
just barely good enough for the crude page layout that people wanted
to do, with absolutely no consideration for SGML sensibilities until
long after the fact.

[9fans] Webbrowser

[John Stalker]

 From martin@familie-kielhorn.de:

>Hi,
>in Linux I do use links
>(http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/)
>as my standard browser...

Most of the responses to this were confused.  Links was originally
just a text browser. It now has a graphics mode which can do X,
but it is just as happy running with SVGALib, on the linux frame buffer,
or in various more arcane ways.  Take a look at the link for details.
I don't think the suggestion was to port the text mode, but only the
graphics mode.  My feeling, and yes I have looked at the links sources
in the past, is that this can definitely be done.  It would also be
a good thing.  Links is actually better than mozilla, konqueror, etc.
in many respects.  It is the browser I use most often even on machines
that have all of those installed.

 From Scott Schwartz <schwartz@bio.cse.psu.edu>

>Frankly, if web browsers interpreted any one of troff macros, ditroff,
>or dvi (with shell escapes removed), the world would be a better place,
>because then we could generate nicely typeset and nicely portable
>documents that could be widely and reliably displayed.  So my proposal is
>this: get someone else to teach mozilla to grok the formats listed above.
>The killer app is that you can then view good old unix manpages in a
>modern mode!

This comment confused me.  I already look at man pages, nicely hyperlinked,
in my web browser (usually links) all the time.  Not just for all three
free BSD's, but for plan9 as well.  In general, though, having dvi
web pages seems like a step in the wrong direction.  The original
idea of the web was that the writer of a page leaves the business
of how things are displayed up to the browser.  One shouldn't even assume
that the browser is visual, as anyone visually impaired can tell you.
Of course, if you need precise control over how things are formatted
then dvi is much better, which is why I write articles in TeX.  But
the web serves a different purpose most of the time, which is why xdvi
is a separate application which my browser invokes when I need it.

 From martin@familie-kielhorn.de again:

>I consider this project as solvable -- a whole web browser will probably
>be much more complicated, probably I will never manage to write my own
>portable web browser.

For what it's worth here is my opinion: Yes, it can be done.  Yes, it should
be done.  No, I am not going to do it.  Sorry.
--
John Stalker
Department of Mathematics
Princeton University
(609)258-6469

Re: [9fans] Webbrowser

[Skip Tavakkolian]

> now that gcc is available for plan9 one may attempt to compile mozilla, but
> i haven't seen anyone here crazy enough...

Nor young enough, at least for the likes of me.  To echo Forsyth's
sentiment earlier, when there are more days behind you than
you can expect ahead, it is hard to contemplate taking on that challenge.

Re: [9fans] Webbrowser

[Boyd Roberts]

andrey mirtchovski wrote:

>" 'Even though some of us used to work on Mozilla, we have to admit that the
>Mozilla code is a gigantic, bloated mess, ...
>
Obviously, this was my first assumption.  I use the damn thing and
just the mail user agent is a hideous, badly thought out mess.  The
browser doesn't render some pages well or at all (well, I guess
'at all' is value of 'not rendered well').

But I digress.

Anyone wanting to port it to Plan 9 (or anywhere else) is
_bound_ to have their work cut out for them.

Port Mozilla or write a browser from scratch?  No thanks.

Re: [9fans] Webbrowser

[andrey mirtchovski]

On Wed, 5 Feb 2003, Ian Broster wrote:

> Anyway, bloat aside, Mozilla is available for multiple platforms,  so the
> designers have clearly been able to  separate  platform dependent issues
> from the browser itself.  A port of mozilla may be an easier (don't read
> `easy') way of getting a  modern graphical  browser running natively on
> plan 9.
>

i was just reading this paragraph when your message arrived:

" 'Even though some of us used to work on Mozilla, we have to admit that the
Mozilla code is a gigantic, bloated mess, not to mention slow, and with an
internal API so flamboyantly baroque that frankly we can't even comprehend
where to begin. Also did we mention big and slow and incomprehensible?'".

sounds nice, doesn't it? :) article here:

http://www.theregister.co.uk/content/39/29183.html

now that gcc is available for plan9 one may attempt to compile mozilla, but
i haven't seen anyone here crazy enough...

andrey

Re: [9fans] Webbrowser

[Jack Johnson]

Ian Broster wrote:
>>andrey mirtchovski wrote:
>>However, it does have a video terminal emulator
>>and that *does* support cursor addressing.
> We don't use VTs anymore, and for good reason. So lets stop using so many
> VT emulators(!) and stop writing applications for a piece of hardware that
> is now a novelty when you see one in a skip.

I'm not certain if other people went and looked at Links or not, but it
has changed significantly since I saw it last.

Though it still has the text-mode interface, it now also has a graphical
interface:

http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/shots/shot2.jpg

Apparently, this is Links 2.

I'm not certain, but maybe this is what the original poster meant when
he suggested it.

-Jack

Re: [9fans] Webbrowser

[Lucio De Re]

On Wed, Feb 05, 2003 at 09:44:34AM +0000, Douglas A. Gwyn wrote:
>
> However, it does have a video terminal emulator
> and that *does* support cursor addressing.

It's personal, I'm sure, but I can't see any benefit in spending
effort beyond installing Inferno's web browser (the name's just
slipped out of my mind, maybe so have I).

The VNC viewer approach seems even more productive, but I'll grant
that there are exceptional situations where it is not viable.

But installing curses and compiling a curses-based utility as an
alternative to the above seems too expensive a path to follow.
Others (masochists?) may differ.

++L

Re: [9fans] Webbrowser

[Ian Broster]

> andrey mirtchovski wrote:
> > plan 9 does not have cursor addressing...
>
> However, it does have a video terminal emulator
> and that *does* support cursor addressing.

We don't use VTs anymore, and for good reason. So lets stop using so many
VT emulators(!) and stop writing applications for a piece of hardware that
is now a novelty when you see one in a skip.

Anyway, bloat aside, Mozilla is available for multiple platforms,  so the
designers have clearly been able to  separate  platform dependent issues
from the browser itself.  A port of mozilla may be an easier (don't read
`easy') way of getting a  modern graphical  browser running natively on
plan 9.

ian

Re: [9fans] Webbrowser

[Douglas A. Gwyn]

andrey mirtchovski wrote:
> plan 9 does not have cursor addressing...

However, it does have a video terminal emulator
and that *does* support cursor addressing.

Re: [9fans] Webbrowser

[Micah Stetson]

> > Would it be usefull to port it to Plan 9?
>
> plan 9 does not have cursor addressing...

I think he's referring to the graphics mode (links -g).  It
runs under X and several different graphics systems, so
it might be little more than writing another graphics driver
for it.

Micah

Re: [9fans] Webbrowser

[andrey mirtchovski]

On Tue, 4 Feb 2003, Joel Salomon wrote:

> vt(1)
>

hmm... i'd like to politely disagree...

[9fans] Webbrowser

[Joel Salomon]

andrey mirtchovski (mirtchov@cpsc.ucalgary.ca) wrote:
> plan 9 does not have cursor addressing...

vt(1)


--Joel
______________________________________________________
Due to economic circumstances, the light at the end of
the tunnel has been turned off.

Re: [9fans] Webbrowser

[Jack Johnson]

Scott Schwartz wrote:
> documents that could be widely and reliably displayed.  So my proposal is
> this: get someone else to teach mozilla to grok the formats listed above.

Just out of curiosity, would an html->troff converter be easier to
implement than a Web browser?  If so, then you may be on to something,
and least for Plan 9.

Recently Googled info on html-to-tex:

http://hilbert.math.albany.edu:8800/hm/emj/1996/msg00268.html

or harass this guy:

http://archives.postgresql.org/pgsql-docs/1999-08/msg00033.php

or cut and paste from this:

http://216.239.37.100/search?q=cache:qQr6kwiKtAEC:www.zip.com.au/~cs/css/scripts/html2mm

(the original is in data heaven, it seems)

-Jack

Re: [9fans] Webbrowser

[Scott Schwartz]

| Check out 'art' on sources (under contrib);  Also, when I looked into
| this before, I came to the conclusion then that porting XCIP to Plan9
| might be the fastest way to get this functionality.  The output is in
| pic format, so is useful for documentation.  You can find
| information on xcip and its history at this URL:
|
| http://www.bell-labs.com/user/dwd/5620faq.html

Frankly, if web browsers interpreted any one of troff macros, ditroff,
or dvi (with shell escapes removed), the world would be a better place,
because then we could generate nicely typeset and nicely portable
documents that could be widely and reliably displayed.  So my proposal is
this: get someone else to teach mozilla to grok the formats listed above.
The killer app is that you can then view good old unix manpages in a
modern mode!  Then, once millions of Linux users have been won back the
the True Path, dozens of Plan 9 users can take advantage of the situation
by not having to suffer html any more.

Re: [9fans] Webbrowser

[Skip Tavakkolian]

> Occasionally I use the browser "i" which was available with "9fs
> sources", but
> it crashes after 2 or 3 pages.
> What would deserve more support -- the developement of "i" until it does
> not crash anymore or the port of "links".
> I do not think that I am experienced enough to begin that.

This is a sort of Holy Grail quest for 9fans, with no good answers.
The best solutions for now are to either use Charon (with Inferno)
and/or run a browser on a non-Plan9 machine and VNC to it.  Might want
to search comp.os.plan9 archives on this subject.

Ideally there would be an HTML rendering application that webfs
could plumb to and a driver application for webfs to receive plumb
messages that have a URL format.

>
> The only thing I programmed in Plan 9 so far is a very small vector
> drawing program.
> I will try to approximate lines, that I drew with a mouse (or with a
> tablet in vmware).
> In the future I will find some way to represent those with bezier
> curver, b-spline or NURBS -- it should be as "sodipodi" but more usable
> and much more portable.

Check out 'art' on sources (under contrib);  Also, when I looked into
this before, I came to the conclusion then that porting XCIP to Plan9
might be the fastest way to get this functionality.  The output is in
pic format, so is useful for documentation.  You can find
information on xcip and its history at this URL:

http://www.bell-labs.com/user/dwd/5620faq.html

Re: [9fans] Webbrowser

[andrey mirtchovski]

On Tue, 4 Feb 2003 martin@familie-kielhorn.de wrote:

> Would it be usefull to port it to Plan 9?

plan 9 does not have cursor addressing...

[9fans] Webbrowser

[martin]

Hi,
in Linux I do use links
(http://atrey.karlin.mff.cuni.cz/~clock/twibright/links/)
as my standard browser.
It does not seem to depend on huge libraries as the mozilla rendering
engine,
or kde but it does display images, tables and has some enough javascript
support (for mie).
Would it be usefull to port it to Plan 9?
I cannot estimate the time this would take.
Occasionally I use the browser "i" which was available with "9fs
sources", but
it crashes after 2 or 3 pages.
What would deserve more support -- the developement of "i" until it does
not crash anymore or the port of "links".
I do not think that I am experienced enough to begin that.

The only thing I programmed in Plan 9 so far is a very small vector
drawing program.
I will try to approximate lines, that I drew with a mouse (or with a
tablet in vmware).
In the future I will find some way to represent those with bezier
curver, b-spline or NURBS -- it should be as "sodipodi" but more usable
and much more portable.
I consider this project as solvable -- a whole web browser will probably
be much more complicated, probably I will never manage to write my own
portable web browser.