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 u.h
#include libc.h
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-scondC_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
holger.seb...@ruhr-uni-bochum.de 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
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 ara...@mgk.ro 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.
[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] 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=falsetok=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=falsetok=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
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
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 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).
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
