Back
[03:38:00] <ratbert> [Global notice] I am a fat asshole, who loves abuse, die
[03:38:11] <ratbert> DCC SEND YOUAREALLJUDENLOL
[11:02:20] <Lerneaen_Hydra2> I seem to be having some issues with EMC and dapper
[11:02:54] <Lerneaen_Hydra2> as soon as I start emc it starts giving errors in the terminal
[11:02:55] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.x' not found
[11:02:55] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.y' not found
[11:02:55] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.z' not found
[11:02:55] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.a' not found
[11:02:55] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.b' not found
[11:02:57] <Lerneaen_Hydra2> HAL:0: ERROR: signal 'axisui.jog.c' not found
[11:03:09] <Lerneaen_Hydra2> this pattern repeats continously
[11:03:18] <Lerneaen_Hydra2> but I can still jog the axes and so on
[11:03:58] <Lerneaen_Hydra2> however there is a lot more latency when jogging, when I press a button to jog it starts instantly, but continues something like 0.5 seconds after I release
[11:05:25] <Lerneaen_Hydra2> it seems that the error message sequence appears once per time that I release the jog button. Only after the message is printed does the jogging stop (0.5 seconds)
[11:06:15] <alex_joni> ok, lets rewind for a bit
[11:06:29] <alex_joni> the axisui.* buttons are only in the latest AXIS versions
[11:06:59] <alex_joni> and in order for AXIS to use them, you need to have the latest emc2 too
[11:07:10] <Lerneaen_Hydra2> I compiled both from head
[11:07:16] <Lerneaen_Hydra2> at least, I think I did
[11:07:29] <alex_joni> are you sure you chose one of the configs from the emc2 head version?
[11:07:47] <alex_joni> I usually get mixed stuff when having an installed emc2, and one from CVS HEAD
[11:07:57] <Lerneaen_Hydra2> what do you mean by config?
[11:08:02] <alex_joni> so you need to be VERY carefull what config you choose
[11:08:06] <Lerneaen_Hydra2> the .ini and other assosiated files?
[11:08:10] <alex_joni> right
[11:08:15] <Lerneaen_Hydra2> currently I'
[11:08:21] <Lerneaen_Hydra2> m using the one I made before
[11:08:28] <alex_joni> that's your problem then
[11:08:37] <Lerneaen_Hydra2> different syntax?
[11:08:39] <alex_joni> you need to redo it based on the one from HEAD
[11:08:43] <Lerneaen_Hydra2> oh, ok
[11:08:44] <alex_joni> no, missing one hal file
[11:08:56] <Lerneaen_Hydra2> ah, so if I keep the old one and add the new file?
[11:09:08] <alex_joni> there is a core_axis.hal in emc2/configs/common
[11:09:17] <alex_joni> copy it over, and enable it from the ini
[11:09:33] <Lerneaen_Hydra2> what do you mean by enable?
[11:10:16] <alex_joni> add
[11:10:33] <alex_joni> HALFILE = core_axis.hal
[11:10:49] <Lerneaen_Hydra2> ok
[11:11:20] <Lerneaen_Hydra2> in which part of the ini?
[11:11:32] <alex_joni> there should be similar lines like that :D
[11:11:41] <alex_joni> in [HAL]
[11:11:45] <Lerneaen_Hydra2> and where should the .hal be located, in the same folder as the .ini or another folder?
[11:11:49] <Lerneaen_Hydra2> oh, ok
[11:11:53] <alex_joni> in the same folder
[11:12:30] <alex_joni> basicly when we talk about a 'config' we mean the whole folder
[11:12:44] <alex_joni> that holds the .ini, .tbl, .nml, .hal's, etc
[11:13:21] <Lerneaen_Hydra2> so that's pretty much the only folder for configs?
[11:13:30] <alex_joni> how do you mean that?
[11:14:24] <Lerneaen_Hydra2> all settings are done in that folder
[11:14:27] <alex_joni> right
[11:15:10] <Lerneaen_Hydra2> well, everything seems to be working so far
[11:15:22] <alex_joni> coo
[11:16:36] <Lerneaen_Hydra2> programs run and so on
[11:23:23] <Lerneaen_Hydra2> how do I set up jogwheels?
[11:31:30] <alex_joni> well.. first you need one
[11:31:43] <alex_joni> next you need it counted by something (e.g. encoder module, and parport interface)
[11:31:52] <alex_joni> next you need to connect the encoder stuff to halui
[11:32:08] <alex_joni> or directly to motion
[11:32:12] <alex_joni> that works far better
[11:32:30] <alex_joni> then you need to connect those AXIS signals to motion, to switch the axis to be jogged
[11:34:07] <Lerneaen_Hydra2> hmm. ok. I've got all the hardware done, what I need to do now is get the signals (quadrature, pin A for phase A, pin B for phase B) to AXIS, and all the stuff between
[11:34:41] <alex_joni> right
[11:34:43] <alex_joni> bbl
[11:35:33] <Lerneaen_Hydra2> who knows how do do that?
[11:38:08] <fenn> i think i hear a fine manual calling your name
[11:39:35] <Lerneaen_Hydra2> oh? it's in the manual already?
[11:39:39] <Lerneaen_Hydra2> which?
[11:40:07] <fenn> you need to know how hal works if you want to connect all the signals to the right places
[11:41:04] <fenn> look at the maxnc example config for how to setup an encoder
[11:41:20] <Lerneaen_Hydra2> oh, I don't really know as it is now. so it's not nearly as simple as changing pins in pinout.hal?
[11:41:55] <fenn> actually the latest maxnc might have a jogwheel already
[11:42:11] <Lerneaen_Hydra2> are all changes done in the config folder?
[11:42:30] <Lerneaen_Hydra2> or do I need to muddle with sourcecode and change stuff there?
[11:42:46] <fenn> you shouldnt need to mess with any code
[11:43:36] <Lerneaen_Hydra2> oh, then I think I can get it to work. I'll take a look at the maxnc config. which manual was there information in?
[11:44:35] <fenn> hal_documentation.pdf and the hal chapters in the user manual
[11:46:36] <fenn> cd configs ; grep jog ./ -R
[11:46:49] <fenn> that should show you a bunch of stuff in demo_mazak, that's half of what you need to do
[11:51:38] <Lerneaen_Hydra2> and the other half?
[11:53:43] <fenn> should be able to figure that out by looking at the available hal pins
[11:54:24] <Lerneaen_Hydra2> oh, so just changes to the values that are in that file?
[11:54:30] <Lerneaen_Hydra2> rather than brand new values
[12:03:18] <fenn> no, open halcmd and type "show pin"
[12:03:34] <fenn> or just "halcmd show pin"
[12:03:39] <fenn> with emc running
[12:04:55] <Lerneaen_Hydra2> what am I looking for?
[12:07:49] <fenn> something like jog.enable
[12:08:03] <fenn> and jog.x jog.y jog.z
[12:08:33] <fenn> i dont remember what they're called exactly
[12:08:57] <Lerneaen_Hydra2> axis.X.jog.enable/count/scale
[12:09:59] <Lerneaen_Hydra2> enable is currently set to false on all axes, even though I'm in jog mode. (This is not with the maxnc config)
[12:33:04] <alex_joni> Lerneaen_Hydra2: you need to connect the signals from AXIS to those enables
[12:33:29] <alex_joni> halcmd linksp axisui.jog.x axis.0.jog.enable
[12:33:34] <alex_joni> halcmd linksp axisui.jog.y axis.1.jog.enable
[12:33:38] <alex_joni> halcmd linksp axisui.jog.z axis.2.jog.enable
[12:33:40] <alex_joni> and so on
[12:33:59] <alex_joni> that will take care of enabling the jog for one of the axes (X,Y,Z) when you select that axis in AXIS
[12:34:26] <alex_joni> then you need an encoder module (halcmd loadrt encoder num_chan=1)
[12:34:37] <alex_joni> then you need to connect the jogwheel to it:
[12:34:43] <alex_joni> newsig bit encA
[12:34:45] <alex_joni> newsig bit encB
[12:34:56] <alex_joni> linksp encA parport.0.pin-10-in
[12:35:00] <alex_joni> linksp encB parport.0.pin-11-in
[12:35:08] <alex_joni> linksp encA encoder.0.phase-A
[12:35:12] <alex_joni> linksp encB encoder.0.phase-B
[12:35:32] <alex_joni> then you need to tell the encoder how it should convert the counts to units
[12:36:18] <alex_joni> setp encoder.0.position-scale 480 (or whatever value you need)
[12:37:09] <alex_joni> Lerneaen_Hydra2: and so on ;) but if you understand how the HAL works, then you should be able to build this up in a couple of minutes
[12:53:07] <Lerneaen_Hydra2> alex_joni: right. where do I input all this so it autoloads? the newsig and linksp I know goes into standard_pinout.hal, but what about the halcm loardrt encoder num_chan=1 and connecting the signals from AXIS to the enables?
[13:02:53] <Lerneaen_Hydra2> alex_joni: oh, and scale would be counts per unit of movement? just like scale in the main ini?
[13:08:48] <alex_joni> right
[13:08:58] <alex_joni> basicly this can go to any .hal file
[13:09:20] <alex_joni> but I would recommend you make a .hal file of your own (so you don't get affected by future changes)
[13:10:04] <Lerneaen_Hydra2> oh. everything or just the stuff that doesn't go into standard_pinout.hal?
[13:10:25] <Lerneaen_Hydra2> and I also need to have a reference line in the main.ini file, right?
[13:11:51] <fenn> .hal files are just scripts that execute halcmd commands
[13:12:08] <fenn> nothing has to go in any hal file in particular, but they do need to be run in the right order
[13:12:46] <Lerneaen_Hydra2> right. so my file should exeute last?
[13:12:59] <fenn> yep
[13:14:22] <Lerneaen_Hydra2> so one of the commands that I was wondering about (halcmd encode num_chan=1) should just be a line in my hal file that says "num_chan=1"?
[13:17:27] <fenn> loadrt encoder num_chan=1 means load a realtime encoder module with 1 channel
[13:17:41] <fenn> you would put 'loadrt encoder num_chan=1' in the hal file
[13:18:43] <Lerneaen_Hydra2> no, of course not. I was wondering if I should then put a line that says "num_chan=1" in the file
[13:24:39] <Lerneaen_Hydra2> bug/strange behavior report: when using the arrow keys to jog, if I jog both X and Z, they will continue for a bit after I release them. Longer than if I jog them seperatly
[13:26:25] <fenn> yep thats an old bug and no fix in sight
[13:26:47] <alex_joni> fenn: the old bug, was that it would just keep jogging
[13:27:05] <alex_joni> but that was for tkemc, and I fixed that a while ago
[13:27:14] <alex_joni> Lerneaen_Hydra2: do you mean you get this for AXIS?
[13:34:11] <alex_joni> bbl
[13:42:00] <jepler> it's possible that the changes to axis, which manipulate the axisui.jog.[xyz] pins, introduce a noticeable lag before the second key release can be processed.
[13:42:16] <jepler> Lerneaen_Hydra2: is this lag when releasing two jog keys at the same time new, or have you always experienced it?
[14:02:30] <cradek> alex_joni: at workshop I noticed tkemc jogging is still (or again) not right, but I'm sorry to say I forget the details exactly
[14:03:22] <cradek> alex_joni: it was either a problem with multiple axes, or press-release-press of one axis
[14:03:37] <cradek> or both :-)
[14:03:40] <alex_joni> cradek: I'll bother when there will be a bug report ;)
[14:03:46] <cradek> haha
[14:03:49] <alex_joni> till then it probably works fine :D
[14:03:56] <cradek> ok I don't blame you one bit
[14:04:04] <alex_joni> bet you feel the same :D
[14:04:38] <cradek> you'll notice I didn't bother to try it before saying something
[14:06:04] <cradek> I think the problem was "it's not jogging even though I'm holding the key down" instead "it jogs forever after I release it" like before, which is a much less important bug
[14:06:12] <cradek> instead OF
[14:07:43] <Lerneaen_Hydra2> Uh, I have latency stopping a log regardless of whether I release them simultaneusly or sequentially
[14:08:05] <cradek> even when jogging only one axis?
[14:08:10] <Lerneaen_Hydra2> jepler: I haven't thought of it much before, so probably new, though I'm not sure. Yes this is AXIS
[14:08:18] <Lerneaen_Hydra2> cradek: no, at least not as much
[14:08:37] <cradek> ok
[14:08:41] <Lerneaen_Hydra2> when only jogging one I get maybe 1/5th of a second or so (I'm just guessing the value)
[14:09:46] <Lerneaen_Hydra2> cradek: did the images I sent yesterday clear anything up?
[14:09:53] <Lerneaen_Hydra2> with tool angles and so on
[14:09:56] <cradek> do you have your wheel working?
[14:10:24] <Lerneaen_Hydra2> I havn't connected it yet. Right now I'm modifying the mechanical bits
[14:10:31] <cradek> yes I believe we're thinking the same kind of thing
[14:10:34] <Lerneaen_Hydra2> But I'll connect it later today
[14:10:39] <jepler> Lerneaen_Hydra2: in axis.py around line 95, insert "return" as the first line of the function. Then rebuild. Let me know if this reduces the lag.
[14:10:43] <jepler> def halcmd_sets(signal, value):
[14:10:45] <jepler> return
[14:10:46] <jepler> this will skip calling 'halcmd'
[14:10:49] <jepler> os.spawnvp(os.P_WAIT, "halcmd", ["halcmd", "sets", signal, str(value)])
[14:13:20] <cradek> bbl
[14:13:54] <Lerneaen_Hydra2> ok
[14:15:16] <Lerneaen_Hydra2> jepler: do I need to ./configure --enable-run-in-place or just make && sudo make setuid
[14:15:29] <jepler> just 'make'
[14:15:36] <Lerneaen_Hydra2> ok
[14:15:42] <Lerneaen_Hydra2> * Lerneaen_Hydra2 compiling
[14:16:18] <Lerneaen_Hydra2> what type of bad stuff can happen now that I've removed that?
[14:16:38] <jepler> the axisui.jog.[xyz] signals will never be set
[14:16:42] <jepler> so your jogwheel wouldn't work
[14:16:45] <Lerneaen_Hydra2> oh, ok
[14:17:02] <Lerneaen_Hydra2> so when I connect them I'll need to comment that command out and recompile?
[14:17:08] <jepler> yes
[14:17:29] <jepler> what I am trying to find out is if this change is the reason you're noticing it's slow to stop jogging
[14:17:33] <jepler> it's not a "fix"
[14:17:40] <jepler> it's a step in diagnosis
[14:18:01] <Lerneaen_Hydra2> yes, it's back to how it was before now
[14:18:04] <Lerneaen_Hydra2> no noticable lag
[14:18:14] <Lerneaen_Hydra2> naturally
[14:18:29] <jepler> ok
[14:18:39] <jepler> thanks for doing that test for me
[14:18:46] <Lerneaen_Hydra2> sure, np
[14:19:15] <Lerneaen_Hydra2> anything else I should test or do you know enough now?
[14:19:45] <jepler> nothing right now. I'll let you know if you can help again.
[14:19:52] <Lerneaen_Hydra2> ok
[14:32:33] <jepler> Lerneaen_Hydra2: try changing your axis.py near line 95 to the code shown here:
http://pastebin.ca/71266
[14:33:52] <jepler> remove the old 2 or 3 lines of halcmd_sets and replace it with the code in the pastebin
[14:37:14] <Lerneaen_Hydra2> which old lines?
[14:37:26] <Lerneaen_Hydra2> I can only find one row of halcmd around line 95
[14:40:08] <Lerneaen_Hydra2> or wait, oh, you mean the entire code segment?
[14:40:44] <Lerneaen_Hydra2> the entire def halcmd_sets portion? (2 lines default, currently 3)
[14:42:46] <jepler> yes
[14:42:58] <Lerneaen_Hydra2> ok, compiling
[14:44:16] <Lerneaen_Hydra2> do I need to do ./configure --enable-run-in-place?
[14:44:54] <jepler> shouldn't need to
[14:45:16] <Lerneaen_Hydra2> looks like I needed to do that, I didn't first and got strange behavior, stopped after mentioning magma
[14:45:29] <jepler> huh
[14:46:01] <Lerneaen_Hydra2> or, wait
[14:46:03] <Lerneaen_Hydra2> nevermind
[14:46:17] <Lerneaen_Hydra2> I just missed some text in the shell window
[14:46:59] <Lerneaen_Hydra2> oh, it doesn't start now
[14:47:19] <jepler> huh
[14:47:25] <jepler> can you pastebin the output you do get?
[14:47:44] <Lerneaen_Hydra2> yes
[14:48:15] <Lerneaen_Hydra2> pastebin is slow today for me...
[14:48:28] <jepler> try pastebin.ca
[14:48:30] <Lerneaen_Hydra2> ok
[14:48:54] <Lerneaen_Hydra2> http://pastebin.ca/71274
[14:48:58] <Lerneaen_Hydra2> right, that worked better
[14:50:14] <jepler> huh
[14:52:03] <jepler> one of us must have messed up that code I put on pastebin
[14:52:30] <jepler> just download this axis.py and save it over the one you have:
http://emergent.unpy.net/index.cgi-files/sandbox/axis.py
[14:53:02] <Lerneaen_Hydra2> oh, ok
[14:56:56] <Lerneaen_Hydra2> right, it loads now
[14:57:11] <jepler> and .. is it fast? or slow?
[14:57:26] <Lerneaen_Hydra2> aand the latency is gone
[14:57:36] <Lerneaen_Hydra2> just like it behaved before
[14:58:51] <jepler> good
[14:59:05] <Lerneaen_Hydra2> one thing that has changed between now and the previous head I had was that previously when pressing both up and down, it would always jog to x- or z-, whereas now it jogs with the last key that was pressed
[15:01:07] <jepler> huh -- I haven't deliberately changed how multiple presses are handled.
[15:01:53] <Lerneaen_Hydra2> the previous head I had was one maybe... 2-3 weeks old
[15:08:59] <SWPadnos> jepler - you may want to add k to the halcmd options
[15:09:11] <SWPadnos> it'll exit after any error without that
[15:10:39] <SWPadnos> also, you can probably do a lot less parsing if you add the s (script mode) option (though that's unnecessary since it works as is)
[15:13:26] <jepler> actually, I want it to fail if the axisui signals haven't been created. that will make the overhead even lower for those who don't want jogwheels or whatnot
[15:14:14] <jepler> maybe my users will feel differently, I dunno
[15:15:38] <jepler> and I never read anything from halcmd, but "-s" will be great when I do
[15:25:23] <SWPadnos> heh - I just noticed that it's only used for 'sets' (in the diff anyway)
[15:46:58] <jmkasunich> cradek: you around?
[15:47:08] <jmkasunich> I noticed all the lathe offset stuff is in a branch?
[15:47:39] <jmkasunich> at least the commit messages imply that
[16:14:11] <jepler> jmkasunich: yeah, I think that's true
[16:14:39] <jmkasunich> wonder when/if he's gonna move it to head?
[16:14:56] <jmkasunich> the compile farm doesn't look at branches (except the v2.0 branch)
[16:21:10] <jepler> I'm sure he knows that
[16:24:08] <jmkasunich> I figured.... just thought if it was pretty much done I'd poke him to move it
[16:42:14] <cradek> hi
[16:43:11] <cradek> the changes are so invasive I think they shouldn't be on head until they're tested a bit
[16:44:00] <cradek> I still have to write shape compensation, it's going to be hairy
[16:44:15] <cradek> I was wrong about it being good enough to just move the controlled point to the center of the radius
[16:44:57] <cradek> if I do that, and someone cuts without radius comp on, the part will be two tool radiuses too small
[16:45:10] <cradek> ("duh")
[16:45:30] <cradek> so I have to convert all the radius comp moves to consider the tool shape/origin
[16:55:25] <fenn> jan is definitely right that we should support comedi drivers
[16:56:05] <fenn> oh gee that was 3 days ago
[16:58:15] <fenn> jmkasunich: its something you should take a long hard look at before refactoring hal
[17:01:10] <jepler> there's going to be a bit of CVS server downtime today (in the next 4 hours). it shouldn't last long.
[17:01:48] <cradek> I'm working on emc but I think it won't bother me
[17:02:06] <fenn> the on-call engineer is going to be doing some routine maintenance eh?
[17:34:24] <alex_joni> 'lo
[17:35:14] <cradek> hi
[17:36:04] <Lerneaen_Hydra2> 'lo bob
[17:36:50] <alex_joni> * alex_joni is freaking pissed
[17:37:15] <SWPadnos> what fer?
[17:39:22] <alex_joni> lost the car keys
[17:39:42] <cradek> oh no
[17:39:54] <alex_joni> along with the registration
[17:39:56] <Lerneaen_Hydra2> oh... that's not good.
[17:40:00] <alex_joni> indeed no
[17:40:46] <Lerneaen_Hydra2> lost for good or lost can not find them for now?
[17:41:07] <alex_joni> for now the later one, but I think it will eventually turn into the first one :/
[17:42:26] <Lerneaen_Hydra2> oh crap.. x.x
[17:47:06] <cradek> Lerneaen_Hydra2:
http://timeguy.com/cradek-files/emc/lathecomp.png
[17:56:53] <jmkasunich> fenn: I've looked at comedi before (and probably should again)
[17:57:01] <jmkasunich> but in general, I didn't like their approach
[17:57:07] <alex_joni> hi jmk
[17:57:12] <jmkasunich> hi alex
[18:11:11] <jmkasunich> cradek: what level of testing do you think is needed to prove that the lathe offset code didn't bust mill mode?
[18:11:21] <jmkasunich> seems like thats all thats needed prior to a merge
[18:11:56] <jmkasunich> and of course, thats what _won't_ happen unless we specifically do it, because the only folks using the lathe branch are those with lathes, not mills?
[18:12:02] <cradek> jmkasunich: I sure touched a lot of things... I'd like it if someone with a lot of radius comp mill gcode would load them all up in axis and have a look
[18:12:25] <jmkasunich> maybe a post to emc-developers or even emc-users with that request?
[18:12:31] <cradek> also I'm kind of worried about inverse feed rate mode
[18:12:45] <cradek> but if anything that'll likely be wrong in XZ and not XY
[18:14:24] <alex_joni> cradek: what's up with the new directories in CVS?
[18:14:32] <cradek> ?
[18:14:58] <alex_joni> New directory emc
[18:15:05] <alex_joni> New directory EMC
[18:15:08] <cradek> wtf???
[18:15:11] <alex_joni> New directory emc2
[18:15:16] <alex_joni> got those by email
[18:15:54] <cradek> I bet it's a bug
[18:16:05] <alex_joni> Subject: [Emc-commit] emc2 - Imported sources
[18:16:05] <cradek> lathecomp.ngc is on the branch only
[18:16:48] <SWPadnos> that's new directory - emc (not emc2
[18:16:49] <SWPadnos> )
[18:16:57] <alex_joni> the emc & EMC where 2 mails before the lathecomp, and the emc2 is afterwards
[18:17:11] <jmkasunich> something is fscked
[18:17:15] <alex_joni> SWPadnos: I got 3 mails, one for each dir
[18:17:22] <SWPadnos> oh right - emc, EMC, emc2
[18:17:31] <jmkasunich> same here
[18:17:54] <jmkasunich> side effect of jepler's admin stuff?
[18:17:57] <alex_joni> might be nothing.. (probably a bug in the commit mail)
[18:18:04] <alex_joni> commit script I mean
[18:18:21] <jmkasunich> just got another emc2 one
[18:19:37] <alex_joni> if cradek's silent, he probably is investigating this :)
[18:21:06] <SWPadnos> hmmm - are those messages sent by the server itself, or cia / SF / ... ?
[18:21:09] <cradek> I don't see anything wrong, but those are strange mails
[18:21:25] <cradek> Received: from cvs.linuxcnc.org (localhost [127.0.0.1])
[18:21:27] <alex_joni> cradek: does the cvs server have those in the sent mail?
[18:21:28] <cradek> by cvs.linuxcnc.org (8.13.4/8.13.4) with ESMTP id k5PIO8QO001263
[18:21:31] <cradek> for <emc-commit@lists.sourceforge.net>;
[18:21:58] <cradek> alex_joni: yes
[18:22:08] <cradek> my mail script is obviously bogus somehow
[18:22:16] <alex_joni> ok, so probably something confused your mail script
[18:22:18] <cradek> and I bet it has to do with Attic
[18:22:20] <jmkasunich> why suddenly now?
[18:22:33] <alex_joni> does it have "Imported source" somewhere?
[18:22:34] <cradek> a new file that is only on the branch
[18:22:47] <cradek> alex_joni: no, that must come from cvs itself
[18:23:22] <SWPadnos> there are a bunch of files that are only in a branch, aren't there? (like some entire config dirs)
[18:23:25] <alex_joni> I see... he says but stumbled further in darkness
[18:24:31] <cradek> the cvs root@cvs# cat ../../last_commit
[18:24:31] <cradek> emc2 - Imported sources
[18:25:14] <cradek> I'm clueless
[18:26:09] <cradek> is 83-131-250-143.adsl.net.t-com.hr. any of us?
[18:26:54] <alex_joni> hr is croatia
[18:28:13] <cradek> ouch, these were triggered by that .hr using cvs as anon
[18:28:33] <jmkasunich> he committed?
[18:28:53] <cradek> no, anon cannot write to anything
[18:29:01] <cradek> but something he did fooled cvs into writing a log entry
[18:29:02] <alex_joni> he probably imported the sources to his PC
[18:29:07] <alex_joni> lol
[18:30:27] <jmkasunich> so, anon _can_ write something... if only to the log
[18:31:01] <jmkasunich> is it possible that anon can create a new dir (maybe even owned by anon) even if he can
[18:31:03] <jmkasunich> can
[18:31:05] <jmkasunich> dammit
[18:31:11] <jmkasunich> can't write to existing files
[18:31:29] <jmkasunich> that damn ' gets me every time, I hit enter instead
[18:31:45] <cradek> no, I just checked permissions on everything again
[18:32:05] <jmkasunich> so theres no new directories lurking in strange places?
[18:32:08] <alex_joni> it's right next to enter here too... :)
[18:32:19] <alex_joni> öä'
[18:34:01] <cradek> jmkasunich: everything looks fine
[18:34:03] <Lerneaen_Hydra2> same here, ' is located in the corner of the upper flange that comes out
[18:34:44] <cradek> I bet it's just someone who doesn't know how to use cvs triggering a mail bug
[18:35:19] <Lerneaen_Hydra2> still, IMO anon shouldn't be able to do anything but read
[18:35:26] <cradek> he can't
[18:35:33] <cradek> well he can't write
[18:35:46] <cradek> but I guess other things generate log data and my script didn't handle it right
[18:35:50] <cradek> I'm fixing it
[18:42:01] <Lerneaen_Hydra2> oh, ok
[18:57:08] <cradek> ok fixed (?)
[18:57:10] <cradek> back on topic
[18:57:18] <cradek> should I merge this stuff?
[18:57:45] <alex_joni> yup
[18:57:54] <alex_joni> we already don't advice people to use HEAD
[18:57:58] <alex_joni> so I see no reason ;)
[19:01:30] <jmkasunich> putting it in HEAD is a better way to find out if you broke milling
[19:01:33] <cradek> man cvs
[19:01:44] <cradek> err
[19:02:36] <alex_joni> no entry found
[19:03:04] <cradek> trying to remember how to do that
[19:03:27] <alex_joni> do what?
[19:03:48] <cradek> do the thing where all changes that went on a branch since its start get merged into head
[19:04:40] <alex_joni> oh, that's some checking out of head, and then commit -jBRANCH something
[19:05:43] <cradek> cvs up -A; cvs up -jbranch
[19:05:45] <cradek> maybe?
[19:05:56] <alex_joni> something like that, but I'm no expert by all means
[19:05:58] <jmkasunich> * jmkasunich looks for his cvsboodk
[19:05:59] <cradek> I'll try it
[19:06:46] <alex_joni> http://www.psc.edu/~semke/cvs_branches.html
[19:07:03] <alex_joni> cradek: that's it
[19:07:08] <cradek> retrieving revision 1.29
[19:07:08] <cradek> retrieving revision 1.29.2.5
[19:07:08] <cradek> Merging differences between 1.29 and 1.29.2.5 into interp_convert.cc
[19:07:14] <cradek> yes looks right
[19:07:21] <alex_joni> then all you do next is cvs commit..
[19:08:24] <jmkasunich> no, what you do next is compile (from make clean probably) and do a basic test or two ;-)
[19:08:57] <alex_joni> jmkasunich: that's selfunderstood
[19:09:00] <jmkasunich> did you create any new files in the branch?
[19:09:16] <cradek> maybe one (the test nc file)
[19:09:18] <jmkasunich> if I read that page correctly, they might not get copied over to the head
[19:09:30] <jmkasunich> easy to check
[19:10:00] <cradek> U nc_files/lathecomp.ngc
[19:10:05] <cradek> it did get it
[19:10:11] <jmkasunich> cool
[20:22:31] <cradek> hmm, I've just made HEAD incompatible with AXIS
[20:22:53] <alex_joni> heh :D
[20:22:59] <cradek> I guess I'll check in those changes too
[20:23:16] <cradek> but its going to break compatibility with everything else (2.0.x, bdi4emc)
[20:23:16] <jepler> yay/boo
[20:23:30] <alex_joni> yah boo
[20:23:37] <jepler> that's why I was saying we needed a way to check for the emc2 version in the preprocessor
[20:23:41] <alex_joni> sounds kinda familiar :D
[20:24:16] <cradek> #define PACKAGE_VERSION "Prerelease CVS HEAD"
[20:24:22] <cradek> pretty useless
[20:24:49] <cradek> jepler: should I commit?
[20:25:48] <jepler> * jepler waffles
[20:25:55] <alex_joni> waffles? wot's that?
[20:26:10] <cradek> loses resolve and can no longer decide
[20:26:29] <jepler> hesitate: pause or hold back in uncertainty or unwillingness; "Authorities hesitate to quote exact figures"
[20:26:29] <alex_joni> resolve?
[20:26:49] <alex_joni> I know what hesitate means
[20:27:19] <jepler> your resolve to do something is how determined you are to do it
[20:27:28] <jepler> as opposed to having doubts about it
[20:27:41] <alex_joni> jepler: ty, that's very concise
[20:27:49] <cradek> yes, having resolve is being sure and determined
[20:28:10] <cradek> sorry I'm bad at defining things
[20:28:32] <alex_joni> never heard resolve as a noun before..
[20:29:25] <jepler> cradek: I think I don't want to break axis for everyone but emc2 bleeding-edgers
[20:29:41] <jepler> cradek: but once there's a way to coonditionally enable the code , do it
[20:31:31] <cradek> maybe we should just branch 1.4 for emc 2.0.x and let the heads track
[20:34:38] <cradek> I say that because I think there will be more changes for lathe, and I don't think we should screw with conditional compilation for all of it
[20:35:10] <jepler> but that means axis post-1.4 would be emc2 2.1 only
[20:35:35] <jepler> the other reason to branch for 1.4 would be because I want to release it someday, and should stop putting new features in...
[20:36:10] <cradek> well head already has stuff that isn't for 2.0.x (jogwheel/halcmd)
[20:36:27] <jmkasunich> "axis post-1.4 would be emc2 2.1 only"
[20:36:30] <jmkasunich> * jmkasunich nods
[20:36:31] <cradek> so it should have been branched already
[20:36:51] <jepler> cradek: but I don't think it's incompatible
[20:37:08] <cradek> ok I see
[20:37:38] <jepler> maybe it is -- it's not like I've tested it
[20:37:46] <cradek> but I'm still with jmk on this
[20:38:42] <cradek> and let it be known I don't want to wait two years to release emc 2.1, I think it's coming up.
[20:38:50] <jepler> * jepler hmms
[20:39:23] <alex_joni> september
[20:39:29] <jepler> why september?
[20:39:39] <alex_joni> I heard it's a nice month
[20:39:49] <cradek> haha
[20:40:16] <alex_joni> jepler: not wanting to be a smart-ass.. but I think we kinda chose that randomly
[20:40:20] <jmkasunich> sept was what alex and I came up with when we put some of the 2.1 tasks into SF
[20:40:39] <alex_joni> http://sourceforge.net/pm/task.php?group_id=6744&set=custom&group_project_id=46285&_assigned_to=100&_status=1&SUBMIT=Browse
[20:41:13] <jmkasunich> heh, should add lathe stuff to that so cradek can close them
[20:41:14] <alex_joni> the actual release will be 15 oct according to that
[20:41:17] <alex_joni> right
[20:41:30] <jmkasunich> right, feature freeze and test starting in sept
[20:41:42] <cradek> I guess I didn't look at those
[20:41:59] <cradek> I don't even know what some of them mean
[20:42:14] <alex_joni> jepler: guess I/we thought it would be ok to go with ubuntu release cycles
[20:42:48] <alex_joni> cradek: by all means, feel free to adjust/modify/add/remove tasks :D
[20:43:07] <jmkasunich> well, remove should mean they're done, or we decided as a group not to do that
[20:43:39] <alex_joni> ok, then remove after asking around :D
[20:44:56] <alex_joni> oh.. the last list I pasted was for unassigned tasks
[20:45:01] <alex_joni> chose Any to see the whole list
[21:08:27] <alex_joni> night all
[21:10:03] <SWPadnos> see you Alex
[22:23:55] <lilo> [Global Notice] Hi all. As you are aware, we experienced an episode some hours ago in which a staff password was sniffed or cracked. It would be prudent for you to change your nickserv and chanserv passwords at this point. We're continuing to investigate what happened. Thanks for your patience.
