Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
Some of these programs are just really thin wrappers around system calls. I don't see how they would benefit from being rewritten in go. Goblin was a fun way to learn go, not a project to be useful. However i would be happy to see some new programs written in go. For example we lack a picture manipulation program. I'd like to see one done the plan 9 way. ie layers as image(6) files and a bunch of small filter programs taht work on them (like crop resample..) And some interface holding this all together. (Maybe a graphics enabled acme?)
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
Hello again, Wow i wrote this post a little while before falling asleep and certainly didn't expect such a torrent of replies O.o @ Aram Hăvărneanu : Thanks for the interest! some of the tools you mentioned are already implemented in Goblin, but i could always take a second look at them see whether they need any "modernizing" tweak or be more golang/ idiomatic go like. @Kurt, @Andrey It is hyped and tinkertoy like kit but calling it java like is too much :P -- Regards, Alex-P. Natsios (a.k.a Drakevr)
Re: [9fans] 5l bug
Patching p -> scond = q -> scond in /sys/src/cmd/5l/noop.c fixes this
unfortunate linker bug.
On Sunday, April 28, 2013 10:54:18 PM UTC-7, Paul Patience wrote:
> Mischief reported a crash with on arm with
>
> winwatch when closing all windows excluding those
>
> ignored through the -e flag. Cinap_lenrek
>
> narrowed the problem down to a bug in the 5l
>
> linker: it generates incorrect code when using
>
> the conditional operator and dividing.
>
> A minimal test case is the following:
>
>
>
> term% cat foo.c
>
> #include
>
> #include
>
>
>
> void
>
> main(void)
>
> {
>
> int i, j, k;
>
>
>
> i = 1;
>
> j = 0;
>
> k = j <= 0 ? 1 : 2/i;
>
> print("%d\n", k);
>
> exits(nil);
>
> }
>
>
>
> The output of asm(main) in acid is:
>
>
>
> acid: asm(main)
>
> main 0x1020 MOVW.W R14,#-0x18(R13)
>
> main+0x4 0x1024 MOVW$#0x1,R1
>
> main+0x8 0x1028 MOVW$#0x0,R2
>
> main+0xc 0x102c CMP.S $#0x0,R2
>
> main+0x10 0x1030 MOVW.LE R1,R3
>
> main+0x14 0x1034 MOVW.GT $#0x2,R3
>
> main+0x18 0x1038 SUB.GT $#0x8,R13,R13
>
> main+0x1c 0x103c MOVWR1,#0x4(R13)
>
> main+0x20 0x1040 MOVWR3,R11
>
> main+0x24 0x1044 BL _div
>
> main+0x28 0x1048 MOVWR11,R3
>
> main+0x2c 0x104c ADD $#0x8,R13,R13
>
> main+0x30 0x1050 MOVW$#0x7080,R0
>
> main+0x34 0x1054 MOVWR3,#0x8(R13)
>
> main+0x38 0x1058 BL print
>
> main+0x3c 0x105c MOVW$#0x0,R0
>
> main+0x40 0x1060 BL exits
>
> main+0x44 0x1064 RET.P #0x18(R13)
>
>
>
> The problem is that the division at main+0x24
>
> happens regardless of the comparison. The output
>
> from the compiler is correct, however:
>
>
>
> term% 5c -S foo.c
>
> TEXTmain+0(SB),0,$20
>
> MOVW$1,R1
>
> MOVW$0,R2
>
> CMP $0,R2,
>
> MOVW.LE R1,R3
>
> MOVW.GT $2,R3
>
> DIV.GT R1,R3,R3
>
> MOVW$.string<>+0(SB),R0
>
> MOVWR3,8(R13)
>
> BL ,print+0(SB)
>
> MOVW$0,R0
>
> BL ,exits+0(SB)
>
> RET ,
>
> DATA.string<>+0(SB)/8,$"%d\n\z\z\z\z\z"
>
> GLOBL .string<>+0(SB),$8
>
> END ,
>
>
>
> A (temporary) workaround for this is using an
>
> if-else statement, for which the linker generates
>
> correct code.
>
>
>
> --
>
> pap
Re: [9fans] 5l bug
> Gesendet: Montag, 29. April 2013 um 21:34 Uhr
> Von: "Richard Miller" <9f...@hamnavoe.com>
> An: 9fans@9fans.net
> Betreff: Re: [9fans] 5l bug
>
> > following up, theres my naive fix for this. instead of
> > emiting conditional division instruction by 5c... dont and
> > keep the branch. does this make any sense?
>
> I think it should be corrected in 5l. Some ARM versions do
> have a hardware divide instruction, which could one day be
> supported by 5l, so 5c should be kept more generic.
The compiler already assumes things that would be not true for
native divide instructions. For example, we assume that divide
modifies the condition flags, which would not be the case for
native SDIV/UDIV, but is the case for the emulated ones because
its implemented as a subroutine:
(from /sys/src/cmd/5c/peep.c)
/*
* Depends on an analysis of the encodings performed by 5l.
* These seem to be all of the opcodes that lead to the "S" bit
* being set in the instruction encodings.
*
* C_SBIT may also have been set explicitly in p->scond.
*/
int
modifiescpsr(Prog *p)
{
return (p->scond&C_SBIT)
|| p->as == ATST
|| p->as == ATEQ
|| p->as == ACMN
|| p->as == ACMP
|| p->as == AMULU
|| p->as == ADIVU
|| p->as == AMUL
|| p->as == ADIV
|| p->as == AMOD
|| p->as == AMODU
|| p->as == ABL;
}
the change i made just avoids the branch optimization for these
instructions not executing them conditionally. the whole idea of
this pass is to avoid the branching arround *short* conditional
code sequences (4 instructions at max).
with the emulated instructions the _div call setup already takes
more than 4 instructions and just reintroducing a branch in the
linker counters what the optimization pass tried to archive in the
first place.
but maybe its not really worth thinking about because conditional
divide seems quite rare (?) and emulated divide will be slow in any
case (?) so it wont matter if we readd conditional branch in the linker?
still, the dependency between 5l <-> 5c above remains... otherwise,
one would need to write condition flag preserving version... for
these instructions to make them behave exactly like the native
instructions... perhaps emulate the instructions by traping in the
kernel? seems even slower... how ignorant do we want 5c to be at
what cost?
--
cinap
Re: [9fans] 5l bug
i is not ovious to me why that would work without adding a conditiona branch. maybe my assumptions are wrong. can you show the resulting assembly for the testcase? > Gesendet: Dienstag, 30. April 2013 um 11:07 Uhr > Von: zephyr.pelle...@gmail.com > An: 9fans@9fans.net > Betreff: Re: [9fans] 5l bug > > Patching p -> scond = q -> scond in /sys/src/cmd/5l/noop.c fixes this > unfortunate linker bug. > -- cinap
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> The bad stuff for Plan9 would be the external dependencies of libtecla > and ncurses (still have not been able to get ncurses to work :( ), so > there would have to be lots of modifications probably. if thine libraries offend thee, pluck them out command line editing is not necessary, and irrelevant to our issue—scripts. - erik
Re: [9fans] German USB keyboard on Raspberry Pi
Hi,
Am 2013-04-28 23:07, schrieb Bakul Shah:
On 28 Apr 2013 22:01:17 +0200 "Holger Sebert"
wrote:
I did a quick hack on kbd.c and could make the "<,>,|" key
work. Awesome! Thank you all for your help.
What was the fix?
The relevant section from kbd.c is
if(kbscan->esc1){
c = kbtabesc1[c];
kbscan->esc1 = 0;
} else if(kbscan->esc2){
kbscan->esc2--;
return;
} else if /* ... */
The logic that is implemented here implies that
sequences of the form "e0 xx" cannot be combined
with a modifier like Shift or AltGr.
Since "<,>,|" is the only key on my keyboard for
which this is relevant, I simply changed the first
line to
if(kbscan->esc1 && c != 0x58){
/*...*/
This way, the sequence "e0 58" is actually interpreted
as "58", so that Shift and AltGr again work.
Of course, this is not a clean solution at all. But at
least it does not change the semantics of the kbmap-file.
In the 'bcm' directory some modules refer to 'omap' although
they apparently mean 'port', like this:
#include "../omap/random.c"
which should be
#include "../port/random.c"
Files from ../port are automatically picked up so you don't
need files in bcm that just include ../port/something.
Furthermore, I noticed that the build system would build _all_
of the kernel each time I invoke 'mk', even though only little
or nothing has changed. Is this the way it is intended to be?
Looks like your source files have a modification time newer
than the current time (as seen on your machine). Either
manually set date/time on boot (if not connected to the net)
or set
TIMESYNCARGS=(-n pool.ntp.org)
in /rc/bin/termrc.local. Pick a public ntpserver near you
instead of pool.ntp.org.
Oh yes, did not think about the missing RTC on the Pi. Thanks
for the solution!
Best,
Holger
Re: [9fans] German USB keyboard on Raspberry Pi
Hi, Am 2013-04-28 23:14, schrieb Richard Miller: #include "../omap/random.c" which should be #include "../port/random.c" Although it was easy to fix, I wonder where this inconsistency in the source tree came from. Did I miss an update or something? I think you did. /sys/src/9/bcm/random.c should have been deleted. Should this have happened when I invoked 'pull'? Or is there a separate update mechanism? Furthermore, I noticed that the build system would build _all_ of the kernel each time I invoke 'mk', even though only little or nothing has changed. Is this the way it is intended to be? Is your pi connected to the internet? If not, its time will be reset to the kernel build time each time you reboot (a function of the "fakertc" device, which was probably not a very good idea). When time goes backwards, 'mk' isn't able to do the right thing. You could build a kernel without the fakertc device; then you'll be prompted for date and time when you reboot. Or connect to the internet so the date can be set from ntp. Yes, I forgot that the Raspberry Pi does not have an RTC; and I do not connect it to the internet everytime I switch it on. Time for me to get an RTC add-on! Thanks for your help!! Best, Holger
Re: [9fans] German USB keyboard on Raspberry Pi
>> I think you did. /sys/src/9/bcm/random.c should have been deleted. > > Should this have happened when I invoked 'pull'? Or is there a > separate update mechanism? Yes, it should have been deleted by the first 'pull' after 1 April: term% grep sys/src/9/bcm/random.c /dist/replica/client/plan9.log 1364809803 16381 d sys/src/9/bcm/random.c - 664 sys sys 1342801416 0 term% date 1364809803 Mon Apr 1 10:50:03 BST 2013
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> I don't see how they would benefit from being rewritten in go. Go versions of base Plan 9 tools would be very useful to me for a number of reasons. Unfortunately, none of them have to do anything with Plan 9 (but then almost nothing posted on 9fans does) and probably my reasons don't apply to many other people, but here they are nevertheless. Sometimes I need to deploy something written in rc(1) over a heterogenous Linux cluster, and a statically compiled rc(1) would be a blessing. I don't want to deal with deploying all plan9port/9base and "modern" distributions make building plan9port statically very hard and annoying. A Go version of rc(1) would also make it easier to be be embedded in Go programs. I'd also want a static version of sam to run on servers by copying it through ssh without having to install it first. I avoid the distribution craze as much as possible, I netboot nodes with just a kernel and busybox in an initrd. I would love to have Plan 9 tools in that initrd instead of busybox. A static Go binary that contains all the tools would be a blessing. Now one can argue that building rc(1) and sam(1) statically can be done, albeit it requires tinkering, embedding rc(1) in Go is not that useful, and plan9port can be made into a single busybox-like binary with some effort and you'd be right. It's not much work, but it's work I have to do, and since it's only myself who is interested in what I written above it would be me that would have to maintain all this stuff. A Go version of the tools would be more interesting for many people, so there would be more people who would use and maintain it (including myself), and this version would support my use cases out of the box without any effort. -- Aram Hăvărneanu
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> with Plan 9 (but then almost nothing posted on 9fans does) and nominated for the the geekier-than-thou meme of the week. - erik
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Tue, Apr 30, 2013 at 11:31:48AM -0400, erik quanstrom wrote: > > with Plan 9 (but then almost nothing posted on 9fans does) and > > nominated for the the geekier-than-thou meme of the week. > > - erik > I thought 9fans was a raspberry pi support list. khm
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
I wasn't talking about rc(1). I was talking about echo, tee, cat, touch, rm, sleep, etc.. 2013/4/30 Aram Hăvărneanu > > Sometimes I need to deploy something written in rc(1) over a > heterogenous Linux cluster, and a statically compiled rc(1) would be a > blessing.
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Tue, Apr 30, 2013 at 05:26:50PM +0200, Aram H?v?rneanu wrote: > > I don't see how they would benefit from being rewritten in go. > > Sometimes I need to deploy something written in rc(1) over a > heterogenous Linux cluster, This is in part Plan9 related. For kerTeX, simply because my compilation framework was done this way, I use POSIX.2 utilities: sh(1) and make(1) mainly. So, on Plan9, kerTeX compiles under APE. But, despite POSIX being the one standard for systems, not everything is really present everywhere, even on Unices (ed(1) is typically something that is left out, while this is the only _line_ editor so the only editor that should be here). So I will have, to ensure that kerTeX runs everywhere, to provide some core utilities. And I think I will switch from sh(1) (ksh or ash) to rc(1) because rc(1) has regexp manipulations, and this is typically a lot of what is done in the scripts (the a=$(echo $b | sed ...) is not really efficient or beautiful). So there may be a rc(1) base sys utilities set some day. (But if someone does it before me, I will not be unhappy) Because, using only C89 (or C99) is great. System(3) is standard C. But the interpreter is neither guaranteed nor defined. If you have scripts (and MetaPost has some for example; and kerTeX administration needs some for the packages...) -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
[9fans] (no subject)
Subject Sheevaplug and NVRAM Every time I start the Sheevaplug, I have to enter the authentication details that ought to be written to VNRAM. This seems unnecessary, but my attempts to assign a single block of flash to NVRAM have so far been unsuccessful. Could somebody mail me an example of a successful allocation of flash memory for Plan 9 use on a Sheevaplug so I can figure out what I am doing wrong? ++L
Re: [9fans] (no subject)
On Tue Apr 30 11:57:34 EDT 2013, lu...@proxima.alt.za wrote: > Subject Sheevaplug and NVRAM > > Every time I start the Sheevaplug, I have to enter the authentication > details that ought to be written to VNRAM. This seems unnecessary, > but my attempts to assign a single block of flash to NVRAM have so far > been unsuccessful. the key for me was to add a partition for the flash to the plan9.ini, e.g. flash0part=nvram 0x10 0x12/plan9.ini 0x12 0x14/kernel 0x14 0x4c - erik
Re: [9fans] Subject Sheevaplug and NVRAM
> Could somebody mail me an example of a successful allocation of flash > memory for Plan 9 use on a Sheevaplug so I can figure out what I am > doing wrong? In you case, you may simply include the nvram in your kernel by adding the "nvram" file to the bootdir section of your kernel configuration and adding "nvram=/boot/nvram" to your plan9.ini. However, if you don't want to spread your passwords over your network, you would prefer to use the flash, simply by adding, for example, the following to your /cfg/*/cpurc: echo add nvram 0x10 0x12 >'#'F/flashctl See flash(3) for a description of devflash. -- David du Colombier
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
If anyone is interested I have (re)ported rc(1) to linux together with the few tools that are unique to plan9: p(1) mc(1) and ls(1). ls may seem a strange choice but I access Linux over ssh from plan9 and want to be able to do things like "ls ../port" and get the files listed with the ../port/ path so I can plumb them. My ls is based on the plan9 code and obeys its rules. I have also ported rc(1) and a base set of command line tools to win32. rc(1) builds standalone but some of the tools need libregexp libbio and libstring which included I attach to windows using a cpu(1) like command dos(1) which opens an rc(1) shell on windows via an nt service - listen(1). This allows me to use the cross compilers there I need for work. Anyone wants any/all of this give me a shout. -Steve
[9fans] Invitation to connect on LinkedIn
LinkedIn Fans, I'd like to add you to my professional network on LinkedIn. - Aram Aram Sadogidis Intern Software Engineer at Bell Laboratories Ireland Confirm that you know Aram Sadogidis: https://www.linkedin.com/e/-b7ebtr-hg5hrqq5-2/isd/12884874408/ZlUc7Ynw/?hs=false&tok=2Kd01CPrV7L5I1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-b7ebtr-hg5hrqq5-2/XUiWqEFikn5NqLDnWAi66COOc0/goo/9fans%409fans%2Enet/20061/I4267108161_1/?hs=false&tok=3iF4SYP_N7L5I1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
I don't know if you've seen this, but there is also a plan9portport to windows [1]. Not everything works, but sam and rc do. [1] https://bitbucket.org/knieriem/pf9
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
I realise I have misrepresented this work, the Linux port of rc(1) was Geoff Collyer's work, both the earlier port some years ago and a recent update which makes the port work again. I provided a minor patch or two. There has been a win32.c in the labs distribution of rc(1) for years but it has never (to my knowledge) worked. I did a major overhall of the win32 port and back ports of a few plan9 tools to posix (I know, I know), and packaged the whole thing up. -Steve
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> rc in go
Also, some extensions could be useful:
* Inferno shell style local variables with := statement
* <> $file { ... } statement
* <>{ ... } statement, which returns both input and output pipes of command
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> * Inferno shell style local variables with := statement
already have. syntax is:
var=val cmd
> * <> $file { ... } statement
already have.
> * <>{ ... } statement, which returns both input and output pipes of command
? pipes aren't first-class language elements.
- erik
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
> syntax is: var=val cmd
Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.
> ? pipes aren't first-class language elements.
Well, they are files:
; foo=>{cat} ; echo $foo
/dev/fd/6
(linux)
I'm talking about something, that returns list with input and output
fd to a command.
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Tue Apr 30 18:50:42 EDT 2013, gleb.ax...@gmail.com wrote:
> > syntax is: var=val cmd
> Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.
i don't see the practical issue. the idiom described works fine.
not liking the syntax is not a good reason to introduce incompatable
ways of doing things.
- erik
[9fans] usb booting
this is a follow up to the discussion about root from usb-hdd
on the raspberry pi discussion (http://9fans.net/archive/2013/03/499)
it's a roundabout trip.
on pcs, i'm using cinap's bios-only loader. it's tiny, and does its job well.
i've added the ability to find bios's first drive and pxe's first card.
information is exported in #ec/drive0 and #ec/ether0. the latter
is quite useful for making machines with many interfaces "just boot".
the former is very useful for usb. bios edd services will tell us if
the drive is usb. (http://www.quanstro.net/magic/man2html/8/pcipl)
i'm also using kernels that have a sd loopback device. a file
can be turned into a sd device with the ctl message
config switch on spec $letter type loop/$file
putting the two together in boot/boot.c allows for boot
to depend on usb disks for nvram or file systems with just
20 lines of extra code.
to apply this to the rasberry pi, one would only need to
add the configuration passed into the pi kernel "drive0=usb=y".
unfortunately, sd(3) doesn't make it easy to have a /dev/sdboot
to make it easy to make this configuration mess go away. ideally,
i think, drives would be renumbered as we do with ethernet devices
already.
- erik
; diffy -c /sys/src/nix/boot/boot.c
/n/dump/2013/0430/sys/src/nix/boot/boot.c:262,274 -
/sys/src/nix/boot/boot.c:262,304
}
static void
+ usbbootdrive(void)
+ {
+ int fd, t;
+ static char usbsrv[] = "/srv/usb";
+ static char usbdrv[] = "/dev/sdU0.0/data";
+
+ for(t = 0; t < 10*1000;){
+ if(access(usbdrv, OREAD) != -1)
+ break;
+ sleep(300);
+ t += 300;
+ }
+
+ fd = open("#S/sdctl", OWRITE);
+ if(fd == -1){
+ fprint(2, "usbbootdrive: open #S/sdctl: %r\n");
+ return;
+ }
+ if(fprint(fd, "config switch on spec u type loop/%s\n", usbdrv) == -1)
+ fprint(2, "usbbootdrive: loopback: %r\n");
+ close(fd);
+ }
+
+ static void
usbinit(void)
{
+ char *s;
static char usbd[] = "/boot/usbd";
if(access("#u/usb/ctl", 0) >= 0 && bind("#u", "/dev", MAFTER) >= 0 &&
- access(usbd, AEXIST) >= 0)
- run(usbd, nil);
+ access(usbd, AEXIST) >= 0){
+ run(usbd, "-m", "/dev", nil);
+ s = getenv("drive0");
+ if(s != nil && strstr(s, " usb=") != nil)
+ usbbootdrive();
+ free(s);
+ }
}
static void
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
With := you can define locale variable where you need it.
That's like pascal style (where you define all variables before the
code) versus c style (where you define variables with code).
Not critical, but there is a practical issue.
2013/5/1 erik quanstrom :
> On Tue Apr 30 18:50:42 EDT 2013, gleb.ax...@gmail.com wrote:
>> > syntax is: var=val cmd
>> Sure, foo=() bar=() baz=() { ... } works, but that's not very practical.
>
> i don't see the practical issue. the idiom described works fine.
>
> not liking the syntax is not a good reason to introduce incompatable
> ways of doing things.
>
> - erik
>
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
Just a nit, but the Algol style of assignment, "becomes" if you will, didn't define the variable instance. It was just an assignment. sent from my ipad On Apr 30, 2013, at 4:45 PM, "suharik" wrote: > With := you can define locale variable where you need it. > That's like pascal style (where you define all variables before the > code) versus c style (where you define variables with code).
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Tue Apr 30 19:45:29 EDT 2013, gleb.ax...@gmail.com wrote: > With := you can define locale variable where you need it. > That's like pascal style (where you define all variables before the > code) versus c style (where you define variables with code). > Not critical, but there is a practical issue. rc uses a 1 pass compiler with limited backpatching. it may be difficult, or at least inelegant, to implement add-hoc variable locals with the current compilation strategy. especially in the face of notes. sure, you could implement the language a different way, but rc is structurally so cool, it wouldn't feel like rc without the virtual machine. at least to me. - erik
[9fans] 9atom updates
it turns out, a few updates have gone in recently. they might be worth noting (even if you're not using 9atom) a number of bug fixes that have gone in recently. i was surprised reviewing the changes how many crashes were fixed. http://www.quanstro.net/plan9/9atom/index.html - erik
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Apr 30, 2013, at 20:56, erik quanstrom wrote: > On Tue Apr 30 19:45:29 EDT 2013, gleb.ax...@gmail.com wrote: >> With := you can define locale variable where you need it. >> That's like pascal style (where you define all variables before the >> code) versus c style (where you define variables with code). >> Not critical, but there is a practical issue. > > rc uses a 1 pass compiler with limited backpatching. it may be > difficult, or at least inelegant, to implement add-hoc variable > locals with the current compilation strategy. especially in > the face of notes. > > sure, you could implement the language a different way, but > rc is structurally so cool, it wouldn't feel like rc without the > virtual machine. at least to me. > > - erik > Why don't you just translate the C to Go. Plan 9 sources map pretty well to Go.
Re: [9fans] Subject Sheevaplug and NVRAM
> However, if you don't want to spread your passwords over > your network, you would prefer to use the flash, simply > by adding, for example, the following to your /cfg/*/cpurc: > > echo add nvram 0x10 0x12 >'#'F/flashctl That's too late for wrkey. There's a lot about the Sheeva that doesn't make any sense to me: /cfg/pxe/example-kw does not set the bootfile, nor does the documentation state what loader should be specified as bootf in /lib/ndb. So I put the actual kernel name in /lib/ndb (/arm/9plug), which gets loaded four times before actually activating. But by then there is no suggestion of an nvram, no such entry exists in /env. I'm a little lost. ++L
Re: [9fans] [GSOC 2013] Implement plan9 commands in Go, Goblin
On Tue, Apr 30, 2013 at 07:18:16PM +0100, Steve Simon wrote: >[...] > I have also ported rc(1) and a base set of command line tools to > win32. rc(1) builds standalone but some of the tools need libregexp > libbio and libstring which included > Well, I'm definitively interested since I'd like to have a defined minimal set of tools (mainly text ones) plus rc(1) for compilation (for creating Makefiles---whatever flavor, maybe mk(1) ones---using the native or cross-compilers with my R.I.S.K. framework, that I started to use for Plan9 or Unices like, but for Windows too for kerTeX) and for providing the tools to have only rc(1) scripts for kerTeX on whatever system (for the system(3) invocations---for MetaPost---or for administrating the packages). -- Thierry Laronde http://www.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
