the protocol (bottom left... jees, its v.v. extravagent...)
I actually don't know where to find it again...
/c: late november 2021 15<<
On Fri, Nov 5, 2021 at 1:56 PM Conor Williams
wrote:
> jees, i was away 4 a while... i have a ton of emails to catch up on &
> soon...
> /c:2021-2021:nov6 or
jees, i was away 4 a while... i have a ton of emails to catch up on & soon...
/c:2021-2021:nov6 or is it 5...
ps: I will attach a couple of handy scripts to this (now almost mine)
thread soon
once the bloody vdi boots up again & again & again... damn internet...
On Fri, Nov 5, 2021 at 1:44 PM
mornin' Kenji et al...
that particular version is... oh ah... well it's just one I open for
special occasions...
I first compiled it on one of the old sun machines now known as computers
in condae korcaigh
/c:202105111336:23
ps: i'm stuck on number 11...
pps: would you prehaps know if it is
Are you running which version of android?
Kenji
sent from android-x86_64-10.0
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M21d3858481b87f8ef1801de0
Delivery options:
v.v. good yet v.v. strange sounds.. /c:202105110315:23
ps: any one got the oberon plugin /w
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M0318941023a1e3d1bf4e493d
Delivery options:
oups...
4
/c:midday nov 2
0
0
On Thu, Nov 4, 2021 at 3:15 AM Conor Williams wrote:
>
> hmmm :-(
>
> /c:2021-cald...bye
>
> On Thu, Nov 4, 2021 at 12:32 AM Conor Williams
> wrote:
> >
> > finally getting around to factotoom...
> > laters - /c:2021:nov21midnight
> > ps: anyone got any chocolate
finally getting around to factotoom...
laters - /c:2021:nov21midnight
ps: anyone got any chocolate bars dere??
On Mon, Nov 1, 2021 at 2:58 AM Conor Williams wrote:
>
> oops make sure, if ye use that compression spacer script that you do
> not zip up a couple of
> vital commands...
> like
oops make sure, if ye use that compression spacer script that you do
not zip up a couple of
vital commands...
like daniel.gz & hamam.gz r.gz queer.gz jd.gz and mount ing.gz each.gz
and other.gz
and your sheel and did i say mount and udder.gz
/c:nov1st4amish
ps: a c version coming soon of a 7z
$ uname -a
Linux dell 5.4.0-89-generic #100-Ubuntu SMP Fri Sep 24 14:50:10 UTC
2021 x86_64 x86_64 x86_64 GNU/Linux
Also, build succeeds when fs is imported from Plan 9 and v9fs mmap
cache option enabled.
On Wed, Oct 27, 2021 at 11:38 AM Richard Miller <9f...@hamnavoe.com> wrote:
> > Go built
> Go built successfully after enabling the v9fs mmap caching on mount!
OK, that's good news. What linux kernel are you running?
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tb065f4df67a8bab9-M8354696be6c4a677c85e819b
Delivery
I did not. Go built successfully after enabling the v9fs mmap caching on mount!
- started diod like this:
sudo ./diod -f -d 1 -n -e /home/fst/SRC/tmp
- mounted it like this:
sudo mount -t 9p -n 127.0.0.1 /mnt/overdiod -o
aname=~/SRC/tmp,version=9p2000.L,uname=root,access=user,cache=mmap
-
It's mildly amusing that a language that emphases explicit error returns
should discard a system interface that does that in favour of one that's
not even a raised exception but a trap.
(ok, ok, Unix typically just returns crappy EIO on a real error, but does
distinguish several other cases such
On Oct 27, 2021, at 3:55 AM, Richard Miller <9f...@hamnavoe.com> wrote:
>> Skip, did you specify -o cache=mmap when mounting diod service
>> for the go build experiment?
>
> I tried it myself using local diod and cache=mmap. I get a similar
> SIGBUS on instruction fetch again. Conclusion: as
Richard Miller <9f...@hamnavoe.com> wrote:
> >> 1. Some of the fpga tools are closed-source so I can't check with
> >> confidence that they will never try to use mmap.
> >
> > Um, nm(1) on the binary to see what it calls?
>
> If you were distributing closed-source proprietary tools, would you
>> 1. Some of the fpga tools are closed-source so I can't check with
>> confidence that they will never try to use mmap.
>
> Um, nm(1) on the binary to see what it calls?
If you were distributing closed-source proprietary tools, would you leave
the symbol tables intact to assist reverse
On Wed, Oct 27, 2021 at 10:11 AM Richard Miller <9f...@hamnavoe.com> wrote:
> > But is it not possible that the FPGA tools don't
> > have the same issues with mmap that e.g. Go does?
>
> 1. Some of the fpga tools are closed-source so I can't check with
> confidence that they will never try to use
Richard Miller <9f...@hamnavoe.com> wrote:
> > But is it not possible that the FPGA tools don't
> > have the same issues with mmap that e.g. Go does?
>
> 1. Some of the fpga tools are closed-source so I can't check with
> confidence that they will never try to use mmap.
Um, nm(1) on the binary
> But is it not possible that the FPGA tools don't
> have the same issues with mmap that e.g. Go does?
1. Some of the fpga tools are closed-source so I can't check with
confidence that they will never try to use mmap.
2. The go compiler is open-source so it was a simple matter to make
an
On Wed, Oct 27, 2021 at 9:16 AM Richard Miller <9f...@hamnavoe.com> wrote:
> > What, precisely, is your use case?
>
> As I said, the go cross-compile was just an example task to
> test the viability of v9fs. I don't *need* to cross-compile
> on linux: the 9pi image, for example, comes with native
> What, precisely, is your use case?
As I said, the go cross-compile was just an example task to
test the viability of v9fs. I don't *need* to cross-compile
on linux: the 9pi image, for example, comes with native
go binaries which I can use for bootstrapping.
The real use case is to have some
On Wed, Oct 27, 2021 at 6:56 AM Richard Miller <9f...@hamnavoe.com> wrote:
> > Skip, did you specify -o cache=mmap when mounting diod service
> > for the go build experiment?
>
> I tried it myself using local diod and cache=mmap. I get a similar
> SIGBUS on instruction fetch again. Conclusion: as
> Skip, did you specify -o cache=mmap when mounting diod service
> for the go build experiment?
I tried it myself using local diod and cache=mmap. I get a similar
SIGBUS on instruction fetch again. Conclusion: as Bakul says, now
I'm debugging linux. Not going there, thanks.
Going further
> I think the question is why mmap works over 9p from linux up to a point but
> then fails in some context: what's the difference?
Skip, did you specify -o cache=mmap when mounting diod service
for the go build experiment?
--
9fans: 9fans
Permalink:
#!/bin/sh
# creator:: conor.willi...@gmail.com
# zipped files thingy f.s c.s... stop>
# WARNING: prototype version v1.3
##set
CMD=$1
echo $CMD
echo ${CMD}
ARGS="$2 $3 $4"
if [ "@${CMD}" = "@" ]; then
echo "give an arg...which is the command..."
exit 753;
fi
if [ ! -d /ABCD ]; then
mkdir /ABCD
I think the question is why mmap works over 9p from linux up to a point but
then fails in some context: what's the difference?
On Wed, 27 Oct 2021 at 00:47, Skip Tavakkolian
wrote:
> I don't know if I'm helping or confusing things, but here's a bit more
> experimentation;
> I did the above, and
I don't know if I'm helping or confusing things, but here's a bit more
experimentation;
I did the above, and git worked correctly with diod as the file server
(=> git requires syscalls
that 9p2000.l provides). But compiling seems to run into an untested
combinatorial case:
$
according to diod docs, mounting diod is similar to what you have:
sudo mount -t 9p -n 127.0.0.1 /mnt
-oaname=/tmp/9,version=9p2000.L,uname=root,access=user
On Tue, Oct 26, 2021 at 12:33 PM Skip Tavakkolian
wrote:
>
> Sorry, I was suggesting a potential diagnostic. I was thinking (all
> steps
Sorry, I was suggesting a potential diagnostic. I was thinking (all
steps are on Linux):
* clone go
* run diod, export / over 9P2000.L
* from the same or another linux box, mount diod-exported fs and
attempt all.bash
I am speculating that if that works, the issue might be with
unsupported fs
> there is a 9P2000.L variant that seems to
> kitchen-sink all Linux fs calls into 9P. There's a file server
> (https://github.com/chaos/diod) that implements it. It would be
> interesting to know if your case fails using it.
Sorry, I've cloned & built diod but I can't quite see how to
deploy it
is anyone working on s.d support for p.9 skip?...
/c:202110261900pmosh
ps: it's a shockin' piney day out.. or sorry cur ping!
On Tue, Oct 26, 2021 at 6:19 PM Skip Tavakkolian
wrote:
> I couldn't get this setup to work before when I tried to use git on
> Linux; there is some sort of race. It
I couldn't get this setup to work before when I tried to use git on
Linux; there is some sort of race. It may be related to flock support?
$ pwd
/mnt/9n/usr/fst
$ ls -l go
ls: cannot access 'go': No such file or directory
$ git clone https://go.googlesource.com/go
Cloning into 'go'...
error:
> if you just want to make forward
> progress in the short term, perhaps consider using the local Linux
> filesystem and exporting that to plan9 using a user-space 9p server?
Sure, that's what I did years ago to bring up go-plan9 without an
existing native go-plan9 to bootstrap from. The
i suppose there is no-reason why the tricky tricky go compiler...
i mean it even to conceptualise the concept... my god... and
taht is even before the coding of it...
i mean that my friends is what we in the business' call tricky
/c:2021102617ish
On Tue, Oct 26, 2021 at 3:55 PM Dan Cross wrote:
On Tue, Oct 26, 2021 at 6:52 AM Richard Miller <9f...@hamnavoe.com> wrote:
> > Can anyone suggest other mount options I should tweak?
>
> I have tried cache=fscache and cache=loose. In both cases I see startling
> cases of incoherency: ie reading file X returns contents of file Y (neither
> of
> Can anyone suggest other mount options I should tweak?
I have tried cache=fscache and cache=loose. In both cases I see startling
cases of incoherency: ie reading file X returns contents of file Y (neither
of which has been modified for months).
Maybe my linux kernel is too old? (4.9.0-5-amd64)
> what you did was compile pprof (not shown...) great!, and then when you ran
> it,
> it failed... on the same machine?? but surely a cross plan 9, cross
> compiler/lnker/env
> is for getting plan 9 binaries going...
> or is your prompt modified??
I'll annotate the error message a bit for
hey my main man, Richard...
u got 'go' going -- great stuff indeed
and then you tried to compile pprof and it failed -- no...
what you did was compile pprof (not shown...) great!, and then when you ran
it,
it failed... on the same machine?? but surely a cross plan 9, cross
compiler/lnker/env
is
> adding 'cache=mmap' to the mount options
> makes it work beautifully!
Not quite beautifully, it turns out. The build proceeds a lot further,
but ends with a memory fault as reported below.
Can anyone suggest other mount options I should tweak?
$ GOOS=plan9 GOARCH=386
38 matches
Mail list logo
