Re: [9fans] Problem with mk
On Wednesday 18 of December 2013 09:23:19 Blake McBride wrote: Problem 1: it seems you have an un-stated dependency/cies among your intermediate targets / prerequisites. Say, foo.o depends on foo.c and foo.h -- but foo.h also depends on generated_foo.h, which should be generated by make. in such case, explicitly state (no recipe is necessary): foo.h: generated_foo.h so mk knows the `generated_foo.h' must be completed first. Problem 2: Even though I am executing mk with the -s option, it still seems like it is running in parallel because a subsequent command can't find a file created by a prior command - as if it didn't wait for the prior command to finish. Remember this build fine, and without error codes, when executed manually. -s won't help you there, because it regards processing of /command line/ arguments, not of prerequisites. consider: $ NPROC=1 mk my_target also investigate -d[egp] debug stuff. have fun with mk, it's a great little tool :-) -- dexen deVries [[[↓][→]]] Take care of the luxuries and the necessities will take care of themselves. -- L. Long
Re: [9fans] Problem with mk
Thanks for the help! See below: On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries dexen.devr...@gmail.comwrote: On Wednesday 18 of December 2013 09:23:19 Blake McBride wrote: Problem 1: it seems you have an un-stated dependency/cies among your intermediate targets / prerequisites. Say, foo.o depends on foo.c and foo.h -- but foo.h also depends on generated_foo.h, which should be generated by make. in such case, explicitly state (no recipe is necessary): foo.h: generated_foo.h so mk knows the `generated_foo.h' must be completed first. Yea, actually my build process is a bit more complex than that. What I am doing reflects that complexity and works perfectly with make. _Initially_ (the first time), generics.h gets built through the generics.1 target, and then updated through the generics.h target process. Thereafter, as the program evolves, new classes are added (*.d files) and changed, generics.h gets updated through the generics.h process only. The generics.h target process reads in generics.h and updates it based on the changed *.d files. You can think of generics.h as a database of generic functions that needs to be initialized and then updated as the system evolves. The purpose of using rules rather than explicit recipes is because the mkfile is often used as a template for much larger projects. The pattern is convenient. Larger projects just have to update the three variables TARGET, CLASSES, and CFILES. If I don't use recipes, the mkfile gets unnecessarily lengthy with larger projects. Also, in spite of my use of a recipe rather than an explicit rule, why would that cause mk to barf? Problem 2: Even though I am executing mk with the -s option, it still seems like it is running in parallel because a subsequent command can't find a file created by a prior command - as if it didn't wait for the prior command to finish. Remember this build fine, and without error codes, when executed manually. -s won't help you there, because it regards processing of /command line/ arguments, not of prerequisites. consider: $ NPROC=1 mk my_target also investigate -d[egp] debug stuff. Yes, I didn't see a difference with or without the -s. I just used it to eliminate one possible source of problems. Also, the random intermixing of stdout and stderr causes me not to know what the order of execution is. have fun with mk, it's a great little tool :-) I'm sure it is. If I can get it to treat generics.h as a database as I described above, it would be great. Thanks! -- dexen deVries [[[↓][→]]] Take care of the luxuries and the necessities will take care of themselves. -- L. Long
Re: [9fans] Problem with mk
On Wed, Dec 18, 2013 at 9:23 AM, Blake McBride bl...@mcbride.name wrote: Problem 3: Somehow Unix or GNU make doesn't mix up buffered stdout with unbuffered stderr output. They remain in order so the total out of make and all of the commands are shown in order and in context. You know, so a human can understand it. mk appears not to handle this the same. stdout output and stderr output are totally out of sequence making it very, very difficult to understand what is going on. mk should flush stdout after completion each command.
Re: [9fans] Problem with mk
On Wed, 18 Dec 2013 10:11:22 CST Blake McBride bl...@mcbride.name wrote: Somehow Unix or GNU make doesn't mix up buffered stdout with unbuffered stderr output. They remain in order so the total out of make and all of the commands are shown in order and in context. You know, so a human can understand it. mk appears not to handle this the same. stdout output and stderr output are totally out of sequence making it very, very difficult to understand what is going on. mk should flush stdout after completion each command. Just as plan9 is not unix, mk is not make. Rather than expect it to behave like make, it pays to understand how mk works, may be by experimenting with little mkfiles.
Re: [9fans] Problem with mk
D on Plan 9? This is madness. -- Aram Hăvărneanu
Re: [9fans] Problem with mk
This is not D. It is a language of my own design called Dynace. It adds multiple inheritance, a metaobject protocol, generic functions, weak typing, garbage collection all to standard C. Class users (*.c files) are standard C in every way, there is only one data type added. The system is written entirely in portable C, and has been used in production environments for years. It also comes with a 350 page book that completely documents it, and a tutorial. I've got it running on Plan-9 except for this mkfile issue with the examples. The system is open-source. A new release will come out with Plan-9 support as soon as I get the mkfile issue solved. Thanks. On Wed, Dec 18, 2013 at 11:06 AM, Aram Hăvărneanu ara...@mgk.ro wrote: D on Plan 9? This is madness. -- Aram Hăvărneanu
Re: [9fans] Problem with mk
Seeing a Go link on your homepage I thought, oh, you also program in go? And then found that you actually *play* go (Google harmed a lot looking for information on the game). More surprising :D On Wed, Dec 18, 2013 at 6:18 PM, Blake McBride bl...@mcbride.name wrote: This is not D. It is a language of my own design called Dynace. It adds multiple inheritance, a metaobject protocol, generic functions, weak typing, garbage collection all to standard C. Class users (*.c files) are standard C in every way, there is only one data type added. The system is written entirely in portable C, and has been used in production environments for years. It also comes with a 350 page book that completely documents it, and a tutorial. I've got it running on Plan-9 except for this mkfile issue with the examples. The system is open-source. A new release will come out with Plan-9 support as soon as I get the mkfile issue solved. Thanks. On Wed, Dec 18, 2013 at 11:06 AM, Aram Hăvărneanu ara...@mgk.ro wrote: D on Plan 9? This is madness. -- Aram Hăvărneanu
Re: [9fans] Problem with mk
Often there is a set of reasonable, alternative algorithms one may utilize to solve a problem. Then, there is a set of unreasonable algorithms one may employ that may or may not solve the problem given various conditions. make has a proven reasonable algorithm to solve the problem for which it was designed. It employs one algorithm among other possible, and equally good, algorithms. You are implying that mk is using another valid algorithm rather than an unreasonable one. I can't see it yet. I'd be a better judge if I understood the purposeful, thought out reason behind the problems I am experiencing - assuming there is one. That's just the way it works or we do it differently because we are not unix are stupid as hell arguments. I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of. Blake On Wed, Dec 18, 2013 at 10:40 AM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 18 Dec 2013 10:11:22 CST Blake McBride bl...@mcbride.name wrote: Somehow Unix or GNU make doesn't mix up buffered stdout with unbuffered stderr output. They remain in order so the total out of make and all of the commands are shown in order and in context. You know, so a human can understand it. mk appears not to handle this the same. stdout output and stderr output are totally out of sequence making it very, very difficult to understand what is going on. mk should flush stdout after completion each command. Just as plan9 is not unix, mk is not make. Rather than expect it to behave like make, it pays to understand how mk works, may be by experimenting with little mkfiles.
Re: [9fans] Problem with mk
Quoting Blake McBride bl...@mcbride.name: I'd be a better judge if I understood the purposeful, thought out reason behind the problems I am experiencing - assuming there is one. That's just the way it works or we do it differently because we are not unix are stupid as hell arguments. No they aren't. Meanwhile, I trust you have read Maintaining Files on Plan 9 with Mk [1] and Plan 9 Mkfiles [2] in their entirety. Whining about software not meeting your behavioral expectations will get you nowhere. Just because other build systems make it relatively easy for you to shove unintended functionality into tools is no reason to disparage software that is working as intended. khm [1] http://doc.cat-v.org/plan_9/4th_edition/papers/mk [2] http://doc.cat-v.org/plan_9/4th_edition/papers/mkfiles
Re: [9fans] Problem with mk
On Wed, 18 Dec 2013 11:28:21 CST Blake McBride bl...@mcbride.name wrote: I'd be a better judge if I understood the purposeful, thought out reason behind the problems I am experiencing - assuming there is one. That's just the way it works or we do it differently because we are not unix are stupid as hell arguments. That's just the way it works is exactly the right attitude to take when you are learning a new language or entering a new culture! Expecting the new language/culture/world to be better or similar to the old will lead to a lot of frustration and slow you down quite a bit. So leave your value judgements at the door and just try to understand things *as they are*. I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of. Tom Knight and the Lisp Machine A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: You cannot fix a machine by just power-cycling it with no understanding of what is going wrong. Knight turned the machine off and on. The machine worked.
Re: [9fans] Problem with mk
In response to both of you: On Wed, Dec 18, 2013 at 11:28 AM, Blake McBride bl...@mcbride.name wrote: ... I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of. Blake If you could point me in the right direction, I'd surely appreciate it. On Wed, Dec 18, 2013 at 12:13 PM, Bakul Shah ba...@bitblocks.com wrote: On Wed, 18 Dec 2013 11:28:21 CST Blake McBride bl...@mcbride.name wrote: I'd be a better judge if I understood the purposeful, thought out reason behind the problems I am experiencing - assuming there is one. That's just the way it works or we do it differently because we are not unix are stupid as hell arguments. That's just the way it works is exactly the right attitude to take when you are learning a new language or entering a new culture! Expecting the new language/culture/world to be better or similar to the old will lead to a lot of frustration and slow you down quite a bit. So leave your value judgements at the door and just try to understand things *as they are*. I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of. Tom Knight and the Lisp Machine A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: You cannot fix a machine by just power-cycling it with no understanding of what is going wrong. Knight turned the machine off and on. The machine worked.
Re: [9fans] Problem with mk
In particular, why would manual execution while echoing $status (to be sure no errors are reported) work, but mk execution of the exact same sequence not work? Thanks! Blake On Wed, Dec 18, 2013 at 12:20 PM, Blake McBride bl...@mcbride.name wrote: In response to both of you: On Wed, Dec 18, 2013 at 11:28 AM, Blake McBride bl...@mcbride.name wrote: ... I remain confident that there is a thought out, reasonable algorithm employed by mk that I am yet ignorant of. Blake If you could point me in the right direction, I'd surely appreciate it.
Re: [9fans] Problem with mk
The problem is solved, but I do have questions that I couldn't the answer to in any of the docs. On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries dexen.devr...@gmail.comwrote: -s won't help you there, because it regards processing of /command line/ arguments, not of prerequisites. consider: $ NPROC=1 mk my_target The NPROC=1 solved the problem. My mkfile is written in a way that requires a sequential operation. I need to look at it further. Think a large part of my problem was a misunderstanding of the -s option. Anyway, here is a question. Presuming I can't fix my mkfile to operate in parallel, is there a way to cause sequential operation other than the NPROC=1 at the command line? It's too easy to forget. Is there a way to specify that mode of operation by something I put into the mkfile? Thanks! Blake
Re: [9fans] Ideas from Plan-9
On Wed Dec 18 04:48:29 EST 2013, conor.willi...@gmail.com wrote: i'm getting an error code 87 writing usbdisk to my key: according to the web: The second fix prevents USB Image Tool from restoring invalid images in device mode. A valid device mode image has to be multiple of 512. If that’s not the case, the write operation will fail with error code 87 close to the end of the process. To prevent this, USB Image Tool now checks, if the image file size is a multiple of 512. http://www.alexpage.de/tag/usb-image-tool/ i'm not sure what tool you're using, but the image is a multiple of 512 bytes long. ; /n/atom/ftp/usbinstamd64.bz2 /tmp/usbinstamd64 bunzip2 ; ls -ltr /tmp --rw-rw-r-- M 788 quanstro quanstro 524288000 Dec 18 15:48 /tmp/usbinstamd64 ; echo 524288000 % 512 | hoc 0 perhaps something got corrupted. the crash dump is good information but in this case the pc does not appear to be valid, so i don't see what's wrong yet. - erik
Re: [9fans] Problem with mk
You could put NPROC=1 in the mkfile.
Re: [9fans] Problem with mk
Thanks. That is what I was wondering. In the interim, and having a better understanding of what is going on, I was able to re-work my mkfile to support parallel builds where possible. I am, however, experiencing a new problem. I will write that up in a separate post. Thank for the info! Blake On Wed, Dec 18, 2013 at 3:04 PM, Jacob Todd jaketodd...@gmail.com wrote: You could put NPROC=1 in the mkfile.
[9fans] mk time-check/slice issue
Greetings, I apologize for beating the heck out of the group. I admit that some of my questions are premature. I appreciate everyones help. I have a better handle on what is going on, and with that knowledge, I was able to restructure the mkfile to work correctly in parallel. I am encountering a new problem, however. Mk (and make) look at file times to determine what needs to be built. Cool. When I type mk my app builds just fine. The problem is that if I type mk again, it (at least) partially builds again. If I keep doing this, eventually it says my target is up-to-date. What I think is going on is that this little test app builds so fast that the file write times look like they are the same time. For example if I build main.c and then do: ls -lrt I should see them listed in this order: main.c main.8 main but sometimes I see them like this: main.c main main.8 I think this is caused because the time slice is too short and the system can't tell the build times apart. Even though main clearly came after main.8 the system sees them as the same time. Of course this can cause mk to dothe link again unnecessarily if mk is called again. This is what is happening to me. Each time I mk it builds less. Perhaps this is a problem with 9port under VMware. Perhaps, in certain environments, the time slices are too big. Any experience or thoughts on the matter are greatly appreciated. Blake
Re: [9fans] mk time-check/slice issue
On Dec 18, 2013, at 17:01, Blake McBride bl...@mcbride.name wrote: I apologize for beating the heck out of the group. I admit that some of my questions are premature. I appreciate everyones help. Don't worry about asking questions ever, man. It's good to see, seeing people willing to ask questions is rare nowadays and shows that you have true sack.
Re: [9fans] mk time-check/slice issue
I think this is caused because the time slice is too short and the system can't tell the build times apart. Even though main clearly came after main.8 the system sees them as the same time. Of course this can cause mk to dothe link again unnecessarily if mk is called again. This is what is happening to me. Each time I mk it builds less. Perhaps this is a problem with 9port under VMware. Perhaps, in certain environments, the time slices are too big. Any experience or thoughts on the matter are greatly appreciated. you are correct. this is all about time resolution. plan 9 times are recorded in 1s resolution, and unless you have a very slow processor, or a very big program, building linking a program can take less than 1s. - erik
[9fans] setting up secstore
I'm finally getting tired of having to type passwords and am setting up secstore on the 9atom cpuserver on a VirtualBox VM on my mac. I'm running into some problems presumably because some of the secstore files and directories are owned by glenda and not adm (i'm part of the adm and sys groups) I looked into changing the ownership of the files to adm/sys user, the stat command on the fossil console can't seem to find the /adm/secstore directory. Is the directory/file permissions really getting in the way of the secstore setup? If so, how can I fix the ownership? % auth/secuser dchawla new account (because /adm/secstore/dchawla accounts dchawla and FICTITIOUS do not exist) dchawla password: retype password: expires [DDMM, default = 18122014]: Enabled or Disabled [default Enabled]: require STA? [default no]: comments [default = ]: Deepak Chawla auth/secuser: can't write password file: can't open PW file for dchawla dcmacp9% ls -l /adm --rw-rw-r-- M 84 admadm 0 May 2 2002 /adm/cache d-rwxr-xr-x M 84 glenda sys 0 Jun 9 2013 /adm/secstore d-rwxrwxr-x M 84 admadm 0 Jun 9 2013 /adm/timezone --rw-rw-r-- M 84 admsys 130 Aug 1 10:17 /adm/users dcmacp9% ls -l /adm/secstore d-rwx-- M 84 glenda sys 0 Jun 9 2013 /adm/secstore/store d-rwxr-xr-x M 84 glenda sys 0 Jun 9 2013 /adm/secstore/who
Re: [9fans] mk time-check/slice issue
Thanks for the encouragement. I'll move into other areas soon. I'll try to do as much research as possible before posting. On Wed, Dec 18, 2013 at 4:08 PM, Matthew Veety mve...@gmail.com wrote: On Dec 18, 2013, at 17:01, Blake McBride bl...@mcbride.name wrote: I apologize for beating the heck out of the group. I admit that some of my questions are premature. I appreciate everyones help. Don't worry about asking questions ever, man. It's good to see, seeing people willing to ask questions is rare nowadays and shows that you have true sack.
Re: [9fans] mk time-check/slice issue
In part to substitute issues with time with issues with checksums, I am writing a build tool for Inferno loosely inspired by djb's redo. I think it deals nicely with some of the problems of make/mk tools: it handles multiple outputs, treats shell variables as /env files for dependencies, and uses the Inferno shell calling small programs, instead of a domain-specific shell-like language in a build description file. https://github.com/catenate/credo
Re: [9fans] Encoding private RSA key to PEM with p9p
Thanks, I managed to convert the key this way and added it to factotum. I think I also need to add the server's CA's certificate, so factotum can check the server identity. Right? I converted the CA crt to DER like this: openssl x509 -in ca.crt.pem -inform PEM -out ca.crt.der -outform DER Not I'm trying to convert this DER to the factotum format : asn12rsa -t 'proto=rsa service=tls owner=*' ca.crt.der ca.crt.plan9 but asn12rsa complains : asn12rsa: couldn't parse asn1 key 2013/12/17 David du Colombier 0in...@gmail.com I tried to do the opposite : generating keys as PEM using linux's openssl, then convert them to plan9 format using pemdecode without success. You have to convert the key from PEM to DER with OpenSSL, then convert it to the Factotum format using auth/asn12rsa: openssl rsa -in key.pem -inform PEM -out key.der -outform DER auth/asn12rsa -t 'proto=rsa service=tls owner=*' key.der key -- David du Colombier -- Jean-André Santoni
Re: [9fans] gdbfs
An Exynos port of Plan 9 on a ChromeBook... that would be seriously cool! On Thu, Dec 19, 2013 at 4:12 PM, Steven Stallion sstall...@gmail.comwrote: Evening 9fans, While working on the Chromebook (nee exynos) port I ended up in a situation where I needed to use a more sophisticated JTAG debugger to find an issue. I ended up grabbing a RealView ICE since they are relatively cheap on eBay (around 500.00USD) compared to other models capable of debugging Cortex-A15 cores. Older firmware revisions of the RVI support the remote GDB protocol (in addition to the closed RDDI protocol). I've written a simple 9P file server that translates memory/register accesses to remote GDB targets. I haven't tried it yet, but this should also work with OpenOCD as well. At the moment this is little more than a toy, but it has been stable enough for me to debug issues on the board reliably. I've added support for ARM and i386 for now - adding additional register maps for the other mach types is straightforward. If there is enough demand, I'll write up a man page and submit a patch. The setup for this isn't particularly obvious since it requires some messing about with RVI firmware updates and downloading the right version of RVDS to setup the board, so a wiki page is deserved as well. For now, you can find the source in my contrib directory on sources: /n/sources/contrib/stallion/src/gdbfs/ (Obligatory screenshot attached) Cheers, Steve
Re: [9fans] setting up secstore
I'm finally getting tired of having to type passwords and am setting up secstore on the 9atom cpuserver on a VirtualBox VM on my mac. I'm running into some problems presumably because some of the secstore files and directories are owned by glenda and not adm (i'm part of the adm and sys groups) I looked into changing the ownership of the files to adm/sys user, the stat command on the fossil console can't seem to find the /adm/secstore directory. i think it would be /active/adm/secstore on the fossil console. alternate solution, open the file system -W. - erik
Re: [9fans] mk time-check/slice issue
So, I think you are saying, that for pieces in a mkfile that take less than 1s to build it is possible for them to be build again, unnecessarily, when mk is run again. This is normal and just the way it is. Is that correct? to be more explicit. if a is built from b and mtime(a) = mtime(b), then mk could fail to rebuild a when it needs to. for correctness, mk must use = not . in some cases, it is possible that this will never converge and adding a sleep 1 to the rule helps things converge. certainly if the point is to save time, then one need not bother. on the other hand, if the point is to make mk precise, that goal can be accomplished with a little effort. - erik
Re: [9fans] mk time-check/slice issue
In part to substitute issues with time with issues with checksums, I am writing a build tool for Inferno loosely inspired by djb's redo. I think it deals nicely with some of the problems of make/mk tools: it handles multiple outputs, treats shell variables as /env files for dependencies, and uses the Inferno shell calling small programs, instead of a domain-specific shell-like language in a build description file. https://github.com/catenate/credo imho, mk could be greatly improved if it had a rule flag that would allow it to compile many c files with a single compiler invocation. - erik
Re: [9fans] mk time-check/slice issue
On Thu, 19 Dec 2013 00:40:52 EST erik quanstrom quans...@quanstro.net wrote: if the point is to make mk precise, that goal can be accomplished with a little effort. I suppose making atime, mtime of type struct timespec would break too much including 9p?
Re: [9fans] Encoding private RSA key to PEM with p9p
I think I also need to add the server's CA's certificate, so factotum can check the server identity. Right? Factotum is meant to store the private keys. The CA certificate would probably have its place in /sys/lib/tls (in PEM format). However, this is not needed, since the current X.509 implementation in Plan 9 doesn't verify certificate chain. Also, TLS client authentication isn't currently supported in Plan 9, but you could try Christian Kellermann's implementation. http://plan9.bell-labs.com/sources/patch/maybe/tls-client-auth/ hget http://www.9legacy.org/9legacy/patch/tls-client-auth.diff | ape/patch -p0 -- David du Colombier
