I did a bulk upload of code to /n/sources/contrib/maht

Hi, just for anyone's interest I uploaded a bunch of code to my plan9 
sources account space

I'm sure I don't need to link to it, but here it is anyway
http://plan9.bell-labs.com/sources/contrib/maht/limbo/

I've added ./appl/(lib cmd) and ./module

Code Highlights :
Flickr uploading, some other querys
cmd line Blogger posting (including SSL sign-in to Google with Factotum) 
and Blogger module
VNC module, 24bit unencrypted no-auth raw connection only, no sending 
keys/mouse. I'm using it to get screen grabs (program also included) not 
do remote control - hooks are there for the whole protocol, I just 
haven't filled them all in yet.
Start of a mandlebrot plotter I was playing with to the learn tk
httpc : http client that can POST and do SSL3 - not HTTP complete but 
copes with chunked responses - it's used in the Web stuff above
ppm writer
postgresql client module
psqlf is supposed to output all the stored procs for one DB in SQL 
format so you can edit them and re-import them to the db, I know it 
works but I just tried it and it fails, I'll look into that soon because 
I actually use it.
mime builds a simple Mime document from parts for sending to flickr
xmhell is the distribution xml but it takes a string instead of an FD

I can't get a mkfile right even though I did try a couple of times by 
copy & paste some other people's so

Hosted inferno without the MDI

After a few years of study I was finally able to follow the "Threads: 
Sewing badges of honor onto a Kernel" thread in 9fans.

Later in the discussion Rog mentioned an Inferno wm what broke out of 
the "Inferno in a window" system

http://groups.google.co.uk/group/comp.os.plan9/msg/4d47ccaf4a1cfe8c

Does this exist now, is it something I missed ?

maht

Re: Hosted inferno without the MDI

On Feb 1, 2008 7:46 AM, maht <maht@...> wrote:
> After a few years of study I was finally able to follow the "Threads:
> Sewing badges of honor onto a Kernel" thread in 9fans.
>
> Later in the discussion Rog mentioned an Inferno wm what broke out of
> the "Inferno in a window" system
>
> http://groups.google.co.uk/group/comp.os.plan9/msg/4d47ccaf4a1cfe8c
>
> Does this exist now, is it something I missed ?
>

Charles will probably give a more educated answer, but the long and
short of it is that Vita reworked wm (and associated infrastructure)
to make it a bit more flexible w.r.t. tk and draw based apps
co-existing.  This should, in theory, make it easy to go to a
"multi-screen"/multi-window draw environment that lets Inferno break
out of the box.  I haven't used it, but it would seem that rioimport.b
tries to accomplish some portion of this (but perhaps just for a
standalone app in a rio window?)

            -eric

Re: Some procedures and wiki

On Oct 1, 2007 10:36 AM, Brian L. Stuart <blstuart@...> wrote:

> That's odd.  The file name that is on the server is inf.iso.gz
> and that's also the name in the HTML of the instructions.  I'm
> not sure where the .tar came from.

I think the mime type on the server is wrong.

mennis <at> gorilla ~ $ wget https://umdrive.memphis.edu/blstuart/htdocs/inf.iso.gz
--15:12:54--  https://umdrive.memphis.edu/blstuart/htdocs/inf.iso.gz
           => `inf.iso.gz'
Resolving umdrive.memphis.edu... 141.225.112.91
Connecting to umdrive.memphis.edu|141.225.112.91|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 21,846,928 (21M) [application/x-tar]

Ian

Re: Hosted inferno without the MDI

a quick explanation of the wm infrastructure:

a client (e.g. a graphical application) interacts with the
graphics environment in two independent ways: via the file system
interface at /dev/draw, and via a limbo channel-based interface
that it receives (usually) from Draw->Context.

that means that communication with the window manager is quite
straightforward and efficient (it doesn't have to implement a file server)
and communication with the graphics engine doesn't have to go through
a limbo process.

when the client needs a new window, it sends a message to the window
server, which creates one as appropriate, and sends it to the client.
the window manager keeps track of the position of the windows,
and sends mouse and keyboard messages to the appropriate application.
(wm(1) and wmsrv(2) have some of the details)

of course, limbo channels don't cross machine boundaries, which
is where wmexport, wmimport, rioimport, etc come in.
these programs act as protocol translators between a filesystem
interface and the channel interface.

for instance, wmexport takes a normal limbo Draw->Context, and
acts as a fileserver providing an interface to the wm channel.

wmimport goes in the other direction - it uses a fileserver interface
(as exported by wmexport) and creates a wm channel interface from it.
rioimport is similar, except that it creates the wm channel
from a rio-style filesystem interface.

Re: Some procedures and wiki

> I think the mime type on the server is wrong.
> 
> mennis <at> gorilla ~ $ wget https://umdrive.memphis.edu/blstuart/htdocs/inf.iso.gz
> --15:12:54--  https://umdrive.memphis.edu/blstuart/htdocs/inf.iso.gz
>            => `inf.iso.gz'
> Resolving umdrive.memphis.edu... 141.225.112.91
> Connecting to umdrive.memphis.edu|141.225.112.91|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 21,846,928 (21M) [application/x-tar]

Ah.  I don't think there's a MIME type specifically for
ISO images, but since it's compressed, I set it to gzip.
Hopefully, that'll work better.

BLS

Re: limbo compiler (code reachability)

> originally the assignment was in, with the `why?' comment, but later commented out.
> i'll study it further in case there's something really subtle.

it wasn't that subtle, but it's not quite right.  the `why?' comment was added
later by someone who even later concluded there was no reason to do it.
if a JMP instruction branches to one of several possible flow-control instructions,
the JMP is replaced by the target instruction, to go directly to the final destination
and avoid the extra jump.  in the case of IRET, however, if the return is the
default return at the end of the function, then the default return is actually being used.
the code that diagnoses failure to return a value needs to know that.
it does it by checking whether it was reachable, but if the instruction is simply copied by IJMP
it will be used (in the sense above) but the original IRET will
remain unreachable, so the diagnostic won't be given.
i've temporarily changed foldbranch to mark IRET reachable, which means
that functions that don't return a value might have an extra (unreachable) IRET
if foldbranch flags it.  i can think of ways to fix that, but not right now.

Re: limbo compiler (code reachability)

>i can think of ways to fix that, but not right now.

i've put a better fix in, that doesn't leave unreachable IRET instructions.

urls in htppd

Re: urls in htppd

The httpd in the distribution is not in a particularly usable state.
Fortunately there are some alternatives... but good luck finding them
(the list archives might be helpful... or not)

uriel

On Feb 4, 2008 2:29 PM, Sergio de Mingo <sdemingo@...> wrote:
> Hi all,
>
> I have a problem with httpd. When I try export the /services/httpd/root
> directory without a index.html, the directory webpage is generated with bad
> links. The "href links" have the absolute path of the files.
>
> ls /services/httpd/root
> bla
> bla2
>
> If I go to the root directory with my navigator, the webpage has a link to
> /services/httpd/bla. Then, If I click in this link, the navigator go to
> http://localhost/services/httpd/root/bla and I get an error because the file
> /services/httpd/root/services/httpd/root/bla doesn't exists. What could be
> the problem?
>
> thanks.
>
> --
>
> Sergio.