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] 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] 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] 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] 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] 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'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] 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] 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] 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] 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=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] 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] 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] 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 <quans...@quanstro.net>
wrote:

> try writing the file?  
>
> On Feb 15, 2017 5:05 AM, Paul Lalonde <paul.a.lalo...@gmail.com> 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]

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 <ba...@bitblocks.com> wrote:

> May be use Russ'es Watch command?
>
> > On Feb 15, 2017, at 5:05 AM, Paul Lalonde <paul.a.lalo...@gmail.com>
> 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
>
>
>

[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] 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 charles.fors...@gmail.com
wrote:


 On 19 March 2015 at 18:26, arn...@skeeve.com wrote:

 Charles Forsyth charles.fors...@gmail.com wrote:

  On 19 March 2015 at 16:09, arn...@skeeve.com 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.

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 ba...@bitblocks.com 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] [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 quans...@quanstro.net
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] [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 robp...@gmail.com wrote:

 That's a shame.

 -rob


 On Mon, Oct 27, 2014 at 9:41 AM,  s...@9front.org 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 quans...@quanstro.net
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] 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 ba...@bitblocks.com wrote:

 On Wed, 19 Mar 2014 04:36:34 EDT Caleb Malchik cmalc...@gmail.com 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.

[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 dexen.devr...@gmail.comwrote:

 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
charles.fors...@gmail.comwrote:


 On 13 January 2014 16:42, Paul Lalonde paul.a.lalo...@gmail.com 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 beg...@gmail.com 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 paul.a.lalo...@gmail.com

 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 paul.a.lalo...@gmail.com 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 charles.fors...@gmail.com
 wrote:


 On 13 January 2014 18:30, Paul Lalonde paul.a.lalo...@gmail.com 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.

[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

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, lu...@proxima.alt.za 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

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 mve...@gmail.com wrote:

 On Aug 9, 2012 10:00 AM, dexen deVries dexen.devr...@gmail.com 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] 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 quans...@quanstro.net 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] 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 Nleonardne...@gmail.com  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/ 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] 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)  
lyn...@orthanc.ca 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 quans...@quanstro.netwrote:

  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] 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
mirtchov...@gmail.comwrote:

 this is cool!

 On Fri, Sep 16, 2011 at 4:23 PM, John Floren j...@jfloren.net 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 first place and have been adding things occasionally
  since then. We would also like to thank Andrey Mirtchovski for
  providing the OLPC 

Re: [9fans] this is kind of sad

[Paul Lalonde]

Works for me.

On Fri, Jun 24, 2011 at 11:19 AM, dexen deVries dexen.devr...@gmail.comwrote:

 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] 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.1979088http://dx.doi.org/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 iru.mu...@gmail.com wrote:

 On Fri, Jun 17, 2011 at 4:57 AM, Guilherme Lino guih.l...@gmail.com
 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] 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 rminn...@gmail.com 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 paul.a.lalo...@gmail.comwrote:

 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 rminn...@gmail.com 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] 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 yari...@gmail.com wrote:

 2011/4/5 Lucio De Re lu...@proxima.alt.za:
  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] 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 rminn...@gmail.com 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] Trap in 5c compiling rc?

[Paul Lalonde]

/arm/9plug

On Wed, Dec 8, 2010 at 5:06 AM, erik quanstrom quans...@labs.coraid.comwrote:

  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] 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 quans...@quanstro.netwrote:

 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 rminn...@gmail.com wrote:

 On Tue, Dec 7, 2010 at 8:26 AM, ron minnich rminn...@gmail.com wrote:
  On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom quans...@quanstro.net
 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 paul.a.lalo...@gmail.comwrote:

 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 rminn...@gmail.com wrote:

 On Tue, Dec 7, 2010 at 8:26 AM, ron minnich rminn...@gmail.com wrote:
  On Tue, Dec 7, 2010 at 5:37 AM, erik quanstrom quans...@quanstro.net
 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]

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 rminn...@gmail.com wrote:

 Build went fine.

 On Sun, Dec 5, 2010 at 10:15 AM, ron minnich rminn...@gmail.com 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 rminn...@gmail.com wrote:

 On Mon, Dec 6, 2010 at 5:54 PM, erik quanstrom quans...@quanstro.net
 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 paul.a.lalo...@gmail.com
 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]

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 quans...@quanstro.netwrote:

 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 paul.a.lalo...@gmail.comwrote:

 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 quans...@quanstro.netwrote:

 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.

[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] 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 j...@corpus-callosum.com 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] 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.

[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.

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 e...@sandien.com 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 e...@sandien.com 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.

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 rminn...@gmail.com 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] 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 plalo...@telus.net 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
 
 
 

[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] 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.

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] 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 plalo...@telus.net:

-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 eri...@gmail.com 
 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] 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] 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 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] 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] 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]

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] 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] 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] 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] 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] 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-