Back
[08:13:07] <bjm_> pcw: What was the Celeron J1800 board you were testing ?
[09:31:18] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/scurve-test2 a61d2bf 06linuxcnc 10(13 files in 6 dirs) WIP * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a61d2bf
[09:40:55] <linuxcnc-build> build #299 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/299 blamelist: Michael Geszkiewicz <micges@wp.pl>
[09:41:06] <linuxcnc-build> build #1686 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1686 blamelist: Michael Geszkiewicz <micges@wp.pl>
[09:41:07] <linuxcnc-build> build #2485 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2485 blamelist: Michael Geszkiewicz <micges@wp.pl>
[09:43:32] <linuxcnc-build> build #2484 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2484 blamelist: Michael Geszkiewicz <micges@wp.pl>
[09:50:03] <linuxcnc-build> build #642 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/642 blamelist: Michael Geszkiewicz <micges@wp.pl>
[09:51:17] <linuxcnc-build> build #642 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/642 blamelist: Michael Geszkiewicz <micges@wp.pl>
[10:03:39] <linuxcnc-build> build #2486 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2486 blamelist: Michael Geszkiewicz <micges@wp.pl>
[10:03:39] <linuxcnc-build> build #2484 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2484 blamelist: Michael Geszkiewicz <micges@wp.pl>
[10:05:00] <linuxcnc-build> build #2485 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2485 blamelist: Michael Geszkiewicz <micges@wp.pl>
[10:05:33] <linuxcnc-build> build #2485 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2485 blamelist: Michael Geszkiewicz <micges@wp.pl>
[10:05:33] <linuxcnc-build> build #2493 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2493 blamelist: Michael Geszkiewicz <micges@wp.pl>
[11:18:38] <pcw_home_> bjm_: Gigabyte J1800D2H though the current wheezy RTAI kernel has trouble with the USB so best for Preemt-RT
[11:18:39] <pcw_home_> (and the ASRock equiv has a less troublesome BIOS)
[11:29:52] <bjm_> Good, I just ordered the ASRock version. I'll try it with the parallel port, and if that doesn't work I can use Preempt-RT & a 6i25
[11:33:40] <pcw_home_> The Gigabyte parallel port works (and works in EPP mode as well) The ASRock uses the same SuperIO chip so should be similar
[11:58:56] <memleak> i made a 3.14 RTAI kernel package and it actually worked in wheezy :)
[12:00:04] <memleak> i gave up though trying to package rtai userspace but the tree is here: github.com/ntulinux/rtai
[12:00:48] <memleak> for some reason only the changelog file ends up in the .deb
[12:01:31] <memleak> it may fix whatever USB issues you are having
[12:02:12] <pcw_home_> Ill have to try that
[12:56:51] <kwallace2> Hello, I'm trying to avoid some divide by zero errors in Python. Currently I'm using: try: a = this / that; except: a = 0. Does this a decent way to guard against /0 or are there better ways?
[13:04:08] <kwallace2> Oops, Does/Is
[13:04:28] <cradek> I don't understand why you think this/0 should give a=0
[13:04:53] <cradek> normally you'd detect "that" being zero or close to zero, and do something about the invalid situation that led you there
[13:05:04] <cradek> what's going on that led you down this path? what are this and that?
[13:05:34] <jepler> kwallace2: cradek's question is a good one -- maybe reexamine what led you to this point
[13:05:52] <jepler> otherwise, anytime you find yourself repeating something over and over again, the answer is to make it a function and then call it as a function
[13:06:18] <jepler> a = divide_or_return_zero_for_zero_denominator(this, that) # but choose a better name
[13:08:24] <kwallace2> For my application, the module needs to go from beginning to end even with faulty values, a = 0 prevents any output that might cause motion.
[13:09:08] <jepler> so if this or that is 0 then you want to do nothing?
[13:09:17] <kwallace2> Yes.
[13:09:24] <jepler> if not this or not that: return # exit early in the case of bad parameters
[13:11:09] <kwallace2> Yeah, except I would have to work out what to return to the calling function to keep it happy, which would be better, but more work.
[13:20:57] <jepler> to give a non-evasive answer to the original question, alternatives would be to write something involving a conditional. two lines using the if statement: if that: a = this/that / else: a = 0 or one line using the inline if: a = this/that if that else 0 (new in python 2.6 I think)
[13:21:20] <jepler> but as a programmer, I don't *want* a low-level routine to silently substitute one value for another when I send in bad values
[13:21:23] <jepler> I want an error message
[13:21:55] <jepler> if not that: throw ValueError, "that can't be zero, it has no sensible physical interpretation"
[13:22:22] <jepler> you could explicitly test for the problems you know arise, and assuming this is for humans, arrange to show the error string when they type in the bad values and click "make chips!!"
[13:22:49] <jepler> because when it's users, the support call goes "when I press the button, nothing happens"
[13:24:09] <jepler> python -mthis | grep silent
[13:25:51] <kwallace2> Yeah, point taken, but ... do I have too?
[13:25:51] <kwallace2> to
[13:26:24] <jepler> for your own code? nah, I'll confine myself to giving advice
[13:32:27] <kwallace2> How about "if this == 0: GOTO ..."?
[13:46:24] <memleak> i was told gotos are bad.
[13:59:32] <jepler> first you'll have to get the authors of Python to add GOTO
[13:59:41] <jepler> I hear they are against such a feature but maybe it's because nobody contributed it yet
[14:00:23] <cradek> I HAVE FEELINGS ABOUT THAT
[14:09:55] <skunkworks> heh
[14:10:11] <skunkworks> so - 2khz for a week - no issues
[14:30:03] <kwallace2> Well it looks like outlawing zero Depth of Cut and Stepover in the UI fixes my errors... imagine that.
[14:33:20] <cradek> yay
[14:34:20] <skunkworks> so following these direction..
https://github.com/firepick1/FireSight
[14:35:16] <skunkworks> It works..
[14:39:56] <skunkworks> firesight -p json/pipeline0.json -i img/cam.jpg takes the cam.jpg and outputs a json file with circle locations
[14:40:01] <skunkworks> pretty neat
[14:40:08] <skunkworks> now what to do...
[14:53:01] <kwallace2> Crud, I found a problem with zero tool diameter, which I don't think I can outlaw.
[15:02:38] <kwallace2> Well, I just did.
[15:03:42] <jepler> hotel booked for texas
[15:03:57] <jepler> I'm really looking forward to seeing fellow linuxcnc developers / users again
[15:04:11] <jepler> except that cradek guy, I see him enough already
[15:12:55] <alex_joni> heh
[15:43:13] <seb_kuzminsky> i'm wondering if i should have booked a room through airbnb instead of some shady cheap hotel i found online
[15:43:39] <PetefromTn_> bates motel?
[15:48:29] <alex_joni> fun
[15:48:49] <Tom_itx> what part of Tx?
[15:49:06] <seb_kuzminsky> Tom_itx: Houston, near the Tx/Rx hackspace
[15:49:22] <Tom_itx> there's a nice Hampton down there
[15:49:27] <Tom_itx> near Galveston
[15:50:59] <Tom_itx> dunno what part of Houston you're going to...
[15:51:06] <seb_kuzminsky> http://books.google.com/books?id=IDFfMPW32hQC&lpg=PA20&dq=%22he'd%20never%20slept%20in%20Cheap%20Hotel%22&pg=PA20#v=onepage&q=%22he'd%20never%20slept%20in%20Cheap%20Hotel%22&f=false
[15:52:16] <cradek> using airbnb to avoid shady sounds iffy at best
[15:53:53] <Tom_itx> seb, you flying from where?
[15:54:02] <Tom_itx> you'll love the Houston airport :D
[16:01:17] <seb_kuzminsky> i'm coming from denver
[16:08:08] <cradek> "gauging error"
[16:09:01] <cradek> which he has troubleshat to an arc precision problem somehow
[16:09:06] <cradek> I don't even
[16:10:25] <cradek> and whatever the problem with the gcode is, he wants to hack linuxcnc to not error, instead of fixing it
[16:11:40] <skunkworks> cradek: what?
[16:11:54] <cradek> oh someone on the forum
[16:11:57] <skunkworks> oh
[16:13:55] <PCW> shades of hardwired fixed point Gerber files from the 70's
[16:15:14] <cradek> if he would have bothered to transcribe the actual error, I would be less snarky
[16:15:36] <PCW> shouldn't that just be a "dont be silly about numbers" check-off box in the post setup
[16:15:50] <cradek> who knows
[16:16:12] <skunkworks> pcw, did you see J1900 2 weeks 2khz?
[16:16:41] <skunkworks> didn't get to trying the dpll today - ran out of time
[16:16:44] <cradek> if it's a cutter comp problem (some of the cutter comp error situations have gOuging in the error) it's unlikely to be an arc end mismatch causing the trouble
[16:17:38] <PCW> Pretty good (the J1800 is the one that ran for 120 days though some at 1KHz)
[16:18:10] <PCW> the G3258 seems happy at 3 KHz (After I removed a DIMM)
[16:18:21] <skunkworks> interesting..
[16:23:54] <PCW> bad DIMM or MB doesn't like interleaving, I was getting machine check errors with 2
[16:24:19] <PCW> machine check errors are not great for latency
[16:25:24] <PCW> probably a marginal DIMM
[16:40:25] <PCW> max readtime ~= 140 usec on G3258
[16:45:47] <skunkworks> wasn't it around 400us on the j1800 or so?
[16:58:00] <PCW> Yes (I suspect its just the time to plow through a lot of kernel code in the worst case) the G3258 plows a lot faster :=)
[16:58:50] <PCW> single thread performance is about 4X J1800
[17:00:32] <PCW> you pay for it with about 30W power dissipation so needs a fan
[17:08:22] <jepler> cradek: particularly if it's someone whose first language is not english, you should be forgiving of errors like gauge vs gouge
[17:08:59] <jepler> (what's the opposite of preaching to the choir? since I'd also jump right on someone's english mistakes)
[17:09:51] <jepler> (hypocrite covers it I suppose)
[19:54:54] <jepler> what an odd troll(?)
http://mid.gmane.org/CAK_6Rwcs7-UccNJQvT_tGBTXLCNXbqfkX5Hp3v2UVDZGSMkLig%40mail.gmail.com
[19:55:10] <jepler> speaking of people who may just be experiencing a terrible language barrier
[19:55:55] <cradek> No such article
[19:56:15] <jepler> hm
[19:56:38] <jepler> I agree
[19:56:47] <jepler> usually my script for showing gmane URLs for arbitray list e-mails works fine
[19:58:01] <jepler> Subject: For most programmers, it is foolish currently develop in machine code, hexadecimal and assembly?
[20:13:17] <Tom_itx> unless you need ultimate tight fast code
[20:14:46] <Tom_itx> or work for MS
[22:55:39] <skunkworks> http://electronicsam.com/images/KandT/testing/pipeline1.jpg
[22:56:10] <skunkworks> me holding a piece of paper with 2 circles in front of the webcam on this laptop
