Re: [9fans] Python/Mercurial error
Beside the Mercurial issue, the Go 1.2 release will not work on Plan 9. You have to follow tip. Just remove "-u release" from the clone line. -- David du Colombier
Re: [9fans] Regression testing
Hi all, If there was a push to write a regression testing suite, or at least some rudimentary tests, I'd be interested in lending a hand. Been working in fairly low level QA/Automation for a few years. Seems like writing a fairly thorough for plan9 would be no trivial task, but certainly could be interesting and valuable to get coverage of some of the basics at least. (sorry if this is a double post) Pauric
[9fans] Regression testing
Hello, I would also be quite interested in helping if people are embarking on such a project. I'm a Computer Science student and I've been using a raspberry pi trying to learn more about plan 9. Creating regression tests could be a good way for me to poke around the system learning how it works while still contributing something useful to the community. On 26 Mar 2014 10:58, "Pauric Ward" wrote: > Hi all, > > If there was a push to write a regression testing suite, or at least some > rudimentary tests, I'd be interested in lending a hand. > > Been working in fairly low level QA/Automation for a few years. > Seems like writing a fairly thorough for plan9 would be no trivial task, > but certainly could be interesting and valuable to get coverage of some of > the basics at least. > (sorry if this is a double post) > > Pauric >
Re: [9fans] Python/Mercurial error
Could you post or have a look at libc_plan9.h - that file is generated by stripping out some things from /sys/include/libc.h and it appears that something in that process has generated a syntax error. Pete ps. I think it’s impossible to copy from vbox unless you have guest additions installed and AFAIK guest additions for plan9 have not been written. From: Ramakrishnan Muthukrishnan Sent: Wednesday, 26 March 2014 11:09 To: Fans of the OS Plan 9 from Bell Labs On Wed, Mar 26, 2014 at 1:05 PM, David du Colombier <0in...@gmail.com> wrote: > Beside the Mercurial issue, the Go 1.2 release will not work on Plan 9. You > have to follow tip. Just remove "-u release" from the clone line. I installed the python/hg binaries from the 9legacy webpage. I also downloaded the go hg tip and did this: cd src ./all.rc I now get errors quite early itself while building lib9.a. Attaching a screenshot. I still can't seem to copy text to/from virtualbox. Ramakrishnan
Re: [9fans] Python/Mercurial error
On Wed, Mar 26, 2014 at 5:23 PM, wrote:
> Could you post or have a look at libc_plan9.h - that file is generated by
> stripping out some things from /sys/include/libc.h and it appears that
> something in that process has generated a syntax error.
Pete,
Yes, you are right. I see an empty enum declaration:
enum {
}
.. in between the "extern .. tokenize.." and "extern .. malloc .. "
declarations.
I will see how this file is generated. Thank you very much. I am
running 9atom and not the Bell Labs plan9. I am not sure if some
structures are not in sync in any header files.
> ps. I think it’s impossible to copy from vbox unless you have guest
> additions installed and AFAIK guest additions for plan9 have not been
> written.
Ah, okay. Thanks. I think I will install it on natively on my desktop
PC this weekend.
Thanks again.
Ramakrishnan
Re: [9fans] Python/Mercurial error
>Attaching a > screenshot. I still can't seem to copy text to/from virtualbox. One thing you can do is to run Plan 9 in virtualbox but use drawterm on the host to access it. Then you can copy/paste from the drawterm window. Mark.
Re: [9fans] Python/Mercurial error
You can easily fix the generated include/plan9/plan9_libc.h file by hand for now. It seems /sys/include/libc.h is slightly different on 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't forget to comment out the generation of plan9_libc.h in src/make.rc. -- David du Colombier
Re: [9fans] Python/Mercurial error
On Wed, Mar 26, 2014 at 6:08 PM, David du Colombier <0in...@gmail.com> wrote: > You can easily fix the generated include/plan9/plan9_libc.h file by > hand for now. It seems /sys/include/libc.h is slightly different on > 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't > forget to comment out the generation of plan9_libc.h in src/make.rc. I tried that, David. The build proceeds but I get a trap now. pkg/text/template/parse pkg/text/template pkg/go/doc pkg/go/build cmd/go sys: trap: invalid opcode pc=0x4d9e9 PC=4d9e9 goroutine 16 [running]: runtime.cmpbody() [.] and then it prints a bunch of registers (ax, bx, .. pc, flags, cs .. gs) and their values. :( I will see what went wrong with libc header file and try to come up with some fix. -- Ramakrishnan
Re: [9fans] Python/Mercurial error
On Wed, Mar 26, 2014 at 5:39 PM, Mark van Atten wrote: >>Attaching a >> screenshot. I still can't seem to copy text to/from virtualbox. > > One thing you can do is to run Plan 9 in virtualbox but use drawterm > on the host to access it. Then you > can copy/paste from the drawterm window. I haven't yet configured my system to be a CPU, does that matter? I will take a dig at it tonight. Thanks Mark. Ramakrishnan
Re: [9fans] Python/Mercurial error
On Wed Mar 26 08:39:24 EDT 2014, 0in...@gmail.com wrote: > You can easily fix the generated include/plan9/plan9_libc.h file by > hand for now. It seems /sys/include/libc.h is slightly different on > 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't > forget to comment out the generation of plan9_libc.h in src/make.rc. this guess is incorrect. i installed python/hg on 9atom 3 weeks ago with jeff, and there were no issues at all. - erik
Re: [9fans] Python/Mercurial error
> Yes, you are right. I see an empty enum declaration:
>
> enum {
> }
>
> .. in between the "extern .. tokenize.." and "extern .. malloc .. "
> declarations.
>
> I will see how this file is generated. Thank you very much. I am
> running 9atom and not the Bell Labs plan9. I am not sure if some
> structures are not in sync in any header files.
i've seen this before. but i don't exactly remember how i cleared
it up. i think it involved mk'ing smaller bits, like mk stage first.
i didn't see this error the last time i tried.
- erik
Re: [9fans] Python/Mercurial error
> this guess is incorrect. i installed python/hg on 9atom > 3 weeks ago with jeff, and there were no issues at all. This is Go, not Python. -- David du Colombier
Re: [9fans] usb/kb
On Tue Mar 25 22:22:23 EDT 2014, kokam...@hera.eonet.ne.jp wrote: > The upas (your nupas) has problem with using POP3 > mail reading. > > In your source, there is a comment regarding this. > Yes, I met the same problem as your comment in > sanembmsg() in mbox.c. > > Before trying this myself, I suppose you have some suggestion > on this point. Where I should try first? i recommend commenting these lines out. ; g sanembmsg|grep pop mbox.c:490: sanembmsg(mb, m); /* fails with pop but i want this debugging for now */ mbox.c:521: sanembmsg(mb, m); /* fails with pop but i want this debugging for now */ mbox.c:548: sanembmsg(mb, m); /* fails with pop but i want this debugging for now */ - erik
Re: [9fans] Python/Mercurial error
On Wed, Mar 26, 2014 at 7:17 PM, erik quanstrom wrote: > On Wed Mar 26 08:39:24 EDT 2014, 0in...@gmail.com wrote: >> You can easily fix the generated include/plan9/plan9_libc.h file by >> hand for now. It seems /sys/include/libc.h is slightly different on >> 9atom, so the include/plan9/mklibc.rc script have to be adapted. Don't >> forget to comment out the generation of plan9_libc.h in src/make.rc. > > this guess is incorrect. i installed python/hg on 9atom > 3 weeks ago with jeff, and there were no issues at all. There wasn't any issue installing hg and python. I have now tried compiling from source and running the binaries and both work just fine (I get the threading.py errors occasionally when running hg). The libc header file error is when I tried to compile go-lang. -- Ramakrishnan
Re: [9fans] No regression tests
> I regret not to have more detailed info. I suspect there is something > changed in the detach primitives or so. But its only a very personal > opinion. hmm. would it be too much to ask to request a ps of the processes that failed to exit? i really would just like to know what state they're in. i think this may have been a latent bug that just came out. - erik
Re: [9fans] Regression testing
On Wed Mar 26 07:11:38 EDT 2014, riddler...@gmail.com wrote: > Hello, > > I would also be quite interested in helping if people are embarking on such > a project. > > I'm a Computer Science student and I've been using a raspberry pi trying to > learn more about plan 9. Creating regression tests could be a good way for > me to poke around the system learning how it works while still contributing > something useful to the community. i think this could be quite valuable. at a minimum, you will learn alot. i assume that you mean automated tests. many things like usb behavior on unplugging is hard to automate without some special equipment. imo, the easiest thing to automate would be the system calls. there are very few of them. i would first start by checking that they do reasonable things with arguments in the text, heap, stack, and various forms of invalid addresses, especially just above or just below valid addresses. it is also pretty straightforward to test a the kernel devices to make sure they all handle invalid file names/directory names well, deal with bad input to control files well, etc. (an idea that occurs to me while typing this is to have a special syscallmal for allocating things with system call lifetime. it allows one to add the rule that everything syscallmal'd must be free'd on kernel exit.) another area that might not be as easy (as you'll have to dive into some obtuse stuff) would be floating point. but this would be very helpful, because it has been a long time since serious effort was put into this. floating point should well behaved with the usual operations, and with standard library functions (and ape, too), with respect to the usual problem areas such as overflow, underflow, -0., ±∞, and denormals, with all fcr (see getfcr(2)) settings, and with all architectures. or at least amd64, rpi and something with emulated fp such as the rb. run-on sentences 'ᴙ' us. i'd be willing to give you some pointers on how to continue. i have some scripts that i used to iron some of the worst bugs out of fp so that python could pass some regression tests. - erik
[9fans] 9atom usb image
i think it's time to get rid of the +usbinstamd64.bz image. the process seems to work pretty well. updates to the image will be here starting immediately: http://ftp.9atom.org/other/usbinstamd64.bz2 - erik
Re: [9fans] No regression tests
erik quanstrom ha scritto: I regret not to have more detailed info. I suspect there is something changed in the detach primitives or so. But its only a very personal opinion. hmm. would it be too much to ask to request a ps of the processes that failed to exit? i really would just like to know what state they're in. i think this may have been a latent bug that just came out. - erik Working on a Bell I've at home, downloaded a few weeks ago. The kernel is built using the same config used on the field, where the wrong behaviour has been noted. The modified usbd and thebcscan process are embedded. After booting with the reader plugged in (normal condition): bootes 120:00 0:00 336K Preadbcscan bootes 130:00 0:00 336K Rendez bcscan bootes 140:00 0:00 336K Rendez bcscan bootes 190:00 0:00 336K Pread bcscan Here mount /srv/bcscan /n/bc gives a readable /n/bc/bcU0/data. Then the reader is unplugged bootes 120:00 0:00 336K Pread bcscan bootes 130:00 0:00 336K Rendez bcscan bootes 140:00 0:00 336K Rendez bcscan Plaese note that here we see a different case. There are three spurious processes. On the plant (same test) there is only one. Then the reader is plugged in again bootes 130:00 0:00 336K Rendez bcscan bootes 140:00 0:00 336K Rendez bcscan bootes 4320:00 0:00 336K Rendez bcscan bootes 4340:00 0:00 336K Pread bcscan bootes 4350:00 0:00 336K Rendez bcscan bootes 4360:00 0:00 336K Rendez bcscan bootes 4370:00 0:00 336K Open bcscan Here mount /srv/bcscan /n/bc gives an empty /n/bc but doesn't complain. adriano
Re: [9fans] No regression tests
> Here mount /srv/bcscan /n/bc gives a readable /n/bc/bcU0/data. > > Then the reader is unplugged > > bootes 120:00 0:00 336K Pread bcscan > bootes 130:00 0:00 336K Rendez bcscan > bootes 140:00 0:00 336K Rendez bcscan > > Plaese note that here we see a different case. There are three > spurious processes. On the plant (same test) there is only one. > > Then the reader is plugged in again > > bootes 130:00 0:00 336K Rendez bcscan > bootes 140:00 0:00 336K Rendez bcscan > bootes 4320:00 0:00 336K Rendez bcscan > bootes 4340:00 0:00 336K Pread bcscan > bootes 4350:00 0:00 336K Rendez bcscan > bootes 4360:00 0:00 336K Rendez bcscan > bootes 4370:00 0:00 336K Open bcscan i should learn chess so i don't ask questions in serial. with acid, you can get a backtrace of process 12 and get the fd it is reading. /proc/12/fd should have the file descriptor bcscan thinks is open. if it also, since process 13 and 14 did not wake from rendezvous, there is a second issue. maybe you can see how 12 could exit and leave 13 and 14 hanging. - erik
Re: [9fans] No regression tests
i should learn chess so i don't ask questions in serial. Sorry, I don't understand the meaning of this sentence. The word by word translation, in italian, has no logical meaning. with acid, you can get a backtrace of process 12 and get the fd it is reading. /proc/12/fd should have the file descriptor bcscan thinks is open. if it also, since process 13 and 14 did not wake from rendezvous, there is a second issue. maybe you can see how 12 could exit and leave 13 and 14 hanging. I'll try, even if I don't know acid very well. What is the backtrace of a process. lstk() ? adriano
Re: [9fans] No regression tests
> I'll try, even if I don't know acid very well. > > What is the backtrace of a process. lstk() ? lstk() gives the details (including locals) stk() is a basic backtrace. see acid(1) or /sys/doc/acid.ps - erik
Re: [9fans] hg and golang
By the way, I've just updated the binary package to Mercurial 2.9.1. http://www.9legacy.org/download.html -- David du Colombier
Re: [9fans] 9atom usb image
erik quanstrom ha scritto:
i think it's time to get rid of the +usbinstamd64.bz image. the
process seems to work pretty well. updates to the image will be
here starting immediately:
http://ftp.9atom.org/other/usbinstamd64.bz2
- erik
This image behaves as follows:
...
8._cp 8.unicode /386/bin/unicode
8._cp 8.tweak /386/bin/tweak
8._cp 8.uniq /386/bin/uniq
8^c -FTVw units.c
8._cp 8.unmount /386/bin/unmount
8._cp 8.webfsget /386/bin/webfsget
8._cp 8.wc /386/bin/wc
8._cp 8.winwatch /386/bin/winwatch
8._cp 8.webcookies /386/bin/webcookies
8._cp 8.xb /386/bin/xb
8._cp 8.wsprint /386/bin/wsprint
8._cp 8.xd /386/bin/xd
8._cp 8.μlawdec /386/bin/μlawdec
8._cp 8.yacc /386/bin/yacc
8._cp 8.bc /386/bin/bc
8^l -o 8.units units.8
8._cp 8.units /386/bin/units
for(i in 1a 1c 1l 2a 2c 2l 5a 5c 5i 5l 6a 6c 6l 7a 7c 7l 8a 8c 8l
9660srv 9a 9c 9l 9nfs abaco acid acme aoedbfs aoesnap aquarela astro
atazz auth aux awk bitsy bzip2 cb cc cdfs cec cfs cifs compose compress
con cpp cwfs db dial dict diff disk dossrv eqn execnet exifsrv exportfs
ext2srv faces fax fossil grap graph grep gs gzip hoc htmlfmt htmlroff
icrop imgloop iostats ip jpg jtag ka kc ki kl lex lnfs lp map mk ndb opc
page paqfs pci pic plot plumb postscript proof qa qc qi ql ratfs rbfs rc
rchistory replica rio runetype sam samterm scat scuzz sftpfs snap spell
spin srvold9p ssh1 ssh2 syscall tapefs tarsplit tbl tcs telco troff
troff2html upas usb va vac vblade vc venti vi vl vnc vt webfs wikifs
θfs) @{
cd $i
echo mk $i
mk $MKFLAGS install
}
mk 1a
yacc -D1 -d a.y
8c -FTVw y.tab.c
8c -FTVw lex.c
8l -o 8.out y.tab.8 lex.8
cp 8.out /386/bin/1a
cp: error writing /386/bin/1a: file system full
mk: cp 8.out /386/bin/1a : exit status=rc 8787: cp 8789: errors
mk: for(i in 1a ... : exit status=rc 8769: rc 8771: mk 8774: error
mk: test -e 8._cp ... : exit status=rc 7466: mk 8757: error
mk: date for (i ... : exit status=rc 416: rc 7452: mk 7454: error
halt system? (yes, no, skip)[no default]:
---
; disk/kfscmd check
checking file system: main
check free list
lo = 0; hi = 0
21694 files
48616 blocks in the file system
48616 used blocks
0 free blocks
21703 maximum qid path
---
; disk/kfscmd -n inst check
checking file system: main
check free list
lo = 50580; hi = 61035199
23209 files
61035199 blocks in the file system
50579 used blocks
60984620 free blocks
23415 maximum qid path
;
The fresh key have about 3000 free blocks.
adriano
Re: [9fans] usb/kb
> ; g sanembmsg|grep pop > mbox.c:490: sanembmsg(mb, m); /* fails with pop but i want this debugging for > now */ > mbox.c:521: sanembmsg(mb, m); /* fails with pop but i want this debugging for > now */ > mbox.c:548: sanembmsg(mb, m); /* fails with pop but i want this debugging for > now */ Wow, that's very easy solution. Yes, now I can receive mails from our pop server. Thanks eric, your nupas is very nice. This is my first email from nupas. Kenji
Re: [9fans] usb/kb
On Wed Mar 26 21:11:45 EDT 2014, kokam...@hera.eonet.ne.jp wrote: > > ; g sanembmsg|grep pop > > mbox.c:490: sanembmsg(mb, m); /* fails with pop but i want this > > debugging for now */ > > mbox.c:521: sanembmsg(mb, m); /* fails with pop but i want this > > debugging for now */ > > mbox.c:548: sanembmsg(mb, m); /* fails with pop but i want this > > debugging for now */ > > Wow, that's very easy solution. > Yes, now I can receive mails from our pop server. > Thanks eric, your nupas is very nice. > > This is my first email from nupas. cool! i committed a patch today to comment out these lines. these checks have not caught an error in years, so there's no reason to leave them enabled. - erik
Re: [9fans] 9atom usb image
thanks, i'll look into this. - erik
