[9fans] Les Mis?rables

[9fans] Les Mis?rables

[jimmy brisson]

From: jmk@pla...
Subject: Re: [9fans] Writing device drivers
Date: Sat, 15 Apr 2006 00:58:38 -0400

>I'd try something simpler than the WPN311
>to start with. I think it uses the Atheros 5212
>chip and I looked at writing a driver for that a
>few weeks ago and decided it was probably more man
>years than I had available.

you seem to be right.

on another note, MadWifi recently released ALL of the sorce included
for their drivers(Including the HAL crap). this allows for a complete
analisys of the project at hand.

If you want me to do something simpler for the time being, I will.
Otherwise I will begin to look at both plan 9 sources and madwifi
sources.

-Jimmy

Re: [9fans] Les Mis?rables

[Steve Simon]

there is russ's partially completed centrino driver
in his area of contrib.

This has the advantage of being a (hopefully) gentle introduction
which already has a plan9 interface and will be very nicely written.

see /n/sources/contrib/rsc/ipw2200

-Steve

Re: [9fans] Les Mis?rables

[Akshat Kumar]

http://9fans.net/archive/2005/09/1
you could also go after that;
seems to be more generic,
but I'm not sure about relative
difficulty/feasibility of such a task.

ak

Re: [9fans] Les Mis?rables

[Enrico Weigelt]

* jimmy brisson <theotherjimmy@gmail.com> wrote:

Hi,

> on another note, MadWifi recently released ALL of the sorce included
> for their drivers(Including the HAL crap). this allows for a complete
> analisys of the project at hand.

Is the binary-only module also open now ?

BTW: what does it take to have the driver for such a device
completely in userland ? What interfaces does the kernel have
to provide ?


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

Re: [9fans] Les Mis?rables

[jimmy brisson]

On Tue, Feb 24, 2009 at 10:00 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * jimmy brisson <theotherjimmy@gmail.com> wrote:
>
> Hi,
>
>> on another note, MadWifi recently released ALL of the sorce included
>> for their drivers(Including the HAL crap). this allows for a complete
>> analisys of the project at hand.
>
> Is the binary-only module also open now ?
Yes, that is what I was refering to.

>
> BTW: what does it take to have the driver for such a device
> completely in userland ?
Not much,The implimentation would be similar

> What interfaces does the kernel have
> to provide ?
I have no Idea

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



-- 
; and logic ensued, bringing joy and relief to people through out the land

Re: [9fans] Les Mis?rables

[Enrico Weigelt]

* jimmy brisson <theotherjimmy@gmail.com> wrote:

Hi,

> > Is the binary-only module also open now ?
> Yes, that is what I was refering to.

cool :)

> > BTW: what does it take to have the driver for such a device
> > completely in userland ?
> Not much,The implimentation would be similar

Is there any example I could learn from ?


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

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

Re: [9fans] Les Mis?rables

[jimmy brisson]

On Wed, Feb 25, 2009 at 8:40 PM, Enrico Weigelt <weigelt@metux.de> wrote:
> * jimmy brisson <theotherjimmy@gmail.com> wrote:
>
> Hi,
>
>> > Is the binary-only module also open now ?
>> Yes, that is what I was refering to.
>
> cool :)
>
>> > BTW: what does it take to have the driver for such a device
>> > completely in userland ?
>> Not much,The implimentation would be similar
>
> Is there any example I could learn from ?
>
that is what stopped me :(
>
> cu
> --
> ----------------------------------------------------------------------
>  Enrico Weigelt, metux IT service -- http://www.metux.de/
>
>  cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
> ----------------------------------------------------------------------
>  Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
>
>



-- 
; and logic ensued, bringing joy and relief to people through out the land

Re: [9fans] Les Mis?rables

[erik quanstrom]

> drivers should be easy. What turns them hard is dealing with all the
> bugs in the hardware.

vendors vary widly in the amount of bugs there are to
deal with.  errata can be your friends.  i can't speak
to wireless parts, but my experience is that intel parts
generally work quite well with few errata.

however, the errata are not necessarly as bad as the
odd features!

i have a recent experience.  a certain $vendor has a
$part.  it has some bits in a register that specify the
"endianness" of the data.  unfortunately, the $spec
specifies the bytes in order.  it took a good long while
to figure out that the $part's docs were specifying
bytes with respect to the native word byte order.
thus the mapping of the bits was the reverse of the
expected.

why such a feature would be included is beyond me.
the special bits need to be fiddled together regardless
and the data have no ordering.

- erik

Re: [9fans] Les Mis?rables

[ron minnich]

Jimmy, your best bet is to find a working wifi card and dig through
that source for a few weeks until you're sure you really understand
it.

drivers should be easy. What turns them hard is dealing with all the
bugs in the hardware.

ron

Re: [9fans] Les Mis?rables

[erik quanstrom]

> See the great Eric Smith who thought he could -- and related messages:
> http://9fans.net/archive/2006/04/286
>
> Sadly, most of that time will probably go into hopes and failures
> of the replication idea, and by the time college starts up,
> you'll have learned just enough to no longer have any more time
> to write working driver code.
> In short: it's not easy (see jmk's post as reply to the above reference).

always look on the bright side of life
da doo da doo da doo da do ta do.

sure it's not easy writing a driver.  if
it were, there'd be no satisfaction in
doing it.

yet they are still just software.  there
is nothing magical about a driver.

i would recommend getting some
documentation, though.  drivers
themselves don't retain much information
on what the magic registers do.

- erik

Re: [9fans] Les Mis?rables

[Akshat Kumar]

2009/1/18 jimmy brisson <theotherjimmy@gmail.com>:
...
> When did supporting Atheros wireless cards stop being a solution?
>
> As a High School senior, I have tons of time on my hands, but very
> little experince.
> Therefore, I am could be handed the sorce for a working wifi driver
> and replicate it for
> Atheros based cards (using my current linux wifi driver for reference).
> In other words, could someone point me in the right direction?

See the great Eric Smith who thought he could -- and related messages:
http://9fans.net/archive/2006/04/286

Sadly, most of that time will probably go into hopes and failures
of the replication idea, and by the time college starts up,
you'll have learned just enough to no longer have any more time
to write working driver code.
In short: it's not easy (see jmk's post as reply to the above reference).

> thanks,
> Jimmy

an import(4) for free time would be very valuable --
I would not have needed a hammer and chisel as a
printing device, usable with Plan 9,
ak

Re: [9fans] Les Misérables

[Akshat Kumar]

hiro:
> Yeah, I think your arguments make perfectly sense.
> I would still be interested to know whether Akshat had the same
> thoughts in mind:)

I have great affinity for everything Plan 9 -- from
the superficial interface to the depths of its
methodology (although, I was recently dumped
by venti). Coding an FS backed application
is something I've always wanted to do; one that
provides an interface for something I regularly
use and understand very well, would be easier
than other things. Steve is spot-on.

And as Erik pointed out, Inferno simply isn't
Plan 9 -- though I still wouldn't mind it on top of
Plan 9 if it were not so slow over
drawterm/cpu(1) on 9vx. Would I still work on this
application? Yeah -- it's not there on Plan 9 natively,
which has its own benefits (and comfort -- see above).

Beyond that, an even more interesting application
would be an IRC server itself, which, with the
backing of an FS, could have a dual effect/usage
of both, fs attachment (for Plan 9 folks), and
the normal protocol connection (for everyone else).
This could perhaps employ the Plan 9 namespace
methodology for containing some sort of conversation-
spaces for users... "and stuff". I won't elaborate...

too many ideas popping in and out,
for otherwise menial tasks
ak

Re: [9fans] Les Mis?rables

[Eris Discordia]

Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Erreplicate. Bye, bye, cute acute.

--On Monday, January 19, 2009 6:53 AM +0000 jimmy brisson
<theotherjimmy@gmail.com> wrote:

>> Although there is already an ircfs for Inferno, since I don't want to
>> run Inferno outside of Plan 9, and certainly not over a remote
>> connection to Plan 9 (these also being my only options -- unless someone
>> wants to start creating drivers for Atheros wireless cards), I've begun
>> work on an FS backed IRC client for native Plan 9. Steve Q.
>
> When did supporting Atheros wireless cards stop being a solution?
>
> As a High School senior, I have tons of time on my hands, but very
> little experince.
> Therefore, I am could be handed the sorce for a working wifi driver
> and replicate it for
> Atheros based cards (using my current linux wifi driver for reference).
> In other words, could someone point me in the right direction?
> thanks,
> Jimmy
>

Re: [9fans] Les Mis?rables

[jimmy brisson]

>Although there is already an ircfs for Inferno, since I don't want to run Inferno
>outside of Plan 9, and certainly not over a remote connection to Plan 9 (these
>also being my only options -- unless someone wants to start creating drivers for
>Atheros wireless cards), I've begun work on an FS backed IRC client for native
>Plan 9. Steve Q.

When did supporting Atheros wireless cards stop being a solution?

As a High School senior, I have tons of time on my hands, but very
little experince.
Therefore, I am could be handed the sorce for a working wifi driver
and replicate it for
Atheros based cards (using my current linux wifi driver for reference).
In other words, could someone point me in the right direction?
thanks,
Jimmy

Re: [9fans] Les Misérables

[LiteStar numnums]

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

Inline

On Sun, Jan 18, 2009 at 6:52 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > Well, actually, I was thinking of something along the lines of Lisaac:
> > "dynamic" modules are statically compiled ala object files, & the run
> time
> > handles issues between Plan9 & Inferno. Sys->load & the like would not be
> > dynamic, but would work as expected. Hell, it could even just be a
> > .Net/perl2exe clone: every binary is just an ultra-cut down Dis +
> compiled
> > modules. I like the Lisaac model better, and that's where I was hedging
> my
> > bets; I have a bunch of notes on my local Inferno install, but nothing to
> > show due to more pressing issues. C'est la vie.
> > & debugging this would require a 9Limbo-aware debugger; the .Net-style
> > approach could serve a /lproc or the like though (not that the native one
> > couldn't, but the VMish approach could have hooks for stopping
> execution).
> > $0.02
>
> perhaps i wasn't clear.  so please forgive me for repeating
> myself and charles.
>

No, I understand actually, but we're talking past each other. Despite being
an ass, I'm not nearly as stupid as you
may think.


>
> this is exactly the type approach that i was pointing out
> would not work.  it won't work because inferno provides an
> environment.  the inferno vm will not be able to replicate
> the environment without also dragging large parts of the
> inferno kernel along.  but the consequence of doing this
> will make inferno procs fundamentally different from
> plan 9 procs.
>

Understood; you'll note I never say port Inferno's everything to run atop
Plan9 (Dis does this fine enough).
I meant an static collection of Limbo modules could be shoe-horned into a
binary. I'm talking about Limbo the language;
there would be numerous differences between a 'native' limbo & the hosted
one. For one, dynamic loading wouldn't work.
Another is the thought experiment you provide below. Certain things could be
abstracted, other things would have to go.
I don't want an libinferno.


>
> if you're not convinced of this, try this thought experiment.
> suppose an inferno proc accesses a # device.  and suppose
> further that this device is different in plan 9 and inferno.
> how do you bridge the cap in both directions so that neither
> inferno nor plan 9 is aware of the joke?
>

Again, a native limbo might be different; a programmer might have to handle
such things, much like the way C programmers
have to handle the differences between Plan9 & everything else. I like Limbo
the *language*, most of which could be abstracted to run atop Plan9 fine
methinks. I don't think I'll be running wm/wm anytime soon, nor did I ever
say that. Given that Limbo is modular, reads of # devices could be handled
by a plan9_limbo & an inferno_limbo module, with the same "interface". I
don't see this as a major issue stopping Limbo *the language* from being
brought into native use. *shrug*


> - erik
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 5016 bytes --]

Re: [9fans] Les Misérables

[erik quanstrom]

> Well, actually, I was thinking of something along the lines of Lisaac:
> "dynamic" modules are statically compiled ala object files, & the run time
> handles issues between Plan9 & Inferno. Sys->load & the like would not be
> dynamic, but would work as expected. Hell, it could even just be a
> .Net/perl2exe clone: every binary is just an ultra-cut down Dis + compiled
> modules. I like the Lisaac model better, and that's where I was hedging my
> bets; I have a bunch of notes on my local Inferno install, but nothing to
> show due to more pressing issues. C'est la vie.
> & debugging this would require a 9Limbo-aware debugger; the .Net-style
> approach could serve a /lproc or the like though (not that the native one
> couldn't, but the VMish approach could have hooks for stopping execution).
> $0.02

perhaps i wasn't clear.  so please forgive me for repeating
myself and charles.

this is exactly the type approach that i was pointing out
would not work.  it won't work because inferno provides an
environment.  the inferno vm will not be able to replicate
the environment without also dragging large parts of the
inferno kernel along.  but the consequence of doing this
will make inferno procs fundamentally different from
plan 9 procs.

if you're not convinced of this, try this thought experiment.
suppose an inferno proc accesses a # device.  and suppose
further that this device is different in plan 9 and inferno.
how do you bridge the cap in both directions so that neither
inferno nor plan 9 is aware of the joke?

- erik

Re: [9fans] Les Misérables

[LiteStar numnums]

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

Well, actually, I was thinking of something along the lines of Lisaac:
"dynamic" modules are statically compiled ala object files, & the run time
handles issues between Plan9 & Inferno. Sys->load & the like would not be
dynamic, but would work as expected. Hell, it could even just be a
.Net/perl2exe clone: every binary is just an ultra-cut down Dis + compiled
modules. I like the Lisaac model better, and that's where I was hedging my
bets; I have a bunch of notes on my local Inferno install, but nothing to
show due to more pressing issues. C'est la vie.
& debugging this would require a 9Limbo-aware debugger; the .Net-style
approach could serve a /lproc or the like though (not that the native one
couldn't, but the VMish approach could have hooks for stopping execution).
$0.02


On Sun, Jan 18, 2009 at 5:26 PM, erik quanstrom <quanstro@quanstro.net>wrote:

> > > >Or have a native Limbo compiler; I've been itching for that for some
> time,
> > >
> > > it doesn't mean anything.
> >
> > Uh, considering that ircfs is for Inferno (via Limbo), having a Limbo
> > compiler to native Plan9 would be a potential solution, assuming the run
> > time could be kept the same.
>
> de top-posted for your reading pleasure.
>
> the reason that a native limbo compiler doesn't make any
> sense is that inferno is not a virtual cpu, it is a virtual
> system, complete with system calls, file system access,
> etc.  of course, this is the right way to do things since
> inferno needs to run natively and on top of other systems
> like windows as well as natively.
>
> i've heard that it was the opinion of some at the labs
> in the early days of plan 9 (can anyone confirm?) that
> plan 9 was a way to glue the unixes together.  if that's
> what plan 9 is, then one should have a fs to make an
> inferno's /proc appear nativeish.  but it's not clear to
> me that one could bridge enough of the gap to make
> this anything other than an annoyance.  for example,
> what if you wanted to debug an inferno process?
>
> - erik
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 3527 bytes --]

Re: [9fans] Les Misérables

[erik quanstrom]

> > >Or have a native Limbo compiler; I've been itching for that for some time,
> >
> > it doesn't mean anything.
>
> Uh, considering that ircfs is for Inferno (via Limbo), having a Limbo
> compiler to native Plan9 would be a potential solution, assuming the run
> time could be kept the same.

de top-posted for your reading pleasure.

the reason that a native limbo compiler doesn't make any
sense is that inferno is not a virtual cpu, it is a virtual
system, complete with system calls, file system access,
etc.  of course, this is the right way to do things since
inferno needs to run natively and on top of other systems
like windows as well as natively.

i've heard that it was the opinion of some at the labs
in the early days of plan 9 (can anyone confirm?) that
plan 9 was a way to glue the unixes together.  if that's
what plan 9 is, then one should have a fs to make an
inferno's /proc appear nativeish.  but it's not clear to
me that one could bridge enough of the gap to make
this anything other than an annoyance.  for example,
what if you wanted to debug an inferno process?

- erik

Re: [9fans] Les Misérables

[Charles Forsyth]

>Or have a native Limbo compiler; I've been itching for that for some time,

it doesn't mean anything.

Re: [9fans] Les Misérables

[LiteStar numnums]

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

Uh, considering that ircfs is for Inferno (via Limbo), having a Limbo
compiler to native Plan9 would be a potential solution, assuming the run
time could be kept the same.

On Sun, Jan 18, 2009 at 4:53 PM, Charles Forsyth <forsyth@terzarima.net>wrote:

> >Or have a native Limbo compiler; I've been itching for that for some time,
>
> it doesn't mean anything.
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 1622 bytes --]

Re: [9fans] Les Misérables

[LiteStar numnums]

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

Or have a native Limbo compiler; I've been itching for that for some time,
but I've much else on my hands. One day when free...


On Sun, Jan 18, 2009 at 9:28 AM, erik quanstrom <quanstro@quanstro.net>wrote:

> >
> > I seem to remember Mjl, the author if the inferno ircfs, wrote an
> > ircfs for Plan 9 ages ago. Still, seems like a total waste of time
> > when you have a perfectly fine one in limbo, which is a much more
> > convenient language for building such a thing anyway.
> >
>
> the op said he was running plan 9.  if we take that as a
> reasonable thing to be doing, then it makes sense to
> want to run native plan 9 programs for a number of
> reasons.  first, if the op doesn't have any inferno running
> already, he doesn't need to install and figure out how
> to run it.  not that this is hard, but it is important to
> admit this is an extra step.  once installed, plan 9 tools
> like ps and  kill won't work on inferno procs.  so one
> need to either deal with the disconnect or write some
> scripts to make it less evident.
>
> none of this is specific to plan 9 and inferno.  the same
> could be said using bsd and 9vx or linux and a browser
> running browser procs.
>
> so, since an ircfs is not a huge project, i don't think
> it's unreasonable to write one for plan 9.  it's what i
> would do.
>
> - erik
>
>


--
And in the "Only Prolog programmers will find this funny" department:

Q: How many Prolog programmers does it take to change a lightbulb?

A: No.
 -- Ovid

   "By cosmic rule, as day yields night, so winter summer, war peace, plenty
famine. All things change. Air penetrates the lump of myrrh, until the
joining bodies die and rise again in smoke called incense."

   "Men do not know how that which is drawn in different directions
harmonises with itself. The harmonious structure of the world depends upon
opposite tension like that of the bow and the lyre."

   "This universe, which is the same for all, has not been made by any god
or man, but it always has been, is, and will be an ever-living fire,
kindling itself by regular measures and going out by regular measures"
-- Heraclitus

[-- Attachment #2: Type: text/html, Size: 2772 bytes --]

Re: [9fans] Les Misérables

[hiro]

On Sun, Jan 18, 2009 at 3:28 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>>
>> I seem to remember Mjl, the author if the inferno ircfs, wrote an
>> ircfs for Plan 9 ages ago. Still, seems like a total waste of time
>> when you have a perfectly fine one in limbo, which is a much more
>> convenient language for building such a thing anyway.
>>
>
> the op said he was running plan 9.  if we take that as a
> reasonable thing to be doing, then it makes sense to
> want to run native plan 9 programs for a number of
> reasons.  first, if the op doesn't have any inferno running
> already, he doesn't need to install and figure out how
> to run it.  not that this is hard, but it is important to
> admit this is an extra step.  once installed, plan 9 tools
> like ps and  kill won't work on inferno procs.  so one
> need to either deal with the disconnect or write some
> scripts to make it less evident.
>
> none of this is specific to plan 9 and inferno.  the same
> could be said using bsd and 9vx or linux and a browser
> running browser procs.
>
> so, since an ircfs is not a huge project, i don't think
> it's unreasonable to write one for plan 9.  it's what i
> would do.
>
> - erik
>
>

Yeah, I think your arguments make perfectly sense.
I would still be interested to know whether Akshat had the same
thoughts in mind:)

Re: [9fans] Les Misérables

[Steve Simon]

>>
>> I seem to remember Mjl, the author if the inferno ircfs, wrote an
>> ircfs for Plan 9 ages ago. Still, seems like a total waste of time
>> when you have a perfectly fine one in limbo, which is a much more
>> convenient language for building such a thing anyway.
>>

[snip]

> so, since an ircfs is not a huge project, i don't think
> it's unreasonable to write one for plan 9.  it's what i
> would do.
>
> - erik

I would add to Erik's comments that perhaps Akshat wants to write an ircfs,
partly to have the end result of having such a tool, but also for the
experience of learning the parts of the plan9 system and techniques
required to build it.

That is what I have done in the past, and what I continue to do.

-Steve

Re: [9fans] Les Misérables

[erik quanstrom]

>
> I seem to remember Mjl, the author if the inferno ircfs, wrote an
> ircfs for Plan 9 ages ago. Still, seems like a total waste of time
> when you have a perfectly fine one in limbo, which is a much more
> convenient language for building such a thing anyway.
>

the op said he was running plan 9.  if we take that as a
reasonable thing to be doing, then it makes sense to
want to run native plan 9 programs for a number of
reasons.  first, if the op doesn't have any inferno running
already, he doesn't need to install and figure out how
to run it.  not that this is hard, but it is important to
admit this is an extra step.  once installed, plan 9 tools
like ps and  kill won't work on inferno procs.  so one
need to either deal with the disconnect or write some
scripts to make it less evident.

none of this is specific to plan 9 and inferno.  the same
could be said using bsd and 9vx or linux and a browser
running browser procs.

so, since an ircfs is not a huge project, i don't think
it's unreasonable to write one for plan 9.  it's what i
would do.

- erik

Re: [9fans] Les Misérables

[hiro]

>I don't want to
> run Inferno
> outside of Plan 9, and certainly not over a remote connection to Plan 9 (these
> also being my only options -- unless someone wants to start creating drivers for
> Atheros wireless cards)

Couldn't you run Inferno inside of plan9?

Re: [9fans] Les Misérables

[Uriel]

On Sun, Jan 18, 2009 at 3:04 AM, Akshat Kumar
<akumar@mail.nanosouffle.net> wrote:
> Although there is already an ircfs for Inferno, since I don't want to
> run Inferno outside of Plan 9

Why not?

> and certainly not over a remote connection to Plan 9

Why not?

> (these
> also being my only options -- unless someone wants to start creating drivers for
> Atheros wireless cards), I've begun work on an FS backed IRC client for native
> Plan 9. Steve Q. has been kind enough to provide me with some ideas and code
> from his previous tries at something like this (i.e., stuff previously found
> inside /n/sources/contrib/steve/chatfs-unfinished.tgz).

I seem to remember Mjl, the author if the inferno ircfs, wrote an
ircfs for Plan 9 ages ago. Still, seems like a total waste of time
when you have a perfectly fine one in limbo, which is a much more
convenient language for building such a thing anyway.

uriel

Re: [9fans] Les Misérables

[Akshat Kumar]

Regarding nadict (the rc scripted Acme interface to dict(7)), for
those interested,
I plan to add the remaining "Next", "Prev", and "Nmatch"
functionalities as found
in adict.
Of the brief trials I did with this, it seemed to get messy.

Although there is already an ircfs for Inferno, since I don't want to
run Inferno
outside of Plan 9, and certainly not over a remote connection to Plan 9 (these
also being my only options -- unless someone wants to start creating drivers for
Atheros wireless cards), I've begun work on an FS backed IRC client for native
Plan 9. Steve Q. has been kind enough to provide me with some ideas and code
from his previous tries at something like this (i.e., stuff previously found
inside /n/sources/contrib/steve/chatfs-unfinished.tgz).

suggestions, code, wifi card drivers, women interested in finding men
on obsolete
operating system discussion mailing lists... all welcome,
ak

Re: [9fans] Les Misérables

[Eris Discordia]

So it did on Windows + Mulberry. I know, I know, I'll shut up.

--On Friday, January 16, 2009 8:17 PM -0500 erik quanstrom
<quanstro@quanstro.net> wrote:

> On Fri Jan 16 20:16:55 EST 2009, akumar@mail.nanosouffle.net wrote:
>> the subject header in the last message came out to be very ugly
>> due to GMail's default encoding. now using Unicode
>>
>> sorry
>> ak
>
> looked fine on plan 9.
>
> - erik
>

Re: [9fans] Les Misérables

[erik quanstrom]

On Fri Jan 16 20:16:55 EST 2009, akumar@mail.nanosouffle.net wrote:
> the subject header in the last message came out to be very ugly
> due to GMail's default encoding. now using Unicode
>
> sorry
> ak

looked fine on plan 9.

- erik

Re: [9fans] Les Misérables

[Akshat Kumar]

the subject header in the last message came out to be very ugly
due to GMail's default encoding. now using Unicode

sorry
ak

[9fans] Les Misérables

[Akshat Kumar]

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

Certain applications have been blessed with 9fans' ignorance for too long.
dict(7) and friends seemed to be becoming over-joyous.

For those interested in Japanese on Plan 9, I provide here (edict2.tar) scripts
to convert Jim Breen's extended Japanese dictionary, EDICT2, to a format
usable with dict(7). However, the simple.c format was not appealing to me,
so I decided to use the format Andrey proposed for converting DICTD
dictionaries, thus, a patch[1] to dict(7), and the appropriate indexing
application[2], are necessary in order to perform the conversion and
use the resulting dictionary (the path to the indexing app
must be specified in leginx.rc).

Parts of adict, the Acme interface to dict(7), still presume some incapabilities
of Acme that are no longer present. One I've found is the assumption that
Acme tags cannot contain non-alphanumeric characters, so adict goes through
the trouble of converting all such characters to underscores.
The simple fix:
comment lines
  /acme/bin/source/adict/adict.c:288 through /acme/bin/source/adict/adict.c:294
-- by the way, the source distributed with Plan 9 by default is not what the
binary adict was built from; updated sources (though still lacking the
above change)
are in /n/sources/patch/applied/adict-fix2

However, I find Russ Cox's idea of making Acme interfaces entirely
scriptable, even
more appealing. For that, his acmeevent[3] from P9P is entirely
portable to native
Plan 9 -- no changes required. I believe the prime example he's used is a
scripted version of adict, also available in P9P -- for this, I've made a few
changes to the script for use on native Plan 9; see nadict.rc.


by the way, has anyone looked into the venti problem Oleg F. posted about,
on my behalf, earlier this month?
ak


[1] http://mirtchovski.com/p9/dict/dict.patch.tgz
[2] http://mirtchovski.com/p9/dict/mkdictd.c

[3] http://swtch.com/usr/local/plan9/src/cmd/acmeevent.c

[-- Attachment #2: edict2.tar --]
[-- Type: application/x-tar, Size: 10240 bytes --]

[-- Attachment #3: nadict.rc --]
[-- Type: application/octet-stream, Size: 2120 bytes --]

#!/bin/rc

fn newwindow {
	winctl=`{read /mnt/acme/new/ctl}
	winid=$winctl(1)
	winctl noscroll
}

fn winctl {	
	echo $* > /mnt/acme/$winid/ctl
}

fn winread {
	cat /mnt/acme/$winid/$1
}

fn winwrite {
	cat > /mnt/acme/$winid/$1
}

fn windump {
	if(! ~ $1 - '')
		winctl dumpdir $1
	if(! ~ $2 - '')
		winctl dump $2
}

fn winname {
	winctl name $1
}

fn wintag {
	winctl tag $1
}

fn winwriteevent {
	echo $1$2$3 $4 | winwrite event
}

fn windel {
	if(~ $1 sure)
		winctl delete
	if not
		winctl del
}

fn wineventloop {
	. <{winread event >[2]/dev/null | acmeevent}
}

fn event {
	# $1 - c1 origin of event
	# $2 - c2 type of action
	# $3 - q0 beginning of selection
	# $4 - q1 end of selection
	# $5 - eq0 beginning of expanded selection
	# $6 - eq1 end of expanded selection
	# $7 - flag
	# $8 - nr number of runes in $9
	# $9 - text
	# $10 - chorded argument
	# $11 - origin of chorded argument

	switch($1$2){
	case E*	# write to body or tag
	case F*	# generated by ourselves; ignore
	case K*	# type away we do not care
	case Mi	# mouse: text inserted in tag
	case MI	# mouse: text inserted in body
	case Md	# mouse: text deleted from tag
	case MD	# mouse: text deleted from body

	case Mx MX	# button 2 in tag or body
		winwriteevent $*

	case Ml ML	# button 3 in tag or body
		{
			if(~ $dict NONE)
				dictwin /nadict/$9/ $9
			if not				
				dictwin /nadict/$dict/$9 $dict $9
		} &
	}
}

fn dictwin {
	newwindow
	winname $1
	switch($#*){
	case 1
		dict -d '?' >[2=1] | sed 1d | winwrite body
	case 2
		dict=$2
	case 3
		dict=$2
		dict -d $dict $3 >[2=1] | winwrite body
	}
	winctl clean
	wineventloop
}

dict=NONE
if(~ $1 -d){
	shift
	dict=$1
	shift
}
if(~ $1 -d*){
	dict=`{echo $1 | sed 's/-d//'}
	shift
}
if(~ $1 -*){
	echo 'usage: adict [-d dict] [word...]' >[1=2]
	exit usage
}

switch($#*){
case 0
	if(~ $dict NONE)
		dictwin /nadict/
	if not
		dictwin /nadict/$dict/ $dict
case *
	if(~ $dict NONE){
		dict=`{dict -d'?' | sed -n 's/^   ([^\[ 	]+).*/\1/p' | sed 1q}
		if(~ $#dict 0){
			echo 'no dictionaries present on this system' >[1=2]
			exit nodict
		}
	}
	for(i)
		dictwin /nadict/$dict/$i $dict $i
}