Re: [9fans] Where can I find active Plan 9 communities for support and collaboration?
On August 4, 2024 7:01:11 p.m. GMT+09:00, kalona.ayeli...@fastmail.us wrote: >I am not the only one with Plan 9 issues. Here is another person with similar >problems: https://driusan.github.io/plan9.html. Wow. I don't know how you found that. Please leave the me of 10 years ago out of this thread while I decide if I should delete that site or leave it as a historical artifact. - Dave -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9804faa2e50a80d8-M26d091ea16498b4e142db497 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Transfer of Plan 9 to the Plan 9 Foundation
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
> > > > 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
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
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
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
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
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
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 ?
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
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
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
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?"
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
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
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
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
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" 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
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
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)
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.
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
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
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
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
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
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
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 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 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
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
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
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
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
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 wrote: > > On 29 May 2016 at 13:44, Dave MacFarlane 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
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 wrote: > > On 28 May 2016 at 18:23, Dave MacFarlane 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
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 > 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
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.
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
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
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?
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