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

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd like to see a 3D graphics protocol.  Then I could run the host on  
some linux or window or mac box to do the display, and run the  
graphics app in Plan9, or inferno, or ...


And (heresy aside) I've love a way to compile C++ programs for  
plan9.  That would give me a reason to get Plan9 up on this scary  
multi-core part I'm working on.  Without C++ support, I can't run the  
principle application I need :-(


Paul

On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote:



There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/
but I think more are needed, and that it would be especially good
to have a further set of useful but simpler and smaller projects.

Projects need to be non-trivial for GSoC, but shouldn't
be hard enough that many of us would shun them (or indeed, have  
shunned them).

Based on my experience several years ago,
I'd also look for projects that are modular, so that the set of  
deliverables can be extended

or reduced depending how things go. That worked well for the
projects I was involved with.

The problem with ports of the system or device driver writing, in  
my experience,

is that satisfying though they are, and as necessary
as they might be, they are typically quite hard to
supervise, and will usually be fairly difficult for relative novices.
There is quite a bit to learn for most students just to
get started and be productive in the programming environment,
although 9vx does make that much easier.
Application-level projects are typically easier to
supervise because they don't need specialised equipment,
and many more people on this list and elsewhere can help
with plausible advice, and also help debug when students are stuck.  
(Advice will
sometimes be contradictory, but that's not a bad lesson to learn,  
too.)
It's quite hard to help when special hardware or kernel-level  
debugging is involved.

Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at
user-level that is done at kernel-level in other systems, that  
shouldn't
narrow the scope much.  I wrote "application-level" not just "user- 
level"

earlier because I thought it would be good to have some
interesting applications of the system.  Of course, I don't mean
to preclude system-level things when students are especially keen
on that (as indeed I was during my school and university years).

I don't know where the best place to suggest or discuss them would be,
but I thought this list would reach nearly everyone interested.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms
o+vaJtOAjx1IxDqCtWskyQY=
=FvNd
-END PGP SIGNATURE-

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

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A modern cfront is nearly impossible.  Templates make it hella-hard.   
And generics might actually be C++'s best feature, at least in  
performance-code land.


Paul

On Mar 25, 2009, at 1:12 PM, Devon H. O'Dell wrote:



2009/3/25 Paul Lalonde :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'd like to see a 3D graphics protocol.  Then I could run the host  
on some
linux or window or mac box to do the display, and run the graphics  
app in

Plan9, or inferno, or ...

And (heresy aside) I've love a way to compile C++ programs for  
plan9.  That
would give me a reason to get Plan9 up on this scary multi-core  
part I'm
working on.  Without C++ support, I can't run the principle  
application I

need :-(


Gogo reimplementation of cfront.


Paul

On Mar 25, 2009, at 8:16 AM, Charles Forsyth wrote:



There are GSoC project suggestions at http://gsoc.cat-v.org/ideas/
but I think more are needed, and that it would be especially good
to have a further set of useful but simpler and smaller projects.

Projects need to be non-trivial for GSoC, but shouldn't
be hard enough that many of us would shun them (or indeed, have  
shunned

them).
Based on my experience several years ago,
I'd also look for projects that are modular, so that the set of
deliverables can be extended
or reduced depending how things go. That worked well for the
projects I was involved with.

The problem with ports of the system or device driver writing, in my
experience,
is that satisfying though they are, and as necessary
as they might be, they are typically quite hard to
supervise, and will usually be fairly difficult for relative  
novices.

There is quite a bit to learn for most students just to
get started and be productive in the programming environment,
although 9vx does make that much easier.
Application-level projects are typically easier to
supervise because they don't need specialised equipment,
and many more people on this list and elsewhere can help
with plausible advice, and also help debug when students are stuck.
(Advice will
sometimes be contradictory, but that's not a bad lesson to learn,  
too.)
It's quite hard to help when special hardware or kernel-level  
debugging is

involved.
Because quite a bit in Plan 9 (or Inferno/9vx/p9p etc) is done at
user-level that is done at kernel-level in other systems, that  
shouldn't
narrow the scope much.  I wrote "application-level" not just  
"user-level"

earlier because I thought it would be good to have some
interesting applications of the system.  Of course, I don't mean
to preclude system-level things when students are especially keen
on that (as indeed I was during my school and university years).

I don't know where the best place to suggest or discuss them  
would be,

but I thought this list would reach nearly everyone interested.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJyoybpJeHo/Fbu1wRAoi3AKCTQLsrxzBt7m94P3LsOR+o85KungCfT6Ms
o+vaJtOAjx1IxDqCtWskyQY=
=FvNd
-END PGP SIGNATURE-






-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJypaTpJeHo/Fbu1wRAvhqAKDVGdbVdtqRqT811TJ/cixYcadiPwCgy/E8
/SJh8wFz5YXgVSg570Xmlnw=
=pomL
-END PGP SIGNATURE-

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

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I wouldn't even consider a native GL port; it's device driver hell  
for an API that I'm hoping will be extinct in the next couple of years.
VMGL looks like it might be a good base.  I would like to see it  
speak 9p though :-)


Paul

On Mar 25, 2009, at 1:40 PM, James Tomaschke wrote:



Paul Lalonde wrote:
I'd like to see a 3D graphics protocol.  Then I could run the host  
on some linux or window or mac box to do the display, and run the  
graphics app in Plan9, or inferno, or ...


A port of vmgl to Plan9 would be nice for this.
http://www.cs.toronto.edu/~andreslc/xen-gl/

As for native GL, I'm not sure if there is any hardware option that  
has enough documentation to implement a driver.  I was considering  
digging up my old 3dfx card for a miniGL to play with.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJyrSppJeHo/Fbu1wRAup1AJ0QtVGC9qs/SRfKinhWbfJnhubUYwCdHybx
cOf6H3838tDouxzXEvWw1PE=
=qRNo
-END PGP SIGNATURE-

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

[Paul Lalonde]

A cfront-ish approach to templates leads to hellish duplication of  
template-generated code in each module, and thence to even worse code  
bloat.  Of course, my understanding of what's possible in a cfront  
translation is perhaps (probably) naive.


Paul

On 25-Mar-09, at 2:12 PM, Charles Forsyth wrote:


A modern cfront is nearly impossible.  Templates make it hella-hard.


really? how is that?

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

[Paul Lalonde]

iJuke ;-)
On 25-Mar-09, at 8:24 PM, Tom Lieber wrote:



On Wed, Mar 25, 2009 at 11:14 PM, Eric Van Hensbergen > wrote:
I think rio is probably not useful, but a purely text based  
environtment

isn't interesting either...


The only thing I could see anyone using this for is if they wrote an
iPhone-tailored UI for controlling... something... and needed to
control it sometime between leaving their work computer and arriving
at their home computer. Not having this phone I couldn't care less
whether drawterm is ported, but allowing others to make mobile
interfaces for their stuff without needing a developer license and
without having to learn anything outside the 9 universe doesn't sound
like a bad deal.

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

Re: [9fans] critique of sockets API

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Even more than transistors are so cheap that doing on-the-fly  
translation to a RISC instruction set in hardware is an essentially  
invisible cost.  Plus you get to change the target microarchitecture  
to exploit new thinking in processor design without breaking existing  
software.


That last reason, not choice, is how IA became dominant.

Paul

On Jun 11, 2009, at 4:41 PM, erik quanstrom wrote:

could it be that since transistors are very cheep, adding  
instructions is

simply the cheapest go-faster trick?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFKMdpjpJeHo/Fbu1wRAsPTAKCmeg6YnYvCNBHpWQCd9hCAM5+Y/wCgw8//
+MMUaZeL/qPutVO0W7sYTqM=
=D+2E
-END PGP SIGNATURE-

Re: [9fans] MIPS LSB compiler

[Paul Lalonde]

I'd be very interested in an ELF based cross-compilation to plan9.  I  
have this many-core IA part that I would desperately love to boot a  
nicer OS on than we currently have (memory footprint, scheduling, vm  
architecture, syscall performance, remote exposure), but the principal  
application that has to run on it is in C++.


If there was a clear path, I might even be able to shake loose some  
resources for it.


Paul

On 2009-11-15, at 8:52 AM, lu...@proxima.alt.za wrote:

Given the addition of this toolchain, one wonders how far we are  
from

being able to port all the P9 compilers to Linux and consequently to
all Posix platforms.  My beef is that I have a wide choice of cross-
and native toolchains with which to port Plan 9 to a MIPS platform
(LSB), but I really wish I could settle on something I am much more
comfortable and familiar with.


I guess I'm not following your line of thought here.


There are two almost orthogonal issues here: "go" itself and the
toolchain that it relies on.  Whereas I do care about "go" and would
dearly like to assimilate it into my toolkit, my more immediate
interest lies with porting native Plan 9 "C" facilities beyond the
Plan 9 boundaries, specifically into the various environments served
by the "ELF" object format.  Worse, my wish is for the Plan 9 kernel
to be able to cope with ELF executables so that Plan 9 can readily (*)
join the platforms that can be used to cross-develop software.

Now, the "go" toolchain is very close to the Plan 9 native toolchain,
its most obvious difference lies in its default object format.  Given
the desirability of being able to generate ELF executables from within
Plan 9 (the MIPS toolchain already does, but I had issues with that
before now and the "go" toolchain diverges from that model somewhat, I
believe from inspecting the source somewhat superficially) my hope is
that the differences in the toolchains provided by the "go"
development and Plan 9 can mostly be eliminated.  Besides providing
Plan 9 with a more modern toolchain, it also makes it more practical
to port "go" to Plan 9 and it makes it possible to cross-develop "go"
code on a Plan 9 platform; a small amount of effort in the direction
of the MIPS architecture will also facilitate porting "go" to it.  All
developments I would be keen to contribute to, but lack the confidence
more than the expertise to undertake on my own.

++L

(*) There are mutual benefits: cross-compiling on a GNU platform to a
Plan 9 target is too hard if one needs to produce Plan 9 native
executables.  Dave Hogan managed to twist GCC 3.0 (actually, binutils
2.11, if I remember right) to produce Plan 9 native executables, but I
have failed dismally to reproduce his results on later versions of the
GNU toolchain, it's just too dense for me.  I have configured a
cross-development toolchain under NetBSD that uses the Plan 9
libraries and syscall interface; it isn't yet possible for me to test
whether the generated ELF executable actually would work, too many
other chestnuts in the fire right now.  Were this cross-development
tool to be viable, one would use it to bootstrap the most recent
stable version of GCC/G++, with results some 9fans might welcome.

[9fans] Mac multi-touch mice and p9p acme anyone?

[Paul Lalonde]

I wound up with one of these today, and I just had to mess with it enough to 
get chording working through the multi-touch interfaces.  I have no idea how it 
behaves  on a trackpad, but the top 20% of my magic mouse is now 3 separate 
buttons with reasonable tapping and chording behaviour.  I can tar up my new 
devdraw for anyone who cares.

I had to make a small change to the build system required to make this work as 
well.  I had to add a -F/System/Library/PrivateFrameworks to the 9l script - 
where's the right place to do this for a single project?

Paul

Re: [9fans] Mac multi-touch mice and p9p acme anyone?

[Paul Lalonde]

Yes.  It's a mod to devdraw that re-interprets mouse-down to mean "read the 
virtual buttons" and passes those along.  The hardest part is adjusting the 
"landing zone" for the buttons - it turns out thirds isn't where I click :-)

It would be a good job throughout the desktop if I could figure out how to 
suppress delivery of the real button clicks (filter them out of the desktop 
event queue), but I've not managed that yet.

Paul

On 2009-11-27, at 8:35 AM, Eric Van Hensbergen wrote:

> Proper acme chords?  I futzed with it before with the previous apple mice and 
> couldn't get it to work.  This with the new multitouch mice?
> 
>-Eric
> 
> Sent from my iPhone
> 
> On Nov 26, 2009, at 1:58 AM, Paul Lalonde  wrote:
> 
>> I wound up with one of these today, and I just had to mess with it enough to 
>> get chording working through the multi-touch interfaces.  I have no idea how 
>> it behaves  on a trackpad, but the top 20% of my magic mouse is now 3 
>> separate buttons with reasonable tapping and chording behaviour.  I can tar 
>> up my new devdraw for anyone who cares.
>> 
>> I had to make a small change to the build system required to make this work 
>> as well.  I had to add a -F/System/Library/PrivateFrameworks to the 9l 
>> script - where's the right place to do this for a single project?
>> 
>> Paul
>> 
>> 
> 

Re: [9fans] GSoC proposal: Alternative window system

[Paul Lalonde]

Multiple displays and display & dpi awareness in acme would make my day!
Multi-display looks easy - we just need handling for adding a new "row",
which is already handily abstracted.

Fitt's law aware mouse movement would be nice too, particularly on large
screens.  You could slightly "trap" the mouse on narrow edges (scroll bars
and resize edges in particular) when the mouse is moving slowly.  Probably
a pain to tune, but would make acme much easier to use on large screens.

Paul


On Wed, Mar 19, 2014 at 12:02 PM, Bakul Shah  wrote:

> On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik  wrote:
> > For my project, I would build a tiling window manager similar to dwm
> > (what I use on Linux). I think a dwm-style interface that could be
> > controlled from the keyboard would provide a nice contrast to what we
> > already have with rio, and as we see from dwm the implementation of such
> > an interface needn't be complex. Development would involve modifying the
> > rio source code to implement the basic functions of a
> > tiling/keyboard-controlled window manager one by one.
>
> I will throw out some rio/acme related ideas. Hope people find
> them interesting enough to want to experiment.
>
> - display size aware (when attached to an external display vs
>   the builtin one of a laptop).
> - dpi aware (pick the right size font)
> - borderless windows (adjoining windows have different color)
>   (but edges are sensitive to resizing etc)
> - auto splitting of windows. The idea is to see if window size
>   fiddling can be minimized (ideally it should /learn/ personal
>   preferences)
> - allow the window with "focus" to be made much much larger to
>   help a user's focus (make other windows less distracting --
>   IIRC there was a web based spreadsheet that did that. Don't
>   recall its name).
> - allow windows to be scrolled in lockstep (in x, y or both
>   directions)
> - support for multiple displays
> - allow programmatic control of all this via a synthetic FS
>
> Not sure if there exists a usable unification of acme + rio
> but that would be nice.
>
>

Re: [9fans] [acme] Edit command -- More than one argument?

[Paul Lalonde]

We (Russ and I) never ported it back to Plan9 because there's a subtle
layout bug when columns have different height fonts for the tag and the
body.  I works well enough for us, but isn't at the quality it should be.

Paul

On Mon Oct 27 2014 at 3:57:01 PM Rob Pike  wrote:

> That's a shame.
>
> -rob
>
>
> On Mon, Oct 27, 2014 at 9:41 AM,   wrote:
> >> Yes you can. That's how I verified this works. Open up the tag to
> >> multiple lines (just type newline in the tag).
> >
> > I think this only works in p9p.
> >
> > sl
> >
>
>

Re: [9fans] [acme] Edit command -- More than one argument?

[Paul Lalonde]

What do you mean by resizing flicker?  I've never seen it with the
multi-line tags.  And we do resize the tag by hand - the scroll wheel opens
and shuts it, in addition to adding/removing the trailing newline.

On Mon Oct 27 2014 at 8:44:57 PM erik quanstrom 
wrote:

> On Mon Oct 27 19:39:19 EDT 2014, paul.a.lalo...@gmail.com wrote:
>
> > We (Russ and I) never ported it back to Plan9 because there's a subtle
> > layout bug when columns have different height fonts for the tag and the
> > body.  I works well enough for us, but isn't at the quality it should be.
>
> the layout is tricky.  and it's hard to prevent resizing flicker.  perhaps
> forcing
> the user to resize the tag by hand might be smoother.
>
> better yet, i'd love to see acme extended to the point where an external
> program could provide
> a sam(1)-style window rather than fiddling with the tag.
>
> - erik
>
>

Re: [9fans] [acme] Edit command -- More than one argument?

[Paul Lalonde]

Yes, the scroll wheel forward expands to the full size, and backwards
reduces it to one line; this is as designed, and only on the wheel for lack
of a better UI idea.
I can't say that it has any amount of documentation or discoverability :-(

I see what you mean about the "jitter" on expand contract.  I can't think
of a way to handle, but if I ever open the source again I'll think about
some sort of hysteresis.

Paul

On Tue Oct 28 2014 at 3:55:39 PM erik quanstrom 
wrote:

> On Mon Oct 27 23:49:06 EDT 2014, paul.a.lalo...@gmail.com wrote:
>
> > What do you mean by resizing flicker?  I've never seen it with the
> > multi-line tags.  And we do resize the tag by hand - the scroll wheel
> opens
> > and shuts it, in addition to adding/removing the trailing newline.
>
> i didn't realize there was the scroll wheel trick.  it doesn't work when
> the tag is empty, or allow one to expand the tag window larger than the
> current tag.
>
> what i mean by "flicker" is that if i modify a file which has
> a tag line that is close to wrapping, then modifying the file
> will often make the tag line too long, and wrapping.  Undo
> has the opposite effect.
>
> - erik
>
>

Re: [9fans] easier refreshing of acme wins

[Paul Lalonde]

The feature direction I'd like when working with Git is for the window of a
git-changed file to become un-editable.  This would require adding the idea
of a un-editable window, which is probably a bad idea.

Meanwhile I use the script below to generate X commands to reload changed
windows.  If I had a little more gumption (and less fear) I'd pipe the last
output to make acme execute the Edits.

#!/bin/bash
cd `git rev-parse --git-dir`/..
git diff --name-only HEAD~ | sed s+^+`pwd`/+ | sort > /tmp/foobar
9p read acme/index | awk '{print $6}' | sort | comm -12 - /tmp/foobar  |
sed 's+\(.*\)+Edit X=\1=,r+'


On Thu, Mar 26, 2015 at 9:36 AM Bakul Shah  wrote:

> What if you watch all tag lines and when a git controlled file is opened
> in a window, you the watch file for changes and when it changes put
> something in a new window that you can just select and middle click?
>
> > On Mar 26, 2015, at 9:02 AM, Mathieu Lonjaret <
> mathieu.lonja...@gmail.com> wrote:
> >
> > Hi,
> >
> > I work with many git branches, often affecting the same files. And I
> > also happen to jump from one to the other quite frequently. There
> > could be a problem with my workflow, but let's pretend there isn't.
> >
> > When one of said files is already open in acme, the win won't
> > automatically refresh it and that's ok, I certainly wouldn't want that
> > anyway, because I don't always to refresh them all.
> >
> > However, I find it a bit tedious that I have to write (or paste)
> > myself the Get tag for each of the wins I want to refresh. To the
> > point that I'm thinking of hardcoding the Get tag as one of the
> > "permanent" tags for a win.
> >
> > Before I do that, does anyone have a better solution to suggest? The
> > best would be that the Get tag gets automatically added to the tag bar
> > whenever the files are changed (by git checkout, or other).
> >
> > p9p acme btw.
> >
> > Thanks,
> > Mathieu
> >
>
>

Re: [9fans] using git

[Paul Lalonde]

I'd like to hear it too - much to learn from others' process.
Paul

On Sat, Mar 28, 2015 at 4:16 AM Charles Forsyth 
wrote:

>
> On 19 March 2015 at 18:26,  wrote:
>
>> Charles Forsyth  wrote:
>>
>> > On 19 March 2015 at 16:09,  wrote:
>> >
>> > > There is definitely some
>> > > learning curve and mindset change
>> >
>> > Just what I want from a little servant that's supposed to help me manage
>> > some file changes.
>>
>> Git is intended for something completely different than RCS.
>>
>> I really, REALLY, don't want to start a flame war, although this being
>> 9fans, it's probably not possible. More's the pity.
>>
>> And again, I AM NOT trying to proselytize.  But, if you are curious as
>> to what value I personally found in git for gawk development, I will be
>> happy to discuss it in personal email.
>
>
> Unfortunately, switching between different devices I missed this reply.
> I wasn't really comparing it to RCS although I can see that was a
> reasonable conclusion from my wording.
>
>
> It might be worthwhile sending a brief description of what you use and
> what you find valuable to the list.
> There isn't much traffic at the moment.
>

[9fans] Acme and Git

[Paul Lalonde]

I know I'm not the only acme user who uses Git extensively :-)
Is there some way to tell if a file is changed on disk that is open in an
editor window?  I frequently change branches and I often find myself
editing stale versions.  I notice when comes time to Put, but that's a bit
late.

Any tips to share?

Paul

Re: [9fans] Acme and Git

[Paul Lalonde]

Do you have a pointer to Russ's Watch?  I quick dig shows I have poor
Google-fu.
Paul

On Wed, Feb 15, 2017 at 12:23 PM Bakul Shah  wrote:

> May be use Russ'es Watch command?
>
> > On Feb 15, 2017, at 5:05 AM, Paul Lalonde 
> wrote:
> >
> > I know I'm not the only acme user who uses Git extensively :-)
> > Is there some way to tell if a file is changed on disk that is open in
> an editor window?  I frequently change branches and I often find myself
> editing stale versions.  I notice when comes time to Put, but that's a bit
> late.
> >
> > Any tips to share?
> >
> > Paul
>
>
>

Re: [9fans] Acme and Git

[Paul Lalonde]

I'll give Watch and a bit of scripting a shot.  I couldn't find a git "HEAD
changed" hook to tie to, so Watch is pretty much the right thing.

Thanks!

On Wed, Feb 15, 2017 at 9:04 PM Erik Quanstrom 
wrote:

> try writing the file?  😀
>
> On Feb 15, 2017 5:05 AM, Paul Lalonde  wrote:
>
> I know I'm not the only acme user who uses Git extensively :-)
> Is there some way to tell if a file is changed on disk that is open in an
> editor window?  I frequently change branches and I often find myself
> editing stale versions.  I notice when comes time to Put, but that's a bit
> late.
>
> Any tips to share?
>
> Paul
>
>
>

Re: [9fans] Acme Edit to remove lines

[Paul Lalonde]

x/^X.*\n/d
Or
x/^X/+-d

Away from a terminal so probably subtly wrong.
On Fri, May 26, 2017 at 7:23 AM dexen deVries 
wrote:

> given multi-line dot, spanning only part of a file, how do i construct
> an Edit command to remove lines matching certain regular expression?
>
> wanted to delete lines starting with one particular character; without
> leaving an empty line behind, thus Edit s/X.+//d is not sufficient.
>
>

Re: [9fans] It looks like our GSoC application was rejected

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The required introspection is about how we function as an open source  
community, I suspect.
We don't fit the usual open source mold, and generally cooperate  
quite poorly with one another (with some notable exceptions).
Our projects aren't particularly well integrated, and don't lead in a  
coherent directions.


Probably they made the right decision, unless we choose to address  
these issues.  We might not *want* to address these issues, but we  
should be aware of them.


Paul

On 18-Mar-08, at 9:26 AM, Iruata Souza wrote:



On Tue, Mar 18, 2008 at 12:32 PM, Skip Tavakkolian  
<[EMAIL PROTECTED]> wrote:
perhaps a little introspection is needed.  was it that they didn't  
like

 the proposals this year or that they didn't like the outcome of last
 year's effort?

 or maybe they just want to spread their love.



last year's big problem was the number of failed projects, not the
effort made by the organization.



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH3/a0pJeHo/Fbu1wRAruXAKC28cziwYbjKzMuv3+XA2LVjzTXNACguAV6
OquW4Z+MVv4lJ5C5nnqt9nI=
=s+eo
-END PGP SIGNATURE-

Re: [9fans] silliness in flight: build a desktop calculator with srv and rio

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ok, so this is really neat.  How do I do it in inferno?  What's the  
equivalent of /srv?


Paul

On 31-Mar-08, at 4:02 PM, ron minnich wrote:


On Mon, Mar 31, 2008 at 3:43 PM, Federico G. Benavento
<[EMAIL PROTECTED]> wrote:

what about:
 % dc <[0=1] | echo 0 > /srv/desk



well I knew somebody would tell me how to do this. Damn. Nice.

ron



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH9m3+pJeHo/Fbu1wRAgAiAJ0Xw7Fy2oPUxcMWqunYcwSTCA/16wCgsq3O
2xqyuBuxSZZWT2qkD+GPX2M=
=+M18
-END PGP SIGNATURE-

Re: [9fans] A shot in the dark

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

FWIW, we used a similar technique just last summer debugging some PS3  
code.  The dev system is kind enough to include 4 front panel lights  
and a very lightweight API for setting them.  We wound up "printing"  
out the program counter during a deadlock by mashing too many calls  
to set the lights into the suspect areas.


I miss hardware debuggers.

Paul

On May 27, 2008, at 5:06 PM, Digby Tarvin wrote:


Don't know where to find that paper, but it reminds of a friend
at UNSW (in Sydney) that used to instrument the OS9 kernel by setting
and clearing bits in the parallel port.

The monitoring hardware was indeed simple - an analogue voltmeter
connected to the bit of interest to produce a simple but effective
short term average.

For example, a bit that is cleared when in the system idle loop
produced a 'tacho' style analogue load meter.

That must have been in the early 80's, but I still find the parallel
interface a good method of getting real-time diagnostics, or front
panel style indicators for statuses such as system/user mode.
Consequently I don't welcome the current trend toward optimising
them out of new hardware. USB parallel interfaces may be ok for
driving printers, but they are no substitute if you want a very low
overhead, low latency i/o mechanism.

Regards,
DigbyT

On Tue, May 27, 2008 at 06:54:58PM -0400, Pietro Gagliardi wrote:

No, I wasn't around that time :-) But I was looking for the Hello
World X11 paper a while back, which was pre-website USENIX. But on  
the

USENIX website it seems that you can purchase papers from before
1991(?). Perhaps they had a paper?

On May 27, 2008, at 6:02 PM, ron minnich wrote:


OK, this is a long shot, but i'm running out of ideas.

Long, long ago, at a Usenix, I saw a talk by some adventurous
australians (are there any other kind?). It was concerning some neat
hardware designed for kernel monitoring.

They had done a very neat hack. Basically, they modified the C
compiler so that, on function entry and exit, the code would emit a
16-bit quantity to the parallel port. They had some simple  
hardware to

grab the data.

WIth this, they were able to get some nice kernel performance  
numbers,

all for the (low at the time) cost of an outw to the parallel port.

OK, I have done some searching and can't find this. IIRC it was
pre-website usenix. I am going to UCB this week and may have time to
hunt it down in the paper archives, but ... just wondering ...  
anyone

else remember this?

thanks

ron





--
Digby R. S. Tarvin  digbyt 
(at)digbyt.com

http://www.digbyt.com



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFIPMllpJeHo/Fbu1wRAtBGAJ49Ngab2WyOW+bYQ0wiUmJrqBKyeACfYhhn
A9b4diGkwg2fiiLyjXVWIGY=
=3r1V
-END PGP SIGNATURE-

Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

[Paul Lalonde]

On 15-Jul-08, at 1:01 AM, Bakul Shah wrote:


I suspect a lot of this complexity will end up being dropped
when you don't have to worry about efficiently using the last
N% of cpu cycles.


Would that I weren't working on a multi-core graphics part...  That N%  
is what the game is all about.



When your bottleneck is memory bandwidth
using core 100% is not going to happen in general.


But in most cases, that memory movement has to share the bus with  
increasingly remote cache accesses, which in turn take bandwidth.   
Affinity is a serious win for reducing on-chip bandwidth usage in  
cache-coherent many-core systems.



 And I am
not sure thread placement belongs in the kernel.  Why not let
an application manage its allocation of h/w thread x cycle
resources?  I am not even sure a full kernel belongs on every
core.


I'm still looking for the right scheduler, in kernel or user space,  
that lets me deal with affinitizing 3 resources that run at different  
granularities: per-core cache, hardware-thread-to-core, and cross-chip  
caches.  There's a rough hierarchy implied by these three resources,  
and perfect scheduling might be possible in a purely cooperative  
world, but reality imposes pre-emption and resource virtualization.



Unlike you I think the kernel should do even less as more and
more cores are added.  It should basically stay out of the
way.  Less government, more privatization :-)  So may be
the plan9 kernel would a better starting point than a Unix
kernel.


Agreed, less and less in the kernel, but *enough*.  I like resource  
virtualization, and as long as it gets affinity right, I win.


Paul

Re: [9fans] Plan 9 and multicores/parallelism/concurrency?

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Jul 17, 2008, at 12:29 PM, Bakul Shah wrote:

My reasoning was that more and more
cores can be (and will be) put on a die but a corresponding
increase in off chip memory bandwidth will not be possible so
at some point memory bottleneck will prevent 100% use of
cores even if you assume ideal placement of threads and no
thread movement to a different core.


As the number of cores increases you have to hugely increase the  
amount of cache - you need cache enough for a large enough working  
set to keep a core busy during the long wait for its next slice of  
bandwidth (figurative slice - the multiplexing clearly should finer  
grained).  Latency hiding on those fetches is critically important.




I was certainly not suggesting moving threads around.  I was
speculating that as the number of cores goes up perhaps the
kernel is not the right place to do affinity scheduling or
much any sophisticated scheduling.


Largely agreed.  The real tension is in virtualizing the resources,  
which beats against affinity.  Affinity is clearly an early loser in  
oversubscribed situations, but it would be a major win to have a  
scheduler (in or out of kernel) that could degrade intelligently in  
the face of oversubscription, instead of the hard wall you get when  
you throw away affinity.



Some friends of mine are able to sqeeze a lot of parallelism
out supposedly hard to parallelize code.  But this is in a
purely cooperative worlds where they assume threads don't
move and where machines are dedicated to specific tasks.


Envy.

The other part not to forget about is data-parallel.  At least in  
graphics we get to recast most of our heavy loads to data-parallel,  
which has huge benefits.  If you can manage data-parallel with a nice  
task DAG and decent load-balancing you can do wonders at keeping data  
on-chip while pushing lots of flops.


Paul, patiently awaiting hardware announcements so he can talk freely.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFIgA6hpJeHo/Fbu1wRAvZUAJ0WxfsfPHZJSclLwhgLj8ibkdgDiwCgx80y
7WT72MW7TsELUwi7jSATr/8=
=5nHw
-END PGP SIGNATURE-

Re: [9fans] mmap

[Paul Lalonde]

Roman V. Shaposhnik wrote:

Personally, my
experience of trying to use mmap() as a useful abstraction for the
CPU's MMU was the last straw. It can't do even that reliably
and in a portable fashion. Not to digress, but I was even more surprised
to learn that there's not a single API on UNIX that can:
http://thread.gmane.org/gmane.os.netbsd.devel.kernel/6392/focus=6457
  


Amen.  I've had to get our OS team to shoehorn in some remap() calls 
that let me point two(many) virtual addresses to a common physical 
address.  It's disgusting that the process for doing this with mmap 
requires /proc/#/mem and other scary things.


Does anyone have pointers to *nice* interfaces for doing this?  I don't 
care which OS, but I'd like to not have the implementation I'm 
requesting suck because I missed some gotchas that someone else already hit.


Thanks,
   Paul

Re: [9fans] image/memimage speed

[Paul Lalonde]

Minor gripe as a graphics person - I loathe frames per second as a  
performance measure.  Because of the inverse you can't really compare  
the numbers.  Consider the difference in improvement between 1fps and  
2fps compared to 29fps and 30fps.  Both improve by 1fps, but they  
represent dramatically different performance gains.


If you can at all, report milliseconds per frame, ideally with fixed  
system overhead removed.


The only time fps is appropriate is if you're targetting your v-blank  
rate.


Yes, I've been reviewing too many papers with bar charts of gps  
measures lately...


Paul

On Nov 30, 2008, at 6:35 PM, erik quanstrom <[EMAIL PROTECTED]>  
wrote:





can you report timings on the xscreensaver hacks (link at bottom)?


sure.  a few of the programs didn't seem to work (delayscreen
and polydominoes).  mountain, sphere and spirograph seemed
to hum right along.

- erik

; cat '#P/archctl'
cpu AMD64 2604 pge
pge on
coherence mfence
cmpswap cmpswap486
i8253set on

; cat /dev/wsys/^`{cat /dev/winid}^/wctl
60 505 7651034 current visible

8.anemone: fps: 30.796417
8.anemotaxis: fps: 25.595581
8.attraction: fps: 55.993117
8.blaster: fps: 71.190817
8.boxfit: fps: 20.596372
8.ccurve: fps: 0.999865
8.cloudlife: fps: 22.795733
8.coral: fps: 70.787094
8.critical: fps: 151.975499
8.decayscreen: fps: 0.00
8.deco: fps: 0.199968
8.deluxe: fps: 14.197528
8.demon: fps: 379.542993
8.discrete: fps: 17.997126
8.drift: fps: 8.998634
8.eruption: fps: 25.996981
8.euler2d: fps: 43.295463
8.fadeplot: fps: 51.393631
8.flame: fps: 7.598581
8.flow: fps: 45.593024
8.fluidballs: fps: 13.798253
8.forest: fps: 8.598666
8.fuzzyflakes: fps: 41.790739
8.galaxy: fps: 160.172456
8.glenda: fps: 46.295627
8.halftone: fps: 18.597379
8.helix: fps: 0.399954
8.hopalong: fps: 414.148296
8.hypercube: fps: 34.194590
8.hyperglenda: fps: 30.996313
8.ifs: fps: 37.993663
8.imsmap: fps: 0.199964
8.interaggregate: fps: 9.198770
8.interference: fps: 5.599390
8.julia: fps: 45.392443
8.lyap: fps: 45674.831450
8.maze: fps: 1.199848
8.moire: fps: 0.999855
8.mountain: fps: 31790.873361
8.munch: fps: 0.199971
8.nerverot: fps: 26.795984
8.pacman: fps: 59.190800
8.pedal: fps: 0.599921
8.petri: fps: 76.190348
8.pyro: fps: 305.364824
8.rd-bomb: fps: 32.995072
8.ripples: fps: 27.196419
8.rorschach: fps: 0.00
8.rotzoomer: fps: 34.194205
8.scrdump: fps: 0.00
8.sierpinski: fps: 46.592159
8.slip: fps: 1.799762
8.sphere: fps: 647.526941
8.spirograph: fps: 23604.015568
8.squiral: fps: 2129.662538
8.starfish: fps: 49.190284
8.strange: fps: 47.992470
8.substrate: fps: 0.00
8.swirl: fps: 551.526029
8.thornbird: fps: 28.196393
8.triangle: fps: 66.588276
8.vermiculate: fps: 1357.648605
8.vines: fps: 87.190306
8.wander: fps: 51699.256387
8.whirlwindwarp: fps: 55.592024
8.wormhole: fps: 32.196066
8.zoom: fps: 2.399737

Re: [9fans] image/memimage speed

[Paul Lalonde]

Again, you can stream a whole frame buffer reasonably fast - that should 
be nearly full-rate; it should be full rate if you pre-fetch with 
sufficient advance notice (500-1000 clocks), or DMA.  But random access 
reads *have* to be slow: you get a stall while the system goes to PCIe 
for each cache line you attempt to read from. 


Paul

ron minnich wrote:

On Fri, Dec 5, 2008 at 10:32 AM, Russ Cox <[EMAIL PROTECTED]> wrote:

  

To a first approximation, no one reads directly from video memory.



That is certainly true, but it's been a concern for some time for GPU
computing, and the chipset folks are paying attention.

ron

  

Re: [9fans] image/memimage speed

[Paul Lalonde]

But random access patterns suck at being speculatively cached.
Linear access patterns still require reasonably careful work for the 
caching to do the right thing.
Expecting your entire frame buffer to be cached in L2 isn't particularly 
reasonable.


Paul

erik quanstrom wrote:

On Fri Dec  5 14:23:22 EST 2008, [EMAIL PROTECTED] wrote:
  
Again, you can stream a whole frame buffer reasonably fast - that should 
be nearly full-rate; it should be full rate if you pre-fetch with 
sufficient advance notice (500-1000 clocks), or DMA.  But random access 
reads *have* to be slow: you get a stall while the system goes to PCIe 
for each cache line you attempt to read from. 


Paul



the cpu is allowed to speculatively cache WC memory.

- erik

  

Re: [9fans] image/memimage speed

[Paul Lalonde]

I'll try to track down an actual PCIe card rather than a simulator and  
run down some numbers on Monday.


Paul

On 5-Dec-08, at 12:11 PM, ron minnich wrote:



On Fri, Dec 5, 2008 at 11:30 AM, Paul Lalonde <[EMAIL PROTECTED]>  
wrote:

But random access patterns suck at being speculatively cached.
Linear access patterns still require reasonably careful work for  
the caching

to do the right thing.
Expecting your entire frame buffer to be cached in L2 isn't  
particularly

reasonable.



I'm pretty sure we can put some #s on this discussion. It's too  
fuzzy for me.


Forget speculative reads, for now. Paul, what kind of time are you
seeing on your measurements to load a cache line over pcie from a
card?

ron

Re: [9fans] graphics scaling

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Have the scrolling tags been ported into the mainline p9 yet?  That's  
the main reason I still spend most of my time in P9P and SAC.


Paul (who hasn't yet managed to get his hands on an Intel PCIe  
graphics adapter of any sort - frustr.  It's as if this company  
specialized in integrated parts or something.)


On Dec 22, 2008, at 9:14 AM, Brian L. Stuart wrote:


 For that matter, it's been a while
since I last used the p9p acme.  I've been doing more
and more from 9vx.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJT9VapJeHo/Fbu1wRAqeAAJ0QquoxviDmIb/XFDW1OqMhJIYsBwCgvyaN
BZuBdOAsh3zZ2sa990A/YUk=
=MHmD
-END PGP SIGNATURE-

Re: [9fans] Acme scrolling tags (was Re: graphics scaling)

[Paul Lalonde]

That differs from my experience - I usually run 3 columns on a 30"  
monitor, with tags open to two lines for most of my active windows;  
the second line typically has an Edit command lying around because you  
can't effectively 2-1 chord Edits.  The extra length is also useful  
for dealing with the obscenely deep tree our development happens in  
(Really, it was easier to fix the editor than to get the rest of the  
team to move to a saner tree structure, aggravated by cross-platform/ 
cross-compile/cross-toolchain requirements that cause a 3 way cross  
product of both build and some sources.  If only the world had been  
sold on Plan9 in 1993).


I use a mouse with a big click-able scroll wheel (yes, the cheap Dell  
ones) that lets me do my button 2 clicks well enough, but also let me  
scoll through my windows and tags - I find tag collapse and expansion  
really nice with the scroll wheel.


Paul

On 22-Dec-08, at 11:42 AM, erik quanstrom wrote:



On Mon Dec 22 13:57:35 EST 2008, r...@swtch.com wrote:

not ported.  i'm glad that that hasn't been ported back.
i find multi-line tags annoying 10 times for each time they
are useful.


is this an abstract assertion or have you actually tried them?

russ


i've used them for quite some time with p9p.  i liked them at
first, but it didn't wear as well as i thought it would for me.
tags can be close to the length of the line and cause a second
line to appear and disappear.  i find that annoying and it
happens more often than i need a long tag.  esc esc then
jolts things back the way they were.

- erik

Re: [9fans] Acme scrolling tags (was Re: graphics scaling)

[Paul Lalonde]

The P9P version has this too: acme -$
But that still doesn't address ease of Edit commands or tags full of  
build config strings and other crap.  Yes, I've been relying more on  
tags than guide files of late.


Paul

On 23-Dec-08, at 10:54 AM, erik quanstrom wrote:




(Really, it was easier to fix the editor than to get the rest of the
team to move to a saner tree structure, aggravated by cross-platform/
cross-compile/cross-toolchain requirements that cause a 3 way cross
product of both build and some sources.  If only the world had been
sold on Plan9 in 1993).


wily being from and of the unix environment
will substitute $fu for /some/long/string.

- erik

Re: [9fans] i7

[Paul Lalonde]

erik quanstrom wrote:

it seems that core i7's work just dandy with plan 9,
even resample seems  just a tad pokey. :-)
  
If only the motherboard my two were plugged into wasn't a the bleeding 
edge of design :-(


Paul

Re: [9fans] Acme huge bar

[Paul Lalonde]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

When I did the expanding tags I wound up choosing to leave them black  
since they aren't part of any frame.


Not totally satisfactory, but the layout logic was baroque enough  
that disturbing it further didn't  make much sense.


I know that a few others have improved that code since I first  
submitted it, and might have more feedback.


Paul

On Feb 27, 2009, at 10:45 AM, Anthony Sorace wrote:


doesn't address whether the gap should be black or not, but that's why
it exists.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFJqJe2pJeHo/Fbu1wRAiMQAJwKgBpLx231NVIwHMEh/3TKFk/SPgCcDT5S
ycFRw3uRxZOF5y0ZSwVCop4=
=MvLX
-END PGP SIGNATURE-

Re: [9fans] IWP92020 Announcement

[Paul Lalonde]

This would totally happen in Waterloo right after I moved away!

Paul

On Mon., Jan. 13, 2020, 6:18 p.m. ,  wrote:

> IWP92020 is happening. Submit papers and sign up here:
> 
> http://iwp9.org
> 
> Hope to see you there!
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7db458ccd8ef1400-M7e64e76ea95f3931ffb08f01
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Jim McKie

[Paul Lalonde]

That's sad news indeed.  I haven't seen him in ten years, but always
enjoyed his wry humor. He always made me feel welcome on the community.

Paul

On Wed., Jun. 24, 2020, 5:37 p.m. Charles Forsyth, <
charles.fors...@gmail.com> wrote:

> I am sorry to say that Jim McKie (jmk) died suddenly on 16 June.
> https://www.ippolitofuneralhomes.com/obituaries/James-B-McKie?obId=15111702&fbclid=IwAR3d7aHZXEOhYz-ciOrQPh-W1eMw-_8MHiCUdeKOxzLBEI6VGHsSn4aTjdk
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td73b359f9dc68c15-M1029bee3a190301c26725c47
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Can compile Plan9 C compiler for windows10?

[Paul Lalonde]

You're now asking a question of ABI (application binary interface) more
than of the compiler.  The ABI is the hard part - what the calling
conventions are, linkage and executable formats, etc, which vary
significantly from system to system.  You may find a way to compile the
compiler so it runs in Windows, but it will keep making (to a first
approximation) binaries for Plan 9.

Paul

On Sun, Mar 28, 2021, 6:16 AM  wrote:

> uh inferno's 8c compiles .exe file?
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T4d77cc95ab4ed70c-M282840a91d42fc4c34ab4a27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Alternative to fine-grained mouse usage?

[Paul Lalonde]

There's a huge difference using my mouse in Plan9 than in Plan9port on my
mac.  Plan9 feels almost unusable by comparison.  I suspect much of this is
the very finely tuned acceleration/fine-pointing behavior of the mouse on
modern desktop platforms.
That's probably a ripe space for improving the Plan9 user experience.

I wish there were better accessibility solutions for Plan9 as regards the
mouse.  That's likely another ripe area for tuning - taking advantage of
Fitts' law in UI interactions (with a real acceleration/precision model)
would be nice.  There's few enough UI elements in our toolkit that it might
even be feasible to do as a hobbyist.

Paul

On Wed, Jun 30, 2021 at 7:53 PM  wrote:

> > needing to copy/paste previous commands in terminal windows, etc.
> 
> see " and "" scripts
> 
> The finnicky mouse stuff is indeed an annoyance in acme.  I use sam &
> a trackball & a huge font.  some conveniences have been added to sam,
> ^B and ^G to switch from sam window and back to buffer.  Make use of
> <>!| commands and so on...  standard ^W ^U ^A ^E stuff...  plumbing,
> searching, command language.  rio window placement mostly automated.
> I have sam just open files fullscreen automatically, which is quite nice…
> 
> umbraticus

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T716c5aa0e2aa8a27-Ma67e1972b37912dac460dfc1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Searching sam for text

[Paul Lalonde]

I occasionally do (in acme, sam MMV)
,x/open/+-{
p
}

It separates the match from the address by a newline, but works well enough
for my needs.


On Mon, Aug 2, 2021 at 9:39 AM  wrote:

> In sam if I invoke ,x g//+-p sam prints out the hits in the sam
> window by lines. I was wondering if there is a way of going from any of
> those search results directly to the line in the document where the string
> occurs?
>
>
>
>
> *9fans * / 9fans / see discussions
>  + participants
>  + delivery options
>  Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T6d4564e82d943342-Md02d6d75af44d1f300cf5be1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Paul Lalonde]

I'd love to see  GPU support for Plan9.  This discussion falls right into
my professional capacity.  I'll say that people generally *grossly*
underestimate the complexity of a modern GPU and of its supporting software
stack.  The GPU driver is effectively a second operating system with shared
memory and DMA interfaces to the host.  Even bringing up a modern GPU for
just compute tasks is a very large endeavour.

That being said, if you want real hardware support, the best place to start
is currently AMD's open-source stack.  Ignoring the Vulkan bit,
understanding their platform abstraction layer (PAL) and shader ISA (
https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
is the base.  The lower hardware levels are reasonably well-described in
linux's libdrm and its AMD support in amdgpu.

Opinions on how to bring this to Plan9?  I don't really have any - it's a
huge pile of work with minimal benefit.  If you're looking for lightweight
graphics, WebGL is a doable path, and almost certainly the right way to
experiment with Plan9-like interfaces to graphics hardware.

Paul



On Sun, Aug 22, 2021 at 5:30 AM sirjofri 
wrote:

>
> 22.08.2021 14:10:20 Stuart Morrow :
> > Also:
> >> people have discussed that for years
> >
> > They have?  I mean I might have seen occasionally someone vaguely
> > going "some sort of GPU support would be cool to have".  That isn't
> > discussion.
> 
> I've even heard of someone actually making GPU stuff work on plan 9. I've
> only heard from their partner, who made a cute glenda thing on a piece of
> cloth. I chatted with her a little and told her she should encourage her
> partner for some discussion about this in our channels. It looked like
> it's some academic work, but I don't know any details about it.
> 
> Worst case, someone already has a proper and good GPU implementation for
> Plan 9 and nobody knows about it.
> 
> sirjofri
> 
> Btw if the said person reads this: it would be nice to learn some
> details.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M5f5fc3eff26e802047dbc69d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Paul Lalonde]

It got complicated because there's no stable interface or ISA.  The
hardware evolved from fixed-function to programmable in a commercial
environment where the only meaningful measure was raw performance per
dollar at many price points.  Every year the hardware spins and becomes
more performant, usually faster than Moore's law.  With 3D APIs hiding the
hardware details there is no pressure to make the hardware interface
uniform, pretty, or neat.  And with the need for performance there are
dozens of fixed function units that effectively need their own sub-drivers
while coordinating at high performance with the other units.
The system diagrams for GPUs look complex, but they are radical
simplifications of what's really on the inside.

Intel really pioneered the open driver stacks, but performance generally
wasn't there.  That might be changing now, but I don't know if their
recently announced discrete product line will be driver-compatible.

Paul


On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah  wrote:

> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the
> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+
> lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to
> be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or
> less unchanged (FreeBSD has shim code to use it). How did the interface to
> an SIMD processor get so complicated?
>
> On Aug 22, 2021, at 6:44 AM, Paul Lalonde 
> wrote:
>
> I'd love to see  GPU support for Plan9.  This discussion falls right into
> my professional capacity.  I'll say that people generally *grossly*
> underestimate the complexity of a modern GPU and of its supporting software
> stack.  The GPU driver is effectively a second operating system with shared
> memory and DMA interfaces to the host.  Even bringing up a modern GPU for
> just compute tasks is a very large endeavour.
>
> That being said, if you want real hardware support, the best place to
> start is currently AMD's open-source stack.  Ignoring the Vulkan bit,
> understanding their platform abstraction layer (PAL) and shader ISA (
> https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
> is the base.  The lower hardware levels are reasonably well-described in
> linux's libdrm and its AMD support in amdgpu.
>
> Opinions on how to bring this to Plan9?  I don't really have any - it's a
> huge pile of work with minimal benefit.  If you're looking for lightweight
> graphics, WebGL is a doable path, and almost certainly the right way to
> experiment with Plan9-like interfaces to graphics hardware.
>
> Paul
>
>
>
> On Sun, Aug 22, 2021 at 5:30 AM sirjofri 
> wrote:
>
>>
>> 22.08.2021 14:10:20 Stuart Morrow :
>> > Also:
>> >> people have discussed that for years
>> >
>> > They have?  I mean I might have seen occasionally someone vaguely
>> > going "some sort of GPU support would be cool to have".  That isn't
>> > discussion.
>> 
>> I've even heard of someone actually making GPU stuff work on plan 9. I've
>> only heard from their partner, who made a cute glenda thing on a piece of
>> cloth. I chatted with her a little and told her she should encourage her
>> partner for some discussion about this in our channels. It looked like
>> it's some academic work, but I don't know any details about it.
>> 
>> Worst case, someone already has a proper and good GPU implementation for
>> Plan 9 and nobody knows about it.
>> 
>> sirjofri
>> 
>> Btw if the said person reads this: it would be nice to learn some
>> details.
>
>
>
> -- Bakul
>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M8658a330dbb6ca9a6e216777>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M1a557f299e542dc652b550b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Drawterm GPU (was: Software philosophy)

[Paul Lalonde]

I'm pretty sure we're still re-inventing, though it's the CPU's turn to
gain some of the complexity of the graphics engine.

Paul

On Sun, Aug 22, 2021, 12:05 PM Bakul Shah  wrote:

> Thanks. Looks like Sutherland's "Wheel of Reincarnation
> <https://www2.cs.arizona.edu/~cscheid/reading/myer-sutherland-design-of-display-processors.pdf>"
> has not only stopped but exploded :-) Or stopped being applicable.
>
> -- Bakul
>
> On Aug 22, 2021, at 9:23 AM, Paul Lalonde 
> wrote:
>
> It got complicated because there's no stable interface or ISA.  The
> hardware evolved from fixed-function to programmable in a commercial
> environment where the only meaningful measure was raw performance per
> dollar at many price points.  Every year the hardware spins and becomes
> more performant, usually faster than Moore's law.  With 3D APIs hiding the
> hardware details there is no pressure to make the hardware interface
> uniform, pretty, or neat.  And with the need for performance there are
> dozens of fixed function units that effectively need their own sub-drivers
> while coordinating at high performance with the other units.
> The system diagrams for GPUs look complex, but they are radical
> simplifications of what's really on the inside.
>
> Intel really pioneered the open driver stacks, but performance generally
> wasn't there.  That might be changing now, but I don't know if their
> recently announced discrete product line will be driver-compatible.
>
> Paul
>
>
> On Sun, Aug 22, 2021 at 8:48 AM Bakul Shah  wrote:
>
>> The FreeBSD amdgpu.ko is over 3Mbytes of compiled code. Not counting the
>> "firmware" that gets loaded on the GPU board. drm/amd/amdgpu has 200K+
>> lines of source code. drm/amd over 2M lines of code. Intel's i915 seems to
>> be about 1/10th the amd size. AIUI, this is linux GPU driver code, more or
>> less unchanged (FreeBSD has shim code to use it). How did the interface to
>> an SIMD processor get so complicated?
>>
>> On Aug 22, 2021, at 6:44 AM, Paul Lalonde 
>> wrote:
>>
>> I'd love to see  GPU support for Plan9.  This discussion falls right into
>> my professional capacity.  I'll say that people generally *grossly*
>> underestimate the complexity of a modern GPU and of its supporting software
>> stack.  The GPU driver is effectively a second operating system with shared
>> memory and DMA interfaces to the host.  Even bringing up a modern GPU for
>> just compute tasks is a very large endeavour.
>>
>> That being said, if you want real hardware support, the best place to
>> start is currently AMD's open-source stack.  Ignoring the Vulkan bit,
>> understanding their platform abstraction layer (PAL) and shader ISA (
>> https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf)
>> is the base.  The lower hardware levels are reasonably well-described in
>> linux's libdrm and its AMD support in amdgpu.
>>
>> Opinions on how to bring this to Plan9?  I don't really have any - it's a
>> huge pile of work with minimal benefit.  If you're looking for lightweight
>> graphics, WebGL is a doable path, and almost certainly the right way to
>> experiment with Plan9-like interfaces to graphics hardware.
>>
>> Paul
>>
>>
>>
>> On Sun, Aug 22, 2021 at 5:30 AM sirjofri 
>> wrote:
>>
>>>
>>> 22.08.2021 14:10:20 Stuart Morrow :
>>> > Also:
>>> >> people have discussed that for years
>>> >
>>> > They have?  I mean I might have seen occasionally someone vaguely
>>> > going "some sort of GPU support would be cool to have".  That isn't
>>> > discussion.
>>> 
>>> I've even heard of someone actually making GPU stuff work on plan 9.
>>> I've
>>> only heard from their partner, who made a cute glenda thing on a piece
>>> of
>>> cloth. I chatted with her a little and told her she should encourage her
>>> partner for some discussion about this in our channels. It looked like
>>> it's some academic work, but I don't know any details about it.
>>> 
>>> Worst case, someone already has a proper and good GPU implementation for
>>> Plan 9 and nobody knows about it.
>>> 
>>> sirjofri
>>> 
>>> Btw if the said person reads this: it would be nice to learn some
>>> details.
>>
>>
>>
>> -- Bakul
>>
>>
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
> <https://9fans.topicbox.com/groups/9fans> + participants
> <https://9fans.topicbox.com/groups/9fans/members> + delivery options
> <https://9fans.topicbox.com/groups/9fans/subscription> Permalink
> <https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M69dfd52c6b6d85727b06d9dc>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tad29bfc223dc4fbe-M6309d0d2644e0651e74b9901
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] porting projects...

[Paul Lalonde]

It does look like this would need raw mouse state to get the DX/Dy data
instead of absolute screen positions.

On Mon, Sep 6, 2021, 12:36 PM Stuart Morrow  wrote:

> On 06/09/2021, Skip Tavakkolian  wrote:
> > To be clear, the discussion is about sharing a Plan 9 term's
> > mouse/keyboard with non-Plan 9 machines/displays.
>
> I know. See previous post.
>
> > The usual way is to layer file-servers to build up the namespace that
> > you need.
> I know.
>
> > The extended (freerange?) mouse would keep track of off-screen
> > movement and forward them to clients.
> 
> How's it supposed use information the operating system doesn't give it.
> 
> When I have said /dev/mouse and screen in this thread, I've meant
> #m/mouse and the actual display.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M57c04c24bece9e2a94b3e355
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] porting projects...

[Paul Lalonde]

Do the other platforms do their own acceleration management?  That makes
you want to feed deltas instead of absolutes.

On Mon, Sep 6, 2021, 1:13 PM Stuart Morrow  wrote:

> On 06/09/2021, Paul Lalonde  wrote:
> > It does look like this would need raw mouse state to get the DX/Dy data
> > instead of absolute screen positions.
> 
> 
> You could detect when it's at the edge, make it invisible (as
> screenlock does), make it visible (on the box that doesn't have the
> mouse plugged in), and warp it to the centre so subsequent movements
> still give m-messages.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Td6b6b3e98268ecde-M8e1810d2216ae4d0ba3ac5c9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Script to apply Edit commands in acme

[Paul Lalonde]

You can, of course, execute multiple commands in one Edit, either lineline
or chroding the "{}" block:
Edit {
,x/a/c/b/
,x/d/c/e/
}


On Wed, Jan 18, 2023 at 8:46 AM Henri Ducrocq 
wrote:

> Here is a script I wrote to run any arbitrary command (Edit, Look, etc)
> in a window (current one by default):
>   https://gist.github.com/perpen/9902359ddf09b24129277ce121e3e86d
>
> E.g.: Aexe 'Edit ,blah'
>
> It's quite horrible, as it appends the command to the body to run it
> using an event (would have been simpler running the command from the
> tag, but there is race making that impossible iirc).
>
> I ended up not using it, so it is not much tested. And I wrote it for
> plan 9, not
> sure how that would work with plan9port.
>
> On Mon, Jan 16, 2023 at 9:06 AM  wrote:
> >
> > Great tips. Thank you. I had no idea I could run ed commands that way.
> > 9fans / 9fans / see discussions + participants + delivery options
> Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Taf408751bc6fb344-Mfc6d82c231782e86759f2c05
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Paul Lalonde]

The Bell Labs approach to source control was, I'm, weak.  It relied on
snapshots of the tree and out-of-band communication.  Don't forget how
small and tight-knit that development team was, and how valuable perfect
historic snapshots were.

Add that 40 years ago source code revision control systems were incredibly
primitive.  The idea of an atomic change set (in Unix land at least) was
revolutionary in the early 90s.

This is one place where 35 years of evolution in software practices has
very much improved.

Paul

On Thu, Apr 18, 2024, 8:55 a.m. certanan via 9fans <9fans@9fans.net> wrote:

> Hi,
> 
> is there any more "organic/natural" way to do source control on today's
> Plan9 (9front specifically), other than Ori's Git?
> 
> In other words, how (if at all) did people at Bell Labs and the community
> alike originally manage their contributions in a way that would allow them
> to create patches without much hassle?
> 
> Was it as simple as backing a source tree up, making some changes, and
> then comparing the two? Venti? Replica?
> 
> tom

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-M1b6d6751f6d830d2a70a696f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iwp9.org (Re: BibTex collections of all 4 proceedings)

[Paul Lalonde]

Both Vancouver and Seattle are trivially doable for me.
I'd offer our Victoria offices, but we're moving into unknown space at the end 
of August.

Paul

On 2010-05-07, at 6:09 AM, Eric Van Hensbergen wrote:

> On Thu, May 6, 2010 at 4:45 PM, ron minnich  wrote:
>> On Thu, May 6, 2010 at 2:21 PM, Skip Tavakkolian <9...@9netics.com> wrote:
 doesn't the weather get ugly in seattle about that time?
>>> 
>>> pick any two: cheap, pretty, convenient. ☺
>> 
>> I actually like seattle that time of year anyway.
>> 
>> Is seattle a one-hop place from Europe? I am sure it is from the
>> important spots on the pacific rim ... this is an interesting
>> suggestion!
>> 
> 
> OSDI is in Vancouver in October, might be more justifiable as a
> destination for academic folks if the workshop and the conference
> "adjoined" -- it would at least be down to a single airfare.
> 
> -eric
> 

Re: [9fans] other mouse buttons in drawterm on a one mouse button mac laptop under OS X

[Paul Lalonde]

It's easy to change and recompile.

Paul

On Tue, Sep 7, 2010 at 8:10 AM, EBo  wrote:

>
>
> >> Yes but drawterm doesn't agree: command (apple key) means right click
> >> and option means middle click.
> >
> > Oh, I see.  I'm not terribly inclined to change that.
> > Drawterm has used those keys for longer than there
> > has been OS X support and many people have that
> > muscle memory well trained.  It is also consistent
> > with plan9port.  I think that it's consistent with what
> > Plan 9 used to do too, but I might be misremembering.
> > (It looks like now there is a dedicated key for each button.)
>
> Is there some way that the user can set/map their personal preferences?
>
>  EBo --
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] other mouse buttons in drawterm on a one mouse button mac laptop under OS X

[Paul Lalonde]

You could intercept /dev/mouse on the cpu server and swap the buttons there
before starting rio.  That's per-user.

Paul

On Tue, Sep 7, 2010 at 1:14 PM, EBo  wrote:

>
>
> > It's easy to change and recompile.
>
> I should have stated "to reconfigure function keys without recompiling the
> system".  For the original posters needs this is likely the way to go, but
> I wondered about multi-user systems (if that is even meaningful with
> drawterm).
>
>  EBo --
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

[9fans] Buying a Guru Plug. Do I want/need the JTAG module too?

[Paul Lalonde]

I'd like to run it as a household control server, notwithstanding various
teething pains/devices.  If I fail too badly, I can probably coerce Linux to
do what I need.

Paul

-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

[9fans] 9vx and replica/pull on OS X

[Paul Lalonde]

I want to build a kw kernel, which caused me to want to update my 9vx
installation.
Have my file system on a case-sensitive remote mounted drive.
I'm getting essentially every file tagged as "locally modified; will not
update".
When a file is good, I get a warning that I can't set the uid; I can
probably live with that.
So I grabbed a fresh plan9.tar.bz2 from Russ's site, and tried it.  Same
thing.
What am I doing wrong?

Paul
-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] IWP9-2010 tentative schedule

[Paul Lalonde]

I'll be a bit late - the floats don't land on Lake Union until 10:00am at
this time of year, so I should just miss Geoff's talk :-(

I do wish my guruplug had arrived already.

Paul

On Sat, Oct 9, 2010 at 9:08 PM, Jeff Sickel  wrote:

>
> On Oct 9, 2010, at 10:26 PM, ron minnich wrote:
>
> > Bring any little fiddly cables that come to mind: I just realized I
> > don't have a dvi -> analog vga cable for my new mac pro. I don't know
> > if I can drive the projector.  Ethernet (short) cables. USB cables.
> > whatever.
>
> I'll pack an old dvi->vga adapter just in case.  I'm also bringing the new
> display port to vga for those new mac book pro users out there.
>
> -jas
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

[9fans] Trap in 5c compiling rc?

[Paul Lalonde]

I'm trying to build an arm userspace, and I'm dying building rc; 5c is dying
at /sys/src/cmd/5c/peep.c:1338, with joinsplit() having been called with
r=0x0.

I'm running from an old distro, but with today's sysfromiso by ron.

Any (non-null) pointers?

Paul



-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

I've rebuilt my x86 userspace, nuked, rebuilt objtype=arm, and still in rc,
bang.
I'm running on 9vx, so I can imagine some random interaction there (I can't
justify the power bills to keep a plan9 386 box going these days given the
frequency I use it).
An rc would let me move all this over to my plug and worry less, methinks.

Paul

On Sun, Dec 5, 2010 at 5:24 AM, erik quanstrom wrote:

> On Sun Dec  5 04:41:17 EST 2010, fors...@terzarima.net wrote:
> > >i'll see how those compare with sources.
> >
> > i can't get 5c to fail when compiling rc. ghostscript might be another
> matter;
> > i haven't tried that yet.
>
> at least on my openrd, everything in /sys/src/cmd
> compiles with no problems, including gs.
>
> - erik
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

Erik sorted me out - and our wee conversation made me remember that in the
presence of 'bind -b /sysfromiso /' it's important not to get the arguments
backwards.
Mea maxima culpa, apologies for the noise.

Paul

On Sun, Dec 5, 2010 at 8:16 AM, Paul Lalonde wrote:

> I've rebuilt my x86 userspace, nuked, rebuilt objtype=arm, and still in rc,
> bang.
> I'm running on 9vx, so I can imagine some random interaction there (I can't
> justify the power bills to keep a plan9 386 box going these days given the
> frequency I use it).
> An rc would let me move all this over to my plug and worry less, methinks.
>
> Paul
>
>
> On Sun, Dec 5, 2010 at 5:24 AM, erik quanstrom wrote:
>
>> On Sun Dec  5 04:41:17 EST 2010, fors...@terzarima.net wrote:
>> > >i'll see how those compare with sources.
>> >
>> > i can't get 5c to fail when compiling rc. ghostscript might be another
>> matter;
>> > i haven't tried that yet.
>>
>> at least on my openrd, everything in /sys/src/cmd
>> compiles with no problems, including gs.
>>
>> - erik
>>
>>
>
>
> --
> I'm migrating my email.  plalo...@telus.net will soon be disconnected.
>  Please use paul.a.lalo...@gmail.com from now on.
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

I got it clean, finally.  I had mis-mapped some pieces while updating my x86
userland, without which 5c crapped out a lot.

Next question: How do I build my plug kernel?  Among my early build
problems:
mk: no recipe to make 'devtwsi.5' in directory /sys/src/9/kw
../boot/libboot.a5 doesn't exist: assuming it will be an archive
mk: no recipe to make 'syscallfmt.5' in directory /sys/src/9/kw

I'm not finding current "how to build a kernel" bits anywhere :-(

Paul

On Sun, Dec 5, 2010 at 10:28 AM, ron minnich  wrote:

> Build went fine.
>
> On Sun, Dec 5, 2010 at 10:15 AM, ron minnich  wrote:
> > just a reminder, when I build from sysfromiso, on 9vx:
> >
> > cd sysfromiso
> > hg pull
> > hg up
> > bind sys/src /sys/src
> > bind sys/include /sys/include
> > cd /sys/src
> > objtype=arm
> > mk nuke
> > mk install
> >
> > I've used this to build bootable openrd kernels. I'm rerunning it now.
> > It always takes time because of gs, but gs is a great test. I'll
> > update with a note on how it went.
> >
> >
> > I just did a push from sources to the sysfromiso repo.
> >
> > ron
> >
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

Getting closer.  I still seem to be lacking syscallfmt.c which is called out
explicitly in the mkfile but isn't in sysfromiso.  The version in sys/pc
clearly won't work.

Paul

On Mon, Dec 6, 2010 at 7:51 PM, ron minnich  wrote:

> On Mon, Dec 6, 2010 at 5:54 PM, erik quanstrom 
> wrote:
> > On Mon Dec  6 20:14:54 EST 2010, rminn...@gmail.com wrote:
> >> On Mon, Dec 6, 2010 at 5:08 PM, Paul Lalonde 
> wrote:
> >> > I got it clean, finally.  I had mis-mapped some pieces while updating
> my x86
> >> > userland, without which 5c crapped out a lot.
> >> > Next question: How do I build my plug kernel?  Among my early build
> >> > problems:
> >> > mk: no recipe to make 'devtwsi.5' in directory /sys/src/9/kw
> >> > ../boot/libboot.a5 doesn't exist: assuming it will be an archive
> >> > mk: no recipe to make 'syscallfmt.5' in directory /sys/src/9/kw
> >> > I'm not finding current "how to build a kernel" bits anywhere :-(
> >> >
> >>
> >>
> >> The guys are always improving things :-)
> >
> > you can just chop twsi out of your kernel configuration and build.
> > i'd be happy to put a pre-built arm kernel out, too.
>
> I just committed a new sysfromiso with that file added.
>
> ron
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

sources!  It's really impressive how much can fall out of your head when you
haven't actually run plan9 for a couple of years.

I have a build, and tonight I should be able to actually try it!

Paul

On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom wrote:

> On Tue Dec  7 00:58:58 EST 2010, paul.a.lalo...@gmail.com wrote:
>
> > Getting closer.  I still seem to be lacking syscallfmt.c which is called
> out
> > explicitly in the mkfile but isn't in sysfromiso.  The version in sys/pc
> > clearly won't work.
>
> there is no current version in pc.  this is what you're intersted in
> ./port/syscallfmt.c
> ./kw/syscall.c
>
> - erik
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

I have a successful boot off my USB stick onto the Guru.

Now, how do I tell it to use the USB stick as a root filesystem?  I'm
guessing I'll want to have two partitions, one to hold the image and another
as a native P4 fs of some sort (if only to get case-sensitive filenames).
 How do I specify the later to the "root is from" prompt?

Paul

On Tue, Dec 7, 2010 at 8:39 AM, ron minnich  wrote:

> On Tue, Dec 7, 2010 at 8:26 AM, ron minnich  wrote:
> > On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom 
> wrote:
> >
> >> there is no current version in pc.  this is what you're intersted in
> >> ./port/syscallfmt.c
> >> ./kw/syscall.c
> >
> > Those are in now as well.
>
> or will be if the hg commit ever finishes ...
>
> ron
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

Oh dear, I spend too much time with Perforce (P4) these days.  I mean an
Plan9 fs, of course.

Paul

On Tue, Dec 7, 2010 at 8:26 PM, Paul Lalonde wrote:

> I have a successful boot off my USB stick onto the Guru.
>
> Now, how do I tell it to use the USB stick as a root filesystem?  I'm
> guessing I'll want to have two partitions, one to hold the image and another
> as a native P4 fs of some sort (if only to get case-sensitive filenames).
>  How do I specify the later to the "root is from" prompt?
>
> Paul
>
>
> On Tue, Dec 7, 2010 at 8:39 AM, ron minnich  wrote:
>
>> On Tue, Dec 7, 2010 at 8:26 AM, ron minnich  wrote:
>> > On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom 
>> wrote:
>> >
>> >> there is no current version in pc.  this is what you're intersted in
>> >> ./port/syscallfmt.c
>> >> ./kw/syscall.c
>> >
>> > Those are in now as well.
>>
>> or will be if the hg commit ever finishes ...
>>
>> ron
>>
>>
>
>
> --
> I'm migrating my email.  plalo...@telus.net will soon be disconnected.
>  Please use paul.a.lalo...@gmail.com from now on.
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

My application is home-control; I have an off-grid cabin that wants to run a
3G usb stick and a low-power cpu server to manage automation - pre-heating,
hot water, etc.  This lets me geek a little at the same time.

Paul

On Tue, Dec 7, 2010 at 10:13 PM, Lucio De Re  wrote:

> On Tue, Dec 07, 2010 at 09:25:37PM -0800, ron minnich wrote:
> >
> > I've gotten part of the way there. I set up a 9fat on the first
> > partition and I can boot the kernel from u-boot with the 9fat. But I'm
> > not quite done the rest.
> >
> The plug really needs fully hands-off booting and this does not seem to
> be the direction you're heading.  I suppose my approach where the file
> server is on the network isn't great either, although it may be suitable
> for an auth server.
>
> What are the various eventual uses for a plug running P9?  I can think of
>
>Stealth CPU server/AUTH server
>ARM development system (where's Go?)
>
> Can't think of anything else, but I'm not great on the imagination thing.
>
> I'm particularly fragmented now, but soon I'll want to focus on only a few
> projects, so I'm offering to help any sort of concrete goals.  I have only
> an oldish plug, probably a year old now, but it's dedicated to Plan 9.
>
> Mind you, so is the YeeLoong and that doesn't seem to be going anywhere.
>
> ++L
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Trap in 5c compiling rc?

[Paul Lalonde]

/arm/9plug

On Wed, Dec 8, 2010 at 5:06 AM, erik quanstrom wrote:

> > Now, how do I tell it to use the USB stick as a root filesystem?  I'm
> > guessing I'll want to have two partitions, one to hold the image and
> another
> > as a native P4 fs of some sort (if only to get case-sensitive filenames).
>
> what do you mean by "image" here?
>
> - erik
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Paul Lalonde]

Best recent c99 example:
int foo[] = {
  [0] = 1,
  [1] = 2,
  [2] = 4,
  [3] = 8,
  [4] = 16,
  [5] = 32
};

I shudder to think about foo[6].

Paul

On Thursday, February 17, 2011, ron minnich  wrote:
> I was looking at another fine example of modern programming from glibc
> and just had to share it.
>
> Where does the getpid happen? It's anyone's guess. This is just so
> readable too ... I'm glad they want to such effort to optimize getpid.
>
> ron
>
> #ifndef NOT_IN_libc
> static inline __attribute__((always_inline)) pid_t really_getpid (pid_t 
> oldval);
>
> static inline __attribute__((always_inline)) pid_t
> really_getpid (pid_t oldval)
> {
>   if (__builtin_expect (oldval == 0, 1))
>     {
>       pid_t selftid = THREAD_GETMEM (THREAD_SELF, tid);
>       if (__builtin_expect (selftid != 0, 1))
>         return selftid;
>     }
>
>   INTERNAL_SYSCALL_DECL (err);
>   pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
>
>   /* We do not set the PID field in the TID here since we might be
>      called from a signal handler while the thread executes fork.  */
>   if (oldval == 0)
>     THREAD_SETMEM (THREAD_SELF, tid, result);
>   return result;
> }
> #endif
>
> pid_t
> __getpid (void)
> {
> #ifdef NOT_IN_libc
>   INTERNAL_SYSCALL_DECL (err);
>   pid_t result = INTERNAL_SYSCALL (getpid, err, 0);
> #else
>   pid_t result = THREAD_GETMEM (THREAD_SELF, pid);
>   if (__builtin_expect (result <= 0, 0))
>     result = really_getpid (result);
> #endif
>   return result;
> }
>
> libc_hidden_def (__getpid)
> weak_alias (__getpid, getpid)
> libc_hidden_def (getpid)
>
>

-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] self modifying code in intel vga bios?

[Paul Lalonde]

Today, of course, we'd call this JIT, and shove it in a new page, and think
ourselves clever.
The last time I poked at one of these self-modifying bits they were really
just jitting a blit loop, in place.  Drops register pressure a little bit,
which has always been a bit of an issue in x86 land.

Paul

On Tue, Mar 8, 2011 at 7:03 AM, ron minnich  wrote:

> you have to allow for self modifying code. Yes, it's in there.
>
> Great, huh? I love BIOS software.
>
> ron
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Go Plan 9

[Paul Lalonde]

So I can write go programs that take advantage of private namespaces and
other Plan9 innovations.

Paul

On Tue, Apr 5, 2011 at 12:06 PM, Yaroslav  wrote:

> 2011/4/5 Lucio De Re :
> > As for not running Go on 9vx, that's a pain, I have such a nice 9vx
> > installation on my Ubuntu 32-bit laptop that it almost fools me into
> > believing it's Plan 9.  I don't always have a convenient CPU server at
> > hand to run Go on it.
>
> Why not to run Go directly on your Ubuntu laptop – without the 9vx
> abstraction?
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Additional compilers under 9vx.OSX

[Paul Lalonde]

Fortunately you can build a case-insensitive file system on a mac, within a
file.  Disk Utility lets you make a filesystem in a file, and you can click
"case-sensitive".  Big win, and though you have to size the FS ahead, it's
also nice to have my 9vx install all in one disk file for moving to other
machines.

Paul

On Thu, Apr 7, 2011 at 8:38 AM, ron minnich  wrote:

> I regularly build kernels and full bins for arm on 9vx. the biggest
> issue with osx is when you install 9vx on a case-insenstive file
> system: things like /bin/Kill and /bin/kill don't quite work out.
>
> ron
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Additional compilers under 9vx.OSX

[Paul Lalonde]

1s/case-insensitive/case-sensitive/

On Thu, Apr 7, 2011 at 8:45 AM, Paul Lalonde wrote:

> Fortunately you can build a case-insensitive file system on a mac, within a
> file.  Disk Utility lets you make a filesystem in a file, and you can click
> "case-sensitive".  Big win, and though you have to size the FS ahead, it's
> also nice to have my 9vx install all in one disk file for moving to other
> machines.
>
> Paul
>
>
> On Thu, Apr 7, 2011 at 8:38 AM, ron minnich  wrote:
>
>> I regularly build kernels and full bins for arm on 9vx. the biggest
>> issue with osx is when you install 9vx on a case-insenstive file
>> system: things like /bin/Kill and /bin/kill don't quite work out.
>>
>> ron
>>
>>
>
>
> --
> I'm migrating my email.  plalo...@telus.net will soon be disconnected.
>  Please use paul.a.lalo...@gmail.com from now on.
>
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] spaces in filenames

[Paul Lalonde]

I mostly run acme from inferno (acme-SAC), and live with trfs to take care
of my windows and mac paths.  My linux paths are much better behaved, and so
I run from p9p there.

Paul

On Tue, Apr 26, 2011 at 12:31 PM, Rob Pike  wrote:

> I still use acme.  My solution for spaces in file names is to avoid
> them.  That might not work for everyone.
>
> -rob
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Mousing is faster than typing but users do not believe it

[Paul Lalonde]

It sounds easy.  But few folks on this list are HCI researchers (I'll tell
you it's odd going from GPU design to HCI - but it's fun!).

None of the micro-tasks (mouse vs keyboard) that folks are going on about on
this list is meaningful to measure.  We know keyboards are good for some
things, and mice are good for others.  Leaving off my personal religion and
anecdotes (I use acme as my editor of choice), the only meaningful measure
is how well the whole system functions for your tasks.  And to really
measure that you need similar measures of expertise.  So we can compare vi
to notepad, for example, and find that "keyboard is better than mouse" by
some measure, but grab an expert acme user vs vi, and perhaps acme comes out
ahead on some task completions and behind on others.

There are, however, good models of what various interactions cost - the
bibilography on doi
10.1145/1978942.1979088
(Bonnie
John, "Using Predictive Human Performance Modls of Inspire and Support UI
Desgin Recommendations") is a recent starting point on predictive modelling
for interface design (that I have in front of me - I know there's better
sources).  I'd recommend becoming familiar with this literature, and then
trying to make the "mouse vs keyboard" argument witha straight face.

Paul

On Fri, Jun 17, 2011 at 6:55 AM, Iruatã Souza  wrote:

> On Fri, Jun 17, 2011 at 4:57 AM, Guilherme Lino 
> wrote:
> > better with it... but generally keyboard is much faster on most day
> tasks,
> > people just don't have the patience to learn it
> >
>
> Measuring the keyboard versus mouse speed is such a trivial experiment
> to repeat.
> Still, as Noah pointed out, people rely on intuition.
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] this is kind of sad

[Paul Lalonde]

Works for me.

On Fri, Jun 24, 2011 at 11:19 AM, dexen deVries wrote:

> On Friday 24 June 2011 16:12:05 Charles Forsyth wrote:
> > i put a copy on u9fs.googlecode.com
>
>
> thanks from one of the ``been meaning to
> try this Plan 9 thing'' guys ;-)
>
> any idea what's up with bell lab's plan 9 server?
>
>
> cheers,
> --
> dexen deVries
>
> ``One can't proceed from the informal to the formal by formal means.''
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Announcing Inferno for Android phones

[Paul Lalonde]

A pretty good week for 9fans!
Grats all involved!
Paul

On Fri, Sep 16, 2011 at 3:32 PM, andrey mirtchovski
wrote:

> this is cool!
>
> On Fri, Sep 16, 2011 at 4:23 PM, John Floren  wrote:
> > We would like to announce the availability of Inferno for Android
> > phones. Because our slogan is "If it ain't broke, break it", we
> > decided to replace the Java stack on Android phones with
> > Inferno. We've dubbed it the Hellaphone--it was originally Hellphone,
> > to keep with the Inferno theme, but then we realized we're in Northern
> > California and the change was obvious.
> >
> > The Hellaphone runs Inferno directly on top of the basic Linux layer
> > provided by Android. We do not even allow the Java system to
> > start. Instead, emu draws directly to the Linux framebuffer (thanks,
> > Andrey, for the initial code!) and treats the touchscreen like a
> > one-button mouse. Because the Java environment doesn't start, it only
> > takes about 10 seconds to go from power off to a fully-booted Inferno
> > environment.
> >
> > As of today, we have Inferno running on the Nexus S and the Nook
> > Color. It should also run on the Android emulator, but we haven't
> > tested that in a long time. The cell radio is supported, at least on
> > the Nexus S (the only actual phone we've had), so you can make phone
> > calls, send texts, and use the data network.
> >
> > The Inferno window manager has been re-worked with cell phone use in
> > mind. Windows are automatically sized to fill the whole screen. The
> > menu has been moved to the top and the menu items have been made
> > significantly larger. Physical buttons on the phone are now used to do
> > many common tasks:
> >
> >(these keys are for the Nexus S, different bindings are used for
> > the Nook, which has different keys available)
> >* Back: Close the current window
> >* Menu: Toggle the onscreen keyboard
> >* Home: Minimize the current window
> >* Power: Turn off the screen
> >* Power+Volume Up: Open the screen brightness widget
> >* Power+Volume Down: Turn off the phone
> >* Power+Home: Restart Inferno
> >
> > Installation is reasonably simple. You'll need the Android SDK
> > (http://developer.android.com/sdk/index.html), with the platform-tools
> > package installed for the adb and fastboot utilities. We also strongly
> > recommend installing CyanogenMod on your phone before
> > proceeding--that's what we use to test.
> >
> > First, make absolutely sure you have the "adb" and "fastboot"
> > commands in your path--see the previous paragraph regarding the
> > SDK and try running "adb" to be sure. Download the tarball from
> > http://bitbucket.org/floren/inferno/downloads/hellaphone.tgz and
> > unpack it in your root. You should end up with a /data/inferno
> > directory (we put it there because of the Inferno build
> > process). Then, go to the /data/inferno/android directory and run
> > the Reflash-Nexus-S.sh script (assuming you have a Nexus S. Run
> > Reflash-Nook-Color.sh if you have a Nook). This will
> > automatically set up the phone to boot into either Inferno or the
> > regular Java environment--during bootup, the screen will go solid
> > white; if you touch the screen at this point, it will boot into
> > the regular Android environment, otherwise it will timeout and go
> > to Inferno. However, at this point you're not yet ready to boot
> > into Inferno, so reboot the phone and touch the screen to go into
> > the regular Android UI. The final task is to run the command "cd
> > /data/inferno; ./parallel-push.sh". Reboot, let it boot into
> > Inferno, and you're ready to go.
> >
> > You can also clone the repository
> > (http://bitbucket.org/floren/inferno/) and build it yourself, but this
> > is a significant effort. I do not recommend it if you wish to simply
> > try the system, but if you want to do development you should get the
> > repository.
> >
> > Disclaimer: If you break your phone, it's not our fault. Don't email
> > us, don't come knocking on our door, and don't call us--oh wait, you
> > won't be able to do that anyway, your phone is broken!
> >
> > Credit where credit is due: Ron Minnich came up with the initial
> > idea--we've been kicking the idea of a Plan 9/Inferno phone around for
> > years. Our summer interns, Joel Armstrong and Joshua Landgraf, did the
> > lion's share of the work of making Inferno into a usable cell phone
> > OS--no small feat, considering that neither had any Limbo or Inferno
> > experience before the start of the summer! They re-wrote the UI,
> > puzzled out the undocumented cell radio interface, figured out audio,
> > worked to make Inferno more portable across phones, and generally
> > figured out how to make Inferno and the Android kernel coexist
> > peacefully. Andy Jones, another intern, also did some very early work
> > with Android that helped us figure out the Android init process and
> > how to build for Android. I took care of getting Inferno running on
> > the phone in the f

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Paul Lalonde]

Not as far as I know.  The grief comes with mixed fonts in the same column.  As 
the tag grows it breaks the column layout height.  You wind up with the choice 
of pushing the windows below around (ugly and unusable) or winding up with 
fractional lines in each window whose font is not the tag font.  The layout 
logic doesn't handle that gracefully as it only counts text lines, not pixel 
heights, and I didn't have the time to make that change.
That said, I find acme (and Edit in particular) damned near unusable without 
multi-line tags now.
Paul

Sent from my iPad

On 2011-10-09, at 12:48, "Lyndon Nerenberg (VE6BBM/VE7TFX)"  
 wrote:

> After the previous round of arguments about (native plan9) acme multi-line
> window tags, did anyone ever come up with a patch that at least some
> people were happy with?
> 
> --lyndon
> 
> P.S.  Is there any point to keeping mailing list archives any more?
> With every messsage including the history of every discussion before
> it, the concept of search is rendered obsolete.
> 
> P.P.S.  Of course, nobody gives a fsck about history any more.
> 
> P.P.P.S.  [P.S.] introduces an interesting idea.  Instead of storing
> message text in a file, place each line of text into venti as a block,
> then store the message as a list of venti hashes pointing to the
> per-line content.  With all the duplicate included text, this should
> be good for a 90% reduction in venti block storage for most mail
> servers.  The 'included line' prefixes would have to be stored
> seperately for this to work.
> 
> --lyndon
> 
> 

Re: [9fans] acme multi-line tags (or maybe, efficient message stores)

[Paul Lalonde]

I often keep an Edit I'm refining in a separate tag line for easy selection.
But the real use was in keeping commands that need chorded parameters, so my
debugger sessions, for example, keep a line of "list print break" etc, so I
can chord in the parameter easily.  That way I don't have to construct the
breakpoint instruction in a scratch window, and I can keep enough of them
around to be useful - one tag line isn't big enough.

Paul

On Sun, Oct 9, 2011 at 8:21 PM, erik quanstrom wrote:

> > didn't have the time to make that change.  That said, I find acme (and
> > Edit in particular) damned near unusable without multi-line tags now.
>
> do you have a particular usage senerio where this is most apparent?
>
> - erik
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] tcl, 9p

[Paul Lalonde]

C is a low level language, not intermediate.

In the second decade of the 21st century is it too much to ask for garbage
collection and type safety?

Hmm.  I'm probably just feeding a troll.

Paul

On Mon, Oct 10, 2011 at 2:05 AM, Balwinder S Dheeman <
bsd.sans...@anu.homelinux.net> wrote:

> On 10/09/2011 08:04 AM, Russ Cox wrote:
>
>> On Sat, Oct 8, 2011 at 8:02 PM, L N  wrote:
>>
>>> Anyone know the state of the art of writing 9p clients/servers in tcl?
>>>
>>
>> I believe the state of the art is not to use tcl.  :-)
>> I'm having fun writing 9p clients in Go.
>>
>
> IMHO, That Go or Go-language thingy seems to be an overkill to me for that
> matter; that's just an opinion and opinions may differ.
>
> The best portable and efficient intermediate level language is C and I hope
> it will remain a 'lingua franca' for computer programmers for years to come
> ;)
>
> --
> Balwinder S "bdheeman" Dheeman
> (http://werc.homelinux.net/**contact/ 
> )
>
>


-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] apparently nice summary of small linux pcs

[Paul Lalonde]

More to the point, you don't want any OS on an 8 bit machine.

A small driver library, maybe.  But really, 8 bit machines today are
just for fun little micro-control projects and you really don't want
an OS in the way.
The first thing I did to make an arduino useful was reclaim the timer
thread that the arduino "OS" steals from you...

Paul

On Tue, Jul 17, 2012 at 9:53 AM, erik quanstrom  wrote:
>> Actually I've toyed with the idea of a "Plan 9 from 8-bit space". It
>> would be a fun challenge, I think, and I'd be interested to find
>> exactly what compromises would be needed. It may even be less of a
>> challenge than writing drivers for the crap peripherals ARM SOCs always
>> seem to be burdened with, but what could you do with it when it was
>> done?
>
> you don't want plan 9 on an 8 bit machine.
>
> - erik
>

Re: [9fans] Acme: how to search only in selection

[Paul Lalonde]

The real question is how to handle the next selection; tracking two
dots seems wrong.

On Thu, Aug 9, 2012 at 8:28 AM, Matthew Veety  wrote:
>
> On Aug 9, 2012 10:00 AM, "dexen deVries"  wrote:
>>
>> On Thursday 09 of August 2012 15:46:47 Rudolf Sykora wrote:
>> > (...)
>> > Otherwise, using '>g pattern' will make a list, in the Error window,
>> > of lines where the pattern is, so then you can go through it.
>>
>>
>> thank you, Ruda, this solves my problem :^)
>> --
>> dexen deVries
>>
>> [[[↓][→]]]
>>
>>
>
> This sounds like a good feature to add though. Might hack on this tonight.
>
> --
> Veety

Re: [9fans] c++

[Paul Lalonde]

PS2 development is generally too expensive for the cost model of education
games, sadly.


On Thu, Nov 22, 2012 at 9:39 AM,  wrote:

> > A friend is developing such
> > web/tablet based lessons for similar kids in India (India has as big a
> > problem of poor ed. as the whole of Africa).
>
> The BBC reports exceptional success by some NGOs introducing tablets
> in rural (central) Africa amongst children.  But the price is wrong.
> Scrappy, perfectly adequate, if antiquated, computer equipment
> discarded in the West and even locally, by urban residents and
> organisations, on the other hand, is much more affordable.
> Electricity is an issue, but the cost of PV panels and inverters is
> dropping.
>
> Please continue with suggestions, I have a few weeks to get started
> and there may well be many ideas I have not considered (MIT Scratch is
> one such idea Charles already mentioned) and may make all the
> difference.  Maybe in private mail?
>
> Also, I have never seen any educational games for the PS2 (I bought
> one a while back as an experiment).  I would have thought it would be
> something worthwhile, maybe I'm too far from the mainstream to have
> come across such games?
>
> ++L
>
>
>

[9fans] Multi-monitor rio in plan9port in Ubuntu

[Paul Lalonde]

I got fed up with Ubuntu's crappy UI, so I went back to basics, but the
default new window manager stuff gave me a small, mirrored desktop across
both my monitors.

To save someone else the grief, here's a quick how-to:

1) Add a new window manager for rio.  Your paths will vary.
~ $ cat /usr/share/xsessions/rio.desktop
[Desktop Entry]
Encoding=UTF-8
Name=rio
Comment=
Exec=/home/plalonde/plan9port/bin/rio.sh
Icon=
Type=Application
~ $

2) Fill in rio.sh to use xrandr to set up your display, and run whatever
init you prefer:
~ $ cat plan9port/bin/rio.sh
#!/bin/sh
xrandr --output LVDS1 --mode 1600x900
xrandr --auto --output HDMI1 --mode 1920x1200 --right-of LVDS1
/home/plalonde/plan9port/bin/plumber &
/home/plalonde/plan9port/bin/rio
~ $

Replace LVDS1 and HDMI1 with the names of your video outputs, as reported
by "xrandr -q"

That should be enough for demuddling the desperate and sufficient for the
method to be indexed for posterity.

Paul

[9fans] Acme, dump, and $HOME

[Paul Lalonde]

Can anyone explain to me the rationale of Dump dropping acme.dump in $HOME
instead of $PWD?
I know I can pass it a different filename, but it seems odd to put it in
$HOME instead of where acme is called from.
My use case is this: I'm working on two projects, and so want to maintain
two long-term "sessions".  Dump does most of what I need when I move from
one to the other, but if I don't chord in the project root directory to
save the dump to, I kill my other project session.
A one line change to looking at $PWD instead of $HOME makes acme much more
useful for my case, but am I missing an important other use?

Paul

Re: [9fans] Acme, dump, and $HOME

[Paul Lalonde]

Yes, I understand the current behaviour.  I don't understand why $home was
privileged this way, instead of the startup directory.  So for instance, if
I drop the dump filename in the top-level tag, and chord it against dump, I
get the right thing - it's deposited in the directory where acme was
started.  I just don't understand why "acme.dump" should go to $home by
default, when everything else in the editor is relative to the window
directory.


On Mon, Jan 13, 2014 at 8:49 AM, dexen deVries wrote:

> On Monday 13 of January 2014 08:42:22 Paul Lalonde wrote:
> > Can anyone explain to me the rationale of Dump dropping acme.dump in
> $HOME
> > instead of $PWD?
> > I know I can pass it a different filename, but it seems odd to put it in
> > $HOME instead of where acme is called from.
> > My use case is this: I'm working on two projects, and so want to maintain
> > two long-term "sessions".  Dump does most of what I need when I move from
> > one to the other, but if I don't chord in the project root directory to
> > save the dump to, I kill my other project session.
> > A one line change to looking at $PWD instead of $HOME makes acme much
> more
> > useful for my case, but am I missing an important other use?
>
>
> from acme(1):
>
> Dump Write the state of acme to the file name, if specified, or
> $home/acme.dump by default.
>
>
> i.e., Dump takes one optional argument: file pathname.
>
>
> --
> dexen deVries
>
> [[[↓][→]]]
>
>
>

Re: [9fans] Acme, dump, and $HOME

[Paul Lalonde]

That seems even more magical, I think.

I've been running with Dump's $HOME lookup changed to $PWD for a few days
now with nary a glitch.
Unless someone tells me otherwise I'll start pushing for a patch :-)

Paul


On Mon, Jan 13, 2014 at 8:57 AM, Charles Forsyth
wrote:

>
> On 13 January 2014 16:42, Paul Lalonde  wrote:
>
>> Can anyone explain to me the rationale of Dump dropping acme.dump in
>> $HOME instead of $PWD?
>
>
> alternatively, if started with acme -l dumpfile, why not write it back to
> the same file?
>

Re: [9fans] Acme, dump, and $HOME

[Paul Lalonde]

Your described behaviour is unaffected by the patch unless you are running
acme (automatically) from another directory.

Paul


On Mon, Jan 13, 2014 at 10:53 AM, Bence Fábián  wrote:

> Because this way there is one default dump file.
> Maybe it should be $home/lib/acme.dump
> But when i turn on my terminal it runs acme -l $home/acme.dump
> automatically. And before i turn it off i just press dump.
> If I need to preserve a state for longer i can do
> Dump otherfile. For me this seems the saner behaviour.
>
> tl;dr I'm against your patch, sorry
>
>
> 2014/1/13 Paul Lalonde 
>
>> That seems even more magical, I think.
>>
>> I've been running with Dump's $HOME lookup changed to $PWD for a few days
>> now with nary a glitch.
>> Unless someone tells me otherwise I'll start pushing for a patch :-)
>>
>> Paul
>>
>>
>> On Mon, Jan 13, 2014 at 8:57 AM, Charles Forsyth <
>> charles.fors...@gmail.com> wrote:
>>
>>>
>>> On 13 January 2014 16:42, Paul Lalonde  wrote:
>>>
>>>> Can anyone explain to me the rationale of Dump dropping acme.dump in
>>>> $HOME instead of $PWD?
>>>
>>>
>>> alternatively, if started with acme -l dumpfile, why not write it back
>>> to the same file?
>>>
>>
>>
>

Re: [9fans] Acme, dump, and $HOME

[Paul Lalonde]

It certainly addresses my use case.  I'll give it a spin when I next have 5
minutes to mess with it.

Paul



On Mon, Jan 13, 2014 at 11:17 AM, Charles Forsyth  wrote:

>
> On 13 January 2014 18:30, Paul Lalonde  wrote:
>
>> That seems even more magical, I think.
>>
>
> The idea is that the dump file is a snapshot of a particular state, and it
> made sense to me to update
> the given state, instead of putting it back in the default file despite
> being given an explicit state.
> That seemed to me a bit contrary.
>

Re: [9fans] NIX experience

[Paul Lalonde]

This data-shuttling is one of the things that GPU vendors have been working
on.

Most of the data the GPU needs is never touched by the CPU, except to move
it to GPU memory.  This is wasteful.
But the GPU already sits on the PCIe bus, as does the storage device.  Why
not move the data directly from storage to GPU memory?
Recent iterations of GPUs can support this.  Likewise, Nvidia's NVLink
high-throughput fabric allows loading directly to GPU memory without
touching CPU memory at the same time.

Although CPU and GPU memory are often the same storage architecture, the
memory controllers differ sufficiently to make it a performance hit to
support both CPU-like random access and GPU-like streaming memory
patterns.  UMA certainly works in mobile and in graphics workloads (witness
phones and game consoles), it's more challenging when trying to squeeze the
ultimate performance-per-watt out of HPC workloads.

It's also important not to conflate a uniform memory address space with a
uniformly implemented address space - it's possible to map a chunk of the
GPU memory to the CPU memory space and treat it like RAM from the CPU's
view, but the operations are typically strongly unbalanced with writes
costing significantly more because of the difference in memory consistency
models between the two devices.

Paul

On Sat, Dec 28, 2024 at 8:25 AM Frank D. Engel, Jr. 
wrote:

> Consequently the CPU and GPU work
> together much more directly without needing to waste time to shuttle
> data between them.
>
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-Mf15c6498d2a1be494bc3799c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

As you say, Ron.

First, here's my nix script, such as it is, cribbed from the old nix one.
It has holes, guaranteed.  Also, I went and pulled in a "user" directory,
just for old habits dying hard.  Yes, I still use glenda on this old
terminal.  Call me names for it.

#!/bin/rc

unmount /sys/include >[2]/dev/null

unmount /sys/src/libc >[2]/dev/null

bind -b /usr/glenda/nix-os/sys/include /sys/include

bind -c /usr/glenda/nix-os/sys/src/libc /sys/src/libc

cd /usr/glenda/nix-os/sys

for(d in man/*){

unmount /sys/$d >[2]/dev/null

bind -b $d /sys/$d

}

exit ''


My terminal is a pi 400, so I had to build out the /amd64 tree,
objtype=arm64.  I'll assume folks are clever enough to do this, or to use
an amd64 terminal or cpu to do this work.


Then mk your heart out.  The main pain points are ulong parameters that are
now usize in 9front, and the renaming of Ureg.ip to Ureg.pc.  These changes
appear limited to

M amd64/include/ureg.h

M sys/include/libc.h

M sys/src/boot/pc/lib.h

M sys/src/nix/boot/nopsession.c

M sys/src/nix/k10/acore.c

M sys/src/nix/k10/fpu.c

M sys/src/nix/k10/sipi.h

M sys/src/nix/k10/syscall.c

M sys/src/nix/k10/trap.c

M sys/src/nix/port/lib.h

M sys/src/nix/port/portfns.h

The diffs are attached.  I don't want to commit a branch because as I said,
I don't think my bind mappings are entirely correct, though I'm seeing many
fewer crossed wires now.
Attached is the (trivial) mkfile I built for nix-os/sys/nix/boot which
*almost* makes a full build happen.  parseipmask has gained a v4 parameter
in 9front, which means the fix there needs actual analysis.  qsort is
somehow also complaining, possibly indicating I'm pulling the wrong header
for it, indicating a problem in my bind script.

This feels completely surmountable.


Paul

On Tue, Jan 7, 2025 at 9:29 PM Ron Minnich  wrote:

> if you can document your steps, then others can stand on your
> shoulders, possibly, and we can all move forward?
>
> On Tue, Jan 7, 2025 at 9:08 PM Paul Lalonde 
> wrote:
> >
> > Ok, not a bad first day poking at it.  I have a growing (but not ready)
> new nix script to pull the right pieces over top of my build environment.
> > I have a near-complete build, but with hazards: 9front has evolved in a
> number of places with many ulong parameters becoming usize.  I have a list
> of those spots, but now they need to be examined for over/underflow.
> > The last puzzle of the day is nix-os/sys/src/nix/boot.  The repo
> includes the libboot.a6 binary, some source files that match the symbols,
> and no mkfile.  Attempting to build also shows some 9front auth changes
> that need to be incorporated into doauthenticate.c, calls to convS2M and
> convM2S that now need buffer length parameters, and the phasing of Tnop out
> 9p?  Nothing at all insurmountable.
> >
> > Not too daunting.  Next time I have a few moments I'll do a more
> principled pass on the nix script so I can share it.  I didn't understand
> enough when I first started updating it.
> >
> > Paul
> >
> >
> > On Tue, Jan 7, 2025 at 6:58 PM Ron Minnich  wrote:
> >>
> >> if you look at the first_commit branch, you'll see a sys/src/nix/nix
> >> script, which sets up some binds.
> >>
> >> What we did, before building nix, on plan 9, in 2011, was a set of
> >> binds to get the right things such as /sys/include and so on.
> >>
> >> This  won't be just a 'mk and it builds'. There's 13 years of bitrot.
> >> I expect it will be strategic changes, and in the end they won't be
> >> all that many lines of code, but there will be some tricky stuff.
> >>
> >> Best ot take it slow, when you hit an issue, ruminate it on for a day
> >> or two, then look again. Otherwise you'll just get frustrated (I have
> >> ...) But before you make any change, be very sure you know WHY you're
> >> doing it, not just that 'it got me past that mk error.'
> >>
> >> Bring issues to the list and, if you want, keep a running doc to which
> >> others can contribute: what you did, what you ran into, what a fix
> >> might be. The old saying; "if you don't write it down it didn't
> >> happen"
> >>
> >> But this is the kind of thing you take slowly and carefully, otherwise
> >> it's total misery.
> >>
> >> ron
> >>
> >> On Tue, Jan 7, 2025 at 5:34 PM Paul Lalonde 
> wrote:
> >> >
> >> > And a bit more digging.  Yes, I'm clearly doing this wrong.  In
> building nix-os/sys/src/k10/trap.c it should absolutely be using the Tos
> structure from nix, not the one in the host sys

Re: [9fans] NIX experience

[Paul Lalonde]

Yes, AMD's EPYC line and derivatives, with their reasonably nice memory
partitioning is *excellent* for running independent VMs.  It does a good
job of letting you scale your core counts appropriately to the size of the
VM.

Nvidia's GeForce NOW game streaming platform runs (ran?  I'm not there
anymore, though this information is publicly available from 2023 at least)
on these AMD CPUs precisely because of the excellent workload isolation and
scalability.

Paul

On Mon, Dec 30, 2024, 12:15 p.m.  wrote:

> Perhaps the target market is not really HPC in the sense of trying to
> speed up _one_ task by doing it, parallely, concurrently, on a lot of
> cores, but more the "cloud": limited needs for global synchronization,
> since, all in all, there are separate VMs running at the same time
> but almost orthogonal---even the storage is in fact segregated. So
> it is a more tightly coupled cluster of separated systems, allowing
> speedy migration of tasks, than a single system (for a single
> task---computing weather evolution or simulating complex physics
> systems. Just a guess.
>
> >
> >
> > On Mon, Dec 30, 2024 at 10:00?AM Ron Minnich  wrote:
> >
> > > On Mon, Dec 30, 2024 at 9:39?AM Bakul Shah via 9fans <9fans@9fans.net>
> > > wrote:
> > > >
> > > > I wonder how these many-core systems share memory effectively.
> > >
> > > Typically there is an on-chip network, and at least on some systems,
> > > memory blocks scattered among the cores.
> > >
> > > See the Esperanto SOC-1 for one example.
> 
> --
> Thierry Laronde 
>  http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M72399792ed2cf545ee3b5efe
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

The hard part is memory consistency.

x86 has a strong coherence model, which means that any write is immediately
visible to any other core that loads the same address.  This wreaks havoc
on your cache architecture.  You need to either have a global
synchronization point (effectively a global shared cache) with its
associated performance bottleneck, or you need some method to track which
cores are using which cache lines that might become invalidated by a
write.  Contended cache lines become very expensive in terms of
communication.  Intel's chips deal with this by having "tag directories"
which track globally which caches contain which cache lines.  AMD has a
similar structure on the IO die of their chiplet-based architectures.  In
both cases, you get much better performance if you avoid *ever* using the
same cache line on separate processors.  In the AMD case you can fairly
easily partition your workload across physical memory channels to do this.
On Intel it's much more "magical", and it's not at all clear how well the
magic scales into very large numbers of cores.  You might note that Intel
is not doing as well as AMD these days on the architecture side.

Relaxing the memory model somewhat like ARM and RISC-V can help there by
reducing the number of (false) synchronization points between caches, but
at the cost of more subtle bugs if you miss including the required
synchronization primitives.

Paul


On Mon, Dec 30, 2024 at 10:00 AM Ron Minnich  wrote:

> On Mon, Dec 30, 2024 at 9:39 AM Bakul Shah via 9fans <9fans@9fans.net>
> wrote:
> >
> > I wonder how these many-core systems share memory effectively.
> 
> Typically there is an on-chip network, and at least on some systems,
> memory blocks scattered among the cores.
> 
> See the Esperanto SOC-1 for one example.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-Mf27994b8c88e9e8b8693b871
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

Xeon Phi was the last remnant of the first GPU architecture I worked on.
It was evolved from Larrabee, meant to run DX11 graphics workloads.
The first Phi was effectively the Larrabee chip but with the texture
sampling hardware fused off.
The remnants of that work are now living on in the AVX512 instruction set.
The principal problem with Larrabee was that the ring bus connecting some
60+ ring stops was *so wide* (512 bits bidirectional = 1024 bits!) that it
consumed too much power.  It was more flexible than it needed to be
compared to a GPU memory controller/crossbar, and its power consumption
couldn't be reduced sufficiently to make it a useful architecture for the
mobile market.  Instead, graphics continued on the older Intel embedded
graphics path.
Frankly, I'm amazed that Intel followed through with 2 more revisions of
Xeon Phi before canning it.  In all honestly, the core choice for the CPU
(P54C) was nice for micro-optimized predictability of instruction execution
times and reasoning about hazards, but Intel's architectural mastery of
micro-op recompilation and out-of-order pipelines really trumps what the
compilers were doing once it was removed from the graphics space.

On Fri, Dec 27, 2024 at 1:12 PM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> I always thought NIX would have been a good fit for Xeon Phi MICs, since
> part of the bringup involved shipping an entire linux system to the card
> for booting anyway.  Sadly, Intel (as usual) gave up on the architecture
> about ten minutes after release.
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-Md2d5c0b29b8a6dfa47a3798f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

On Fri, Dec 27, 2024 at 1:25 PM sirjofri 
wrote:

> I've been a game developer for >5 years and I'm always surprised by how
> much GPUs can do if used correctly. It's just incredible.
>
Yes, it still doesn't cease to amaze me.  The compute density is just
astounding.


> Can't wait to see what will happen in the future to Plan 9 and GPUs in
> combination!
>

I wish I had better thoughts in this space.  The naive approach says "give
your data regions nice (file)names" but the file abstraction falls apart
completely once you start managing the synchronization primitives.
Add that the drivers are the most complex OS software ever built and it
becomes very difficult to do more than to expose some sort of RPC to a
different computer running a native (non-plan9) workload on the GPU.

That said, now that NVDA has moved a bunch of their "resource manager"
(read, OS) to the GPU itself and simplified the linux DRM module, the
driver layer has simplified significantly.  I'm not sure I have anywhere
near the bandwidth it would take to manage a plan9 port of even the
simplest interfaces, however.

Paul

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M89fcff19fd181cf3b97e35cc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

Not directly.  The AVX512 instructions include some significant
permute/shuffle/mask hardware, available on pretty much all instructions.
These in turn lead to very long capacitance chains (ie, transistors in
series that have to stabilize each clock) and so constrain how fast the
clock can run.  For Larrabee that wasn't a big deal as the clock was
relatively slow, but modern 4-5GHz clocks do not like structures this
long.  Another choice is to split the registers into two banks to run on
alternate clocks and then settle the permutations in a post-process using
register renaming to avoid hazards.  I don't know if any have been
implemented this way as that would be after my time.
It looks a lot like the old CISC vs RISC arguments, only now about
shuffles.  The classical GPU architecture won with what's effectively the
"RISC" version.

Paul

On Fri, Dec 27, 2024 at 1:41 PM Kurt H Maier via 9fans <9fans@9fans.net>
wrote:

> Is the power consumption the reason the cores downclock when you start
> sending AVX512 instructions?
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M6fde8bb81da995615fa76603
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

GPUs have been my bread and butter for 20+ years.

The best introductory source continues to be Kayvon Fatahalian and Mike
Houston's 2008 CACM paper: https://dl.acm.org/doi/10.1145/1400181.1400197

It says little about the software interface to the GPU, but does a very
good job of motivating and describing the architecture.

The in-depth resource for modern GPU architecture is the Nvidia A100 tensor
architecture paper:
https://images.nvidia.com/aem-dam/en-zz/Solutions/data-center/nvidia-ampere-architecture-whitepaper.pdf.
It's a slog, but clearly shows how compute has changed.  Particularly, much
of the success is in turning branchy workloads with scattered memory
accesses into much more bulk-oriented data streams that match well to the
"natural" structure of the tensor cores.  The performance gains can be
astronomical. I've personally made > 1000x - yes, that's *times* not
percentages - speedups with some workloads.  There is very little compute
that's "cpu-limited" at multi-second scales that can't benefit from these
approaches, hence the death of non-GPU supercomputing.

Paul



On Fri, Dec 27, 2024 at 7:13 AM  wrote:

> On Thu, Dec 26, 2024 at 10:24:23PM -0800, Ron Minnich wrote:
> [very interesting stuff]
> >
> > Finally, why did something like this not ever happen? Because GPUs
> > came along a few years later and that's where all the parallelism in
> > HPC is nowadays. NIX was a nice idea, but it did not survive in the
> > GPU era.
> >
> 
> GPUs are actually wreaking havoc other kernels, with, in the Unix
> world, X11 being in a bad shape for several reasons, one being that
> GPU are not limited to graphical display---this tends to be
> anecdoctical in some sense.
> 
> Can you elaborate on the GPUs paradigm break? I tend to think that
> there is a main difference between "equals" sharing a same address
> space via MMU, and auxiliary processors that are using another address
> space. A GPU, as far as I know (this is not much), is an auxiliary
> processor when the GPU is discrete, and is a specialized processor
> sharing the same address space when integrated (but I guess that a
> HPC have discrete GPUs with perhaps a specialized connection).
> 
> Do you know good references about:
> 
> - organizing processors depending on memory connection---I found
> mainly M. J. Flynn's paper(s) about this, but nothing more
> recent---and the impact on an OS design;
> 
> - IPC vs threads---from your description, it seems that your solution
> was multiplying processes so IPC instead of multiplying threads---but
> nonetheless the sharing of differing memories remains, and is more
> easy to solve with IPC than with threads;
> 
> - Present GPU's architecture (supposing it is documented; it seems not
> totally from "General-Purpose Graphics Processor Archictectures",
> Aamodt, Lun Fung, Rogers, SpringerVerlag) and the RISC-V approach,
> composing hardware by connecting dedicated elements, and vectors vs
> SIMT.
> 
> Thanks for sharing (what can be shared)!
> --
> Thierry Laronde 
>  http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M515bf7357d2a3e968c25260f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] NIX experience

[Paul Lalonde]

MIG is interesting.  It's something we partly devised to deal with sharing
interactive workloads on the same GPU.
Time-slicing is very difficult on a GPU because the state is so large. You
wind up having to drain the workload and that means you're holding on to
resources until the longest job ends.  Utilization becomes very poor, and
even worse if your application uses a long (read, non-terminating) compute
task.
So you want some way to partition the GPU more along spatial lines - giving
each process a subset of the hardware resources.
For some workloads this scheduling is easy - you give each workload enough
front end resources, memory, and threads to donuts job.  But I think we're
still a long way off from the GPU being able to do these allocations
dynamically and efficiently.
There are some really interesting non-uniform co-scheduling constraints
that I've not seen addressed in the literature.

Paul

On Sat, Dec 28, 2024, 4:19 p.m. Skip Tavakkolian 
wrote:

> I think there is a conflict between two different types of usage that
> GPU architectures need to support. One is full-speed performance,
> where the resource is fully owned and utilized for a single purpose
> for a large chunk of time, and the other is where the GPU is a rare
> resource that needs to be shared in short intervals (e.g. ML/AI
> inference mode)
>
> If I understand correctly, NIX's approach addresses the first case (at
> least for cores).  Nvidia's Multiple-Instance GPU (MIG) architecture
> seems to help to handle the second type of usage. The first case
> requires maximizing data transfer rate, and the second needs clever
> scheduling to minimize switching (large/huge) model parameters in/out.
>
>
> On Fri, Dec 27, 2024 at 8:33 AM Paul Lalonde 
> wrote:
> >
> > GPUs have been my bread and butter for 20+ years.
> >
> > The best introductory source continues to be Kayvon Fatahalian and Mike
> Houston's 2008 CACM paper: https://dl.acm.org/doi/10.1145/1400181.1400197
> >
> > It says little about the software interface to the GPU, but does a very
> good job of motivating and describing the architecture.
> >
> > The in-depth resource for modern GPU architecture is the Nvidia A100
> tensor architecture paper:
> https://images.nvidia.com/aem-dam/en-zz/Solutions/data-center/nvidia-ampere-architecture-whitepaper.pdf.
> It's a slog, but clearly shows how compute has changed.  Particularly, much
> of the success is in turning branchy workloads with scattered memory
> accesses into much more bulk-oriented data streams that match well to the
> "natural" structure of the tensor cores.  The performance gains can be
> astronomical. I've personally made > 1000x - yes, that's *times* not
> percentages - speedups with some workloads.  There is very little compute
> that's "cpu-limited" at multi-second scales that can't benefit from these
> approaches, hence the death of non-GPU supercomputing.
> >
> > Paul
> >
> >
> >
> > On Fri, Dec 27, 2024 at 7:13 AM  wrote:
> >>
> >> On Thu, Dec 26, 2024 at 10:24:23PM -0800, Ron Minnich wrote:
> >> [very interesting stuff]
> >> >
> >> > Finally, why did something like this not ever happen? Because GPUs
> >> > came along a few years later and that's where all the parallelism in
> >> > HPC is nowadays. NIX was a nice idea, but it did not survive in the
> >> > GPU era.
> >> >
> >>
> >> GPUs are actually wreaking havoc other kernels, with, in the Unix
> >> world, X11 being in a bad shape for several reasons, one being that
> >> GPU are not limited to graphical display---this tends to be
> >> anecdoctical in some sense.
> >>
> >> Can you elaborate on the GPUs paradigm break? I tend to think that
> >> there is a main difference between "equals" sharing a same address
> >> space via MMU, and auxiliary processors that are using another address
> >> space. A GPU, as far as I know (this is not much), is an auxiliary
> >> processor when the GPU is discrete, and is a specialized processor
> >> sharing the same address space when integrated (but I guess that a
> >> HPC have discrete GPUs with perhaps a specialized connection).
> >>
> >> Do you know good references about:
> >>
> >> - organizing processors depending on memory connection---I found
> >> mainly M. J. Flynn's paper(s) about this, but nothing more
> >> recent---and the impact on an OS design;
> >>
> >> - IPC vs threads---from your description, it seems that your solution
> >> was multiplying processes so IPC

Re: [9fans] NIX experience

[Paul Lalonde]

I'll take 6912 simple cores at 1Ghz over 192 core at 5GHz any day.  So long
as I can spend the 3 months rebuilding the implementation to be cache and
memory friendly.

I love the EPYC line, and have spec'd them into DCs.  But for raw compute
it's just not competitive for HPC-like workloads.

Paul

On Fri, Dec 27, 2024 at 8:44 PM Cyber Fonic  wrote:

> Whilst there are many HPC workloads that are well supported by GPGPUs, we
> also have multi-core systems such as Ampere One and AMD EPYC with 192 cores
> (and soon even more).
> Permalink
> 
>

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T7692a612f26c8ec5-M7c5247ba28dbf36e9c6a27af
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 20241121 Plan9 Foundation Board Meeting Minutes

[paul lalonde]

For your information, attached.

Paul

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2076dcd08fd197c2-Mb185053184b89cd0ecbb5095
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription


20241121 Minutes for Distribution.pdf
Description: Adobe PDF document

[9fans] 2024 Plan 9 Foundation Board Report

[paul lalonde]

It is my pleasure to distribute the Plan 9 Foundations' 2024 Annual Report.
It is also attached in PDF format for your reference.


Paul Lalonde,

Secretary of the Board of Directors of the Plan 9 Foundation.


Plan 9 Foundation Annual Report 2024

Glenda’s Diary
Important events

The theme of earlier years might have been described as “righting the
ship.” This year, now that we were no longer doing major repairs, we were
able to get ready to sail.

The theme for the year was to build a community.


   -

   We had IWP9 in Philadelphia, and it was quite a success. More
   importantly, we established the cadence for conferences, always starting
   work on the next year’s conference at the close of this year’s conference.
   -

   We arranged for the next IWP9 in Paris, in a prestigious venue.
   -

   We are on a firm financial footing, with contributions continuing to
   come in each month.
   -

   We worked with 9front to get the repo into a state that people are
   comfortable with.
   -

   We got a mailing list going, and although usage is very light, we are
   getting there.
   -

   We got permission to manage 9fans, taking over that list, making it
   moderated, and merging it with our existing list. Because 9fans has been a
   continual source of reputational harm, this is a significant change.

Did we achieve our 2024 goal?

We assembled our community, and getting control of 9fans is important, but
discussion is still light.  We are overall pleased with the progress but
aren’t yet seeing the impact of the change.
Goals to shoot for in 2025

Grow the number of places experimenting with Plan 9 ideas. [visit unis,
profs, research labs…]

Provide a trivial on-ramp to Plan9.

Your ideas here (yes, that means you).

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T88b1ba241b319a33-M194263c51058912156a99fd5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription


Annual Report 2024.pdf
Description: Adobe PDF document

Re: [9fans] NIX/regen

[Paul Lalonde]

On Sun, Jan 12, 2025 at 10:02 AM  wrote:

> [I have made a first PR for some small fixes to nix/nix
> and adding a NOTES that fixes some infelicities in the
> instructions to get started]
>

Thank you!  Infelicities is a very polite way to point out my poor
note-taking skills!


> Would it be possible to gather the (modification) bits together, for
> example in sys/src/nix/rc, mounted via (nix/nix) in order to appear
> as nix/vmx, nix/mkusbkey and so long, in order to put the pieces
> together?
>

Yes, this is a great suggestion.  Please do!


> Note: there are a number of warnings when compiling so my next
> assignment will be to fix the compiler (assembler, compiler, linker)
> warnings before tracking panics. I prefer to grasp the easier task at
> hand ;-^
>

I'll admit to punting on these.

Most of them are from parameter and signature changes from long to size,
and each requires careful examination and analysis to understand if
sign-extending is sufficient/appropriate, and whether the size change
should propagate through more of the neighboring code.  Most important is
to avoid any casting to quiet the compiler since it is telling us something
useful.

Paul

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Ted30b22de106b2db-M6b605fc778fa62da7ecc4bce
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] 12 December 2024 Plan 9 Foundation Board Meeting Minutes

[paul lalonde]

Please find attached the minutes of the December meeting of the Plan 9
Foundation, approved at today's board meeting.

Paul

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf9ad3c6aea65f28a-M685ee58be10cf99819a59db8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription


20241219 Meeting Minutes.pdf
Description: Adobe PDF document

[9fans] 9front USB EFI Boot hang

[Paul Lalonde]

Hi,
  I was trying to bring up 9front on another machine I have (Lenovo
Thinkstation P620 with a Threadripper Pro 3955WX), and I hang right after
the "boot\n" output of the EFI loader.

Any suggestions on how to debug this?  Is there a simple way to just build
the EFI and 9fat partitions on a USB stick until I have something that
boots far enough to mount root from my cpu server?

Paul

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb7ff9ca34535affa-M260c45424e5ca4e807eab37e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9front USB EFI Boot hang

[Paul Lalonde]

Thank Ori and Moody.

I've started walking through making my custom iso and efi partition.
Reasonably straightforward, though I get this error when building:
fluxcpu% disk/mk9660 -c9j -B pc/9bootiso -E efi/efiboot.fat -v 'Plan 9
Front ('^$objtype^')' /tmp/test.iso
warning: boot image too big; will only load the first 2K

Is it normal for 9bootiso to be 6664 bytes long?  Or is there something
broken in my source tree?

Paul

On Mon, Jan 27, 2025 at 10:18 AM Jacob Moody  wrote:

> On 1/27/25 11:34, Paul Lalonde wrote:
> > Hi,
> >   I was trying to bring up 9front on another machine I have (Lenovo
> Thinkstation P620 with a Threadripper Pro 3955WX), and I hang right after
> the "boot\n" output of the EFI loader.
> >
> > Any suggestions on how to debug this?  Is there a simple way to just
> build the EFI and 9fat partitions on a USB stick until I have
> something that boots far enough to mount root from my cpu server?
> 
> If I got to "boot" then its possible it actually got in to the kernel and
> it's the kernel that is hanging.
> Regardless, if you want to attempt to debug the EFI bootloader you can
> find it in /sys/src/boot/efi.
> The efi bootloader will search either the ESP itself for a kernel as well
> as a 9fat partition.
> So for just debugging, you can make yourself an ESP and place both the the
> bootloader and a kernel there.
> 
> We have had reports of some machines having buggy EFI firmware that forces
> people to place their kernel
> on the ESP, so maybe that's worth a try as well? Although I think with
> those the bootloader complains
> that its not able to find the kernel and doesn't just hang.
> 
> If you do want to make yourself a plan9 partition + a 9fat perhaps take a
> look at what the installer
> scripts do (/rc/bin/inst/*) to see the process.
> 
> Thanks,
> moody
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb7ff9ca34535affa-M9687d11007555ca811e1f22b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Nix/regen: multiboot flags

[Paul Lalonde]

The multiboot specification says: If bit 16 in the ‘flags’ word is set,
then the fields at offsets 12-28 in the Multiboot header are valid, and the
boot loader should use them instead of the fields in the actual executable
header to calculate where to load the OS image.

I believe they are valid in this case.  These include the load address for
the kernel and the bit depth of the display, found at l32p.s:37,44

Paul

On Tue, Jan 28, 2025 at 6:09 AM  wrote:

> In l32p.s, the multiboot flags in the the mbi are set as
> 
> $0x00010007
> 
> but I don't find flags definitions relative to the higher word,
> neither in the multiboot v1 spec, nor in the enum in multiboot.c. They
> are all limited to the two lowest bytes.
> 
> What is the purpose of the:
> 
> $0x00010007
>   ^
> 
> Typo?
> --
> Thierry Laronde 
>  http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T57431cc6930f8b70-Mf34572c05f19207ae4ccc210
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription