Back
[02:20:52] <cmorley> spam on forum alert.....
[09:22:19] <morlenxus_> hi
[09:22:31] <morlenxus_> Someone here has experience with rtnet? I would like to get the remote ip address when getting packets with rt_dev_recv.
[09:24:29] <KimK_2> CaptHindsight: Good morning. I'm not at all sure I did the config right, but I left the make running last night and left. I didn't use the -j2 option. Here's the last screenful of make output:
http://pastebin.com/SDYqRa22 Shall I build again using the ...MISMATCH=y option? Or continue with "sudo make install"? Or something else? Oh, also pasted are some other info-gathering screens that may help.
[09:25:45] <KimK_2> morlenxus_: Hi. You're in the right place, but people are often busy doing other things, and are in and out. Please be patient, and eventually someone who knows will see your question.
[09:25:55] <morlenxus_> Thanks :)
[09:26:55] <KimK_2> In fact, I have to go back to other things now too, but I'll check back later.
[10:19:45] <morlenxus_> If receiving the ip using rt_dev_recv () is not possible, is it possible to get the current used IP from rteth0 with some rtnet function? I would let the client send the ip with the data to the server.
[10:21:36] <pcw_home> Can't you get it from RT-nets arp table? (assuming you know the MAC address)
[10:22:42] <morlenxus_> The rtnet arp table only holds the remote mac addresses.
[10:25:31] <morlenxus_> If only one client would send packets, that could be used by the server, yes. But i have different client.
[10:28:20] <pcw_home> Thats odd, what does the ARP table hold if not MAC/IP address pairs?
[10:32:53] <jepler> morlenxus_: recvfrom gives you the sender's address
[11:11:42] <morlenxus_> w00t
[11:11:49] <morlenxus_> That would be way to easy :)
[11:11:54] <morlenxus_> Checking that, thanks.
[11:27:40] <jepler> morlenxus_: I am not familiar with rtnet but that is how normal userspace recvfrom works
[11:31:34] <zultron> jepler, you see the earlier exchange with awallin about problems with UBC and make -j2? If you have any insight on that, I'd love some help.
[11:31:50] <zultron> Here's his build log with the problem we've been able to reproduce:
http://pastebin.ca/2443030
[11:32:32] <zultron> It's during the 2nd-level recursion 'make modules'.
[11:32:32] <jepler>
[11:32:32] <jepler> Sorry, an error has occurred. Reason: That is an invalid ID, or the post has expired.
[11:33:23] <zultron> jepler: Still had it open, so just repasted. :)
http://pastebin.ca/2443538
[11:34:57] <zultron> You can see that the linker's being run twice for some objects.
[11:35:54] <jepler> is this while building a ref that is on git.l.o?
[11:36:16] <zultron> Yes, unified-build-candidate-3.
[11:36:41] <zultron> Earlier UBCs had the same problem, but failed earlier at a 'ln -sf' that I masked over.
[11:37:34] <zultron> masked over for UBC3, that is, which simply made the problem manifest itself at a later point in the build.
[11:38:35] <jepler> how reliably does this occur with "make -j2" on a clean tree?
[11:39:36] <zultron> On my Precise machine, every time. On my EL6 machine, never.
[11:40:03] <jepler> is the recursive make supposed to be just for kernel modules?
[11:40:16] <zultron> Yes, that's the only extra recursion I added.
[11:40:20] <jepler> i.e., it is an error if the recursive make is building something like userspace librs274?
[11:40:47] <jepler> (which you can't tell from the output of make: it can run the recursive make in parallel with the outer make)
[11:40:50] <zultron> Yes. I think you're homing in on it. :)
[11:43:16] <jepler> when you recursively invoke make, you should specify a target which causes it to build just the things that are dependent on the value of threads=
[11:43:19] <jepler> otherwise it builds the default target again
[11:43:44] <zultron> Ah ha.
[11:43:55] <jepler> I didn't immediately see what that target name would be
[11:44:04] <zultron> e.g. 'make modules_posix'?
[11:44:20] <zultron> That could be done without recursion.
[11:44:43] <jepler> is modules_posix something that doesn't exist yet? git grep didn't find it for me.
[11:45:45] <zultron> Nevermind, I misread your suggestion. Lemme think...
[11:45:46] <jepler> is it just 'modules' again, and you get a different rule for modules when threads= is non-empty?
[11:45:52] <CaptHindsight> KimK_2: please post the kernel config you used when you get a chance
[11:46:15] <zultron> Yes, the top-level make modules target simply calls $(MAKE) modules threads=posix.
[11:47:02] <zultron> That's all controlled by conditionals based on the value of $(threads) (or indirectly so).
[11:47:16] <jepler> try this?
http://emergent.unpythonic.net/files/sandbox/0001-only-build-modules-when-recursing-for-each-flavor.patch
[11:47:38] <jepler> make -j doesn't error out here (ubuntu 10.04, no realtime kernel installed) so I don't know if it'll do the trick
[11:47:52] <zultron> Oh wow, how'd I miss that.
[11:48:06] <jepler> probably staring at it too long?
[11:48:55] <zultron> I must've thought that was all buttoned up & didn't need to check it again. :-/
[11:50:25] <jepler> well if it's that easy you can have my patch for free this time
[11:54:54] <zultron> I even wrote it above: <zultron> Yes, the top-level make modules target simply calls $(MAKE) modules threads=posix.
[11:55:00] <zultron> That was it. Thank you!
[11:55:09] <jepler> you're welcome
[12:14:46] <mhaberler> jeff - thanks; really appreciated
[12:15:34] <mhaberler> can I run a thought for background consideration by you - because it affects preview (this is part of the 'noNML'-work)
[13:12:46] <KGB-linuxcnc> 03john 05unified-build-candidate-3 4c19bf9 06linuxcnc 10src/Makefile * UB Makefile: fix recursive make -j2
[13:13:17] <jepler> mhaberler: sorry, I went off to lunch without seeing your request
[13:21:17] <linuxcnc-build> build #1301 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1301 blamelist: John Morris <john@zultron.com>
[13:21:48] <linuxcnc-build> build #1299 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1299 blamelist: John Morris <john@zultron.com>
[13:23:34] <linuxcnc-build> build #1297 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1297 blamelist: John Morris <john@zultron.com>
[13:25:19] <linuxcnc-build> build #1297 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1297 blamelist: John Morris <john@zultron.com>
[13:26:19] <jepler> hmm that lucid build failure probably requires attention
[13:26:24] <jepler> the real error seems to be: asciidoc: ERROR: UnifiedBuild.txt: line 979: empty section is not valid
[13:28:30] <linuxcnc-build> build #1300 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1300 blamelist: John Morris <john@zultron.com>
[13:30:06] <jepler> perhaps the level of headings is not what is intended ("short term" should be a subsection of "remaining work" but is not..?)
[13:31:51] <linuxcnc-build> build #1300 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1300 blamelist: John Morris <john@zultron.com>
[13:33:07] <KimK_2> CaptHindsight: Sure, no problem. The .config file is now at
http://pastebin.com/bs2VfwUD . I also have rtai_64_defconfig and rtai_64_defconfig.old, if those would help.
[13:36:07] <jepler> for consideration of anybody who's watching and wants to test it before pushing to ubc3:
http://emergent.unpythonic.net/files/sandbox/0001-docs-Fix-empty-section-error.patch
[13:44:42] <memleak> KimK_2, Hello. I see you are having troubles building RTAI from source. If you are not going to follow that guide exactly, word for word, I cannot help you. I told seb that he can go around my instructions because he is experienced with that sort of thing, but that was only for seb. If you follow my HOWTO and do not go around it by any means, it should work fine. It is very straight forward and well written.
[13:45:27] <memleak> If you have any questions let me know, but be sure to read and follow it carefully.
[13:47:10] <memleak> The README.INSTALL file should work fine. Unless you highly experienced with building RTAI, I suggest that.
[13:48:53] <jepler> zultron or mhaberler: I tested my doc build fix on lucid, should I push it to ubc3 or let someone else do it?
[13:50:09] <KimK> memleak: Ah, thanks, you have looked at my posts and found that I made some mistake? What was it?
[13:51:16] <memleak> kernel config issues.
[13:52:04] <memleak> http://pastebin.com/SDYqRa22 staging is turned on, my config doesn't turn on staging, therefor fixes the problem.
[13:54:01] <memleak> use rtai_64_defconfig, then save it to .config
[13:54:22] <KimK> Issues? Ha, well, that's very likely, since that's the first time I've ever done (that is, stumbled through) a kernel config, and I had a lot of unknowns and unanswered questions. Thanks very much for figuring it out, I'll look forward to trying it again later.
[13:55:28] <memleak> you can make the kernel use rtai_64_defconfig two ways. load it through make menuconfig and save it to an alternative config location then typing in ".config" without quotes (with the beginning period) or you can use mv -v rtai_64_defconfig .config then use make oldconfig
[13:58:02] <KimK> OK, thanks. And how do I turn off staging, that is, where do they hide that in the makeconfig menu? (Sheesh, what a menu)
[13:58:20] <memleak> my config does all that for you (rtai_64_defconfig)
[13:58:34] <KimK> Oh, OK, great!
[13:58:48] <memleak> all you have to do is enable scsi and I2C support for your board
[13:59:12] <memleak> README.INSTALL walks you through. lspci -k ftw!
[14:00:19] <KimK> And since I have both rtai_64_defconfig and rtai_defconfig.old at this point, which one should I use?
[14:00:33] <KimK> Oops
[14:01:19] <KimK> s/ and rtai_/and rtai_64_/
[14:01:30] <memleak> you shouldn't write to rtai_64_defconfig rather write it to .config
[14:01:44] <memleak> at this point this is what i would do to be safe
[14:01:57] <KimK> OK, well, at this point I'm not really sure what I did.
[14:02:06] <memleak> make mrproper && rm -rf *defconfig*
[14:02:41] <memleak> inside kernel source run this:
[14:02:48] <memleak> wget
https://raw.github.com/ShabbyX/RTAI/master/base/arch/x86/configs/rtai_64_defconfig
[14:03:25] <memleak> follow README.INSTALL starting at line 87: make menuconfig
[14:03:29] <mhaberler> jepler: thanks - just push it!
[14:04:00] <linuxcnc-build> build #397 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/397 blamelist: John Morris <john@zultron.com>
[14:04:11] <mhaberler> of course, you could do a pull request on your github repo too ;)
[14:04:40] <memleak> mhaberler, my github repo?
[14:04:55] <jepler> ho boy, trying so hard today to not be trolled
[14:05:06] <memleak> oh that was to jepler, sorry
[14:05:11] <KGB-linuxcnc> 03jepler 05unified-build-candidate-3 0d3b24c 06linuxcnc 10docs/src/common/UnifiedBuild.txt * docs: Fix 'empty section' error
[14:06:31] <KimK> memleak: OK, thanks very much. If you think of any other advice, please post it, and I'll check back later when I retry.
[14:06:34] <linuxcnc-build> build #381 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/381 blamelist: John Morris <john@zultron.com>
[14:06:41] <mhaberler> jepler: let me know when you have say 15min to pull plans for NML restructuring by you, for now: task+builtin interp (that's the hard part anyway)
[14:07:32] <memleak> KimK, just run make mrproper && rm -rf *defconfig* inside kernel source then do the wget command, then follow the guide at make menuconfig and you should be fine.
[14:07:42] <linuxcnc-build> build #381 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/381 blamelist: John Morris <john@zultron.com>
[14:07:44] <jepler> not sure what interp has to do with anything, since it doesn't deal in nml (does it?)
[14:07:59] <linuxcnc-build> build #501 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/501 blamelist: John Morris <john@zultron.com>
[14:08:41] <memleak> KimK, the only issue i could think of are possible X issues on your next reboot. what graphics card and current distro are you on?
[14:09:52] <mhaberler> semi, it touches upon structure but it takes more than one line
[14:11:19] <linuxcnc-build> build #407 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/407 blamelist: John Morris <john@zultron.com>
[14:11:20] <linuxcnc-build> build #1295 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1295 blamelist: John Morris <john@zultron.com>
[14:16:10] <mhaberler> actually canon is conveyed as NML messages internally, but the point is rather that task has become a bloated pig, and I think before going about it it is time to review the structure; since we now have RPC and pub/sub comms pattern ontop of the shmbuffer model, it becomes fairly straightforward to for instance split out interp into a demon. This would have several advantages: the bizarre mdi/readahead_reading() logic just goes awa
[14:16:10] <mhaberler> the interpreter has its own main loop feed by rpc commands (taskplanopen, taskplanrun, execute(mdi) etc); on synch() it would do an rpc into the demon which manages the world model (the replacement for EMC_STAT which wont go over a shm buffer anymore).
[14:19:20] <linuxcnc-build> build #1298 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1298 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:19:26] <mhaberler> I think a reasonable split could be: spin out interp into a process (and while at it it becomes instantiable, which it isnt now because of the static _setup); second, separate task between taskplan(), and taskexecute(). this is exactly what was proposed years ago here:
http://www.fennetic.net/irc/emc3/docs/EMC3_Architecture.doc (discussion between Fenn and JMK)
[14:19:51] <mhaberler> the upside is: taskexecute() is a useful motion scripting api, which we dont have now
[14:19:54] <linuxcnc-build> build #1302 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1302 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:20:20] <mhaberler> its either task or nothing else driving it
[14:21:11] <linuxcnc-build> build #1300 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1300 blamelist: Jeff Epler <jepler@unpythonic.net>
[14:21:44] <mhaberler> taskexecute() would move to the RT environment and have a zmq/protobuf public API; the interp calling cruft is gone, meaning state/mode management and scheduling is left in task (i.e. taskplan()), and that is potentially comprehensible for mortals.
[14:22:03] <mhaberler> now while thinking about spinning out interp, I had the following idea:
[14:23:11] <mhaberler> one could perfectly well feed the interp with a 'preview' option ontop of the input (file or string for mdi), and in task couple out the generated canon commands for preview generation, meaning the requirement to have a second interp in the gui goes away
[14:23:55] <mhaberler> since there's only one left, harder to get out of sync, and UI's not bothere with preview interp (which implies sharing file systems btw)
[14:25:26] <jepler> mhaberler: reading back...
[14:25:42] <mhaberler> preview plotting would come out of task on the preview run; progress remains with the machine state server; UI's subscribe to what they want via pub/sub
[14:27:37] <mhaberler> what the interpd process gives us ontop of a drastic simplification of control flow is: you can have several instances, and switch in task between them. That combined with the alternate motion queue scheme I came up with a while ago for jog-during-pause will give us MDI-during-pause
[14:27:42] <jepler> Right now you can do things with the interpreter like run rs274 standalone in a single process, and if you can find your way around all the broken pieces you can do the same thing in axis (printcanon, bitrotted though it is)
[14:28:29] <jepler> the "single process" thing I don't care so much about, but if there becomes an extra setup step then it had better be encapsulated pretty conveniently
[14:28:40] <mhaberler> I wouldnt touch that, the instantiation scheme of the interpreter remains as is, as does rs274 and the py module for those who need it
[14:29:06] <jepler> there's no reason that you wouldn't want a UI where you can inspect the next part program to be run while the previous part program is actually running
[14:29:48] <mhaberler> still parsing the first part of that sentence..
[14:30:44] <mhaberler> oh, I see. sure, this comes with the concept of several input contexts, which are tied to interp instances.
[14:30:53] <jepler> I want to still be able to simply: rs274 -g foo.ngc
[14:31:18] <jepler> without manually starting some sort of "interp daemon"
[14:31:45] <jepler> (or is that not the sentence that was causing a parse error?)
[14:32:10] <mhaberler> I am not suggesting to remove rs274
[14:32:29] <mhaberler> I am suggesting to make task and interp interact in a different and simpler way
[14:32:51] <mhaberler> the interp class isnt touched at all, it is all at the instantiation and use level
[14:33:13] <mhaberler> hence rs274 doesnt change either
[14:33:15] <jepler> I was thinking about what it might be nice to do in user interface land, and running one program while previewing another might be nice -- axis doesn't do it now, but it *could* now, but it would be harder if both the "preview interp" and "running interp" were one and the same interpreter instance in the address space of some daemon program
[14:34:23] <jepler> ok, I must have latched on to and misinterpreted a single element of what you were saying
[14:35:12] <mhaberler> it is fresh, sorry - be patient a bit
[14:35:30] <mhaberler> I've only been discussing with Sascha offline, in german ;)
[14:35:30] <jepler> you sure could make up a list of all the calls in and out of the interpreter and put them behind an RPC / IPC / something interface if that's useful
[14:36:42] <mhaberler> well yes, that corresponds to a few taskplan* routines in task. The simplification of control flow comes from burying the idea of task calling interp line by line, and have task its own read/eval loop
[14:36:57] <jepler> with a similar level of work (maybe with the same work) you could also make interp run as a thread in task without RPC/IPC, just inter-thread communication
[14:37:10] <mhaberler> when it needs to sync, it does an rpc to the machestate demon, all linear - no more MDI contortions
[14:37:21] <mhaberler> that I have considered
[14:37:39] <mhaberler> if we can deal with the _setup static blob, that is an option
[14:38:07] <mhaberler> the demon scheme gets around that, and gets a public messaging api ontop
[14:38:43] <mhaberler> nb: everything which operates over zmq+protobuf messages can be done in Python with no further bindings
[14:39:27] <jepler> I know I have beaten this drum before but: as we know, the difficulty (technical and political) of merging stuff goes up in a worse-than-linear fashion vs the amount of stuff changed
[14:39:27] <mhaberler> pyzmq bindings exist in good shape, and all protobuf messages have autogenerated python classes
[14:39:27] <CaptHindsight> KimK: just to be clear, building an Ubuntu kernel (using Ubuntu kernel configs) for RTAI is up to whoever wants to do it, but it's highly unlikely to be memleak or myself
[14:39:37] <jepler> so get zmq stuff done first and then do the next thing which sensibly builds on it separatelty
[14:40:10] <mhaberler> that isnt either or, in fact is it in the context of this work. this is why:
[14:40:43] <jepler> I understand your ideas about interp build on zmq, so it's not mix-and-match
[14:40:54] <jepler> but zmq sounds like one step, and interp like a second step that builds on the first step
[14:41:04] <mhaberler> I have done a partial slipping in of zmq/protobuf into task, and that works fine at that particular level.
[14:41:11] <mhaberler> now there are two ways you can go about this:
[14:41:36] <mhaberler> you can transliterate NML semantics into zmq/pb as is
[14:41:45] <CaptHindsight> KimK: we will be working on getting RTAI working with newer kernels, but they aren't Ubuntu specific
[14:42:15] <mhaberler> b) you can take advantage of the comms patterns you have now to simplifiy the structure
[14:43:00] <mhaberler> I have considered a then b, I think b) without a) is more sensible because we get a simplification and two useful api's with it
[14:43:54] <mhaberler> meaning: only a) forfeits the advantages of using the new patters, at great cost btw - very tedious
[14:44:42] <mhaberler> this is why I'm considering this step and asking on opinions; I'm not sure about the best way forward
[14:45:51] <mhaberler> my implicit hope is that what is with what is left of task, and not any NML in it, it becomes amenable to alternative implementations which might even use python
[14:46:28] <mhaberler> as long as we have NML in it, we're married to c++ there, except if one goes the detour of cooking complete NML python bindings
[14:46:47] <mhaberler> I'd prefer a year of Guantanamo ;)
[14:46:52] <jepler> OK there's something I'm missing, because the API of interp is C++ function calls and methods, not NML
[14:46:56] <jepler> nobody gets just a year in gitmo
[14:47:12] <jepler> so anyway we must be understanding "the API of interp" as different things
[14:47:15] <mhaberler> even on good conduct ;)
[14:47:42] <mhaberler> no look at emcanon, that's where NML comes in - not at the interp level directly
[14:48:00] <mhaberler> and of course not in the preview interp with the fake canon callback layer
[14:48:27] <mhaberler> standing back a bit I view preview and progress like so:
[14:48:39] <jepler> I think the API is functions called by the interpreter (like STRAIGHT_TRAVERSE) and calls into the interpreter (like Interp::execute)
[14:48:51] <mhaberler> right
[14:49:32] <jepler> I don't care about emccanon.cc and whether it e.g., has an instance of EMC_TRAJ_LINEAR_MOVE or a global called interp_list of whatever type it is
[14:49:55] <mhaberler> there are two sources of points or polylines, generated by different entities - that is a perfect match for a pub/sub model; interested parties subscribe to the position and/or polyline stream
[14:49:58] <jepler> in the sense that you can change that to your heart's content without affecting rs274 or gcodemodule
[14:50:53] <mhaberler> absolutely, thats what I mean with a flag to interp meaning preview or 'for good' - essentially it ticks a box in canon for preview or running semantics
[14:51:16] <mhaberler> whichs isnt all that different from what is there now - to different canon layers linked to the same interp
[14:52:15] <mhaberler> except for a runtime choice, and task nows what to do - pass to taskexecute(), or publish as preview polylines
[14:52:43] <mhaberler> single method for all UI's, and no assumptions about shared filesystem
[14:53:31] <jepler> that would be an interesting step to take later
[14:53:33] <mhaberler> in the overall scheme, I would view that as a minor advantage, which in alone isnt worth it; together with the instantiable interps, and the simplification in task IMO it becomes worthwhile
[14:54:05] <jepler> because of the ongoing UB3 process I just am driven so hard to try to find out: what's the smallest mergeable portion of the Big Picture(TM) idea
[14:54:35] <jepler> and you seem to find that viewpoint .. less interesting
[14:54:53] <mhaberler> no, not at all - in ub3 its src/rtapi, and structurally quite simple
[14:55:10] <andypugh> Why don't we just start again from scratch? (Not an altogether stupid idea, you could pull in a lot of existing code, but only the good bits)
[14:55:59] <mhaberler> I'm happy to give a walkthrough or some other form of guidance at it, but I have found very few interested parties so far ;)
[14:56:49] <mhaberler> andypugh: thats quite reasonable - for instance interp is reasonable to keep, which this idea includes
[14:57:34] <mhaberler> oh, I forgot one upside of the separate interpd approach. It becomes trivial to use say Python or some other language as an interp
[14:58:10] <mhaberler> because the complexities of task/interp interactions completely vanish - it is one single read-eval-generate canon loop, with an rpc for syn as needed
[14:58:14] <mhaberler> any language can do that
[14:58:15] <andypugh> I think that is a worthy aim. G-code is horrible,
[14:58:59] <andypugh> 3D printers should be sent polygons and fill patterns, not G-code moves.
[14:59:25] <mhaberler> all it needs to do is expose the meth ods as equivalent to the ones currently called by task, which are maybe 5-10
[14:59:31] <jepler> $DAY_JOB is calling me. Have fun storming the castle.
[14:59:36] <mhaberler> ha!
[15:00:44] <jepler> we do have plugabble interpreters though they have to be C++ ".so"s. libcanterp is the one that we build and test, so it's not too useful.
[15:00:49] <jepler> see tests/interp/plug
[15:01:14] <CaptHindsight> AMF for 3D printers makes more sense than using G-code
[15:01:40] <CaptHindsight> we have put up with G-code for now, but thats going to change
[15:01:56] <jepler> AMF may refer to: ... Adios Motherfucker, a mixed drink with high alcoholic content. [note: no wikipedia page]
[15:02:23] <CaptHindsight> heh,
http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format
[15:04:09] <mhaberler> well yes, you can tick any interp-<yourpreference>.so box when starting an interpd - no change here; the point is: the external api becomes the input rpc's which pass open/run/mdi etc commands, and canon at the output end; plus sync() rpc, and logging. that is the external API which is required so it can be plugged into the scheme - this is at a higher level than the interp class; meaning you can do the former without the latter
[15:05:04] <mhaberler> and Andy gets his chance to generate canon from Visualbasic, toolchange and all ;)
[15:05:09] <jepler> please forgive me for dropping into sarcasm mode for a moment, but maybe it's time to port linuxcnc to the hurd microkernel, but then what would we call it?
[15:05:20] <jepler> now really $DAY_JOBbing, honest
[15:05:37] <linuxcnc-build> build #382 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/382 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:06:05] <mhaberler> I would call it linuxcnc with a sensible structural design, enabled by postwar middleware
[15:06:12] <linuxcnc-build> build #398 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/398 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:06:59] <mhaberler> that NML boat anchor has held things back incredibly
[15:07:05] <jepler> seb_kuzminsky: it looks like the precise buildslaves need hugs and kisses, tests are failing due to halrun: Realtime already running. Use 'halrun -U' to stop existing realtime session.
[15:08:03] <linuxcnc-build> build #502 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/502 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:10:06] <linuxcnc-build> build #1301 of lucid-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1301 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:10:18] <linuxcnc-build> build #382 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/382 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:10:57] <mhaberler> jepler: re docs - the weird thing is - I saw the bb log showing an error, and failing to complete the PDF - just it wont reproduce on my lucid install which completes fine
[15:11:14] <jepler> mhaberler: it reproduced on my lucid install actually
[15:11:40] <mhaberler> could you check 'asciidoc --version', I might have a fudged one: 8.5.2
[15:12:18] <jepler> here too: asciidoc 8.5.2
[15:12:32] <linuxcnc-build> build #408 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/408 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:12:33] <linuxcnc-build> build #1296 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1296 blamelist: Jeff Epler <jepler@unpythonic.net>
[15:12:36] <jepler> 8.5.2-1ubuntu1
[15:13:06] <mhaberler> yep, apt-show-versions |grep asciidoc
[15:13:07] <mhaberler> asciidoc/lucid uptodate 8.5.2-1ubuntu1
[15:14:16] <mhaberler> hm, was it actually asciidoc which failed or some later stage command? the docs build is a tad byzantine
[15:15:40] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1297/steps/compile/logs/stdio
[15:16:05] <mhaberler> aja, a2x failed
[15:16:07] <jepler> so asciidoc prints a line that says ERROR, then a2x prints a line that says ERROR, but the thing that actually stops make is a 'rm' command
[15:17:13] <jepler> oh, it's the conditional remove in the case of a2x failing:
[15:17:18] <jepler> $(A2X) -L -d book -vf pdf $< || (X=$$?; rm $@; exit $$X)
[15:17:28] <jepler> should be rm -f $@ or something
[15:17:43] <jepler> so yes A2X is failing, and then the just-in-case removal of the output file also fails
[15:17:56] <jepler> (if a2x failed but left its output file in place, then a subsequent make would incorrectly decide it did not have to build that target)
[15:18:16] <jepler> (most programs that are intended to be called from make delete an incomplete output file, but we must have had evidence to the contrary about a2x)
[15:19:14] <jepler> psha's initial commit of the asciidoc stuff had that removal rule so it was apparently not worth separate notice
[15:22:41] <mhaberler> so the asciidoc error makes a2x fail, and the a2x fail causes the rm, the rm fails, and things grind to halt. Fine. Still doesnt explain to me why my build worked.. a2x is 8.5.2 here as well. Very odd. Well tomorrow is new moon.
[15:23:28] <mhaberler> should we try with an rm -f ? wont cost much
[15:24:38] <mhaberler> I guess it's the '%.pdf: %.txt' rule
[15:28:58] <KGB-linuxcnc> 03git 05ubc3-doc-test 524449c 06linuxcnc 10docs/src/Makefile * docs/build: dont fail on removing a non-existent file
[15:29:27] <mhaberler> I backed out your fix so it fails, lets see
[15:37:08] <linuxcnc-build> build #1303 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1303 blamelist: Michael Haberler <git@mah.priv.at>
[15:38:29] <linuxcnc-build> build #1299 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1299 blamelist: Michael Haberler <git@mah.priv.at>
[15:38:53] <linuxcnc-build> build #1301 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1301 blamelist: Michael Haberler <git@mah.priv.at>
[15:42:29] <linuxcnc-build> build #1299 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1299 blamelist: Michael Haberler <git@mah.priv.at>
[15:45:52] <linuxcnc-build> build #1302 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1302 blamelist: Michael Haberler <git@mah.priv.at>
[15:47:34] <linuxcnc-build> build #1302 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1302 blamelist: Michael Haberler <git@mah.priv.at>
[15:53:29] <mhaberler> looks like I managed to modify the wrong rule :/
[16:19:20] <linuxcnc-build> build #399 of precise-x86-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-rtpreempt-rip/builds/399 blamelist: Michael Haberler <git@mah.priv.at>
[16:20:52] <linuxcnc-build> build #383 of precise-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-rtpreempt-rip/builds/383 blamelist: Michael Haberler <git@mah.priv.at>
[16:22:47] <linuxcnc-build> build #383 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/383 blamelist: Michael Haberler <git@mah.priv.at>
[16:23:39] <linuxcnc-build> build #503 of precise-i386-realtime-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/503 blamelist: Michael Haberler <git@mah.priv.at>
[16:25:33] <linuxcnc-build> build #409 of precise-x86-xenomai-rip is complete: Failure [4failed apt-get-update compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-x86-xenomai-rip/builds/409 blamelist: Michael Haberler <git@mah.priv.at>
[16:25:33] <linuxcnc-build> build #1297 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1297 blamelist: Michael Haberler <git@mah.priv.at>