Back
[04:03:57] <linuxcnc-build> build #1878 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1878 blamelist: dummy, Jeff Epler <jepler@unpythonic.net>, Michael Haberler <git@mah.priv.at>, John Morris <john@zultron.com>, John Thornton <jthornton@gnipsel.com>, Chris Morley
[04:03:57] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Andy Pugh <andy@bodgesoc.org>, Frederic Rible <frible@teaser.fr>, Bence Kovacs <bence.kovacs@generalmechatronics.com>, Norbert Schechner <nieson@web.de>, Michael Geszkiewicz <micges@wp.pl>, Sebastian Kuzminsky <seb@highlab.com>, ArcEye <arceye@mgware.co.uk>, Dewey Garrett <dgarrett@panix.com>
[08:20:14] <dgarr> any objection to merging branch dgarr/ini_includes to master ?
[08:34:47] <cradek> dgarr: something is wrong - you have all teh commits twice, off two different parents, then merged together
[08:34:51] <cradek> the
[08:35:26] <dgarr> i know -- i don't care something went wrong, the result is ok ( i think)
[08:35:44] <cradek> brb
[09:13:17] <cradek> was there an existing ini file setup that made emccalib not work, before this change?
[09:14:58] <dgarr> axis.ini
[09:15:07] <dgarr> for example
[09:16:39] <cradek> sorry - which one? what made it not work?
[09:17:07] <dgarr> sim configs typically don't have the right stuff in ini nor hal files for emccalib
[09:17:54] <dgarr> so when a user tries it , the result is unproductive and confusing
[09:18:06] <cradek> oh I see - so this is the situation where it shows nothing useful (because there's nothing to tune) and you generate a message now, instead of showing a mostly blank screen
[09:18:20] <dgarr> yes
[09:18:46] <cradek> ok, thanks (still studying)
[09:19:44] <KGB-linuxcnc> 03John Morris 05zultron/ubc3-dev 5a58181 06linuxcnc 10scripts/check-system-configuration.sh scripts/check-system-configuration.sh: suppress error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5a58181
[09:39:11] <linuxcnc-build> build #27 of 1401.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/27 blamelist: John Morris <john@zultron.com>
[09:40:41] <linuxcnc-build> build #27 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/27 blamelist: John Morris <john@zultron.com>
[10:19:23] <seb_kuzminsky> dgarr: i think you should discard the erroneous merge commit 3c4a3fcd5, and then we should consider bc1880c0 the head of ini-includes
[10:21:14] <dgarr> as usual, i'm not how to do that for origin/dgarr/ini_includes -- if you want to fix it and merge to master for me that would be great
[10:21:42] <seb_kuzminsky> ok sure
[10:21:59] <seb_kuzminsky> cradek: do you agree that bc1880c0 is the commit to consider for merging into master?
[10:22:05] <seb_kuzminsky> (I haven't reviewed it yet)
[10:34:30] <seb_kuzminsky> dgarr: the changes to linuxcnc.in and the docs look good to me, i haven't looked at the rest
[10:35:19] <dgarr> the rest is just a test configuration for demonstration
[10:35:49] <dgarr> oh, and updates for emccalib
[10:46:20] <cradek> I suggest using something like breal=$(eval echo "$b"), instead of reinventing (part of) tilde expansion
[10:48:21] <cradek> but in general, I wonder if using something existing to do the expansion would be better
[10:48:51] <cradek> cpp is an obvious choice but I don't know if machines without build-essential have it
[10:49:33] <cradek> adding include ability to our reader(s) is hard because I think we have at least three of them, written in bash, c++, and (though not by us) python
[10:51:19] <dgarr> what specificallyare the readers you refer to?
[10:52:50] <cradek> I thought inivar was a bash function, but it's a program we build
[10:53:17] <cradek> so maybe there are only two readers: that inivar code (which is built into inivar and also linked into things like task) and the python inifile module
[10:54:17] <cradek> oops I mean the python ConfigParser module
[10:56:20] <dgarr> cradek: i'm not folowing,the branch creates a temporary ini file and nothing that reads ini files is modified
[10:56:21] <cradek> interesting, ConfigParser has expansion built in (we wrote an incompatible version ourselves)
[10:56:50] <seb_kuzminsky> it does?!
[10:57:07] <cradek> seb_kuzminsky:
http://docs.python.org/2/library/configparser.html
[10:58:18] <cradek> dgarr: sorry for being opaque. I was wondering whether putting include smarts in the reader would be a better approach. to evaluate that, I was talking about whether it would be hard to do or not.
[10:58:55] <seb_kuzminsky> oh, you mean variable expansion, not file-include expansion
[10:59:02] <seb_kuzminsky> bbl
[10:59:50] <cradek> I'm not focusing very well am I
[10:59:52] <cradek> sorry
[11:08:09] <seb_kuzminsky> speaking of jumping around on topics, linuxcnc doesnt build on debian jesse because libgnomeprintui (used by classic ladder) was removed, because it's obsolete says the package maintainer
[11:08:20] <seb_kuzminsky> so we've got that going for us, which is not nice
[11:13:02] <cradek> dgarr: do you want me to fix up the git and merge that? then we can work on improving the tilde expansion stuff.
[11:13:39] <dgarr> that would be fine with me
[11:17:55] <KGB-linuxcnc> 03Chris Radek 05master bc1880c 06linuxcnc fast forward * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bc1880c
[11:23:04] <seb_kuzminsky> thanks
[11:24:17] <dgarr> thanks! i don't claim to be a bash expert so if the tilde expansion can be improved that would be good
[11:25:20] <cradek> welcome
[11:25:23] <cradek> I'm playing with the expansion
[11:26:05] <cradek> I think my ~ fix will give expanding environment for free, and I can imagine using it like #INCLUDE dir/${LINUXCNCVERSION}/file
[11:26:23] <cradek> err I meant will give dollar expansion
[11:45:34] <KGB-linuxcnc> 03Chris Radek 05master bcc1be2 06linuxcnc 10scripts/linuxcnc.in Use bash's built-in expansion * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bcc1be2
[11:45:34] <KGB-linuxcnc> 03Chris Radek 05master a89b4e9 06linuxcnc 10scripts/linuxcnc.in Fix including files with spaces in their names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a89b4e9
[11:51:31] <cradek> I tested an include file named "axis 1.inc" and "2.6.0~pre" (with #INCLUDE ${LINUXCNCVERSION}) which is a cool trick
[11:52:01] <cradek> with care, you could make a config that tweaks itself to run on different versions
[11:56:58] <cradek> dgarr: thanks for doing that - people have sure asked for it more than once.
[11:57:33] <dgarr> thanks for your help
[12:36:59] <linuxcnc-build> build #1879 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1879 blamelist: John Morris <john@zultron.com>
[13:59:08] <linuxcnc-build> build #35 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/35 blamelist: Chris Radek <chris@timeguy.com>, Dewey Garrett <dgarrett@panix.com>
[14:38:42] <KGB-linuxcnc> 05dgarr/ini_includes 3c4a3fc 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c4a3fc
[15:03:17] <zultron> seb_kuzminsky, you can pull from glo/zultron/ubc3-dev into glo/unified-build-candidate-3 to get three fixes to check-system-configuration.sh.
[15:07:04] <cradek> zultron: might it be better to use ulimit -l?
[15:09:02] <zultron> And assume that if limits in the current shell are acceptable, that the system's configured as needed? Probably.
[15:10:19] <cradek> it's valid if they're systemwide and/or this user is the one who will be trying to run it
[15:11:40] <cradek> a suitably perverse person might use login classes or something to do it, and the ulimit test could be more correct in that case
[15:12:53] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/demo_apps 14a8080 06linuxcnc 10(19 files in 6 dirs) linuxcnc.in,pickconfig.tcl: support .demo files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=14a8080
[15:13:44] <cradek> I confirmed my 3.4.55-rtai-2 machine with linuxcnc 1:2.6.0~pre0.5022.gdc54291 installed reports ulimit -l => 20480
[15:14:20] <cradek> for my normal user
[15:17:47] <cradek> jthornton: following errors in sim? what sim? that sounds like bugs, not a problem with your script
[15:18:57] <cradek> zultron: do you want me to change it?
[15:19:30] <zultron> cradek, sure, fix it as you see fit. Thanks!
[15:39:38] <cradek> zultron: we've been setting 20480 for ages, and unfortunately we have been using the non- .d/ method. do you know for sure that's not enough? if it's enough it would be nice to relax this test to save trouble.
[15:45:52] <KGB-linuxcnc> 03Chris Radek 05zultron/ubc3-dev 25029d5 06linuxcnc 10scripts/check-system-configuration.sh Check memlock in a safer way * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=25029d5
[15:46:19] <zultron> Sorry, I don't know the ideal value. In my config management system, I install a file with 32768. I think these numbers are all arbitrary.
[15:47:46] <cradek> yeah I don't know how to know
[15:48:10] <cradek> it's a separate conceptual change anyway, so I pushed what I had so far
[15:48:20] <zultron> I'm fine with 20480. In the unlikely chance it breaks something, we can raise it.
[15:48:58] <cradek> that would save our rtai folks neck pain if it's actually enough
[15:49:01] <cradek> I'll change it
[15:49:02] <cradek> thanks
[15:49:16] <zultron> Great, thank you.
[15:50:32] <zultron> Honestly, I think this check belongs in run-time code, not the build-time code.
[15:50:50] <cradek> that's absolutely true
[15:51:25] <zultron> Perhaps I'd read a 'memlock_min' value from a config file, set to 20480 by default, and compare it to the currently set limit.
[15:51:45] <cradek> and it's a bogus test anyway. some machines need more than others (because I think it's proportional to the number of hal pins or somesuch) - so a graceful failure if it's too low for the config you try to run is what we actually want
[15:52:35] <zultron> Yes. If the check fails, the realtime environment should refuse to start. If the user is sure he wants a different value, it can be set in the config file.
[15:52:54] <KGB-linuxcnc> 03Chris Radek 05zultron/ubc3-dev 4bb89e0 06linuxcnc 10scripts/check-system-configuration.sh Old RTAI users have had 20480 forever; this is probably enough. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4bb89e0
[15:53:09] <cradek> this is sure easier :-/
[15:53:33] <zultron> And it makes no sense to spit out a bunch of warnings when it's quite likely we're building on a non-RT host.
[15:53:55] <cradek> you're making me sad
[15:54:14] <zultron> Why come you sad?
[15:54:38] <cradek> fixing stuff with trivial bashisms is firmly within my skill set
[15:55:05] <zultron> Well, we could transplant it into realtime.in.
[15:59:57] <cradek> (what's the cultural expectation regarding pushing to someone-else/featurename branches?)
[16:00:34] <cradek> is that normal when you want to fix something but someone-else should still be the boss of the branch?
[16:03:22] <zultron> I've heard those are used as 'personal' branches, and I saw Seb doing it, so I did it too. :)
[16:03:39] <cradek> you know exactly as much as me about it, then!
[16:03:52] <cradek> I like the idea
[16:03:56] <zultron> As for glo/ubc3, Seb's indicated that it's frozen, so I'm a little wary of touching it.
[16:03:57] <seb_kuzminsky> you have to pee on it to mark it as yours
[16:04:27] <seb_kuzminsky> i asked michael to stop merging new kinematics and things into it, is that what you mean?
[16:04:49] <seb_kuzminsky> bugfixes & things are of course welcome
[16:04:53] <zultron> Yeah, I've heard of git server configs where one may force-push branches beginning with his own user name, but shared branches will refuse force pushes.
[16:05:15] <cradek> I'd assume it's frozen for new features, but wanting bugfixes
[16:05:34] <zultron> Yeah, I know you said 'new features', but I still feel shy.
[16:06:08] <cradek> that sounds smart (but if we just approximate that by culture that's fine with me too - rarely we do need to force push shared branches)
[16:06:26] <seb_kuzminsky> zultron: i appreciate your help in stabilizing it and making it mergeable, and i trust you to do the right thing
[16:06:40] <cradek> me too me too
[16:06:51] <zultron> Ok, thanks, guys, I appreciate it.
[16:08:07] <cradek> seb_kuzminsky: so you're suggesting boldly peeing wherever appropriate?
[16:08:22] <seb_kuzminsky> err
[16:08:35] <seb_kuzminsky> mozmck wants no part of this conversation
[16:08:40] <cradek> well something like that.
[16:09:59] <seb_kuzminsky> i suggest/request everyone help in rolling this boulder over the hill, and if that means pushing to a branch that says 'seb' in the name that's fine
[16:10:36] <seb_kuzminsky> i use it partially as a way to help remind me which branches are my responsibility to finish and/or remove
[16:11:01] <seb_kuzminsky> and partially as a way to help other devs declutter the 'git branch -a' list mentally - they can just ignore stuff that says seb in the branch name
[16:11:08] <cradek> I like how it fixes the problem of not knowing who should eventually remove it
[16:12:07] <seb_kuzminsky> it's also kind of a warning that i may force-push it whenever i feel like it (unless you've spoken to me about it and asked me to stay my hand)
[16:12:44] <seb_kuzminsky> but i think we all have enough git-fu to handle races in that process
[16:13:55] <zultron> Solves proliferation of branches in a shared repo, big plus.
[16:14:23] <zultron> Why not enforce new branch creation with git server configuration?
[16:15:02] <cradek> enforce what rule?
[16:17:14] <zultron> Mmm, pushing new branches not prepended with your user name + '/' will fail.
[16:18:00] <cradek> I guess I'd rather use culture to do stuff like that, so people can do something else when it makes sense
[16:18:24] <cradek> I hate to lock things down when there's really not an active problem it solves
[16:18:49] <zultron> Sure. And I can think of problems it introduces.
[16:18:54] <cradek> I've had committers say "I only need write access to certain directories" and such, but that's not a thing I do, because why do it?
[16:22:01] <cradek> (once we talked about allowing *anyone* to push to anon/branchname, which I think is an interesting possibility in the opposite direction)
[16:23:13] <cradek> bbl, my weekend is starting
[16:24:57] <seb_kuzminsky> i'd be scared to let anon run 'sudo make setuid' on all the buildslaves
[16:34:25] <linuxcnc-build> build #36 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/36 blamelist: Dewey Garrett <dgarrett@panix.com>
[16:48:15] <linuxcnc-build> build #30 of 1401.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-amd64/builds/30 blamelist: Chris Radek <chris@timeguy.com>
[16:51:29] <linuxcnc-build> build #30 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/30 blamelist: Chris Radek <chris@timeguy.com>
[17:35:18] <cradek> seb_kuzminsky: yes I'm sure you wouldn't want to buildbot them (or probably do anything with them really, except review and merge them into something useful)
[17:35:30] <cradek> anyway, it's not a thing to do today
[17:44:23] <KGB-linuxcnc> 03Dewey Garrett 05master 667fc26 06linuxcnc 10scripts/latencyplot.in latencyplot.in: bug fix for deb * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=667fc26
[18:13:22] <dgarr> seb_kuzminsky: or cradek: i've managed to make the same git mistake with a new branch, maybe someone can analyze what i do wrong:
http://www.panix.com/~dgarrett/stuff/gitprob.txt
[19:06:37] <andypugh> dgarr: You are way ahead of me, I didn't even know you could shorten the commands.
[19:07:16] <dgarr> if you mean gitl, it's just a bash alias
[19:07:46] <cradek> dgarr: we'll have to wait for seb - I still need manpage in-hand when using rebase
[19:08:04] <dgarr> ok thanks -- it's beyond me
[19:08:05] <cradek> ... this may not be the same thing at all
[19:08:15] <andypugh> I tend to work in a feature branch locally, eventually combune my work onto one commit, check out master, cherry-pick that commit, then push.
[19:08:21] <cradek> recommend adding --graph to your gitl, because you can see merges then
[19:08:46] <cradek> if you rebased your branch correctly (moved it from one point on master to another) it's expected that you'll have to --force your push
[19:08:53] <andypugh> Not because that is the right thing to do, it is the wrong thing to do, but it is all I know how to make happen
[19:08:55] <cradek> so you may not have anything wrong at all
[19:09:36] <cradek> if you look at gitk or git log --graph you might see it better
[19:12:11] <cradek> I think your rebase was right
[19:12:54] <cradek> I don't think you've got a problem at all; you've just got to force your push because you rebased (rewrote history)
[19:13:03] <cradek> and this is fine to do in a dgarr/* branch
[19:13:38] <dgarr> i never have had to force, let me try that with dry-run
[19:14:06] <cradek> I'd like to see a screenshot of gitk for good measure
[19:14:22] <cradek> or the same thing: git log --graph --decorate
[19:14:53] <dgarr> git push --dry-run --force origin dgarr/demo_apps shows no errors so maybe thats ok , should i just do that?
[19:15:11] <cradek> I think so, but let's look at it once more first
[19:18:09] <dgarr> http://www.panix.com/~dgarrett/stuff/gitk.png
[19:18:50] <cradek> that looks perfect
[19:19:03] <dgarr> so i should try the --force?
[19:19:04] <cradek> you just moved that branch of one commit with rebase
[19:19:06] <andypugh> I need to make a trivial push, I have dropped out of History :-)
[19:19:22] <cradek> yes use --force
[19:20:05] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/demo_apps 85b3caf 06linuxcnc 10(19 files in 6 dirs) linuxcnc.in,pickconfig.tcl: support .demo files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85b3caf
[19:20:13] <cradek> yay
[19:20:17] <andypugh> (hardly surprising, I have been bashing metal, not code, for months)
[19:21:00] <cradek> andypugh: what do you mean dropped out of History?
[19:21:05] <dgarr> ok -- thanks i guess i have to study when --force is required, i didn't find the git messages very helpful
[19:21:16] <andypugh> (Question) Does anyone actually _want_ the tool table work? I pushed a branch, there was no comment.
[19:21:37] <cradek> as soon as you rebased the branch that you had previously pushed, it became neccessary
[19:22:11] <cradek> you rewrote the existing branch (by moving it to a new parent) instead of just piling more commits on top of it ("fast-forward")
[19:23:04] <cradek> the non-fast-forward message means the git server detected you are trying to do something OTHER than just pile new commits on top of existing stuff, so it stops you and makes you think twice, and force it if that's what you meant
[19:24:22] <cradek> (and it's not you - pretty much all of the git UI is obtuse and incomprehensible)
[19:25:57] <dgarr> your explanation helps, its funny the git message (dry-run, no force) had 1 error line and 4 'hint' lines but even now the text confuses me
[19:26:13] <cradek> andypugh: I think yes people really want it, including me. I bet all our brains are full of ubc3 stuff though.
[19:28:05] <cradek> I think they added the hints recently - it used to just say "nope, failed, non-fast-forward"
[19:28:14] <andypugh> That could be it. I do intend to get back to it. It would be easier if I actuallly needed it, I think. I am mainly doing it because I said I would, and started it before I realised the scope.
[19:28:49] <cradek> yuck, that sure makes it hard.
[19:29:49] <andypugh> It does need doing. It is only when you look at tool offsets that you realise how oddly handled they are.
[19:30:26] <andypugh> But making them less odd touches more than (say) the TP work.
[19:30:57] <andypugh> Less than mah's "expunge NML" ambition though.
[19:31:41] <cradek> yes he's not shy
[19:32:01] <cradek> the biggest thing I see people want every day is "also apply tool offset #N"
[19:32:24] <cradek> or more specifically "apply offsets #1 and #10", although I see the general solution as "also"
[19:32:38] <andypugh> I am quite liking that there is more appetite for big changes now than there was. The JMK "why jog while paused is hard" document is interesting reading now. I rather find myself thinking "Not _that_ hard, then"
[19:34:21] <cradek> jogging while paused is simple and can just be hacked in. (note: simple != easy) changing the tool offset is the complex (and important) part and takes fundamental changes.
[19:34:44] <andypugh> The hard thing is tool database + offset when paused + lookahead. I think we need to dump the queue much more readily. With modern hardware that is likely to be hardly any penalty at all. But It takes a lit of work to test.
[19:35:51] <andypugh> it isn't "hard" is is just "big"
[19:38:41] <andypugh> What I still need to work out is the difference between comitted database state and internal lookahead tool database state. I rather suspect that _any_ tool geometry change has to instantly invalidate the motion queue. Which is probably no penalty at all in practice. I doubt anyone demands smooth motion thorugh a G10.
[19:39:33] <cradek> G10 of tool stuff doesn't change anything about the path
[19:39:58] <cradek> only at G41/42/43 time
[19:40:20] <cradek> when those happen you need to get the latest
[19:40:35] <cradek> but I bet nobody cares about queueing past them at all
[19:40:49] <cradek> because they never? happen when the tool is touching the work
[19:42:34] <andypugh> Quite. I suspect that you probably can maintain the queue through a G10, but it complicates the internal view of tool state. It is much easier to not try, and to have the tool table "always true, right now"
[19:44:07] <zultron> Hrm, was dgarr's problem not that he didn't do a 'git fetch origin' first?
[19:44:18] <andypugh> I probably need to talk to Robert too, as the other person in the word who has a clue about the TP
[19:44:43] <cradek> I don't think dgarr had anything wrong at all
[19:45:21] <cradek> he rebased a branch he had previously pushed, but didn't realize that would cause a --force to be required
[19:45:34] <zultron> Once he did the 'rebase origin/master', he should've had a fast-forwardable branch.
[19:45:58] <zultron> When he tried to do the push, the server complained that it wasn't fast-forwardable.
[19:46:13] <cradek> but he was pushing his feature, not master
[19:46:15] <zultron> That probably means there were commits added to origin/master that he hadn't fetched yet.
[19:46:29] <zultron> Oh, missed that. Whew!
[19:46:45] <zultron> Aha: git push --dry-run origin dgarr/demo_apps
[19:47:12] <andypugh> Why is it that I admire Git and hate windows? The former actually gets in my way more often.
[19:48:10] <zultron> git's a lot of extra typing, but worth the effort.
[19:49:12] <andypugh> Though, I did recently find a truly annoying Windows/Excel issue. Even Stackoverflow was mute:
http://stackoverflow.com/questions/22071347/excel-vba-ribbon-getenabled-not-called-when-code-running
[19:50:03] <cradek> I don't even know what ways windows is irritating lately, so I can't comment
[19:50:27] <cradek> but surely it's like comparing apples and ... submarines?
[19:51:17] <cradek> I must have the one IT job in the world where I don't have to deal with windows at all
[19:51:52] <linuxcnc-build> build #1882 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/1882 blamelist: Chris Radek <chris@timeguy.com>
[19:52:32] <andypugh> I accidentally buuilt a 20,000 loc Excel macro,
[19:52:59] <cradek> hm, wonder what on earth that means
[19:52:59] <andypugh> (If I had known what it would become, I would have started somewhere else)
[19:53:19] <andypugh> (loc == lines of code)
[19:53:41] <cradek> haha
[19:54:10] <andypugh> It was useful, I used it, I emailed it to colleagues, it grew...
[19:54:41] <andypugh> Then they said "can it do this"and Lo! it could y doubling in size
[19:59:24] <andypugh> Currently it can work with either
http://www.accuratetechnologies.com/content/view/178/174/lang,en/ or
http://www.etas.com/en/products/inca.php (via wrapper classes, so actually you can work with both at the same time) to do almost anything to a vehicle ECO, while at the same time also talking to
https://www.avl.com/puma-open to control an engine test bed. The fact it runs in Excel is purely an accident that lets me
[19:59:25] <andypugh> email a "spreadsheet" to colleagues without anyone realising that actually is is software.
[20:01:04] <cradek> wow, I bet you could be mistaken for an expert in windows stuff.
[20:01:45] <andypugh> And, frankly, the VBA IDE is a nice place to work, breakpoints, seeing inside objects, all unavoidably Object oriented (as you can only actually _see_ from inside a huge object model.
[20:03:40] <andypugh> Seriously, if you know anyone who wants to learn OO then tell them to try Excel VBA. it's OO but effectively interpreted, so runtime debuggable/ viewable/ etc.
[20:04:17] <andypugh> And you can't cheat, you are inserted at the bottom of the object structure.
[20:05:22] <andypugh> And when you type a dot after your variable, there is a drop-down of the availaible properties/methods.
[20:06:39] <andypugh> <ahem, tries to regain Linux-cred> It is fundamentally flawed in many ways, of course, especially philosophical ones.
[20:55:02] <skunkworks> I use VB for applications in ms access.. it is surprisingly powerful...
[20:57:08] <skunkworks> we have made some wicked database applications with it pretty quickly
[20:57:16] <skunkworks> for internal stuff.
[20:59:06] <andypugh> Yes, like, for example, triviallly just deleting all the standard menus.
[21:12:19] <linuxcnc-build> build #37 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/37 blamelist: Dewey Garrett <dgarrett@panix.com>
[22:56:55] <linuxcnc-build> build #38 of 4017.deb-wheezy-armhf is complete: Failure [4failed apt-get-update shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-armhf/builds/38 blamelist: dummy, Dewey Garrett <dgarrett@panix.com>
