Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation

[Dave MacFarlane]

Wow, fantastic news! Congratulations!

Is there any way we can donate to the foundation (time or money) to keep
things moving along?



On Tue, Mar 23, 2021 at 9:09 AM  wrote:

> We are thrilled to announce that Nokia has transferred the copyright of
> Plan 9 to the Plan 9 Foundation. This transfer applies to all of the
> Plan 9 from Bell Labs code, from the earliest days through their final
> release.
> 
> The most exciting immediate effect of this is that the Plan 9 Foundation
> is making the historical 1st through 4th editions of Plan 9 available
> under the terms of the MIT license. These are the releases as they
> existed at the time, with minimal changes to reflect the above.
> 
> 1st and 2nd edition were never released as open source software, and
> both (but especially 1st edition) were only available to a very small
> number of people. 3rd and 4th were previously available as open source,
> but under a license which was problematic for some people (especially
> the 3rd edition). We think making these available under the MIT license
> is something that's going to be a significant benefit for all projects
> using Plan 9 code. While this doesn't automatically change the license
> on any downstream projects, and you're welcome to keep using the LPL if
> you like, you now have the option of switching to MIT, which we think
> most everyone will find preferable.
> 
> Obviously, for folks in the Plan 9 community, there isn't a way to say
> "thank you" to Bell Labs, and its various parent organizations, that's
> really adequate. None of us would be talking about any of this if it
> weren't for the work done there for decades. All of us here at the Plan
> 9 Foundation express our sincerest thanks to the team at Nokia who made
> this possible, the Plan 9 alumni who supported the effort, and the Plan
> 9 community who have kept kernels booting and the userland useful.
> 
> The historical releases are available right now at:
> https://p9f.org/dl/
> 
> You can read Nokia's press release on the transfer here:
> 
> https://www.bell-labs.com/institute/blog/plan-9-bell-labs-cyberspace/
> 
> Thank you for your time,
> Anthony Sorace
> Plan 9 Foundation


-- 
- Dave

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf20bce89ef96d4b6-M8fc59aff65ad1bf08246beff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Software preservation in the post-hg era

[Dave MacFarlane]

>
>
>
> How does it compare performance wise with git9 ?
>
> https://github.com/oridb/git9
>

Based on the unscientific testing I just did of cloning the same repo
(dgit's) a few times,  they're in the same ballpark (~13s on 9front amd64.)
git9 had a couple faster runs and dgit a couple slower ones,  but nothing
outside of what could be explained by my wifi connection since the network
is the bottleneck in cloning.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-Mc0071e2d08745673c7852cd2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Software preservation in the post-hg era

[Dave MacFarlane]

On Mon, Mar 30, 2020 at 9:12 PM Sean Hinchee  wrote:

> As a footnote, there's a decent git client written in Go that works
> alright on plan9 [4], but it's slow and memory intensive at the
> moment.
>
>
[...]

[4] https://github.com/driusan/dgit

This (and the fact that the speed of Go on Plan9/amd64 seems to be finally
be useable enough to do development again as of 1.14..) finally gave me the
kick I needed to fix some of the hacks that were causing performance
problems on clone. The self-clone time went from ~160s to ~13s on my
machine (compared to ~8s with "real" git) If there's other parts that you
were referring to as being slow and memory intensive let me know (or if you
still find it's memory intensive, I didn't benchmark that part..)

- Dave

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-Mbc073232aabcf86a9843
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Software preservation in the post-hg era

[Dave MacFarlane]

On Tue, Mar 31, 2020 at 10:46 AM  wrote:
> > If anyone has further thoughts, anything they want added, or any lists
> > or indices of works they want archived/mirrored, I would love to see
> > these posted.
>
> I think the lede got buried here, and people went of discussing git
> clients.
>
> Given that the aptly-named bitbucket is deleting mercurial repositories,
> is there anything of interest that should be retrieved before they empty
> the bitbucket onto the curb?
>

Is Inferno already mirrored?

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T303744e1ec6d2108-M8ffeabfca5531d4d9caffcb1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Request for (constructive?) comments: Plan 9 : 2020

[Dave MacFarlane]

On Tue, Oct 29, 2019 at 3:44 PM Lyndon Nerenberg  wrote:
>
> Lyndon Nerenberg writes:
>
> > Maybe an unofficial get together around BSDCan in Montreal next spring?
>
> Doh!  BSDCan is in Ottawa, not Montreal.  The suggestion still stands.
>

Ottawa is only about a 2 hour drive from Montreal and the train is
relatively cheap.

(If there's enough people in the area and an interest in an unofficial
Montreal get together, I can do what I can help organize..)

- Dave

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2e674653159c4ce8-M732cac8c9963410a8ba4a083
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Git client

[Dave MacFarlane]

I could be mistaken, but I think they're posix shell, not bash, so you
might be able to just bind ape over /bin and run them.

On Mon, Apr 22, 2019, 08:59 Kyohei Kadota,  wrote:

> I don't run tests yet because tests are written in bash with
> traditional Unix tools.
> Especially my Plan 9 box hasn't installed Perl.
>
> 2019年4月22日(月) 21:10 Dave MacFarlane :
> >
> > Nice work. (Note to self: avoid libexpat)
> >
> > Can you run the official git tests in the "t" subdirectory of the git
> repo, or do they all depend on some of the ancillary git commands that
> aren't built? If so, I'm curious how many of the tests are passing.
> >
> > On Sun, Apr 21, 2019, 07:07 Kyohei Kadota,  wrote:
> >>
> >> Hi, 9fans.
> >>
> >> I ported official Git client to 9legacy. It's very early version yet,
> >> but it can do basic commands such as fetch, pull, log, add, and commit
> >> -m.
> >>
> >> Probably there are many bugs. Some of them might be results from a
> >> issue of 8c that don't initialize rest fields of struct and union with
> >> zero if field names are specified.
> >>
> >> x86 binaries are available here:
> >> https://lufia.org/git-386.tgz
> >>
> >> Source codes:
> >> - https://github.com/0intro/plan9-contrib/pull/6
> >> - https://github.com/0intro/plan9-contrib/pull/7
> >> - https://github.com/madler/zlib/pull/398
> >> - https://github.com/libressl-portable/portable/pull/510
> >> - https://github.com/libexpat/libexpat/pull/242
> >> - https://github.com/curl/curl/pull/3701
> >> - https://github.com/lufia/git
> >>
> >> - kadota
> >>
>
>

Re: [9fans] Git client

[Dave MacFarlane]

Nice work. (Note to self: avoid libexpat)

Can you run the official git tests in the "t" subdirectory of the git repo,
or do they all depend on some of the ancillary git commands that aren't
built? If so, I'm curious how many of the tests are passing.

On Sun, Apr 21, 2019, 07:07 Kyohei Kadota,  wrote:

> Hi, 9fans.
>
> I ported official Git client to 9legacy. It's very early version yet,
> but it can do basic commands such as fetch, pull, log, add, and commit
> -m.
>
> Probably there are many bugs. Some of them might be results from a
> issue of 8c that don't initialize rest fields of struct and union with
> zero if field names are specified.
>
> x86 binaries are available here:
> https://lufia.org/git-386.tgz
>
> Source codes:
> - https://github.com/0intro/plan9-contrib/pull/6
> - https://github.com/0intro/plan9-contrib/pull/7
> - https://github.com/madler/zlib/pull/398
> - https://github.com/libressl-portable/portable/pull/510
> - https://github.com/libexpat/libexpat/pull/242
> - https://github.com/curl/curl/pull/3701
> - https://github.com/lufia/git
>
> - kadota
>
>

Re: [9fans] Git/fs: Possibly Usable

[Dave MacFarlane]

On Tue, Apr 2, 2019 at 12:49 AM  wrote:
> One caveat I have: Git's index file format is a bit
> boneheaded, so I'm ignoring it. The index doesn't affect
> the wire protocol, so this isn't an interoperability issue,
> unless you share the same physical repository on both
> Plan 9 and Unix. If you do, expect them to get out of
> sync on uncommitted but added files.
>

What problems did you have with the index format? In my experience
it was relatively sane (relative to the pack protocol/format, I mean,
which is a pretty low bar to set.)

- Dave

Re: [9fans] plan9port : complete system : kernel : freebsd || linux ?

[Dave MacFarlane]

What do you mean by "a complete, installable system for plan9ports"?

If you mean one that uses p9p in place of gnu utils, that's something
I've thought about
trying to do before, but I'd suggest taking it one step further and
seeing if you could use
a 9p root filesystem and see how far you can take the per process
namespaces of Linux
to make it feel like Plan 9. (AFAIK, that wouldn't be possible with
NetBSD or FreeBSD, but
I might be mistaken..)

- Dave
On Tue, Oct 2, 2018 at 7:32 AM Mayuresh Kathe  wrote:
>
> i had been trying to work with a collaborator to develop a complete,
> installable system for plan9port.
>
> while initially being quite gung-ho about linux, an accidental discovery
> and ensuing experiements show the freebsd environment to be a lot more
> performant and responsive, almost as much as netbsd for something like a
> plan9port system.
>
> wish to ask the community that if such a system were to be successfully
> developed and distributed with source and free of cost, would it be
> welcomed or most would not even bother to look at?
>
> also, if there's enough interest, would there be someone out here
> capable enough to support netbsd-amd64?
>
> thanks,
>
> ~mayuresh
>
>


-- 
- Dave

Re: [9fans] aux/wpa

[Dave MacFarlane]

There's probably a better way, but I do:

bind '#l1' /net
echo 'key proto=wpapsk essid=wifiname !password=hunter2' >> /mnt/factotum/ctl
aux/wpa -s wifiname /net/ether1
ip/ipconfig ether /net/ether1
auth=myauthserver

in my /cfg/$host/termrc, since I don't have access to the secstore on
myauthserver until I'm connected to the wifi.
On Fri, Sep 21, 2018 at 8:30 PM G B  wrote:
>
> Now that I have 9front installed on my Thinkpad T60 and WiFi is working, how 
> do I get aux/wpa set to run at boot?
>
> Do I need to setup a secstore and add wpapsk to factotum?  How does factotum 
> know which to use if you had a key for say mail, aux/wpa, etc?
>


-- 
- Dave

[9fans] Git

[Dave MacFarlane]

I've been trying to do more development of dgit under 9front instead of
DragonFly so that it'll force me to catch/fix any major bugs missed by the
test suite. I fixed one significant performance problem and now it seems to
mostly be useable for basic git usage under Plan 9 (or at least 9front) and
pushing to GitHub. I also added factotum support (at least for the
password, it still prompts for the username..)

I wrote up some instructions for how to set it up (and use it instead of
the rc script for go) at http://driusan.github.io/plan9/git.md

- Dave

Re: [9fans] 9front VMX

[Dave MacFarlane]

I've always found performance to be terrible for OpenBSD even on
physical hardware, so I can't really hold that against vmx..

- Dave

Re: [9fans] Is Plan 9 C "Less Dangerous?"

[Dave MacFarlane]

On Tue, Sep 4, 2018, 22:31 Chris McGee,  wrote:

>
> I believe that the core of the problem with the C language is that is
>> based upon abstracting the PDP-11 instruction set.  CPUs, such as Intel/AMD
>> x64 are vastly more complex so "optimising" C compilers are trying to make
>> something simple take advantage of something far more complex.  Perhaps we
>> should call them "complexifying" compilers.
>>
>> Generally, model-to-model transformations (which is effectively what
>> compilers do under the covers) are easier to define when we transform from
>> a higher level of abstraction to a lower level of abstraction.  As folks in
>> the MBSE field explain it, trying to put a pig together from sausages.
>>
>
> I wonder if the hardware world suffers from some of the same complexity
> problems the software world does. Is it possible to build much simpler
> hardware as well or are there real physical properties that force them to
> be as complex as they are now?
>

Wasn't that the whole point of RISC?

>

Re: [9fans] question about #include_next directive

[Dave MacFarlane]

How advanced is your git usage? If you're only doing simple merges and pushes
dgit (https://github.com/driusan/dgit) is approaching useful since
someone taught
me how to throw the official git test suite at it.

I definitely wouldn't recommend it as a daily driver, but if you only
want to push a
couple things here and there, don't rebase, and have a fairly linear
history it might
work for you.

- Dave

On Fri, Aug 3, 2018 at 2:35 PM, Kyohei Kadota  wrote:
> Thanks cinap.
>
> I know Plan 9's devtls is more useful than Unix's libraries, but finally
> want to use git and github.com on Plan 9.
> My team works frequently with git.
>
> Git-wrapper can clone but it can't merge, push, and so on.
> And I started to port LibreSSL because official git links some libraries
> such as libexpat, libcurl, and openssl.
>
> 2018-08-04 0:22 :
>>
>> what are you intending to use libressl for in native plan9?
>> plan9 already has a crypto library (libsec) which is a fraction of the
>> size of openssl and works quite well. i'v been using it to implement
>> many crypto protocols to talk to the outside world.
>>
>> for tls, plan9 uses devtls which allows you to wrap any file descriptor
>> to make it a encrypted channel and then you get a filedescriptor back
>> that you can pass arround, so the programs communicating actually dont
>> even need to know the secret session keys. so adding tls support to
>> programs is very trivial in plan9. one function call basically to wrap
>> the fd. while in unix programs that want encryption have to change all
>> ther read and wirte calls to use special libssl functions.
>>
>> also, plan9 has factotum to hold and work on secret keys. you can use
>> factotum todo the public key operations like signing, encryption and
>> decryption using the key for you so keys never have to leave factotum.
>>
>> even if you port programs from unix, it might be worth taking a step
>> back and learn how plan9 does crypto, which is quite advanced compared
>> to traditional unix.
>>
>> --
>> cinap
>>
>



-- 
- Dave

Re: [9fans] SCMs

[Dave MacFarlane]

On Feb 14, 2018 02:22, "Rui Carmo"  wrote:



> On 14 Feb 2018, at 01:47, Bakul Shah  wrote:
>
> Dave MacFarlane's git client (dgit) does a decent job on plan9.

This interests me greatly. Last time I checked there wasn’t a good enough
got client, so I used Mercurial. Where is dgit exactly?

R.


https://www.github.com/driusan/dgit/

It's written in Go, which means it'll only work on platforms that Go
supports (I think there's a list somewhere on the Go wiki, but it's some
subset of 386/arm/amd64 depending on which fork you're using.)

[9fans] DKIM with upas

[Dave MacFarlane]

I started hosting my personal domain's email on 9front and wanted to
sign my outgoing emails with a DKIM, so I wrote something in Go that
reads a message from stdin and writes a DKIM signed version to stdout
(https://github.com/driusan/dkim).

I was planning on using it in /mail/lib/remotemail by having the final
"exec smtp [...]" replaced by " exec dkimsign [...] | upas/smtp [...]"
and that works with marshal (if I ensure that I add all the headers
that I'm signing manually), but not acme.

>From what I can tell, acme always uses a From line of "From:
localname" (overriding any that you manually specified), and expects
upas/smtp to add in the domain, which is causing the signature to fail
after smtp modifies the signed header. (marshal leaves any headers
that you manually specify unmolested, so the signature is valid as
long as you include a fully qualified From: line while writing the
message.)

Is there a better place/way to do the signing? Ideally I could sign it
as the last thing it does before going out over the wire, but at the
very least I need to sign it after expanding the addresses. (The
standard says I also need to do the hashing before smtp dot stuffing,
but I can take care of that with a flag on the Go side..) The best I
can think of is some convoluted mix of "upas/smtp -f .domainname |
dkimsign | [some script that undoes most of what upas/smtp -f did ] |
upas/smtp", but I have a feeling I'm just missing some better place to
do the signing from.

- Dave

Re: [9fans] Go on amd64

[Dave MacFarlane]

Nevermind, the problems went away after recompiling 1.9.2 from source a
second time, something must have went wrong with my initial bootstrap..

On Dec 20, 2017 19:29, "Dave MacFarlane" <driu...@gmail.com> wrote:

What's the latest version of Go on amd64 that anyone's used successfully?

I just reinstalled 9front after putting in a new SSD on my laptop and
I'm getting panics about errors lowering to SSA while trying to
compile dgit, but I'm not sure if something went wrong bootstrapping
go 1.9.2 or how much effort I should into trying to put into make a
minimal test case (the function it's panicing on is going to be hard
to extract and I don't have any ideas what's special about it that's
causing a panic..)

--
- Dave

[9fans] Go on amd64

[Dave MacFarlane]

What's the latest version of Go on amd64 that anyone's used successfully?

I just reinstalled 9front after putting in a new SSD on my laptop and
I'm getting panics about errors lowering to SSA while trying to
compile dgit, but I'm not sure if something went wrong bootstrapping
go 1.9.2 or how much effort I should into trying to put into make a
minimal test case (the function it's panicing on is going to be hard
to extract and I don't have any ideas what's special about it that's
causing a panic..)

-- 
- Dave

Re: [9fans] git

[Dave MacFarlane]

David du Colombier's rc script is required to bootstrap my version
anyways, so it's the best place to start (though dgit should work to
for "go get"  if you bind it to have the name "git" in your
namespace). The upside of his is that it's more reliable and is less
likely to have a bug that eats your children, but the downside is that
it isn't a git client.

On Wed, Nov 29, 2017 at 4:25 PM, Skip Tavakkolian
 wrote:
> David du Colombier (djc) has a rc script.  I've used it to keep up with Go.
>
> http://9legacy.org/9legacy/tools/git
>
> driusan has written one in Go:
>
> https://github.com/driusan/dgit
>
>
> On Wed, Nov 29, 2017 at 9:00 AM Steve Simon  wrote:
>>
>> A few years ago there was some discussion about plan9 git clients.
>>
>> Is there any solution for using git from plan9, or do I have to use an
>> inferior OS?
>>
>> -Steve
>>
>



-- 
- Dave

[9fans] Reimplementing Plan 9 in Go (Was: Re: [9front] bio io functions)

[Dave MacFarlane]

On Fri, May 5, 2017 at 6:21 AM, Stanley Lieber  wrote:
>
> Plan 9 has not yet been re-implemented in Go.
>
> sl
>

I started trying to do that at one point, but never got my kernel much
farther than booting just enough to run "Hello, world!" compiled with
6c on a FAT filesystem in ring 0 and then crashing the system before
deciding I don't have the time to finish it or get it somewhere
useable. If anyone who has the time is interested in picking it up,
contact me off-list and I'll send you a link to my (horribly written
and designed) code.

I'm more of a userspace kinda guy anyways..

- Dave

Re: [9fans] Raspberry Pi plan9, keyboard not working.

[Dave MacFarlane]

I recommend a simple wireless keyboard/mouse combo. That way the
dongle only takes up 1 of the USB ports for both keyboard and mouse,
since they share the dongle. I never had any problem with either of
both the wireless combos that I've tried with Richard's arm port on my
pi. (I think one was logitech, and one was a microsoft.)

On Tue, Mar 7, 2017 at 1:09 AM, Bakul Shah  wrote:
> On Tue, 07 Mar 2017 01:55:49 GMT kraftkl...@memeware.net wrote:
>> Dear,
>>
>> I just put plan9 onto my raspi. When I plug it in , it all seems to
>> work, including the mouse, but my wired USB keyboard (a dell rt7d10)
>
> This keyboard has 7 "hot keys" -- chances are it is sending
> some code not understood by plan9's kbd driver. Suggest buying
> a keyboard that has no fancy features.
>
>> will not work. I get the error:
>> error intr 082
>> With more 0s, but I didn't bother counting.
>> Why is this? Can this problem be solved in the software, or do I need to
>
> Assuming the message starts out something like
> usbotg: epX.Y error intr
> it is from /sys/src/9/bcm/usbdwc.c.  0x80 means Xacterr
> (transaction error) and 0x02 means Ahberr (AHB DMA error).
>
>> just buy another keyboard?
>
> Yes. A simple non-fancy keyboard.
>



-- 
- Dave

Re: [9fans] SHA-1 collision and venti

[Dave MacFarlane]

Why not skip sha-256 and go directly to Sha3?

On Sun, Feb 26, 2017 at 4:02 PM, Kim Shrier  wrote:
> I have had a personal project on my list of "things to do
> when I have time", is to redo venti using sha256.  Does
> any body see any problems with doing that?
>
> Kim
>
>



-- 
- Dave

Re: [9fans] Update APE

[Dave MacFarlane]

Doesn't being a secret, dark hidden project imply existence?

On Tue, Feb 21, 2017 at 5:20 PM,   wrote:
> Jens Staal  writes:
>
>> If someone could backport apex from Harvey, that would be cool.
>
> I've seen this "Harvey" thing mentioned here and there, but does it
> really exist?  I tried subscribing to the "Harvey" mailing list, but my
> subscription request was rejected.  So I just assumed it was a secret,
> dark project hidden to all but a select inner circle of digital ninjas.
>



-- 
- Dave

[9fans] my git client, again

[Dave MacFarlane]

I finally got a laptop that can connect to my network under Plan 9 so
I can work on my Go git client, and enough of it's done that I'm
primarily developing it under 9front/amd64 now. I've caught most of
the stupid things where I was taking for granted things that the
official git client had done as side-effects while I was bootstrapping
it under other OSes..  and I fixed some little things like it trying
to use $EDITOR instead of $editor under Plan 9.

I'm most of the way to having three-way merge done (the low-level
three-way read-tree is done, I just can't figure out any easy way to
handle git-merge-file(1) using ape/???, which means I can't handle
conflicts, which I need to do before adding it to the porcelain merge
command.) diff is also almost there (the basic low level
git-diff-files(1) and git-diff-index(1) work, including the "-p"
option to display a patch, I just need to write the porcelain diff
command so that you don't need to remember how to use them directly.)

I decided to rename the repo from "go-git" to "dgit", because typing
"go-" at the start of a command name is annoying, there's already a
more popular Go libgit2 implementation  named go-git, and I couldn't
think of a better name than just adding my initial to it, so if anyone
wants to try it or contribute, it now lives at
https://github.com/driusan/dgit instead.

- Dave

Re: [9fans] [9front] DHCP not working on usb ethernet dongle

[Dave MacFarlane]

I don't think it's related, since there's no primary ethernet or /net
on the laptop for it to conflict with (there's just a wifi card that
isn't supported, which is why I needed the dongle in the first place.)

I spent some time comparing nusb/ether/asix.c to the axeg(4) driver on
my lunch hour yesterday, and I'm suspecting that it might be a 88178
vs 88178a chipset thing since the rx ctl register is different between
the two drivers and the problem is that asixreceive() is never getting
called, but I haven't had a chance to dig any deeper or verify if it's
an "a" chipset with mislabeled packaging while I have physical access
to the machine/dongle.

On Wed, Jan 4, 2017 at 6:20 PM, Steve Simon  wrote:
> Its not the same problem, but just in case it helps,
> adding a second usb ether adapter onto a raspberry pi,
> which runs the labs distro not 9front.
>
> I need to add
> ether1=type=usb
> to cmdline.txt
>
> and then add the following to /cfg/$sysname/termrc
>
> if(! ~ `{cat '#l1/ether1/addr'} ){
> echo ether1: present
> bind -b '#l1' /net.alt
> bind -b '#I1' /net.alt
> ip/ipconfig -x /net.alt ether /net.alt/ether1
> ndb/cs -x /net.alt
> ndb/dns -x /net.alt -r
> }
> if not {
> echo ether1: missing
> }
>
> this worked seamlessly once I got a supported, and reliable ethernet dongle.
> I tried a couple of chinese ones but settled on an apple one which is well
> manufactured (perhaps I was just unlucky).
>
> All kudos to Richard Miller who helped me through this.
>
> -Steve



-- 
- Dave

Re: [9fans] git client-ish

[Dave MacFarlane]

On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee  wrote:
>
> The tests seem to be passing. I will try more rigorous tests. If the github
> bug gets fixed then I can submit pull requests.

The bug that was preventing me from pushing to GitHub is now fixed, so
if you update
feel free to pull request away.

- Dave

Re: [9fans] git client-ish

[Dave MacFarlane]

Yeah, someone already pointed out those two problems off-list. There
should be a fix committed. It turns out that none of the stat(3)
information that git dumps into the index is really required (just the
mtime and size, which you can get from the os.FileInfo), so the best
cross-platform fix is probably to just set the things you had to
change to 0. The Go syscall package also seems to do some weird things
like using different field names in its Fstat struct on different
platforms, so is best avoided.

The sha1 thing is just because I forgot to commit something.

(and I'm not sure that "tests" is appropriate to pluralize in this
context. There's only one, and it's.. not rigorous.)

On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee <newton...@gmail.com> wrote:
> Thanks for the tool.
>
> I managed to get it working on plan9front/386 Go 1.8 beta1 with a network
> connection. I will probably try it soon on plan9/arm.
>
> Initially, it did not compile. Here are the quick fixes that I needed to
> make.
>
> 1) There is no syscall.Stat_t on plan9, instead the stat.Sys() returns a
> syscall.Dir
>
> index.go:AddFile():
> I changed stat to be fstat.Sys().(*syscall.Dir)
> csec = stat.Mtime (This is how APE maps ctimes)
> cnano = uint64(0) (There does not seem to be any nanosecond precision on
> mtimes in plan9)
> uint32(stat.Qid.Path) (Roughly equivalent to inode numbers)
> uint32(0) (GID’s are strings in plan9)
> uint32(0) (UID’s are strings)
> I assume that you want the library to be platform neutral so these should
> probably be abstracted.
>
> 2) Compile error
>
> sha1.go:GetTree()
> Sha1FromString(commit.Tree.Id.String())
>
> The tests seem to be passing. I will try more rigorous tests. If the github
> bug gets fixed then I can submit pull requests.
>
> Cheers,
> Chris
>
> On Dec 3, 2016, at 2:20 PM, Dave MacFarlane <driu...@gmail.com> wrote:
>
> I mentioned in another thread that I had started working on a pure go
> git client a while ago, then abandoned it, which gave me an itch to
> pick it up again. I've finally implemented enough that it can
> bootstrap its own development, and theoretically be used on Plan 9,
> but then I realized I don't currently have any machines with all of
> Plan 9, Go, and a network connection to test it on.
>
> Would someone who has all of the above kindly try compiling it on Plan
> 9 and let me know if there's any problems? It's at
> https://github.com/driusan/go-git.You'll need the 9legacy git rc hack
> for Go to bootstrap it..
>
> You should be able to:
> go-git init
> go-git clone*
> go-git fetch*
> go-git add file (from the root of the working directory only)
> go-git checkout file (same)
> go-git commit -m 'message'
> go-git status
> go-git merge (fast-forward only)
> go-git push works over https to GitLab, but not GitHub (GitHub
> responds with "200 OK" and no body but doesn't update the references,
> so I opened a ticket to see if I can get more information from them
> about why it doesn't work.. you also need to run as "go-git push
> localbranchname", which isn't the standard git command line.. )
>
> The happy paths for a few other git plumbing commands are implemented.
>
> The code's not very well written (I didn't know much about git
> internals or Go when I started, and mostly just wanted to hack
> something together that works at first), but if anyone wants to
> contribute, you can try to email me a patch using ape/diff in some
> kind of format that I can apply under DragonFlyBSD and commit under
> your name until whatever the issue with GitHub is is resolved..
>
> * large repositories will likely crash because the Go zlib
> implementation is greedy on the underlying io.Reader, and the hack
> that I added to rewind to the end of the last compressed block when
> reading packfiles isn't 100% accurate.
>
> - Dave
>
>



-- 
- Dave

[9fans] git client-ish

[Dave MacFarlane]

I mentioned in another thread that I had started working on a pure go
git client a while ago, then abandoned it, which gave me an itch to
pick it up again. I've finally implemented enough that it can
bootstrap its own development, and theoretically be used on Plan 9,
but then I realized I don't currently have any machines with all of
Plan 9, Go, and a network connection to test it on.

Would someone who has all of the above kindly try compiling it on Plan
9 and let me know if there's any problems? It's at
https://github.com/driusan/go-git.You'll need the 9legacy git rc hack
for Go to bootstrap it..

You should be able to:
go-git init
go-git clone*
go-git fetch*
go-git add file (from the root of the working directory only)
go-git checkout file (same)
go-git commit -m 'message'
go-git status
go-git merge (fast-forward only)
go-git push works over https to GitLab, but not GitHub (GitHub
responds with "200 OK" and no body but doesn't update the references,
so I opened a ticket to see if I can get more information from them
about why it doesn't work.. you also need to run as "go-git push
localbranchname", which isn't the standard git command line.. )

The happy paths for a few other git plumbing commands are implemented.

The code's not very well written (I didn't know much about git
internals or Go when I started, and mostly just wanted to hack
something together that works at first), but if anyone wants to
contribute, you can try to email me a patch using ape/diff in some
kind of format that I can apply under DragonFlyBSD and commit under
your name until whatever the issue with GitHub is is resolved..

* large repositories will likely crash because the Go zlib
implementation is greedy on the underlying io.Reader, and the hack
that I added to rewind to the end of the last compressed block when
reading packfiles isn't 100% accurate.

- Dave

Re: [9fans] Plan 9 5th Edition

[Dave MacFarlane]

On Wed, Nov 16, 2016 at 6:53 PM, Chris McGee  wrote:
> For git, there's a wrapper script for github and others. But yes, a fuller
> featured git would be good. There are some projects trying to do that in Go.
> Maybe that'll work someday.

I know I started a really half-assed, wholly-abandoned implementation
here: https://github.com/driusan/go-git
when I was starting to learn Go so that I could fix a bug in some of
my code on Plan 9 (eventually I just made
the change, tested it, and copied the file to a supported git platform
over drawterm, and commited it from there..)

Who else is trying to do it?

- Dave

Re: [9fans] More about /dev/draw

[Dave MacFarlane]

On Mon, May 30, 2016 at 8:37 AM, Richard Miller <9f...@hamnavoe.com> wrote:

> > It turns out that the interface 9pi used for querying framebuffer depth
> > is also now broken.  Setting framebuffer_depth=N in config.txt used to
> > work for changing the pixel format, now it doesn't.
>
> OK, new 9pi and 9pi2 kernels in /n/sources/contrib/miller should now do
> the right thing for 24bpp, which can be requested with framebuffer_depth=24
> in config.txt or vgasize=WxHx24 in cmdline.txt
>

I was pretty sure it was either a kernel or libmemdraw bug, but I don't
know how you can possibly
track these things down so quickly without even getting a proper bug
report.

- Dave

Re: [9fans] More about /dev/draw

[Dave MacFarlane]

Probably a typo, I was going from memory. I thought it was a multiple of 8
bits per component, not for the whole thing, so that (and a typo) would
explain it.

But the bigger problem was that even if you only have 1 bit for r, g, and b
you should be able to represent yellow as 110, so any r>1g>1b>1 should be
able to handle it.

On Mon, May 30, 2016 at 5:27 AM,  wrote:

> 6+5+6 is 17, not 16 bit. is this a typo or was r5g6b5 ment?
>
> --
> cinap
>
>


-- 
- Dave

Re: [9fans] More about /dev/draw

[Dave MacFarlane]

Well, that led me down a rabbit hole where I found two problems and now I'm
having a third that I need advice on. The main problem was that I was
forgot to set the draw op to src when doing the final draw of the window,
so it was defaulting to SoverD. Second, unrelatedly, the alpha masks were
being doubled (or halved, I guess) when filling an alpha channel because I
was using the same id as the src and the mask since they have the same
bounds, so the mask was getting multiplied through a second time, but that
wasn't affecting the background disappearing since they were opaque colours.

Now, after setting the drawop to src, I'm getting a black background
instead of a dark blue one. I tried changing the colours arbitrarily to see
if black was just how it represents an alpha channel when there's nothing
under it, and with lighter colours it's drawing a yellow background on
drawterm and a pink one on the Pi. I've narrowed it down to the fact that
the the screen channel descriptor on the Pi is different. When I do cat
/dev/draw/new, it's telling me it's an r6g5b6 channel while in drawterm
it's x8r8g8b8. I'm not sure how that's possible though, because I'm fairly
sure I remember reading in a man page that channels had to be multiples of
8, though I can't find where I read that now.

Is there anything I can do about this? I'm fairly sure an r6g5b6 channel
should be able to represent yellow as a combination of red and green, but
the the format of colours in a draw operation is irrespective of the
channel format, so I can't be doing anything wrong there. Oddly, the places
where I'm directly replacing pixels in the buffer with 'y', where the
channel format *does* matter seem to be fine, but I think that might just
be luck because the gradient is mostly red and green.

On Sun, May 29, 2016 at 8:58 AM, Charles Forsyth <charles.fors...@gmail.com>
wrote:

>
> On 29 May 2016 at 13:44, Dave MacFarlane <driu...@gmail.com> wrote:
>
>> Why would the alpha channel work differently with the same image from the
>> same code with the same hardware
>> depending on the driver?
>>
>
> Because there might be a difference in the way the components inside the
> pixel word are being interpreted or used by memdraw.
>



-- 
- Dave

Re: [9fans] More about /dev/draw

[Dave MacFarlane]

Why would the alpha channel work differently with the same image from the
same code with the same hardware
depending on the driver? (I've already tried setting it to a 50% alpha just
in case it was something like a bug
in drawterm not honouring the alpha channel and I was doing something
stupid. The 50% alpha worked fine
in drawterm but didn't change anything locally..)

On Sun, May 29, 2016 at 6:50 AM, Charles Forsyth <charles.fors...@gmail.com>
wrote:

>
> On 28 May 2016 at 18:23, Dave MacFarlane <driu...@gmail.com> wrote:
>
>> Does anyone have any pointers?
>
>
> I'd check that the image you're drawing with S over D isn't filled with a
> completely transparent value
> if the image has got an alpha channel.
>



-- 
- Dave

Re: [9fans] More about /dev/draw

[Dave MacFarlane]

That's exactly what I'm doing. I don't have a monitor with HDMI within
network-cable and power-cable reach to hook it up to, and the last time I
hooked it up to my TV my toddler tore the usb/power cable of the Pi in two,
so I can only try debugging it when he's not around..

(And Go 1.6 or later for Plan9, but 1.7 or later for ARM, for the record..)

On Sat, May 28, 2016 at 1:34 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> a quick and easy way to get a local Plan 9 terminal is to use 9Pi (Plan 9
> on Raspberry Pi). with Go 1.6 and later you can cross compile for plan9/arm.
>
>
> On Sat, May 28, 2016 at 10:24 AM Dave MacFarlane <driu...@gmail.com>
> wrote:
>
>> Either I'm going insane, the default Plan 9 /dev/draw in-memory
>> implementation
>> doesn't implement draw(3), or possibly both.
>>
>> When I do the following, it works as expected under both drawterm and a
>> locally mounted instance:
>> 1. Allocate a screen with an 'A' message
>> 2. Allocate an image on the screen of the same size as /dev/wctl  with a
>> 'b' message
>> 3. Draw the image over the window with a 'd' message
>> 4. Flush the buffer with 'v'
>>
>> When I do the following, it works under drawterm, but not with a local
>> /dev/draw implementation:
>> Steps 1-2 above
>> 3. Allocate another image of some arbitrary fill colour with 'b' (with or
>> without the repl bit)
>> 4a. (Optional, doesn't seem to make a difference) set the compositing
>> operator with 'O'
>> 4b. Draw the new image over a portion of the window image from step 2
>> with 'd'
>> 5. Go to step 3-4 from the first variation.
>>
>> (I don't have a 9front instance to test on.)
>>
>> On the other hand, replacing a portion of the image from step 2 with 'y'
>> works under either. (I haven't gotten around to using 'Y' when appropriate
>> yet.)
>>
>> Basically, I can only get any variation of this code:
>> https://github.com/driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devdrawdriver/uploadimpl.go#L50
>>
>> to work under drawterm.
>>
>> The end result is that under a local Plan 9 instance the basic sample
>> shiny test looks like this:
>>
>> http://driusan.github.io/plan9/basicmem.png
>>
>> Instead of this:
>>
>> http://driusan.github.io/plan9/basicdrawterm.png
>>
>> Does anyone have any pointers? I don't have much access to a physical
>> Plan 9 machine, so I'm having trouble debugging this since it works under
>> drawterm (or perhaps is buggy under drawterm in a way that makes it seem
>> like it's working..)
>>
>> It would also potentially be helpful if someone who uses Go under 9front
>> could let me know how x/exp/shiny/examples/basic looks with the shiny
>> driver in that branch, but I'm not sure that it matters since it'll most
>> likely be the same as one of the above..
>>
>> - Dave
>>
>


-- 
- Dave

[9fans] More about /dev/draw

[Dave MacFarlane]

Either I'm going insane, the default Plan 9 /dev/draw in-memory
implementation
doesn't implement draw(3), or possibly both.

When I do the following, it works as expected under both drawterm and a
locally mounted instance:
1. Allocate a screen with an 'A' message
2. Allocate an image on the screen of the same size as /dev/wctl  with a
'b' message
3. Draw the image over the window with a 'd' message
4. Flush the buffer with 'v'

When I do the following, it works under drawterm, but not with a local
/dev/draw implementation:
Steps 1-2 above
3. Allocate another image of some arbitrary fill colour with 'b' (with or
without the repl bit)
4a. (Optional, doesn't seem to make a difference) set the compositing
operator with 'O'
4b. Draw the new image over a portion of the window image from step 2 with
'd'
5. Go to step 3-4 from the first variation.

(I don't have a 9front instance to test on.)

On the other hand, replacing a portion of the image from step 2 with 'y'
works under either. (I haven't gotten around to using 'Y' when appropriate
yet.)

Basically, I can only get any variation of this code:
https://github.com/driusan/exp/blob/18a78a1549541d46d26cb6088a904585c386d812/shiny/driver/devdrawdriver/uploadimpl.go#L50

to work under drawterm.

The end result is that under a local Plan 9 instance the basic sample shiny
test looks like this:

http://driusan.github.io/plan9/basicmem.png

Instead of this:

http://driusan.github.io/plan9/basicdrawterm.png

Does anyone have any pointers? I don't have much access to a physical Plan
9 machine, so I'm having trouble debugging this since it works under
drawterm (or perhaps is buggy under drawterm in a way that makes it seem
like it's working..)

It would also potentially be helpful if someone who uses Go under 9front
could let me know how x/exp/shiny/examples/basic looks with the shiny
driver in that branch, but I'm not sure that it matters since it'll most
likely be the same as one of the above..

- Dave

Re: [9fans] 9front sam in plan9port.

[Dave MacFarlane]

Speaking as the author of it, I wouldn't be offended by either. It's only,
like, a week old, and mostly written for myself.

But it's not going to work under Plan 9 until I finish the /dev/draw shiny
driver that I started and have been procrastinating on finishing. I should
probably try it and see how it works...

-- Dave

On Mon, May 23, 2016 at 5:28 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:

> since it's a slow news day, i'm throwing this in. i'm neither condoning
> use of it nor disparaging it.
>
> https://github.com/driusan/de
>
>
> On Mon, May 23, 2016 at 1:27 PM Mart Zirnask 
> wrote:
>
>> looks like Rob King added ctrl-b (ctrl-k in his case) to deadpixi's
>> sam about a month ago. cool. :)
>>
>> https://github.com/deadpixi/sam/commit/cdbdf04093a76cd3634e59e127bfd8f7a5083b20#diff-22f470141ff9a8838525c57e45bcdb63
>>
>> On 23 May 2016 at 10:25, Mart Zirnask  wrote:
>> >> I wasn't able to get it working remotely because the additional 'rsam'
>> >> command doesn't seem to be built. I haven't looked at that yet though.
>> >
>> > I can't confirm for now if it was built for me on Tiny Core Linux. The
>> > source and makefile for 'rsam' are included and also documented,
>> > though.
>> > it also doesn't have the 'E' command.
>> >
>> > btw, is 9front's ctrl-b patch (for switching to the command window)
>> > available somewhere?
>> > I'm really interested in having that keyboard shortcut in this version
>> of sam.
>> >
>> > best,
>> > Mart
>>
>>


-- 
- Dave

Re: [9fans] A couple questions about /dev/draw and /dev/kbmap

[Dave MacFarlane]

In that case, is there any way to get the current max packet size that 9p
will allow for
a read or write, or to determine if you're drawing to a local machine or
not? I'm not seeing anything obvious under /dev or /env.

On Wed, May 4, 2016 at 10:45 PM,  wrote:

> you wont have that limitation on devdraw on the local machine. but
> over 9p, your reads and writes are limited by the iounit of the
> channel over which 9p is transfered.
>
> the reson for having a iounit is that you'r not the only one doing
> stuff over the channel. you chunk stuff up in packets, so multiple
> things can appear as simultanious even tho theres only one serial
> channel. the bigger you make the packets, the bigger the latency
> for concurrent packets wanting to be transmitted.
>
> for the keyboard stuff. you cant do that with /dev/cons. drawterm
> only gives you runes, but no kbmap (you'r probably seeing the cpu
> servers kbmap, not the one in drawterm). in 9front [1,2], theres
> /dev/kbd [3] which also gives you button states.
>
> [1] http://9front.org/
> [2] http://drawterm.9front.org/
> [3] http://man.9front.org/8/kbdfs
>
> --
> cinap
>
>


-- 
- Dave

[9fans] A couple questions about /dev/draw and /dev/kbmap

[Dave MacFarlane]

Hi 9fans,

I have most of a working prototype of a Go Shiny driver for Plan9, but
there's a couple issues that I'd like to resolve and cleanup that I'd like
to do.

First, reads and writes to /dev/draw/n/data seem to fail if it's larger
than 65536 bytes. At 4 bytes per pixel, that's not very much (that means
the image you can read is 128x128, and the biggest you can write slightly
smaller with the overhead of the header for the write..) As a hack, I'm
splitting up the calls for rectangles larger than that when reading or
writing ('r' and 'y' messages from draw(3)) into 1 read/write per row. But
65536 bytes still seems pretty artificially low? Is there any other way
around it? I'm not even sure if it's Go, Plan9, or drawterm that's adding
this restriction..

Second, I'd like to improve the keyboard handling. Right now I'm just
assuming that reading 'a' off /dev/cons came from the a key, 'A' came from
shift-A, etc. I'd like to load /dev/kbmap and make a more intelligent guess
of "the first key code which matches this utf8 rune in the kbmap" but man
kbmap is only partially helpful. It says that column 1 is "a table number"
and column 2 is "a hardware specific scan code". I think it's safe to
assume that table 0 is the unmodified key, but other than that does anyone
have any pointers for how to go from "table number" to "modifiers which
that table represents" and "hardware specific scan code" to "USB HID Key
Code"?

- Dave

Re: [9fans] Go on Plan 9?

[Dave MacFarlane]

I've managed to get Go running on an RPi2 using a similar method, but:

1. You need to make sure you're using go-tip. <= 1.6 doesn't have Plan9/arm
support.
2. I had to apply this patch that Richard Miller sent me to my kernel:

term% diff /n/sources/contrib/miller/9/bcm/mem.h /sys/src/9/bcm/mem.h
55c55
< #define   USTKTOP 0x2000  /* user segment end
+1 */
---
> #define   USTKTOP 0x4000  /* user segment end
+1 */

(Then realized that the git client I was writing in Go wasn't ready enough
to use
as a daily driver for developing Go programs under Plan9, so I didn't go
much
further than that and compiling a few test programs..)

-- Dave

On Tue, Apr 12, 2016 at 3:21 PM, Chris McGee  wrote:

> Hi Skip,
>
> Have you managed to get Go running on an RPi this way?
>
> Cheers,
> Chris
>
> >
> > If you run Plan 9 in a VM, emulator or a confined device (RPi), it will
> be easier/faster to cross compile your app and copy it over. E.g. to
> compile for 9Pi:
> > $ GOOS=plan9 GOARCH=arm go build
> >
> >
>
>
>


-- 
- Dave