* [9fans] Problem with mk @ 2013-12-18 15:23 Blake McBride 2013-12-18 15:37 ` dexen deVries 2013-12-18 16:11 ` Blake McBride 0 siblings, 2 replies; 18+ messages in thread From: Blake McBride @ 2013-12-18 15:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2686 bytes --] Greetings, I have spent hours on a trivial problem that I still haven't figured out. I am using 9front, and I am building a C app using mk. I understand about that parallel stuff so I am calling mk with -s for now. There are actually three problems, but the fact that it won't build is clearly the first. Here are the facts: Problem 1: If I execute "mk -s", mk prints out what it is executing interspersed with messages from the command being executed. Somewhere in the middle I see: mk: ../../bin/dpp -g -t ... : status=rc 1357: dpp 1359: Exit code 1 Each time I run it, the two numbers (1357 & 1369) are different. This message is showing up in the middle of all of the commands getting executed. If I execute "mk -n" and manually execute each command the build succeeds. If I manually execute each command and append "; echo $status" to each command, no error code is ever displayed. Since I can build manually, and I get no error codes when I do so, I cannot figure out what the problem is. 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. 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. ---- Here is my mkfile: </$objtype/mkfile DYNACE_PATH = ../.. BINDIR = $DYNACE_PATH/bin LIBDIR = $DYNACE_PATH/lib INCDIR = $DYNACE_PATH/include TARGET = main CLASSES = class1.d CFILES = main.c OBJS = ${CFILES:%.c=%.$O} ${CLASSES:%.d=%.$O} CFLAGS = -DPLAN9 -I$INCDIR -p C_CLASSES = ${CLASSES:%.d=%.c} %.$O : %.c $CC $CFLAGS $stem.c %.c : %.d $BINDIR/dpp -g -p $prereq $TARGET : generics.1 generics.h generics.$O $OBJS $LD -o $target $OBJS generics.$O $LIBDIR/Dynace.a generics.h : $CLASSES $BINDIR/dpp -g -t generics.h generics.c generics.$O -h -s $newprereq generics.c : generics.h $BINDIR/dpp -g -c generics.1 newgens: $INCDIR/generics.h $BINDIR/dpp -g $INCDIR/generics.h -s $CLASSES -h touch generics.1 clean realclean:VQ: rm -f generics.* $TARGET *.$O $C_CLASSES Any suggestion would sure be appreciated. Thanks. Blake McBride [-- Attachment #2: Type: text/html, Size: 9422 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 15:23 [9fans] Problem with mk Blake McBride @ 2013-12-18 15:37 ` dexen deVries 2013-12-18 16:07 ` Blake McBride 2013-12-18 20:21 ` Blake McBride 2013-12-18 16:11 ` Blake McBride 1 sibling, 2 replies; 18+ messages in thread From: dexen deVries @ 2013-12-18 15:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 15:37 ` dexen deVries @ 2013-12-18 16:07 ` Blake McBride 2013-12-18 20:21 ` Blake McBride 1 sibling, 0 replies; 18+ messages in thread From: Blake McBride @ 2013-12-18 16:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2900 bytes --] Thanks for the help! See below: On Wed, Dec 18, 2013 at 9:37 AM, dexen deVries <dexen.devries@gmail.com>wrote: > 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 > > > [-- Attachment #2: Type: text/html, Size: 8601 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 15:37 ` dexen deVries 2013-12-18 16:07 ` Blake McBride @ 2013-12-18 20:21 ` Blake McBride 2013-12-18 21:04 ` Jacob Todd 1 sibling, 1 reply; 18+ messages in thread From: Blake McBride @ 2013-12-18 20:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 870 bytes --] 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.devries@gmail.com>wrote: > > > -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 [-- Attachment #2: Type: text/html, Size: 1742 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 20:21 ` Blake McBride @ 2013-12-18 21:04 ` Jacob Todd 2013-12-18 21:14 ` Blake McBride 0 siblings, 1 reply; 18+ messages in thread From: Jacob Todd @ 2013-12-18 21:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 38 bytes --] You could put NPROC=1 in the mkfile. [-- Attachment #2: Type: text/html, Size: 55 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 21:04 ` Jacob Todd @ 2013-12-18 21:14 ` Blake McBride 2013-12-19 8:16 ` dexen deVries 0 siblings, 1 reply; 18+ messages in thread From: Blake McBride @ 2013-12-18 21:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 435 bytes --] 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 <jaketodd422@gmail.com> wrote: > You could put NPROC=1 in the mkfile. > [-- Attachment #2: Type: text/html, Size: 799 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 21:14 ` Blake McBride @ 2013-12-19 8:16 ` dexen deVries 2013-12-19 16:20 ` Blake McBride 0 siblings, 1 reply; 18+ messages in thread From: dexen deVries @ 2013-12-19 8:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs the problem is not solved, merely one of the manifestation is eliminated. actual solution requires stating all the dependencies. if your list of sources and/or targets is dynamic, consider using mk include: <| GEN_DEPS where `GEN_DEPS' is your script generating deps in form TARGET: PREREQUISITE On Wed, Dec 18, 2013 at 10:14 PM, Blake McBride <blake@mcbride.name> wrote: > 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 <jaketodd422@gmail.com> wrote: >> >> You could put NPROC=1 in the mkfile. > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-19 8:16 ` dexen deVries @ 2013-12-19 16:20 ` Blake McBride 0 siblings, 0 replies; 18+ messages in thread From: Blake McBride @ 2013-12-19 16:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1328 bytes --] On Thu, Dec 19, 2013 at 2:16 AM, dexen deVries <dexen.devries@gmail.com>wrote: > the problem is not solved, merely one of the manifestation is eliminated. > actual solution requires stating all the dependencies. > > if your list of sources and/or targets is dynamic, consider using mkinclude: > <| GEN_DEPS > where `GEN_DEPS' is your script generating deps in form TARGET: > PREREQUISITE > > The following mkfile does what I need/expect without explicit dependencies. # Makefile for Plan 9 </$objtype/mkfile DYNACE_PATH = ../.. BINDIR = $DYNACE_PATH/bin LIBDIR = $DYNACE_PATH/lib INCDIR = $DYNACE_PATH/include TARGET = main CLASSES = class1.d CFILES = main.c OBJS = ${CFILES:%.c=%.$O} ${CLASSES:%.d=%.$O} CFLAGS = -DPLAN9 -I$INCDIR -p C_CLASSES = ${CLASSES:%.d=%.c} %.$O : %.c $CC $CFLAGS $stem.c %.c : %.d $BINDIR/dpp -g -p $stem.d $TARGET : generics.$O $OBJS $LD -o $target $OBJS generics.$O $LIBDIR/Dynace.a generics.h : generics.1 $CLASSES $BINDIR/dpp -g -t generics.h generics.c generics.$O -h -s $newprereq generics.c : generics.h $BINDIR/dpp -g -c generics.1 newgens: $INCDIR/generics.h $BINDIR/dpp -g $INCDIR/generics.h -s $CLASSES -h touch generics.1 $OBJS $C_CLASSES : generics.h clean realclean:VQ: rm -f generics.* $TARGET *.$O $C_CLASSES [-- Attachment #2: Type: text/html, Size: 6976 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 15:23 [9fans] Problem with mk Blake McBride 2013-12-18 15:37 ` dexen deVries @ 2013-12-18 16:11 ` Blake McBride 2013-12-18 16:40 ` Bakul Shah 1 sibling, 1 reply; 18+ messages in thread From: Blake McBride @ 2013-12-18 16:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 579 bytes --] On Wed, Dec 18, 2013 at 9:23 AM, Blake McBride <blake@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. [-- Attachment #2: Type: text/html, Size: 1121 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 16:11 ` Blake McBride @ 2013-12-18 16:40 ` Bakul Shah 2013-12-18 17:06 ` Aram Hăvărneanu 2013-12-18 17:28 ` Blake McBride 0 siblings, 2 replies; 18+ messages in thread From: Bakul Shah @ 2013-12-18 16:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 18 Dec 2013 10:11:22 CST Blake McBride <blake@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 16:40 ` Bakul Shah @ 2013-12-18 17:06 ` Aram Hăvărneanu 2013-12-18 17:18 ` Blake McBride 2013-12-18 17:28 ` Blake McBride 1 sibling, 1 reply; 18+ messages in thread From: Aram Hăvărneanu @ 2013-12-18 17:06 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs D on Plan 9? This is madness. -- Aram Hăvărneanu ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 17:06 ` Aram Hăvărneanu @ 2013-12-18 17:18 ` Blake McBride 2013-12-18 17:27 ` Rubén Berenguel 0 siblings, 1 reply; 18+ messages in thread From: Blake McBride @ 2013-12-18 17:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 842 bytes --] 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 <aram.h@mgk.ro> wrote: > D on Plan 9? This is madness. > > -- > Aram Hăvărneanu > > [-- Attachment #2: Type: text/html, Size: 1469 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 17:18 ` Blake McBride @ 2013-12-18 17:27 ` Rubén Berenguel 0 siblings, 0 replies; 18+ messages in thread From: Rubén Berenguel @ 2013-12-18 17:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1163 bytes --] 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 <blake@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 <aram.h@mgk.ro> wrote: > >> D on Plan 9? This is madness. >> >> -- >> Aram Hăvărneanu >> >> > [-- Attachment #2: Type: text/html, Size: 1948 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 16:40 ` Bakul Shah 2013-12-18 17:06 ` Aram Hăvărneanu @ 2013-12-18 17:28 ` Blake McBride 2013-12-18 17:47 ` Kurt H Maier 2013-12-18 18:13 ` Bakul Shah 1 sibling, 2 replies; 18+ messages in thread From: Blake McBride @ 2013-12-18 17:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1765 bytes --] 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 <bakul@bitblocks.com> wrote: > On Wed, 18 Dec 2013 10:11:22 CST Blake McBride <blake@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. > > [-- Attachment #2: Type: text/html, Size: 4018 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 17:28 ` Blake McBride @ 2013-12-18 17:47 ` Kurt H Maier 2013-12-18 18:13 ` Bakul Shah 1 sibling, 0 replies; 18+ messages in thread From: Kurt H Maier @ 2013-12-18 17:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Quoting Blake McBride <blake@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 17:28 ` Blake McBride 2013-12-18 17:47 ` Kurt H Maier @ 2013-12-18 18:13 ` Bakul Shah 2013-12-18 18:20 ` Blake McBride 1 sibling, 1 reply; 18+ messages in thread From: Bakul Shah @ 2013-12-18 18:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, 18 Dec 2013 11:28:21 CST Blake McBride <blake@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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 18:13 ` Bakul Shah @ 2013-12-18 18:20 ` Blake McBride 2013-12-18 18:28 ` Blake McBride 0 siblings, 1 reply; 18+ messages in thread From: Blake McBride @ 2013-12-18 18:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1686 bytes --] In response to both of you: On Wed, Dec 18, 2013 at 11:28 AM, Blake McBride <blake@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 <bakul@bitblocks.com> wrote: > On Wed, 18 Dec 2013 11:28:21 CST Blake McBride <blake@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. > > [-- Attachment #2: Type: text/html, Size: 4000 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [9fans] Problem with mk 2013-12-18 18:20 ` Blake McBride @ 2013-12-18 18:28 ` Blake McBride 0 siblings, 0 replies; 18+ messages in thread From: Blake McBride @ 2013-12-18 18:28 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 626 bytes --] 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 <blake@mcbride.name> wrote: > In response to both of you: > > On Wed, Dec 18, 2013 at 11:28 AM, Blake McBride <blake@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. > > [-- Attachment #2: Type: text/html, Size: 1915 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2013-12-19 16:20 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-12-18 15:23 [9fans] Problem with mk Blake McBride 2013-12-18 15:37 ` dexen deVries 2013-12-18 16:07 ` Blake McBride 2013-12-18 20:21 ` Blake McBride 2013-12-18 21:04 ` Jacob Todd 2013-12-18 21:14 ` Blake McBride 2013-12-19 8:16 ` dexen deVries 2013-12-19 16:20 ` Blake McBride 2013-12-18 16:11 ` Blake McBride 2013-12-18 16:40 ` Bakul Shah 2013-12-18 17:06 ` Aram Hăvărneanu 2013-12-18 17:18 ` Blake McBride 2013-12-18 17:27 ` Rubén Berenguel 2013-12-18 17:28 ` Blake McBride 2013-12-18 17:47 ` Kurt H Maier 2013-12-18 18:13 ` Bakul Shah 2013-12-18 18:20 ` Blake McBride 2013-12-18 18:28 ` Blake McBride
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).