Back
[08:06:15] <alex_joni> wyard: still there?
[08:06:26] <alex_joni> 13:12 < jthornton> wyard: I'm usually on in the mornings (for me) and I'm GMT-6 for time reference. in case you read back on the logs
[08:06:32] <alex_joni> 14:34 < jthornton> wyard: another option to trying to catch me at a computer is to start a topic on the forum in the Documents section
http://www.linuxcnc.org/
[08:11:23] <micges_work> hi alex_joni
[09:24:54] <alex_joni> hi micges_work
[16:12:31] <jepler> hm, I notice that the linux kernel parport epp driver does a few things that our epp hardware drivers don't
[16:13:58] <jepler> it sets the ps2 direction register before each transfer, which at least pluto doesn't but ppmc does
[16:15:22] <jepler> and it sets the PARPORT_CONTROL_INIT bit as well
[16:15:28] <jepler> which I'm not aware of any driver of ours doing
[16:51:48] <cradek> seb_kuzminsky: sorry if it sounded like I was yelling at you...
[16:54:06] <seb_kuzminsky> hi cradek
[16:54:14] <seb_kuzminsky> it didn't sound like yelling, you should hear my wife ;-)
[16:54:23] <cradek> ha
[16:54:34] <cradek> I've met her - I don't believe you for a second.
[16:54:38] <seb_kuzminsky> heh
[16:54:45] <seb_kuzminsky> you're right, she's a sweetie
[16:55:11] <seb_kuzminsky> i think i'll follow jeff's suggestion and add argv_split inside a #ifnded
[16:55:31] <seb_kuzminsky> the commit message should have been better, but it was late and i was cold and feeling lazy
[16:56:22] <seb_kuzminsky> the change is not totally frivolous, it fixes a real bug: strsep() modifies the input string
[16:56:33] <seb_kuzminsky> so it breaks if you have to re-parse it later
[16:56:47] <cradek> I didn't mean it as "you should have done better!!" - I have noticed that some people just never thought about it and don't know they should answer "why" instead of "what"
[16:57:48] <seb_kuzminsky> which can happen when you have multiple anyio boards - it tries to apply the first config to the first board found...
[16:57:48] <cradek> cool - if jeff's advice lets you fix the bug for the future but not break compatibility, surely that's the best of all possible worlds
[16:58:05] <seb_kuzminsky> if that fails it tries the first config with the second board, but strsep() broke the first config string...
[16:58:22] <seb_kuzminsky> the real fix is to let the user say which board should get which config string...
[16:59:55] <cradek> by some number in lspci maybe? seems like a pain.
[17:00:06] <cradek> brb
[17:04:48] <seb_kuzminsky> the PCI slot number looks like a good identifier
[17:10:53] <cradek> there's at least a little precedent for that: the BusID used by xorg
[17:11:37] <cradek> BusID "PCI:1:0:0"
[17:11:47] <cradek> for lspci's 0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0391 (rev a1)
[17:12:24] <cradek> they have the same problem - you can have several video cards of the same or different types, and you have to distinguish
[17:19:26] <seb_kuzminsky> well that sounds good then
[17:24:29] <jepler> seb_kuzminsky: if trying to get my 3x20 firmwares working drags out, maybe you can bring the board down at the end of the month
[17:27:51] <seb_kuzminsky> i'm planning to bring everything :-)
[17:28:03] <cradek> that's the spirit
[17:28:28] <cradek> can you bring an extra day or two too?
[17:28:51] <seb_kuzminsky> heh
[17:29:08] <seb_kuzminsky> no but i can simulate the extra time by substituting sleep for caffeine
[17:29:28] <cradek> which days is it again? I should arrange my vacation.
[17:30:37] <cradek> I've been planning what I should put stuart to work on :-)
[17:30:44] <seb_kuzminsky> I'll arrive the evening of Friday Jan 29, prolly around 7 PM, and leave Sunday late morning
[17:31:05] <seb_kuzminsky> what are you planning for him?
[17:32:37] <cradek> not sure yet...
[17:33:23] <cradek> one thing I've been wanting to do is make a tool holder for the probe. I might ask his advice on that.
[17:36:13] <cradek> (ok I took both the friday and monday off...)
[17:37:43] <dgarr> what is the current thinking on params-to-pins modifications for *.comp files?
[17:38:57] <cradek> I bet that's a lot safer than the same change to the ones written in C, since with comp you can't do the trick of not exporting params but using them internally anyway
[17:40:02] <jepler> it will also diagnose at compile time assignment to 'in' parameters.
[17:40:32] <jepler> 3 pin in bit in;
[17:40:34] <jepler> 6 in = 1;
[17:40:37] <jepler> _.comp:6: error: invalid lvalue in assignment
[17:42:11] <jepler> (incidentally, comp should probably reject "_" as a component name :-P
[17:42:12] <jepler> )
[17:42:26] <jepler> Component Pins:
[17:42:26] <jepler> Owner Type Dir Value Name
[17:42:26] <jepler> 32769 bit IN FALSE .0.in
[17:43:58] <jepler> so: if you have a use case and test the change I'd probably accept it
[17:46:42] <dgarr> i have a case of using sum2 as an integrator where having the gains as pins makes it easier to reset it.
[17:47:41] <jepler> that looks pretty unproblematic
[17:48:20] <jepler> something about the integ component is unsuitable?
[17:49:48] <dgarr> nope -- i just hadn't seen it, i'll use that, thanks
[17:52:25] <jepler> ok
[17:53:08] <dgarr> although i think params-to-pins for comps would be a good thing in general
[17:53:47] <dgarr> as i can imagine gains (for instance) connected to signals as convenient
[17:55:32] <jepler> somebody needs to write an arithmetic component
[17:55:54] <jepler> loadrt arithmetic function0="in0*in1+in2*in3"
[18:55:44] <SWPadnos> jepler, it makes my skin crawl to consider an infix -> postfix interpreter in the kernel
[18:55:46] <SWPadnos> nothing personal :)
[18:55:55] <alex_joni> RPN ?
[18:56:12] <SWPadnos> oh, that would be even more useful to the average machinist :)
[18:56:46] <alex_joni> function0=in0,in1*,in2,in3*+
[18:57:04] <SWPadnos> yep. much wasier than using all those parenthesis ...
[18:57:08] <SWPadnos> s/w/e/
[19:02:13] <alex_joni> :)
[19:02:53] <jepler> actually I think you'd use a bytecode in a shared memory area, and compile the infix expression to bytecode in userspace
[19:04:25] <SWPadnos> yep. maybe have the userspace module automatically load the kernel module, similar to halscope and scope_rt
[19:25:25] <cradek> neat, looks like we're getting a dapper buildbot
[19:26:59] <jepler> seb_kuzminsky: I just saw that hm2_7i43 does the following to set EPP mode: outb(0x94, board[i].port.base_hi + HM2_7I43_ECP_CONTROL_HIGH_OFFSET); // select EPP mode in ECR
[19:27:36] <jepler> do you recall how you arrived at the value 0x94?
[19:29:44] <cradek> huh, I just found a nasty bug by spotting it in the code.
[19:30:14] <cradek> set an X offset, then g0 g53 x1 / g91 g81 r.1 z-1 y1 l5 f60
[19:30:16] <jepler> bits 0x10 and 0x04 are documented as "ECP Interrupt bit" and "ECP DMA Enable Bit" which I don't think are desired
[19:32:03] <micges> cradek: master?
[19:32:18] <cradek> for extra credit, see if you can figure out how it SHOULD work if you then specify x-1 l3 on the next line
[19:32:36] <cradek> micges: all emc versions :-)
[19:32:46] <micges> heh ok :)
[19:36:03] <cradek> the nist ngc doc doesn't say how this should work
[19:41:26] <jepler> cradek: my expectation the holes should be at the same locations as you'd get from g91 g0 y1 / g0 y1 [l-1 times]
[19:41:47] <jepler> or if you add x-1 then at the same locations as you'd get from g91 g0 x-1 y1 / g0 x-1 y1 [l-1 times]
[19:43:02] <cradek> ok I think I agree
[19:43:06] <jepler> I don't see anything that specifies that x or y are sticky
[19:43:38] <cradek> so, g91 g81 r.1 z-1 y1 l5 f60 / x1 l5 means the second set of holes go right, not diagonally
[19:44:22] <jepler> In addition, at the beginning of the first cycle and each repeat, the following one or two moves are made
[19:44:25] <jepler> 1. a straight traverse parallel to the XY-plane to the given XY-position,
[19:45:24] <cradek> do you think they didn't intend that X xor Y can be unspecified?
[19:47:13] <jepler> incidentally, while wikipedia says atan2(0,0) is undefined, the x87 defines atan2(+-0,+-0) as +-0 or +-pi depending on the two signs involved
[19:47:15] <cradek> this is not written in terms of Interp::find_ends because they wanted all the cycle stuff to be plane-agnostic
[19:47:52] <jepler> (more specifically, that's the definition of the FPATAN instruction)
[19:48:25] <jepler> It is an error if:
[19:48:26] <jepler> * X, Y, and Z words are all missing during a canned cycle,
[19:48:58] <jepler> so according to the docs g81 with both x and y missing are ok..
[19:49:46] <cradek> yes I'm pretty sure that just means 'drill here'
[19:49:52] <SWPadnos> 100 times ...
[19:49:54] <SWPadnos> :)
[19:50:19] <cradek> yes you can do that with g81 r.1 z-1 l100
[19:50:38] <cradek> ok, I think I know what it should do - now I just have to make it do that
[20:01:19] <jepler> http://blog.makezine.com/archive/2010/01/18/rsz_in-case-of-nuclear-attack.jpg (step 7: comfort the dying)
[20:02:21] <SWPadnos> heh
[20:02:31] <SWPadnos> then isolate corpses to prevent spread of disease
[20:02:47] <SWPadnos> I always feel better with a newspaper over my head though
[20:06:03] <SWPadnos> cradek, been usint python a lot lately?
[20:06:06] <SWPadnos> using
[20:07:17] <cradek> SWPadnos: I wrote touchy in python recently
[20:07:34] <cradek> why? what did I do?
[20:07:35] <SWPadnos> ok, just wondering. I noticed that you set those variables to 0., rather than 0 or 0.0 :)
[20:07:54] <cradek> hm, well if I did it the same every time, it'd be boring
[20:07:57] <SWPadnos> which is something I've seen in python a lot, but not so much in C/C++
[20:08:00] <SWPadnos> heh
[20:08:09] <jepler> is 0. a Python thing?
[20:08:22] <cradek> I think I've seen that exclusively in C
[20:09:00] <SWPadnos> oh, funny. I think I've only seen 0 or 0.0 when people are paranoid about preventing conversions
[20:09:33] <SWPadnos> for the last 15-20 years (at least), most compilers would generate the same code for "double x=0
[20:09:37] <SWPadnos> "
[20:09:44] <SWPadnos> vs. "double x=0.0"
[20:10:11] <cradek> well you should just be thankful that I initialized it at all.
[20:10:17] <SWPadnos> oh, I am
[20:10:23] <jepler> depressing daytime app has 85000 of them, so it may be something local that chris and I have picked up.
[20:11:06] <SWPadnos> that's a lot of initializers
[20:11:17] <cradek> Results 1 - 9 of about 575,000,000 for double x=0.;
[20:11:31] <cradek> (but that's a totally bogus result)
[20:11:35] <jepler> dist = 9.E+99;
[20:11:40] <SWPadnos> well, maybe I need more coffee or something
[20:12:37] <jepler> apropos of decimal points, I remember learning that in Commodore basic, POKE addr,. was just a hair faster than POKE addr,0
[20:12:38] <cradek> of course, daytime app is older than both 20 years and ANSI C
[20:13:08] <SWPadnos> wow, was commodore basic that strange?
[20:13:27] <SWPadnos> I don't remember doing much optimization on those, as I was an Atari man
[20:13:31] <SWPadnos> err, boy
[20:13:34] <jepler> har
[20:16:34] <cradek> these macros make me cry
[20:17:18] <jepler> wow was commodore basic really that slow? For 2000 POKEs in a for loop it took 16 seconds for POKE53280,0 and 15 seconds for POKE53280,.
[20:19:22] <jepler> (and so the speed difference isn't that great either)
[20:19:32] <SWPadnos> heh - was that the start of color memory or the start of graphics memory?
[20:19:43] <jepler> border color
[20:19:58] <SWPadnos> ah, ok
[20:20:08] <SWPadnos> I remembered 53279 being something graphics related as well
[20:20:20] <SWPadnos> though I could be thinking of the display list pointer on the Ataris
[20:21:17] <jepler> 53279 is the sprite-to-background collision register
[20:21:37] <SWPadnos> ok, I'm thinking of Atari stuff then
[20:22:17] <SWPadnos> I did quite a lot on those (including writing an Asteroids-like game in BASIC on paper, since I didn't have a computer yet)
[20:23:02] <jepler> (ATARI 53279) > This buzzer has a fixed tone and duration. To create a variable duration, one must POKE zero into the speaker register, CONSOL, at location 53279 decimal. The duration is set by the number of times CONSOL is set to zero.
[20:23:57] <SWPadnos> ok, maybe it's time for a brain reboot or somethinf
[20:23:59] <SWPadnos> g
[20:25:41] <seb_kuzminsky> jepler: probably a bad cut-n-paste from somewhere :-/
[20:26:48] <jepler> seb_kuzminsky: it must work OK
[20:27:04] <seb_kuzminsky> i think the ecp-specific stuff is ignored in epp mode
[20:27:11] <jepler> probably true
[20:34:03] <jepler> seb_kuzminsky: I should mention that something in the back of my head tells me that 6.06 won't build packages from master
[20:34:15] <jepler> oh, I think because of the lyx document version
[20:35:25] <seb_kuzminsky> ok thanks, i'll drop it from the master builds if it doesnt behave itself
[20:36:52] <cradek> neat, my smarter polar coords work
[20:37:35] <seb_kuzminsky> jepler: bummer, i was hoping to make the buildbot tell me if i break the build on dapper again in the future
[20:37:55] <cradek> g0 @2 / g91 g81 r.1 z-1 f60 ^45 l8
[20:37:57] <jepler> you can build a realtime rip build and do the runtests
[20:38:04] <jepler> but you can't build a deb
[20:38:26] <jepler> CIA-5: are you dozing?
[20:49:48] <cradek> I bet we have no canned cycles in our test suite...
[20:50:50] <cradek> CIA-5: I pushed the new polar coord code. Would you tell everyone please?
[21:15:52] <alex_joni> cradek: you didn't say why you did it :P
[21:16:30] <cradek> actually I did
[21:16:40] <cradek> in both commits
[21:16:59] <alex_joni> oh right.. cia only has the first line on their site
[21:17:01] <alex_joni> http://cia.vc/stats/project/emc
[21:17:54] <alex_joni> did you see the failed runtest on lenny?
[21:18:10] <cradek> me?
[21:18:43] <alex_joni> it was after your commit, but I notice it's unrelated
[21:18:49] <alex_joni> hostmot2 can't be loaded
[21:18:58] <jepler> seb knows about that
[21:20:02] <alex_joni> the 2 previous builds were successfull
[21:20:10] <alex_joni> s/ll/l/
[21:22:48] <jepler> huh, so they were
[21:23:11] <jepler> beats me then
[21:23:50] <jepler> no, the previous build #796 is the one where seb introduced the breakage
[21:23:57] <jepler> #793 must have failed for a different reason
[21:24:33] <jepler> ah, that was when johnt had accidentally pushed the thc stuff which didn't build
[21:26:26] <seb_kuzminsky> yeah my bad
[21:26:57] <seb_kuzminsky> i love build test automation because i'm so sloppy, i need a robot to smack me on the head when i break stuff
[21:28:38] <cradek> but what happens when you break the robot?
[21:32:29] <alex_joni> the owner smacks you on the head
[21:32:33] <alex_joni> been there, done that
[21:38:12] <alex_joni> thank god for mandatory hard-hat rules
[22:33:20] <jt-plasma> * jt-plasma knows about git push --dry-run now
[22:33:43] <jt-plasma> and why it is important not to push from this computer :)
[23:35:38] <seb_kuzminsky> ok i'm done breaking the buildbot for a while
[23:36:09] <seb_kuzminsky> next i'll fix the argv_split() thing...
[23:36:48] <seb_kuzminsky> we now have dapper buildslaves again, for both master and 2.3
[23:41:04] <jthornton> is it my turn?
[23:42:59] <SWPadnos> seb_kuzminsky, it may be ugly, but you can always replace the ending NUL with the string separator to rebuild the original string, if you're careful
[23:43:52] <SWPadnos> (careful meaning that you need to be sure you (a) didn't get a null return, and (b) that you aren't screwing up the real end of the string - maybe by using strlen before and after the call)
[23:58:28] <seb_kuzminsky> laters
