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 thre
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
>
>
>
> 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
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/am
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
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
ially 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
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, wr
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
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 tak
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
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
I've always found performance to be terrible for OpenBSD even on
physical hardware, so I can't really hold that against vmx..
- Dave
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
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
co
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.
h
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 h
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 jus
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
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 you
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 c
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 logit
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
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 subscri
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
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 yes
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.
e 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
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 cur
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 impl
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
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
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
>> sam
tupid. 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
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.
>>
>> Whe
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
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
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 de
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 (
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
40 matches
Mail list logo