[9fans] another webfs question

[Mathieu]

Hi all,

It seems I'm hitting this error when sending some GET requests:

In /sys/src/cmd/webfs/url.c:

if(strstr(url, "%00")){
werrstr("escaped NUL in URI");
return -1;
}

I haven't fully understood the comment above, especially if it is against
the RFC to have an escaped NUL in an url, but this can actually happen,
at least with queries to a bittorrent tracker. For example when specifying
the info hash of a specific torrent when sending a scrape request:

http://bttracker.debian.org:6969/scrape?info_hash=%F1%AE%D2%E5%15%A0%BD%F1%41%54%9D%44%00%47%AB%97%81%2B%69%16
(13th char in the info hash is a NUL)

I get a reply to that one both with wget on linux or hget on plan 9,
while webfs gives the error from the code above.

So is it webfs that needs fixing for that case, or are the other tools
breaking some RFC with that? 

Cheers,
Mathieu

Re: [9fans] GSOC: Gitfs

[yy]

2009/3/26 Devon H. O'Dell :
> The GSoC traffic is misdirected. The GSoC emails *SHOULD* be going to
> the plan9-gsoc list, which is hosted by Google.
>

I hope the plan9-gsoc list gets more attention. I sent my project
ideas there a week ago and you were the only person who replied my
message. Maybe that's why people is directing their emails to 9fans.

Since I would really like to hear some comments before writting my
application, I will explain here what I have in mind (there's also
some alternative ideas in my original message:
http://groups.google.com/group/plan9-gsoc/browse_frm/thread/52d77f27a3f5645b):
1. Cleaning up drawterm and 9vx draw devices in unix (I don't have a
windows or macos dev environment, or any experience FWIW). I have seen
several small TODOs in the code, and in particular all the Xlib code
should be isolated. I don't know if a complete merge would be
possible, or if p9p could be included in the group.
2. As suggested in drawterm TODO, replace the console with 9term (in 9vx too).
3. Write a wctl device which speaks directly with Xlib, this way rio
wouldn't have to (but could) be used in 9vx/drawterm, and windows
could be managed with the X wm.
4. I have seen the A-term proposition in gsoc.cat-v.org and I could do
it. I'm quite familiar with acme code and in fact is something I had
in mind (to be used with the wctl described above).
I don't think any of these projects is enough for gsoc, but more than
one of the ideas could be combined. I'd like to know your opinions
about what could/should be done.

Regards,


-- 
- yiyus || JGL .

Re: [9fans] 9P writes for directories

[Roman Shaposhnik]

On Mar 26, 2009, at 1:54 PM, Eric Van Hensbergen wrote:

I have thought about that too, but became convinced that POST is more
like create (or more like write on a subdirectory -- hence the  
original

question). With the clone operation it is the *opening* of the clone
device that provides you with a new fid. In HTTP that would be like  
getting

a redirection on GET. Don't you think?



Except that Creates give an ID/path for creation instead of receiving
one -- that's the key thing that makes it like clone, the most
important bit being that this sort of mechanism avoids collision.


I believe we're on the same page, but the wording is  not always
accurate.


Whether or not that is critical depends on how you write your app.  I
think the main difference here is you are trying to map HTTP syntax to
9P syntax, and I've been thinking of semantics -- an HTTP POST to a
subdirectory would equal the opening of a clone file (within that
subdirectory), and writing the metadata,


Interesting point. I guess it all depends on what is the model for
new nodes to be created in the URI tree. In fact, if I were to complete
the analogy, then POST to an existing URI (although, nothing really  
exists
in the world of URIs) corresponding to a "subdirectory" would be, in  
fact,

what you say. A POST/PUT to a non-existing URI could be considered
a creation of the named resource in its parent. Although I'm not sure  
that

such a thing should be always allowed.


a read on that file would
return the ID -- this would be done atomically by the HTTP server to
service the POST not as a set of HTTP routines.


If you mean PRG (http://en.wikipedia.org/wiki/Post/Redirect/Get) then
yes.

I think the critical aspect from the REST/CRUD perspective is that  
the POST

has to be idempotent


Not as per HTTP RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5


Outside of the ID bit, why wouldn't create suffice?


It would (just as Erik pointed out). I guess I was just looking for
symmetry (if POST is really a write(*), it should translate into  
write

independent of whether the URI corresponds to a subdirectory or
not) and potential pitfalls that made 9P spec disallow writes on
subdirectories (and since nobody can identify any of those -- I'll
rest my case and proceed with translating POST into different
9P messages depending on the type of the URI).



I don't think the symmetry is worth altering the semantics of the
protocol -- its likely more trouble than its worth in the long run.


Agreed.

Thanks,
Roman.

P.S. I wonder if there's a general interest in REST from the Plan9
folks. I've seen your blog post on the subject, so there's that. It is
actually quite fun to see how things like Google App Engine and
http://konstrukt.dk/, etc can reap the same benefits from the elegance
of FS-aware design. Could it be that with the right approach
(lib9p/libixp plugin for apache?) writing web services could be
as much fun as writing filesystems for Plan9? 

Re: [9fans] GSOC: Gitfs

[Federico G. Benavento]

you could also use uriel's port of git to Plan 9, I think

On Thu, Mar 26, 2009 at 6:23 PM, Devon H. O'Dell  wrote:
> 2009/3/26 Roman Shaposhnik :
>> Somehow I didn't see the original email from Manzur (was it ever
>> posted to the list?) But given my personal interests, I'd be delighted
>> to help along with the gitfs.
>
> Yeah, it was.
>
>> Since I've ignored most of the GSOC traffic so far, could someone,
>> please point me to the right URLs so that I can see what's required
>> of mentors and whether I'd be a good match for that.
>
> The GSoC traffic is misdirected. The GSoC emails *SHOULD* be going to
> the plan9-gsoc list, which is hosted by Google.
>
> As far as becoming a mentor, create a google account, and go to
> http://socghop.appspot.com/org/apply_mentor/google/gsoc2009
>
> Anthony Sorace is the administrator for the project this year and he
> will have to approve your mentor application.
>
>> Thanks,
>> Roman.
>
> Hope that helps!
>
> --dho
>
>> P.S. besides, there's always a benefit of communicating in Russian
>> or getting together for a few beers in SPB ;-)
>>
>>
>
>



-- 
Federico G. Benavento

Re: [9fans] GSOC: Drawterm for the iPhone

[Devon H. O'Dell]

2009/3/26 Pietro Gagliardi :
> On Mar 26, 2009, at 3:35 PM, Eric Van Hensbergen wrote:
>
>> I'm merely trying to debunk roadblocks which others
>> seem to want to through in his way.
>
> I don't want to throw a roadblock in this student's way. (In fact, drawterm
> on iPhone benefits me too, though that benefit would come in or after June
> :-| ) I just tried to point out a few hurdles. That's what design and
> development is for: jumping hurdles.

I think Eric's sentiment is more towards that those `hurdles' aren't
actually hurdles at all and are misinterpretations that caused about
20 posts debating whether it was actually a hurdle.

> On Mar 26, 2009, at 2:50 PM, andrey mirtchovski wrote:
>>
>> a straight cocoa drawterm rewrite
>
> On Mar 26, 2009, at 3:00 PM, Uriel wrote:
>>
>> A 9vx, p9p or inferno cocoa port is a project that seems fairly
>
> I can do one of these; which is the most needed/wanted?

If you get one, you should get all. Unfortunately, the code bases for
all of these things differ slightly. Some have bugfixes that others
don't have. In my mind, 9vx is the most needed / wanted. Others will
say Inferno. I think fewer would say p9p.

--dho

Re: [9fans] GSOC: Gitfs

[Devon H. O'Dell]

2009/3/26 Roman Shaposhnik :
> Somehow I didn't see the original email from Manzur (was it ever
> posted to the list?) But given my personal interests, I'd be delighted
> to help along with the gitfs.

Yeah, it was.

> Since I've ignored most of the GSOC traffic so far, could someone,
> please point me to the right URLs so that I can see what's required
> of mentors and whether I'd be a good match for that.

The GSoC traffic is misdirected. The GSoC emails *SHOULD* be going to
the plan9-gsoc list, which is hosted by Google.

As far as becoming a mentor, create a google account, and go to
http://socghop.appspot.com/org/apply_mentor/google/gsoc2009

Anthony Sorace is the administrator for the project this year and he
will have to approve your mentor application.

> Thanks,
> Roman.

Hope that helps!

--dho

> P.S. besides, there's always a benefit of communicating in Russian
> or getting together for a few beers in SPB ;-)
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[Pietro Gagliardi]

On Mar 26, 2009, at 3:35 PM, Eric Van Hensbergen wrote:


I'm merely trying to debunk roadblocks which others
seem to want to through in his way.


I don't want to throw a roadblock in this student's way. (In fact,  
drawterm on iPhone benefits me too, though that benefit would come in  
or after June :-| ) I just tried to point out a few hurdles. That's  
what design and development is for: jumping hurdles.


On Mar 26, 2009, at 2:50 PM, andrey mirtchovski wrote:

a straight cocoa drawterm rewrite

On Mar 26, 2009, at 3:00 PM, Uriel wrote:

A 9vx, p9p or inferno cocoa port is a project that seems fairly


I can do one of these; which is the most needed/wanted?

Re: [9fans] GSOC: Gitfs

[Roman Shaposhnik]

On Mar 26, 2009, at 2:10 PM, J.R. Mauro wrote:

On Thu, Mar 26, 2009 at 9:30 AM, Mukhitdinov Manzur
 wrote:


Hello!

I'm a cs student from Saint-Petersburg,Russia(sea-gull on  
#plan9-soc).

I'm interested in your project of implementing Git file system
for Plan9.
Implementing Gitfs when we have Hgfs[1] and hgc may seem odd to
somebody,
especially when Git doesn't have apparent advantages over mercury.
But there are some benefits to community: as I'm new to Plan9/Inferno
the more difficult task I get, the more and deeper I'll learn  
Plan9. And

that means,
the better and longer I can help to the community
But I'll benefit no less than you: I'll learn miraculous Plan9,
get friends and spend my time to something useful


Somehow I didn't see the original email from Manzur (was it ever
posted to the list?) But given my personal interests, I'd be delighted
to help along with the gitfs.

Since I've ignored most of the GSOC traffic so far, could someone,
please point me to the right URLs so that I can see what's required
of mentors and whether I'd be a good match for that.

Thanks,
Roman.

P.S. besides, there's always a benefit of communicating in Russian
or getting together for a few beers in SPB ;-)

Re: [9fans] GSOC: Gitfs

[J.R. Mauro]

On Thu, Mar 26, 2009 at 9:30 AM, Mukhitdinov Manzur
 wrote:
>
> Hello!
>
>     I'm a cs student from Saint-Petersburg,Russia(sea-gull on #plan9-soc).
> I'm interested in your project of implementing Git file system
> for Plan9.
>     Implementing Gitfs when we have Hgfs[1] and hgc may seem odd to
> somebody,
> especially when Git doesn't have apparent advantages over mercury.
> But there are some benefits to community: as I'm new to Plan9/Inferno
> the more difficult task I get, the more and deeper I'll learn Plan9. And
> that means,
> the better and longer I can help to the community
> But I'll benefit no less than you: I'll learn miraculous Plan9,
> get friends and spend my time to something useful

If I remember correctly, someone made a FUSE filesystem that worked
with a git checkout. Its implementation may perhaps be helpful in
writing a 9P filesystem.

>
> I've some other ideas:
> - Something like Boost library for Limbo
> - Dis decompiler
>
> Comments are appreciated!
>
> Thanks, Manzur
>
> References:
>     1. http://www.ueber.net/hg/hgfs/files/last/README
>
>
>

Re: [9fans] 9P writes for directories

[erik quanstrom]

> It would (just as Erik pointed out). I guess I was just looking for
> symmetry (if POST is really a write(*), it should translate into write
> independent of whether the URI corresponds to a subdirectory or
> not) and potential pitfalls that made 9P spec disallow writes on
> subdirectories (and since nobody can identify any of those -- I'll
> rest my case and proceed with translating POST into different
> 9P messages depending on the type of the URI).

the only thing that write and create have in common
is the fact that they both translate to 9p messages.

the beauty of create is that it is atomic.  if you don't
care about atomicity, you can just open if create fails.
using write, the qid could not be returned and there
would always be a race.  since one would not have the
qid, it would be impossible to tell if the race had been
won.

- erik

Re: [9fans] GSOC: Gitfs

[Enrico Weigelt]

* Mukhitdinov Manzur  wrote:

Hi,

> I'm interested in your project of implementing Git file system
> for Plan9.

Great thing! 
I'd be your first user :)


cu
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: i...@metux.de   skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--

Re: [9fans] gsoc linuxemu project help

[Sebastian A. Liem]

On 3/26/09, David Leimbach  wrote:
> 2009/3/26 Zhao Shuai 
>
>>
>> >Does creative masoshism count as GSoC project?  I dont know :)
>> >
>> >Hm...  These points all belong to the big topic, getting modern linux
>> >distro binaries (NTPL stuff) to work.  This would be a good thing
>> >because I'm stuck on some old debian sarge that was just moved to the
>> >archives.
>> >
>> >Step one would be to get the simple single-threaded stuff to run like
>> >echo and cat.  The part point here is TLS.  I had a somewhat working
>> >plan9 driver for it but never packaged it up because i wanted the
>> >whole thing working before submitting a kernel patch. You may later
>> >progress to multithreaded apps wich use futex syscall.
>> >
>> >The way I work on linuxemu is randomly trying stuff out, see where it
>> >crashes...  try to understand why it crashes...  implement/fix
>> >syscalls and try again.  Sometimes it easy and sometimes you scratch
>> >your head for a several months.  Its hard to estimate the time needed
>> >to get X running because you never know what crazy optimization shit
>> >the linux/libc guys come up with next to make you suffer.
>> >
>> >Here is always a huge risk of failure in linuxemu because all the
>> >details are in Ulrich Dreppers head only or encrypted with
>> >c-preprocessor-ifdef-encryption in the glibc-code so getting help is
>> >very hard and most of the stuff you have to find out yourself (this
>> >may cause brain damage over time).
>> >
>> >I cant (officialy) mentor you as I'm short of time and have no
>> >scientific background or something, but I will try to give you all
>> >infeormation/code and support I have...  Its good to hear that someone
>> >starts taking over some work!  :) Just drop me an email.  I may be
>> >in irc from time to time too but dont count on it.
>> >
>> >--
>> >cinap
>>
>>
>
>>
>> If nothing else in linuxemu can make a GSoc project, I would like to give
>> NTPL a try.
>>
>> Is NTPL the same thing as NPTL, and everyone is just repeatedly spelling
> their acronyms incorrectly?
>
>
>
>>
>> Now I wonder how does Linuxemu work? I guess it parses the linux binary
>> and whenever
>> encounter a system call, emulate using Plan 9's function. I haven't dig
>> into the source
>> code, just guess.
>>
>>
>>
>> --
>> 网易邮箱，中国第一大电子邮件服务商 
>

Re: [9fans] 9P writes for directories

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 3:23 PM, Roman Shaposhnik  wrote:
> On Mar 26, 2009, at 12:44 PM, Eric Van Hensbergen wrote:
>>
>> On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik  wrote:
>>>
>>> On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote:
>>>
>>> The story here is that we are building a bunch of RESTful APIs
>>> and my personal preference is to bend HTTP as close to 9P
>>> as I can get (for obvious reasons). Now, the closest match
>>> to "create" would be POST with a metadata payload on a
>>> "subdirectory" URI. But of course, it is not a create at all.
>>> It really is much closer to write on a subdirectory. Hence the
>>> question: is there anything that HTTP makes us lose except
>>> for the transactional nature of create?
>>>
>>
>> So, my understanding is the function of POST to a collection/directory
>> was to create a new entry in the collection where the ID is assigned
>> automatically by the collection. The ID created is typically returned
>> by this operation.
>
> If by ID you mean URI, that would be my current understanding as well.
> Unlike create though, that is guaranteed to create an object in the
> subdirectory
> identified by an ID (fid), the POST can return any URI.

I think we have a semantic mismatch, if ID==URI then ID != FID.  I
don't see where FID's fit in to the REST model (making REST closer to
Op, then 9p)

>
>> This actually sounds more like a (devip style) clone operation to me.
>
> I have thought about that too, but became convinced that POST is more
> like create (or more like write on a subdirectory -- hence the original
> question). With the clone operation it is the *opening* of the clone
> device that provides you with a new fid. In HTTP that would be like getting
> a redirection on GET. Don't you think?
>

Except that Creates give an ID/path for creation instead of receiving
one -- that's the key thing that makes it like clone, the most
important bit being that this sort of mechanism avoids collision.
Whether or not that is critical depends on how you write your app.  I
think the main difference here is you are trying to map HTTP syntax to
9P syntax, and I've been thinking of semantics -- an HTTP POST to a
subdirectory would equal the opening of a clone file (within that
subdirectory), and writing the metadata, a read on that file would
return the ID -- this would be done atomically by the HTTP server to
service the POST not as a set of HTTP routines.  Again - this all
depends on what you are actually trying to do with your app as to
whether or not clone semantics are necessary.  I think the critical
aspect from the REST/CRUD perspective is that the POST has to be
idempotent which I don't think you can guarantee with just create
semantics due to the possibility of collision (but perhaps creates
with collision just fail), not sure if that is "expected" from a REST
perspective, but it is probably legal.

>> Outside of the ID bit, why wouldn't create suffice?
>
> It would (just as Erik pointed out). I guess I was just looking for
> symmetry (if POST is really a write(*), it should translate into write
> independent of whether the URI corresponds to a subdirectory or
> not) and potential pitfalls that made 9P spec disallow writes on
> subdirectories (and since nobody can identify any of those -- I'll
> rest my case and proceed with translating POST into different
> 9P messages depending on the type of the URI).
>

I don't think the symmetry is worth altering the semantics of the
protocol -- its likely more trouble than its worth in the long run.

-eric

Re: [9fans] 9P writes for directories

[Roman Shaposhnik]

On Mar 26, 2009, at 12:44 PM, Eric Van Hensbergen wrote:

On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik  wrote:

On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote:

The story here is that we are building a bunch of RESTful APIs
and my personal preference is to bend HTTP as close to 9P
as I can get (for obvious reasons). Now, the closest match
to "create" would be POST with a metadata payload on a
"subdirectory" URI. But of course, it is not a create at all.
It really is much closer to write on a subdirectory. Hence the
question: is there anything that HTTP makes us lose except
for the transactional nature of create?



So, my understanding is the function of POST to a collection/directory
was to create a new entry in the collection where the ID is assigned
automatically by the collection. The ID created is typically returned
by this operation.


If by ID you mean URI, that would be my current understanding as well.
Unlike create though, that is guaranteed to create an object in the  
subdirectory

identified by an ID (fid), the POST can return any URI.


This actually sounds more like a (devip style) clone operation to me.


I have thought about that too, but became convinced that POST is more
like create (or more like write on a subdirectory -- hence the original
question). With the clone operation it is the *opening* of the clone
device that provides you with a new fid. In HTTP that would be like  
getting

a redirection on GET. Don't you think?


Outside of the ID bit, why wouldn't create suffice?



It would (just as Erik pointed out). I guess I was just looking for
symmetry (if POST is really a write(*), it should translate into write
independent of whether the URI corresponds to a subdirectory or
not) and potential pitfalls that made 9P spec disallow writes on
subdirectories (and since nobody can identify any of those -- I'll
rest my case and proceed with translating POST into different
9P messages depending on the type of the URI).

Thanks,
Roman.

(*) Now, POST really is *not* a write. PUT is. But current generation
of browsers can only "write" local files to remote destinations
with POST, not PUT. And even with JavaScript that restriction is too  
painful

to overcome :-(

Re: [9fans] 9P writes for directories

[erik quanstrom]

> >> to "create" would be POST with a metadata payload on a
> >> "subdirectory" URI. But of course, it is not a create at all.
> >
> > i'm not sure what fine hair you're trying to split.  why can't the
> > post contain the same information a create would?
> 
> 
> If "hair splitting" is the answer to the original question -- that's
> completely fine. In fact, I was looking for that to be an answer.
> It's just that everytime I see something being explicitly forbidden
> in 9P spec there's usually a pretty good reason for that.

i wasn't clear.  why can't you gather up the data from
the post and do a create rather than a write to the directory?

- erik

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 2:36 PM, andrey mirtchovski
 wrote:
> On Thu, Mar 26, 2009 at 1:27 PM, Eric Van Hensbergen  wrote:
>> I have VNC lite on my iphone, which amazingly isn't jailbroken...
>>
>>      -eric
>
> sure, but that's a client. i thought you were talking about exporting
> iPhone's screen and interfaces as one would using a vnc server.
>

The comparison is that since drawterm initiates the connection, from
the uninitiated point of view it is acting as a client (/mnt/term
aside) -- the fact that it is actually serving the frame buffer,
keyboard, mouse, etc. to the other side of the connection is protocol
semantics -- not something that would get Apple's panties in a bunch
IMHO.

-eric

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 2:57 PM, Charles Forsyth  wrote:
>>The difference between a VNC client and drawterm (from a rules
>>perspective) is difficult to see
>
> i supposed the difference was /mnt/term
>

Yeah, but there are plenty of apps which allow the phone to act as a
file server.
It likely won't be the whole phone, just the dt's Documents directory.

-eric

Re: [9fans] 9P writes for directories

[Roman Shaposhnik]

On Mar 26, 2009, at 12:35 PM, erik quanstrom wrote:

question: is there anything that HTTP makes us lose except
for the transactional nature of create?


sanity?


That's dead and buried already :-( But I've got be honest
with you -- REST is actually the closes thing to 9P
that has a potential to excite PHBs and thus get approved.
HTTP is stateless, yes, but the biggest PITA that brought us
so far would be authentication, not the core functionality.


to "create" would be POST with a metadata payload on a
"subdirectory" URI. But of course, it is not a create at all.


i'm not sure what fine hair you're trying to split.  why can't the
post contain the same information a create would?



If "hair splitting" is the answer to the original question -- that's
completely fine. In fact, I was looking for that to be an answer.
It's just that everytime I see something being explicitly forbidden
in 9P spec there's usually a pretty good reason for that.

Thanks,
Roman.

Re: [9fans] 9P writes for directories

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 2:31 PM, Roman Shaposhnik  wrote:
> On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote:
>
> The story here is that we are building a bunch of RESTful APIs
> and my personal preference is to bend HTTP as close to 9P
> as I can get (for obvious reasons). Now, the closest match
> to "create" would be POST with a metadata payload on a
> "subdirectory" URI. But of course, it is not a create at all.
> It really is much closer to write on a subdirectory. Hence the
> question: is there anything that HTTP makes us lose except
> for the transactional nature of create?
>

So, my understanding is the function of POST to a collection/directory
was to create a new entry in the collection where the ID is assigned
automatically by the collection. The ID created is typically returned
by this operation.

This actually sounds more like a (devip style) clone operation to me.
Outside of the ID bit, why wouldn't create suffice?

 -eric

Re: [9fans] Inferno slow on Plan 9?

[Charles Forsyth]

> FWIW, native graphics applications (including Hyperglenda) are very fast...

hmm. Inferno is a native graphics application.

Re: [9fans] GSOC: Drawterm for the iPhone

[Charles Forsyth]

>The difference between a VNC client and drawterm (from a rules
>perspective) is difficult to see

i supposed the difference was /mnt/term

Re: [9fans] 9P writes for directories

[erik quanstrom]

> question: is there anything that HTTP makes us lose except
> for the transactional nature of create?

sanity?

> to "create" would be POST with a metadata payload on a
> "subdirectory" URI. But of course, it is not a create at all.

i'm not sure what fine hair you're trying to split.  why can't the
post contain the same information a create would?

- erik

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 1:39 PM, J.R. Mauro  wrote:
>>
>> That makes zero sense.  As per the VNC discussion, there's already
>> precedent for exporting screen and interfaces.
>
> No, it makes perfect sense, if you actually know that there are VNC
> clients on the phone, but not servers. You should look these things up
> before saying I'm talking nonsense.
>

The difference between a VNC client and drawterm (from a rules
perspective) is difficult to see -- lets stop being paranoid about
evil empires.
Let's remember that this (unbelievably lengthy) thread was started as
a student's idea.  I'm merely trying to debunk roadblocks which others
seem to want to through in his way.  As I am prevented from mentoring
in GSoC, my opinion of whether this is a good or a bad project is
immaterial -- let's just stop the FUD.

  -eric

Re: [9fans] GSOC: Drawterm for the iPhone

[andrey mirtchovski]

On Thu, Mar 26, 2009 at 1:27 PM, Eric Van Hensbergen  wrote:
> I have VNC lite on my iphone, which amazingly isn't jailbroken...
>
>      -eric

sure, but that's a client. i thought you were talking about exporting
iPhone's screen and interfaces as one would using a vnc server.

Re: [9fans] Inferno slow on Plan 9?

[erik quanstrom]

> The CPU doesn't support PATs, sorry.
> 
> It does have MTRR support though, wasn't there a patch to support
> Write-combining for the framebuffer region using them instead?
> 
> FWIW, native graphics applications (including Hyperglenda) are very fast...

if the slowdown is caused by reading the framebuffer, than the patch wouldn't
help anyway.  reading the frame buffer on certain nvidia cards (for example,
mine) can be astoundingly slow.

- erik

Re: [9fans] 9P writes for directories

[Roman Shaposhnik]

On Mar 21, 2009, at 12:00 AM, Roman Shaposhnik wrote:
I could swear that I remember the following question being asked  
during

the times when 9P2000 was being introduced, but I simply can't find
any relevant threads. I do apologize if my google-foo is failing me,
but here it goes: what is the reason for not allowing writes to the
directories (with the append-only semantics and stat structures
payloads, of course)?

Is it simply because since we can't really get rid of create (because
of the transactional nature of create-open) it was deemed to be
unimportant to have directory writing semantics or was there a
subtler reason that I can't fully recall.


No takers, huh? Well, may be a bit of background would help so that
the question doesn't sound as a purely navel-gazing exercise.

The story here is that we are building a bunch of RESTful APIs
and my personal preference is to bend HTTP as close to 9P
as I can get (for obvious reasons). Now, the closest match
to "create" would be POST with a metadata payload on a
"subdirectory" URI. But of course, it is not a create at all.
It really is much closer to write on a subdirectory. Hence the
question: is there anything that HTTP makes us lose except
for the transactional nature of create?

Thanks,
Roman.

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

I have VNC lite on my iphone, which amazingly isn't jailbroken...

  -eric


On Thu, Mar 26, 2009 at 1:29 PM, andrey mirtchovski
 wrote:
>> That makes zero sense.  As per the VNC discussion, there's already
>> precedent for exporting screen and interfaces.
>> That does leave room for apple to restrict access to camera, location,
>> orientation, etc. -- but I see no reason why they would.
>
> as far as I can see Veency (the VNC server) is for jailbroken iphones only.
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[lucio]

> the only problem is, without the iPhone tag it just doesn't sound so
> cool anymore, does it? :)

Apple restrict the iPhone for the same reason all religions interfere
with sex: it is a measurement of the success of their marketing that
people still buy their product despite the discomfort.

That will only stop when the faithful move to a new, improved
religion.

++L

Re: [9fans] Inferno slow on Plan 9?

[Venkatesh Srinivas]

The CPU doesn't support PATs, sorry.

It does have MTRR support though, wasn't there a patch to support
Write-combining for the framebuffer region using them instead?

FWIW, native graphics applications (including Hyperglenda) are very fast...

-- vs

Re: [9fans] GSOC: Drawterm for the iPhone

[Uriel]

A 9vx, p9p or inferno cocoa port is a project that seems fairly
reasonable and I think everyone (even those that don't use Macs) can
agree on (and then if somebody wants they can port it to the other
draw users).

uriel

On Thu, Mar 26, 2009 at 7:50 PM, andrey mirtchovski
 wrote:
> let's rephrase the project. screw the iPhone temporarily (cool as it
> may be) and do a straight cocoa drawterm rewrite.  a cocoa-native
> drawterm can explore all the functionality of the iphone interface
> (gestures, etc) and much more, without all the restrictions that apple
> forces on iPhone developers.
>
> the only problem is, without the iPhone tag it just doesn't sound so
> cool anymore, does it? :)
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[andrey mirtchovski]

let's rephrase the project. screw the iPhone temporarily (cool as it
may be) and do a straight cocoa drawterm rewrite.  a cocoa-native
drawterm can explore all the functionality of the iphone interface
(gestures, etc) and much more, without all the restrictions that apple
forces on iPhone developers.

the only problem is, without the iPhone tag it just doesn't sound so
cool anymore, does it? :)

Re: [9fans] GSOC: Drawterm for the iPhone

[J.R. Mauro]

On Thu, Mar 26, 2009 at 2:22 PM, Eric Van Hensbergen  wrote:
> On Thu, Mar 26, 2009 at 1:04 PM, J.R. Mauro  wrote:
>> On Wed, Mar 25, 2009 at 07:54:57PM -0500, Eric Van Hensbergen wrote:
>>> One nice thing about drawterm is it lets you export the iphone's
>>> interfaces to Plan 9 -- that could lead to much more interesting
>>
>> I doubt you'll be able to do that with the insane restrictions Apple puts on
>> officially-sanctioned apps. You'd have to work via the iPhone jailbreak to
>> expose anything other than a very small, sandboxed directory on the phone via
>> drawterm.
>>
>
> That makes zero sense.  As per the VNC discussion, there's already
> precedent for exporting screen and interfaces.

No, it makes perfect sense, if you actually know that there are VNC
clients on the phone, but not servers. You should look these things up
before saying I'm talking nonsense. Apple is fanatical about
controlling access to resources on the phone, even from apps that run
on the phone. The result of writing drawterm with Apple's SDK will be
a very crippled vnc/ssh type client.

> That does leave room for apple to restrict access to camera, location,
> orientation, etc. -- but I see no reason why they would.

Because it's Apple.

>
>         -eric
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[Tom Lieber]

On Thu, Mar 26, 2009 at 2:29 PM, andrey mirtchovski
 wrote:
>> That makes zero sense.  As per the VNC discussion, there's already
>> precedent for exporting screen and interfaces.
>> That does leave room for apple to restrict access to camera, location,
>> orientation, etc. -- but I see no reason why they would.
>
> as far as I can see Veency (the VNC server) is for jailbroken iphones only.

VNC clients

-- 
Tom Lieber
http://AllTom.com/

Re: [9fans] Inferno slow on Plan 9?

[Charles Forsyth]

>anything graphical draws painfully slowly
>(several seconds to paint the white rectangle while Charon is starting).

that isn't normal, except when using it through drawterm.
it's even fine for me in 9vx on Linux.

Re: [9fans] GSOC: Drawterm for the iPhone

[andrey mirtchovski]

> That makes zero sense.  As per the VNC discussion, there's already
> precedent for exporting screen and interfaces.
> That does leave room for apple to restrict access to camera, location,
> orientation, etc. -- but I see no reason why they would.

as far as I can see Veency (the VNC server) is for jailbroken iphones only.

Re: [9fans] Inferno slow on Plan 9?

[erik quanstrom]

> Is there any reason this might be happening? If its related to
> Inferno's /dev/draw, is there any way I can import /dev/draw from P9
> and use it in Inferno? Would that be faster?

does the PAT register patch (/n/sources/patch/pat) make any difference?

- erik

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 1:04 PM, J.R. Mauro  wrote:
> On Wed, Mar 25, 2009 at 07:54:57PM -0500, Eric Van Hensbergen wrote:
>> One nice thing about drawterm is it lets you export the iphone's
>> interfaces to Plan 9 -- that could lead to much more interesting
>
> I doubt you'll be able to do that with the insane restrictions Apple puts on
> officially-sanctioned apps. You'd have to work via the iPhone jailbreak to
> expose anything other than a very small, sandboxed directory on the phone via
> drawterm.
>

That makes zero sense.  As per the VNC discussion, there's already
precedent for exporting screen and interfaces.
That does leave room for apple to restrict access to camera, location,
orientation, etc. -- but I see no reason why they would.

 -eric

[9fans] Inferno slow on Plan 9?

[Venkatesh Srinivas]

Hi,

I'm running Plan 9 on a machine with a GeForce2 MX200. I've tried to
run Inferno in p9, but anything graphical draws painfully slowly
(several seconds to paint the white rectangle while Charon is
starting).

Is there any reason this might be happening? If its related to
Inferno's /dev/draw, is there any way I can import /dev/draw from P9
and use it in Inferno? Would that be faster?

Thanks,
-- vs

Re: [9fans] GSOC: Drawterm for the iPhone

[J.R. Mauro]

On Wed, Mar 25, 2009 at 07:54:57PM -0500, Eric Van Hensbergen wrote:
> One nice thing about drawterm is it lets you export the iphone's
> interfaces to Plan 9 -- that could lead to much more interesting

I doubt you'll be able to do that with the insane restrictions Apple puts on
officially-sanctioned apps. You'd have to work via the iPhone jailbreak to
expose anything other than a very small, sandboxed directory on the phone via
drawterm.

> possibilities beyond typing at the shell.  Probably a better approach
> would be to look at providing an octopus client for iPhone though...
> 
>   -eric
> 
> 
> On Wed, Mar 25, 2009 at 7:39 PM, Federico G. Benavento
>  wrote:
> > ok, you can't compare porting inferno to the ds with drawterm for the iphone
> > drawterm is an app to get to a Plan 9 server, inferno is a self contained
> > operating system where you can get the advantage of writing your
> > own apps for it.
> >
> > for this port to be useful you need 1) an iphone;  2) a cpu server to cpu
> > and 3) that killer app that makes want to drawterm from the iphone.
> >
> > I think writing that killer app, whatever that is makes more sense.
> >
> >
> > On Wed, Mar 25, 2009 at 9:24 PM, Devon H. O'Dell  
> > wrote:
> >> 2009/3/25 Federico G. Benavento :
> >>> do we need drawterm for the iphone? is anyone going to use it?
> >>>
> >>> I mean, it's a tiny screen, typing on handhelds sucks, plus is not
> >>> that there is killer app Plan 9 has that  you _must_ run.
> >>>
> >>> am I forgetting something obvious?
> >>
> >> Tiny screen, but reasonable resolution. Should find out who put it on
> >> the ideas page for GSoC; it wasn't me (so clearly somebody is
> >> interested). Besides, look at the DS port. Smaller screens, lower
> >> resolution (even combined, I think). Whether it's novelty or not isn't
> >> for me to say, but I can see how it would be useful.
> >>
> >> --dho
> >>
> >>
> >
> >
> >
> > --
> > Federico G. Benavento
> >
> >
> 

-- 
J.R. Mauro

()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against Microsoft attachments

Re: [9fans] GSOC: Drawterm for the iPhone

[erik quanstrom]

> >> especially if the kernel were (sort-of) pxe loaded so that clients would
> >> only need a local copy of the loader and changes would then be
> >> automaticly distributed.)
> >
> > Now that could be fun.
> >
> 
> I smell the feminine stench -- flowers and butterflies -- of GSoC project
> proposal in every character of that message.
> 
> 
> or perhaps I have sinusitis
> so this is all imagined

i believe you owe the list an apology for this
offensive and unacceptable comment.

- erik

[9fans] LLVM & Exceptions (Was re. request for more GSoC project suggestions)

[Joel C. Salomon]

Devon H. O'Dell wrote:
> Another student I spoke to on IRC spoke of the possibility of
> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively.
> That would give us a whole bunch of different compilers.

Something to watch out for with such a project:

The LLVM back-end for Windows does not support C++ (nicely) because of
issues with exception handling; Windows provides a mechanism for stack
unwinding—especially across DLL boundaries—that neither GCC nor LLVM
handle well.  Porting LLVM to Plan 9 may well have some of the same
troubles.

Those who have dealt with the GCC port can answer this:  What does g++
do on Plan 9?  Does it add DWARF debugging tables to the executable so
that the stack can be unwound?  Does it play games with setjmp/longjmp? 
Does it even work at all?  Otherwise, a large part of an LLVM project
would be a port of some exception mechanism.

Does plan9port’s mach-stack(3) have any precedent in Plan 9? and is that
the correct basis for exception-like stack unwinding?  (I.e., a program
unwinding its own stack, rather than a debugger tracing the stack back.)

—Joel Salomon

P.s.:  I am not raising the question of whether exception handling via
stack unwinding is a good idea—which has been done to death on this
list; see the “Same Functions Everywhere” thread from 2003 at
 and message 56 & responses at
—just asking how to implement it
under Plan 9 using the existing tools as far as possible.



signature.asc
Description: OpenPGP digital signature

Re: [9fans] GSOC: Drawterm for the iPhone

[Bakul Shah]

I wasn't commenting on the GSoC; just reinforcing Eric's
point that a multitouch interface would be very interesting
in itself and pointing out that such a device in conjunction
with a 3d extension would be even more fun!  But yes, a
multitouch interface design would make a nice GSoC project.
Nothing directly useful may come of it but one never knows.
Look at bumptop.com -- that interface started out as a
student project. Look at the kind of things people do with
openframeworks.cc code. 

Plan9 can be a far simpler platform for things like that.
Imagine a multitouch device that dynamically creates a set
of pointer streams /dev/mt/{0,1,...} with each mt/n acting
like /dev/mouse. Or you can have a single multiplexed stream,
where each read returns, for example,

 keychar ptr-index x y msec [blob-size [blob-type]]

When you lift your finger the blob-size becomes 0.  If you
don't press it again within some time period and within a
small distance of its expected position, the ptr disappears.
Or something like that! A program to map camera input to
/dev/mt would give you a cheap multitouch device.

As for GSoC, if students pick projects that get their
creative juices flowing *and* if they can produce something
tangible (but not necessarily useful) in threee months,
that'd be success in my eyes.  FWIW.

On Thu, 26 Mar 2009 00:32:31 -0300 "Federico G. Benavento" 
  wrote:
> my questions were more about the real usage of iphone's dt
> my short sighted vision of the gsoc is this, I didn't use any
> of the stuff that gsoc 2007 got us, though I recognize the
> inferno ds port.
> but for the rest, it might be interesting, but is someone
> using that stuff?
> 
> iphone's drawterm sounds like something that very few
> people will use (the ones that have a cpu server and an
> iphone) in not that much often, of course it could be
> interesting to have it, but...
> 
> I think that gsoc is a good chance to get going stuff that
> we need and we will really use.
> 
> think of the openssh port, I did that, not for a gsoc and
> people use it, some guy even wrote a filesystem which
> suits lot's of people's needs.
> 
> 
> 
> On Thu, Mar 26, 2009 at 12:20 AM, Bakul Shah  wr=
> ote:
> > On Wed, 25 Mar 2009 21:25:07 CDT Eric Van Hensbergen  =
> =C2=A0wrote:
> >> Also, figuring out how multitouch works with plan 9 would be valuable
> >> in itself -- although admitadly could be done without an iPhone.
> >
> > Exactly what I was thinking while reading this thread! =C2=A0An
> > intuitive multitouch interface that goes beyond cut-n-paste
> > would go very well with a 3D graphics protocol. 9gl anyone?!
> >
> >
> 
> 
> 
> --=20
> Federico G. Benavento
> 

Re: [9fans] GSOC: Drawterm for the iPhone

[Akshat Kumar]

>> especially if the kernel were (sort-of) pxe loaded so that clients would
>> only need a local copy of the loader and changes would then be
>> automaticly distributed.)
>
> Now that could be fun.
>

I smell the feminine stench -- flowers and butterflies -- of GSoC project
proposal in every character of that message.


or perhaps I have sinusitis
so this is all imagined
ak

Re: [9fans] request for more GSoC project suggestions

[lucio]

> If we can rope in at minimum rminnich and preferably
> also forsyth, then I will feel a lot less unsure of my skills.

Or equivalent, of course; these are the one _I_ would feel most
comfortable with.

++L

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

2009/3/26 Juan M. Mendez :
> Maybe porting parrot (http://www.parrot.org ) to Plan9 would be an
> interesting Gsoc project

My co-worker is the backup org admin for Parrot (but is responsible
for the Perl 6 and Parrot programs). If there's real interest here,
submit a proposal for a port to Plan 9 to both projects, and we'll
work something out to co-mentor. If both projects get an application,
the chances of that actually happening do increase.

--dho

> Parrot is a virtual machine designed to efficiently compile and
> execute bytecode for dynamic languages. Parrot currently hosts a
> variety of language implementations in various stages of completion,
> including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6,
> APL, and a .NET bytecode translator.
>
> This is the list of languages at different status of support:
> http://www.parrot.org/languages
>
>
> --
> http://vejeta.com/portal
> Fidonet: 2:345/432.2
>
>

Re: [9fans] request for more GSoC project suggestions

[Juan M. Mendez]

Maybe porting parrot (http://www.parrot.org ) to Plan9 would be an
interesting Gsoc project

Parrot is a virtual machine designed to efficiently compile and
execute bytecode for dynamic languages. Parrot currently hosts a
variety of language implementations in various stages of completion,
including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6,
APL, and a .NET bytecode translator.

This is the list of languages at different status of support:
http://www.parrot.org/languages


-- 
http://vejeta.com/portal
Fidonet: 2:345/432.2

Re: [9fans] request for more GSoC project suggestions

[lucio]

> Alright, sounds good. Are you signed up as a mentor? (I'm not an
> admin, so I don't know).
> 
I'm not, but that can be arranged.

> I'll add this to the ideas page; if you're interested and able to
> mentor, this would be a great project, I think.

I would be wary of being the sole mentor here, my theoretical
knowledge is a bit thin and students may find it frustrating to deal
with me alone.  If we can rope in at minimum rminnich and preferably
also forsyth, then I will feel a lot less unsure of my skills.

++L

Re: [9fans] GSOC: Drawterm for the iPhone

[Brian L. Stuart]

> 9vx could replace drawterm in our environment, but i think
> the following work is required.  9vx needs
> - to be able to boot with no local files other than the executable,
> (i.e. directly from a plan 9 fs)

Actually, I've been using it this way for a while.  More
precisely, when I'm on my home network it boots like a
terminal talking to my file server.  When I'm away from
my home network, it boots off a local fossil/venti partition.
It did take some relatively minor changes, but if they're
not in the tree, they might have fallen through the cracks.
I even threw in the plan9.ini parsing so I could give
myself a menu and set the appropriate variables.  (I'm
not using it for any other plan9.ini sorts of things.)

The relevant bits of my 9vx.ini file are:
[native]
nobootprompt=local!#S/sd00/
venti=#S/sd00/arenas
user=glenda

[home]
nobootprompt=tcp
fs=172.30.1.2
auth=172.30.1.2
user=stuart

> especially if the kernel were (sort-of) pxe loaded so that clients would
> only need a local copy of the loader and changes would then be
> automaticly distributed.)

Now that could be fun.

BLS

Re: [9fans] gsoc linuxemu project help

[David Leimbach]

2009/3/26 Zhao Shuai 

>
> >Does creative masoshism count as GSoC project?  I dont know :)
> >
> >Hm...  These points all belong to the big topic, getting modern linux
> >distro binaries (NTPL stuff) to work.  This would be a good thing
> >because I'm stuck on some old debian sarge that was just moved to the
> >archives.
> >
> >Step one would be to get the simple single-threaded stuff to run like
> >echo and cat.  The part point here is TLS.  I had a somewhat working
> >plan9 driver for it but never packaged it up because i wanted the
> >whole thing working before submitting a kernel patch. You may later
> >progress to multithreaded apps wich use futex syscall.
> >
> >The way I work on linuxemu is randomly trying stuff out, see where it
> >crashes...  try to understand why it crashes...  implement/fix
> >syscalls and try again.  Sometimes it easy and sometimes you scratch
> >your head for a several months.  Its hard to estimate the time needed
> >to get X running because you never know what crazy optimization shit
> >the linux/libc guys come up with next to make you suffer.
> >
> >Here is always a huge risk of failure in linuxemu because all the
> >details are in Ulrich Dreppers head only or encrypted with
> >c-preprocessor-ifdef-encryption in the glibc-code so getting help is
> >very hard and most of the stuff you have to find out yourself (this
> >may cause brain damage over time).
> >
> >I cant (officialy) mentor you as I'm short of time and have no
> >scientific background or something, but I will try to give you all
> >infeormation/code and support I have...  Its good to hear that someone
> >starts taking over some work!  :) Just drop me an email.  I may be
> >in irc from time to time too but dont count on it.
> >
> >--
> >cinap
>
>

>
> If nothing else in linuxemu can make a GSoc project, I would like to give 
> NTPL a try.
>
> Is NTPL the same thing as NPTL, and everyone is just repeatedly spelling
their acronyms incorrectly?



>
> Now I wonder how does Linuxemu work? I guess it parses the linux binary and 
> whenever
> encounter a system call, emulate using Plan 9's function. I haven't dig into 
> the source
> code, just guess.
>
>
>
> --
> 网易邮箱，中国第一大电子邮件服务商 

Re: [9fans] request for more GSoC project suggestions

[Joel C. Salomon]

On Wed, Mar 25, 2009 at 7:26 PM, erik quanstrom  wrote:
> On Wed Mar 25 19:22:23 EDT 2009, devon.od...@gmail.com wrote:
>> Another student I spoke to on IRC spoke of the possibility of
>> bootstrapping LLVM for Plan 9 on Linux and getting it to run natively.
>> That would give us a whole bunch of different compilers.
>
> at the risk of being called stupid twice in one day, i have to say
> i don't see what the payoff would be.   doing something with
> gcc helps with gcc-specific code.  what does llvm give us?

Current versions of LLVM use GCC's front-end for C & C++, so porting
the back-end to Plan 9 effectively gives us GCC. When clang is
completed, LLVM will be GCC-compatible without including GCC code.

—Joel Salomon

Re: [9fans] gsoc linuxemu project help

[Zhao Shuai]

>Does creative masoshism count as GSoC project?  I dont know :)
>
>Hm...  These points all belong to the big topic, getting modern linux
>distro binaries (NTPL stuff) to work.  This would be a good thing
>because I'm stuck on some old debian sarge that was just moved to the
>archives.
>
>Step one would be to get the simple single-threaded stuff to run like
>echo and cat.  The part point here is TLS.  I had a somewhat working
>plan9 driver for it but never packaged it up because i wanted the
>whole thing working before submitting a kernel patch. You may later
>progress to multithreaded apps wich use futex syscall.
>
>The way I work on linuxemu is randomly trying stuff out, see where it
>crashes...  try to understand why it crashes...  implement/fix
>syscalls and try again.  Sometimes it easy and sometimes you scratch
>your head for a several months.  Its hard to estimate the time needed
>to get X running because you never know what crazy optimization shit
>the linux/libc guys come up with next to make you suffer.
>
>Here is always a huge risk of failure in linuxemu because all the
>details are in Ulrich Dreppers head only or encrypted with
>c-preprocessor-ifdef-encryption in the glibc-code so getting help is
>very hard and most of the stuff you have to find out yourself (this
>may cause brain damage over time).
>
>I cant (officialy) mentor you as I'm short of time and have no
>scientific background or something, but I will try to give you all
>infeormation/code and support I have...  Its good to hear that someone
>starts taking over some work!  :) Just drop me an email.  I may be
>in irc from time to time too but dont count on it.
>
>--
>cinap

If nothing else in linuxemu can make a GSoc project, I would like to give NTPL 
a try.

Now I wonder how does Linuxemu work? I guess it parses the linux binary and 
whenever 
encounter a system call, emulate using Plan 9's function. I haven't dig into 
the source
code, just guess.

Re: [9fans] new toy - gmap

[erik quanstrom]

On Thu Mar 26 04:42:48 EDT 2009, lu...@proxima.alt.za wrote:
> > Pick up the new code, it reads the key from /lib/gmapkey
> > and gets the longditude and latitude the correct way round
> > (as several people have told me.
> 
> I use:
> 
> lng=`{echo $here(2) | sed -e 's/^-(.*)/+\1/' -e 's/^([0-9])/-\1/'}
> 
> Because double negatives (--) don't seem to cut it in the URL :-)
> I imagine there's a better way, but rc programming is not my strong
> suit.  And I can't test now the simplification that drops the \1 from the 
> first term.

this was my approach.  just remove any leading --.

/n/dump/2009/0326/rc/bin/gmap:5,11 - /rc/bin/gmap:5,11
  gmapkey = `{cat /lib/gmapkey}
  here = `{cat /lib/sky/here}
  lat = $here(1)
- lng = -$here(2)
+ lng = `{echo -$here(2) | sed 's/^--//g'}
  
  if(~ $#gmapkey 0){
echo goto http://code.google.com/apis/maps/signup.html and get a google 
maps key (free)


> I got caught by the fact that the space after -e is mandatory (why?)
> and the first \1 belongs to me trying to figure out what I was doing
> wrong.

this is due to non-standard usage of ARGF.
it might be a good idea to replace the continues
between ARGBEGIN and ARGEND with break.
currently ARGEND doesn't do anything, but one
could imagine a different implementation that does.

- erik

; diff -c sed.c /sys/src/cmd/
sed.c:203,209 - /sys/src/cmd//sed.c:203,208
  void
  main(int argc, char **argv)
  {
-   char *p;
int compfl;
  
lnum = 0;
sed.c:215,230 - /sys/src/cmd//sed.c:214,229
exits(0);
ARGBEGIN{
case 'e':
-   if ((p = ARGF()) == nil)
+   if (argc <= 1)
quit("missing pattern");
-   newfile(P_ARG, p);
+   newfile(P_ARG, ARGF());
fcomp();
compfl = 1;
continue;
case 'f':
-   if ((p = ARGF()) == nil)
+   if(argc <= 1)
quit("no pattern-file");
-   newfile(P_FILE, p);
+   newfile(P_FILE, ARGF());
fcomp();
compfl = 1;
continue;

Re: [9fans] GSOC: Drawterm for the iPhone

[Devon H. O'Dell]

2009/3/26 erik quanstrom :
> so please stop saying that 9vx or inferno make drawterm obsolete
> until that's actually true.

Additionally, both 9vx and inferno do actually execute code, which
would facilitate a breach of the SDK license.

> - erik

--me

Re: [9fans] GSOC: Drawterm for the iPhone

[erik quanstrom]

On Thu Mar 26 08:53:03 EDT 2009, urie...@gmail.com wrote:
> Porting drawterm is a dead end with very little potential of either
> learning anything interesting or being useful in the future.

inferno is a red herring.  you might as well suggest qnx as
an alternative.

while drawterm might not be appropriate as is for the platform
in question, drawterm is still the best option for connecting
to a localish plan 9 system from a machine that's not running
plan 9.  it requires no local administration.  that's a big deal.
i already have two independent systems and 50 users to manage.

9vx could replace drawterm in our environment, but i think
the following work is required.  9vx needs
- to be able to boot with no local files other than the executable,
(i.e. directly from a plan 9 fs)
- to have native networking built in,
- to be harmonized with plan 9 devices.  (i don't think users will
accept "if you're on 9vx, do this; if you're on a cpu server, do that".)

(booting from a plan 9 fs could be an interesting gsoc project,
especially if the kernel were (sort-of) pxe loaded so that clients would
only need a local copy of the loader and changes would then be
automaticly distributed.)

so please stop saying that 9vx or inferno make drawterm obsolete
until that's actually true.

- erik

[9fans] GSOC: Gitfs

[Mukhitdinov Manzur]

Hello!

I'm a cs student from Saint-Petersburg,Russia(sea-gull on #plan9-soc).
I'm interested in your project of implementing Git file system
for Plan9.
Implementing Gitfs when we have Hgfs[1] and hgc may seem odd to
somebody,
especially when Git doesn't have apparent advantages over mercury.
But there are some benefits to community: as I'm new to Plan9/Inferno
the more difficult task I get, the more and deeper I'll learn Plan9. And
that means,
the better and longer I can help to the community
But I'll benefit no less than you: I'll learn miraculous Plan9,
get friends and spend my time to something useful

I've some other ideas:
- Something like Boost library for Limbo
- Dis decompiler

Comments are appreciated!

Thanks, Manzur

References:
1. http://www.ueber.net/hg/hgfs/files/last/README

Re: [9fans] GSOC: Drawterm for the iPhone

[Devon H. O'Dell]

2009/3/26 Eric Van Hensbergen :
> On Thu, Mar 26, 2009 at 7:30 AM, Federico G. Benavento
>  wrote:
>>I mean, drawterm for the iphone! why not for symbian?
>>
>
> I'd have no problems with those suggestions either, as far as multitouch
> goes there are probably even further platforms -- even just support of
> 2 simultaneous mice.
> But the student seems keen on iphone, and if there is a mentor
> similarly interested then
> I don't see a problem.

+1

>         -eric

Re: [9fans] Plan 9 on Routers?

[Devon H. O'Dell]

2009/3/26  :
>> I've wanted to work with somebody
>> on Plan 9 as a routing device in networks for some time, at least in
>> the field of packet classification.
>
> I'll be happy to help, too, if so desired, I have been playing with
> IPFilters in a pretty serious way for many years (and ipfw before
> that) and may well be able to contribute my experiences in this
> field.

Sweet. Perhaps I'll re-implement the hookable filters into 9vx. The
interface is a more difficult problem than a proof-of-concept filter
(which I've implemented a few times). Maybe we should talk about ideas
for rule lookups and the like off-list? I'll put it up as an idea
again this year as well, and see if anybody bites.

--dho

> ++L
>
>
>

Re: [9fans] request for more GSoC project suggestions

[Devon H. O'Dell]

2009/3/26  :
>> so if you have any ideas you'd like to get on
>> there, just mail them to me, or to the plan9-gsoc mailing list and
>> I'll get them plopped up there.
>
> I'm actively working on GCC from two directions: a port of the Plan 9
> libraries to a cross-compilation environment under NetBSD (I have
> Ubuntu handy as well, so that becomes an option) and implementing ELF
> support in the Plan 9 kernel.  The latter requires familiarity with
> Linuxemu which in turns provides two useful extensions besides its own
> value: ELF and MMAP.
>
> MMAP is so ubiquitous, someone ought to be looking into it, but it
> won't be me until ELF is sorted out.

^

> I have no idea whether any of these are potential GSoC projects, but
> anyone who wants to contribute is welcome in whatever way they like.

Alright, sounds good. Are you signed up as a mentor? (I'm not an
admin, so I don't know).

I'll add this to the ideas page; if you're interested and able to
mentor, this would be a great project, I think.

--dho

> ++L
>
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Thu, Mar 26, 2009 at 7:30 AM, Federico G. Benavento
 wrote:
>> My personal belief is that this is a really bad, if not dangerous criteria
>> for projects.  The goal for gsoc should not be to assign work for stuff 'we
>> need' -- if we need something we should be doing it ourselves.  The goal
>> should be to create interesting projects that attract new developers and
>> ideas to the system -- and ones tha
>>
(damn iphone interface cut me off! how's that for irony) -- what I was
going to say was

...ideas to the system -- and ones that provide opportunities for
folks to learn Plan 9
ways of doing things and incorporating new approaches into Plan 9
(like multitouch).
This is more of a general concern than specific support for the
drawterm on iphone
project idea.

>
>But, the main point of this paragraph isn't to support multi-touch, just to 
>steer folks away
>this is a bit misleading, if someone wants to explore small screens,
>multi-touch and whatelse, why not getting a linux phone and starting
>there?
>
>I mean, drawterm for the iphone! why not for symbian?
>

I'd have no problems with those suggestions either, as far as multitouch
goes there are probably even further platforms -- even just support of
2 simultaneous mice.
But the student seems keen on iphone, and if there is a mentor
similarly interested then
I don't see a problem.

 -eric

Re: [9fans] GSOC: Drawterm for the iPhone

[Uriel]

Why not Inferno for iPhone or Symbian or Android? If one is going to
research multitouch/small-scree GUIs, one will want to write
applications, and being able to write apps in Limbo for either
platform would be a big win, plus you get all the drawterm
functionality for free, and could be the basis of an Octopus port.

Porting drawterm is a dead end with very little potential of either
learning anything interesting or being useful in the future.

uriel

On Thu, Mar 26, 2009 at 1:30 PM, Federico G. Benavento
 wrote:
>> My personal belief is that this is a really bad, if not dangerous criteria
>> for projects.  The goal for gsoc should not be to assign work for stuff 'we
>> need' -- if we need something we should be doing it ourselves.  The goal
>> should be to create interesting projects that attract new developers and
>> ideas to the system -- and ones tha
>>
>
> this is a bit misleading, if someone wants to explore small screens,
> multi-touch and whatelse, why not getting a linux phone and starting
> there?
>
> I mean, drawterm for the iphone! why not for symbian?
>
>
> --
> Federico G. Benavento
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[Federico G. Benavento]

> My personal belief is that this is a really bad, if not dangerous criteria
> for projects.  The goal for gsoc should not be to assign work for stuff 'we
> need' -- if we need something we should be doing it ourselves.  The goal
> should be to create interesting projects that attract new developers and
> ideas to the system -- and ones tha
>

this is a bit misleading, if someone wants to explore small screens,
multi-touch and whatelse, why not getting a linux phone and starting
there?

I mean, drawterm for the iphone! why not for symbian?


-- 
Federico G. Benavento

Re: [9fans] GSOC: Drawterm for the iPhone

[hiro]

On Thu, Mar 26, 2009 at 11:42 AM, Pietro Gagliardi  wrote:
> On Mar 26, 2009, at 3:32 AM, André Günther wrote:
>
> [1] http://www.minithink.org/mock.jpg
> (Sorry for the image quality)
>
> I just tried giving that to Interface Builder. Apparently, toolbars can only
> be on the horizontal in Cocoa Touch. But this is an interesting start.
> The problem of how to make rio work on a small device still exists. How
> about replace rio with a two-fold environment:
> 1) Window Choosing/Managing. If you click a window, you can either bring it
> up or move/resize.
> 2) Window: When you choose to bring up a window, you can work in that
> window. There should be a Zoom/Pan button which will allow you to modify the
> area you work in for higher visibility in larger windows.
>

you should look at dynamic window management, try out dwm and wmii
from suckless.org

Re: [9fans] GSOC: Drawterm for the iPhone

[Eric Van Hensbergen]

On Mar 25, 2009, at 10:32 PM, "Federico G. Benavento" > wrote:




I think that gsoc is a good chance to get going stuff that
we need and we will really use.



My personal belief is that this is a really bad, if not dangerous  
criteria for projects.  The goal for gsoc should not be to assign work  
for stuff 'we need' -- if we need something we should be doing it  
ourselves.  The goal should be to create interesting projects that  
attract new developers and ideas to the system -- and ones tha







On Thu, Mar 26, 2009 at 12:20 AM, Bakul Shah > wrote:
On Wed, 25 Mar 2009 21:25:07 CDT Eric Van Hensbergen >  wrote:
Also, figuring out how multitouch works with plan 9 would be  
valuable

in itself -- although admitadly could be done without an iPhone.


Exactly what I was thinking while reading this thread!  An
intuitive multitouch interface that goes beyond cut-n-paste
would go very well with a 3D graphics protocol. 9gl anyone?!






--
Federico G. Benavento

Re: [9fans] GSOC: Drawterm for the iPhone

[Pietro Gagliardi]

On Mar 26, 2009, at 3:32 AM, André Günther wrote:


[1] http://www.minithink.org/mock.jpg
(Sorry for the image quality)


I just tried giving that to Interface Builder. Apparently, toolbars  
can only be on the horizontal in Cocoa Touch. But this is an  
interesting start.


The problem of how to make rio work on a small device still exists.  
How about replace rio with a two-fold environment:


1) Window Choosing/Managing. If you click a window, you can either  
bring it up or move/resize.
2) Window: When you choose to bring up a window, you can work in that  
window. There should be a Zoom/Pan button which will allow you to  
modify the area you work in for higher visibility in larger windows.

Re: [9fans] request for more GSoC project suggestions

[Charles Forsyth]

>GSoC isn't entirely about completing a
>project: the scope of a project may just be laying groundwork or a
>foundation for a later project which involves the porting.

Based on the experience last time, I think it is better to
have simpler projects that are straightforward, self-contained (but modular),
and can actually be completed. They should not require a lot of specialised 
support, or ask
a student to do something we haven't normally attempted ourselves.
I don't think those characteristics make a project less interesting
or challenging, but they do help both with supervision and providing
the satisfaction of actually having got something useful done by
the end of the summer. The GSoC project is quite a public thing
for a student (though last time a few seemed not to realise that),
and I know that potential employers look at them.

Re: [9fans] new toy - gmap

[lucio]

> Pick up the new code, it reads the key from /lib/gmapkey
> and gets the longditude and latitude the correct way round
> (as several people have told me.

I use:

lng=`{echo $here(2) | sed -e 's/^-(.*)/+\1/' -e 's/^([0-9])/-\1/'}

Because double negatives (--) don't seem to cut it in the URL :-)
I imagine there's a better way, but rc programming is not my strong
suit.  And I can't test now the simplification that drops the \1 from the first 
term.

I got caught by the fact that the space after -e is mandatory (why?)
and the first \1 belongs to me trying to figure out what I was doing
wrong.

++L

Re: [9fans] request for more GSoC project suggestions

[lucio]

> so if you have any ideas you'd like to get on
> there, just mail them to me, or to the plan9-gsoc mailing list and
> I'll get them plopped up there.

I'm actively working on GCC from two directions: a port of the Plan 9
libraries to a cross-compilation environment under NetBSD (I have
Ubuntu handy as well, so that becomes an option) and implementing ELF
support in the Plan 9 kernel.  The latter requires familiarity with
Linuxemu which in turns provides two useful extensions besides its own
value: ELF and MMAP.

MMAP is so ubiquitous, someone ought to be looking into it, but it
won't be me until ELF is sorted out.

I have no idea whether any of these are potential GSoC projects, but
anyone who wants to contribute is welcome in whatever way they like.

++L

Re: [9fans] GSOC: Drawterm for the iPhone

[Francisco J Ballesteros]

If we got o/live running on iPhone it wouldnt matter
if you drop the connection.

The layout and all the editing state is kept in the cpu server.
Thus it's very much like a screen blank/ resume instead of a
shutdown, reboot.


On Thu, Mar 26, 2009 at 2:21 AM, Eric Van Hensbergen  wrote:
> Guess it depends on how you are using it.  Wonder if you could save enough
> state to recover -- probably just Vnc at that point though.
>
> Would octopus have the same problem or would Op help solve the state
> problem?
>
>     -eric
>
> Sent from my iPhone
>
> On Mar 25, 2009, at 8:11 PM, andrey mirtchovski 
> wrote:
>
>> dropping the connection to the plan9 host every time you do something
>> else not a showstopper?
>>
>> On Wed, Mar 25, 2009 at 7:07 PM, Eric Van Hensbergen 
>> wrote:
>>>
>>> Wait, why?
>>
>
>

Re: [9fans] GSOC: Drawterm for the iPhone

[André Günther]

Hi,

here's the guy again that made the original post:
It seems the idea is almost dismissed and I am sorry for wasting your  
time once again, but I'd like to reply to some arguments:


1) Close the iPhone App and your drawterm session is gone

A part of the project could be to write a server that holds the real  
drawterm connection and simulates a drawterm up to the point that  
another drawterm could connect to it and continue the session. Much  
like a irc bouncer.


2) Using drawterm on such a screen is a big pain in the ass

For clicking: Just think of a horizontal iPhone. With one hand you  
point. With the other hand you lay on buttons in a side bar that can  
modify your clicks. ([1] for a simple mockup (examplary: left hand for  
pointing, right thumb for modifying)


Managing rio windows might be possible by giving some extra brainpower  
to the drawterm, like resizing/moving windows with gestures and also  
creating new or deleting windows with gestures.


I imagine both clicking and managing rio become very fluent after you  
get used to it.


__This also might  be a test how the mouse philosophy of plan9  
transfers to touch devices. which is an interesting aspect for the  
project also for the future__


3) Extra applications...

I just give here a small list of devices one could export on an  
iPhone, just to give you an idea:

- Screen
- Multitouch
- Audio (In and Out)
- Camera
- Global positioning data
- the ssd disk on the iPhone
- 3dimensional rotation of the phone

I am sure just about everyone can pick up some of these to think of an  
application he would find useful for everyday work.



Best wishes,
André
[1] http://www.minithink.org/mock.jpg
(Sorry for the image quality)