Back
[00:04:01] -!-
theorbtwo has quit [Ping timeout: 240 seconds]
[00:04:07] theorb is now known as
theorbtwo
[00:07:38] -!-
seb_kuzminsky has quit [Ping timeout: 240 seconds]
[00:16:06] -!-
servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[00:38:26] -!-
dgarr [
[email protected]] has joined #emc-devel
[00:41:52] -!-
Howard has quit [Read error: Connection reset by peer]
[00:45:29] -!-
HDB10 has quit [Client Quit]
[01:01:00] -!-
mhaberler has quit [Ping timeout: 276 seconds]
[01:13:27] -!-
the_wench has quit [Ping timeout: 240 seconds]
[01:14:15] -!-
archivist has quit [Ping timeout: 240 seconds]
[01:20:54] -!-
Dannyboy has quit [Remote host closed the connection]
[01:23:03] -!-
tlab has quit [Ping timeout: 240 seconds]
[01:23:09] -!-
rooks has quit [Quit: So long, and thanks for all the fish.]
[01:24:52] -!-
archivist [
[email protected]] has joined #emc-devel
[01:31:51] -!-
HDB10 has quit [Quit: Ex-Chat]
[01:38:30] -!-
tlab has quit [Ping timeout: 240 seconds]
[01:51:26] -!-
PCW has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
[02:30:29] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[02:48:26] -!-
Valen has quit [Quit: Leaving.]
[02:56:23] -!-
HDB10 has quit [Quit: Ex-Chat]
[03:39:03] -!-
archivist has quit [Ping timeout: 240 seconds]
[03:42:07] -!-
Guest100 has quit [Quit: Visitor from www.linuxcnc.org]
[03:43:59] -!-
EDocToor has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
[03:52:45] -!-
archivist [
[email protected]] has joined #emc-devel
[04:00:00] -!-
Guest100 has quit [Quit: Visitor from www.linuxcnc.org]
[04:08:30] -!-
ries has quit [Quit: ries]
[04:21:27] -!-
archivist has quit [Ping timeout: 240 seconds]
[04:32:00] -!-
SWPadnos has quit [Read error: Connection reset by peer]
[04:32:23] -!-
SWPadnos [
[email protected]] has joined #emc-devel
[04:35:22] -!-
EmcRules_Cad has quit [Quit: Visitor from www.linuxcnc.org]
[04:35:46] -!-
archivist [
[email protected]] has joined #emc-devel
[04:56:42] -!-
tlab has quit [Quit: Leaving]
[04:59:32] -!-
Tom_L has quit []
[05:00:18] -!-
mhaberler [
[email protected]] has joined #emc-devel
[05:02:43] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-412.dsl.airstreamcomm.net] has joined #emc-devel
[05:32:50] -!-
adb has quit [Ping timeout: 240 seconds]
[05:40:27] -!-
LawrenceG has quit [Remote host closed the connection]
[05:56:11] -!-
kb8wmc has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101206122310]]
[05:58:37] -!-
vezza has quit [Quit: Sto andando via]
[05:59:59] -!-
dgarr has quit [Quit: Leaving.]
[06:17:58] -!-
UnderSampled has quit [Read error: Connection reset by peer]
[06:28:27] -!-
psha [
[email protected]] has joined #emc-devel
[06:40:27] -!-
mhaberler has quit [Ping timeout: 265 seconds]
[06:55:03] -!-
nullie has quit [Read error: No route to host]
[06:58:39] -!-
bootnecklad_ has quit [Ping timeout: 240 seconds]
[07:00:10] -!-
mhaberler [
[email protected]] has joined #emc-devel
[07:01:34] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[07:02:06] <mhaberler_> psha: good morning!
[07:16:04] <psha> good morning
[07:16:30] <mhaberler_> how are things - are you working on 'The EMC Book' ;-?
[07:21:27] <psha> yes, trying to choose proper format...
[07:21:37] <psha> that's hard since i was working only with one of them
[07:22:01] <psha> also i've talked with micges and he pointed that there is another nice candidate for glade widgets
[07:22:10] <psha> it's a selectable list (like combobox)
[07:23:24] <mhaberler_> example?
[07:24:27] <psha> any use case of combobox :)
[07:24:35] <mhaberler_> link?
[07:24:47] <psha> technicaly it's just 'always unrolled' combobox
[07:25:13] <psha> for example selectable depth of cut (just guessing)
[07:28:06] <mhaberler_> what do you think re my mail?
[07:38:58] <psha> i think i've to read it first ;)
[07:39:00] <psha> wait a bit
[07:41:44] <psha> hm
[07:42:01] <psha> what would you get from several interp_list's?
[07:42:18] <mhaberler_> switch to a different queue for subs or mid?
[07:42:20] <mhaberler_> mdi
[07:42:25] <psha> and miss all abort commands
[07:42:36] <mhaberler_> that's optional
[07:42:43] <psha> since they'll arive in old queue
[07:42:49] <psha> no
[07:42:54] <psha> they are arrived from NML buffer
[07:42:59] <psha> and then stored into interp_list
[07:43:03] <psha> so you'll get them
[07:44:03] <mhaberler_> I think working with different interp instances is pretty worthless if they all work on the same list
[07:45:21] <psha> i think it's ok if they'll work on same list - if they are different interp instances
[07:45:41] <psha> that list is nothing but path to deliver generated commands for execution
[07:45:54] <mhaberler_> the you'll have to go through contortions like your mdi side queue
[07:46:47] <psha> i think i need to clarify my point
[07:47:09] <psha> what's side queue? it's another interp_list instance but isolated from existing processing functions
[07:47:24] <mhaberler_> right
[07:47:27] <psha> so things stored there are only accessed in mdi_execute_hook and in one switch case
[07:47:42] <psha> functions like readahead_reading don't know anything about it
[07:48:04] <psha> now you introduce other interp_lists
[07:48:05] <psha> but how?
[07:48:11] <psha> providing pointer instead of static var
[07:48:23] <psha> and then i guess you want to swap that pointer with something new
[07:48:30] <psha> and all processing functions will work on new list
[07:48:33] <mhaberler_> yes, the context
[07:48:42] <psha> and what's difference?
[07:48:55] <mhaberler_> I can store the list for later insertion/execution
[07:49:36] <psha> in current design everything work with global interp_list
[07:49:59] <psha> so you either have to redo _every_ function so it'll work with local object
[07:50:18] <psha> or live in fear of polluting your current list with trash
[07:50:38] <mhaberler_> as I said: it affects a total pf 3 files
[07:50:45] <psha> no
[07:51:00] <psha> all you've done - replaced var with pointer
[07:51:03] <mhaberler_> you dont like my ideas ;)
[07:51:28] <psha> yes, that allow you to replace global list with another _global_ list
[07:51:36] <mhaberler_> yes
[07:51:58] <psha> i don't see profit in it :)
[07:52:01] <mhaberler_> however, it could be an instance variable with some more work
[07:52:23] <psha> interp instances (not lists) are sane things
[07:52:29] <psha> since they carry state
[07:52:45] <mhaberler_> they all share the same global state
[07:52:53] <psha> but interp_list owns no state - in most cases it's empty :)
[07:53:21] <psha> consider mdi for example
[07:53:32] <psha> what for i've added side queue?
[07:53:38] <psha> i'm getting message
[07:53:41] <psha> exec plan
[07:53:45] <psha> starting execution
[07:53:54] <psha> i've to wait for completion (with possible rescheds)
[07:54:03] <psha> then i get another exec plan message
[07:54:17] <psha> how your patch may help in this situation?
[07:55:23] <psha> re: share global state: that's problem that have to be fixed... interp_list has neraly zero impact on this as i understand
[07:55:49] <mhaberler_> well that's basically the static _setup struct in interp
[07:56:52] <psha> _setup holds some global settings? or execution stack is stored there too?
[07:57:08] <mhaberler_> pretty much all of it
[07:57:51] <psha> ah, stack is there too
[07:58:29] <psha> i think it may be solved with something like 'forking' current interp into new with copy of _setup structure
[07:58:44] <psha> so it's modifications won't affect original interp
[08:01:27] -!-
mhaberler has quit [Ping timeout: 240 seconds]
[08:01:40] -!-
mhaberler_ has quit [Ping timeout: 260 seconds]
[08:03:25] -!-
mhaberler [
[email protected]] has joined #emc-devel
[08:03:42] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[08:05:25] <psha> using several interp's is really good idea - don't blame me for blindly refusing all your proposals :)
[08:05:51] <psha> but swapable _global_ interp_list is nearly useless as i see it
[08:05:59] <mhaberler> Ok. Stand in corner for two hours, then return ;-)
[08:06:21] <psha> on dried peas? :D
[08:06:38] <mhaberler> that's what my question was about - how do I grind this cat to make it most useful?
[08:06:40] <mhaberler> re: no peas, fire logs
[08:07:59] <mhaberler> that branch was just a balloon to see how much would be affected
[08:08:01] <mhaberler> emccanon woud have to be rewritten to use an instance var
[08:10:54] <mhaberler> re interps: actually I think the harder question is how to deal with setup
[08:10:56] <mhaberler> probably should be able to init from other interp and sync with other instance
[08:12:35] <psha> is sync needed?
[08:13:04] <psha> or only 'fork'?
[08:13:39] <psha> it may be needed for transfering new variable values to parent
[08:13:42] <mhaberler> I guess the point is to start a new interp from existing context, do something, and finish that without affecting other instances, except if directed to
[08:13:44] <psha> or something else?
[08:15:35] <mhaberler> I'm not quite sure
[08:15:37] <mhaberler> synch updates with world model
[08:15:38] <mhaberler> but there's lots of other stuff in setup which is really local interp state (sub stuff for instance)
[08:16:07] <mhaberler> this probably needs more clearly separated into 'world model' and 'interpreter state' structs
[08:17:21] <mhaberler> the former needs to be synced at times
[08:17:23] <mhaberler> the latter probably shouldnt
[08:21:46] <mhaberler> probably there needs to be a concept like 'currently active interpreter' - read as: task works on this fellows list
[08:22:14] <mhaberler> the interp_list instance var is half of that story
[08:28:15] <psha> as i understand interp_list is nothing but temporary storage of recieved commands
[08:28:24] <psha> from outside world
[08:28:29] -!-
pjm has quit [Ping timeout: 240 seconds]
[08:29:33] <psha> and it's not representing interp state
[08:29:42] <mhaberler> definitely, yes
[08:31:02] <psha> so question lies in the field of setup split
[08:31:10] <mhaberler> yes..
[08:39:10] -!-
maximilian_h [
[email protected]] has joined #emc-devel
[08:42:06] -!-
pjm__ has quit [Quit: TTFO]
[08:44:54] <mhaberler> this needs a bit more thought, I think - wrt usage scenarios and side effects
[08:44:56] <mhaberler> hey, need to ru, mundane earthly tasks eat my time :-/
[08:44:58] <mhaberler> ru/run
[08:45:41] <psha> bb
[08:49:30] -!-
mhaberler has quit [Ping timeout: 240 seconds]
[08:49:44] -!-
mhaberler_ has quit [Ping timeout: 250 seconds]
[08:53:29] -!-
psha has quit [Quit: Lost terminal]
[09:05:34] -!-
The_Ball has quit [Ping timeout: 255 seconds]
[09:17:26] -!-
ChavesBrugo has quit []
[09:22:48] -!-
maximilian_h has quit [Quit: Leaving.]
[09:26:21] -!-
the_wench [
[email protected]] has joined #emc-devel
[09:51:43] -!-
robh__ [
[email protected]] has joined #emc-devel
[10:24:48] -!-
micges [
[email protected]] has joined #emc-devel
[10:44:56] -!-
micges has quit [Ping timeout: 255 seconds]
[10:47:23] -!-
micges [
[email protected]] has joined #emc-devel
[10:58:34] -!-
logger[psha] [logger[psha]
[email protected]] has joined #emc-devel
[11:16:23] -!-
mhaberler [
[email protected]] has joined #emc-devel
[11:17:18] -!-
maximilian_h [
[email protected]] has joined #emc-devel
[11:58:08] -!-
micges has quit [Ping timeout: 246 seconds]
[12:00:06] -!-
ries [
[email protected]] has joined #emc-devel
[12:03:48] -!-
mhaberler has quit [Ping timeout: 265 seconds]
[13:04:40] -!-
JT-Shop [
[email protected]] has joined #emc-devel
[13:07:15] -!-
SWPadnos has quit [Changing host]
[13:07:15] -!-
SWPadnos [SWPadnos!~Me@emc/developer/SWPadnos] has joined #emc-devel
[13:36:39] -!-
acemi has quit [Quit: WeeChat 0.3.2]
[13:46:06] -!-
nullie has quit [Quit: Ex-Chat]
[13:49:44] -!-
mhaberler [
[email protected]] has joined #emc-devel
[13:55:08] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[14:05:48] -!-
motioncontrol has quit [Remote host closed the connection]
[14:06:50] -!-
skunkworks has quit [Ping timeout: 260 seconds]
[14:18:35] -!-
Valen has quit [Quit: Leaving.]
[14:32:25] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[14:33:30] -!-
JT-Shop [
[email protected]] has joined #emc-devel
[14:40:52] -!-
KimK [
[email protected]] has joined #emc-devel
[14:45:24] -!-
adb [
[email protected]] has joined #emc-devel
[14:50:42] -!-
adb has quit [Ping timeout: 250 seconds]
[14:53:13] -!-
nullie has quit [Quit: Ex-Chat]
[15:20:46] -!-
adb [
[email protected]] has joined #emc-devel
[15:24:43] -!-
awallin_ [awallin_!~quassel@2001:708:110:1020:224:7eff:feda:7c7d] has joined #emc-devel
[15:40:10] -!-
kb8wmc has quit [Client Quit]
[15:53:37] <CIA-53> EMC: 03jepler 07master * r2eecc03f439c 10/debian/configure: packaging: debian testing renamed to 6.0
[16:26:28] -!-
maximilian_h [
[email protected]] has parted #emc-devel
[16:27:13] -!-
awallin_ has quit [Remote host closed the connection]
[16:27:14] -!-
ewidance [
[email protected]] has joined #emc-devel
[16:30:43] -!-
nullie has quit [Quit: Ex-Chat]
[16:39:40] -!-
Tom_L has quit [Client Quit]
[17:04:39] -!-
micges [
[email protected]] has joined #emc-devel
[17:27:28] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100423140709]]
[17:35:41] -!-
EmcRules_Cad has quit [Quit: Visitor from www.linuxcnc.org]
[17:45:28] -!-
isssy has quit [Quit: Visitor from www.linuxcnc.org]
[17:46:37] -!-
mozmck has quit [Quit: Leaving.]
[17:57:30] -!-
psha [
[email protected]] has joined #emc-devel
[17:58:20] <psha> mhaberler: here?
[17:58:23] -!-
logger_dev has quit [Ping timeout: 264 seconds]
[17:58:24] -!-
Connor_CNC has quit [Ping timeout: 264 seconds]
[17:58:24] -!-
rooks has quit [Ping timeout: 264 seconds]
[17:58:25] -!-
i_tarzan has quit [Ping timeout: 264 seconds]
[17:58:25] -!-
L84Supper has quit [Ping timeout: 264 seconds]
[17:58:26] -!-
jmkasunich has quit [Ping timeout: 264 seconds]
[17:58:27] -!-
jmkasunich [
[email protected]] has joined #emc-devel
[17:58:27] -!-
jmkasunich has quit [Changing host]
[17:58:27] -!-
jmkasunich [jmkasunich!~jmkasunic@emc/board-of-directors/jmkasunich] has joined #emc-devel
[17:58:36] <mhaberler> da, tovarish!
[17:58:48] <psha> :)
[17:58:54] <psha> [ 6071.596980] gladevcp[3750]: segfault at 8 ip 0013b6cc sp bfce8ce0 error 6 in libemchal.so.0[136000+8000]
[17:59:06] <psha> how to overcome this error on RT system?
[17:59:16] <psha> 2.5 RIP, 2.4 from livecd
[17:59:39] <psha> i've seen you was talking with JT about this error
[18:00:02] <mhaberler> dont remember, but anyway
[18:00:19] <psha> you need to setup hal somehow
[18:00:22] <psha> i guess
[18:01:47] <mhaberler> no, I would attach gdb to the process
[18:01:48] <mhaberler> disassemble before the errored address
[18:01:50] <mhaberler> the symbols should give a clue which function this is
[18:01:51] <mhaberler> very likely you'll feel embarassed immediately ;-)
[18:02:10] <mhaberler> need to disassemble instruction mode thouch
[18:02:32] <mhaberler> is it reproducable for a mortal like me? I'd give it a stab
[18:02:53] <mhaberler> there is some text on rt debugging on the wiki
[18:03:09] <psha> heh
[18:03:12] <mhaberler> but this one is in a .so not in kernel
[18:03:16] <psha> it's just error with unloaded hal modules
[18:03:29] <mhaberler> make me understand you
[18:03:59] <mhaberler> when and where does it happen?
[18:04:27] <micges> doc about debugging is in emc-src/docs/rtfaults.txt
[18:04:44] <micges> you should be able to debug *.so also
[18:04:53] <mhaberler> aja
[18:04:54] <mhaberler> but then its userland
[18:05:36] <psha> that's simple hal.component() bug!
[18:05:38] <psha> nothing serious
[18:06:51] <mhaberler> actually looking at the libemchal.so symbol table might give you a clue already
[18:06:53] <mhaberler> I guess the faulting insn is offset b36cc from text segment start
[18:07:29] <psha> RTAPI: ERROR: could not open shared memory (errno=2)
[18:07:30] <psha> Segmentation fault
[18:08:07] <mhaberler> a, my crystal ball says emchal tries to deref into shared memory which aint there
[18:08:43] <psha> /etc/init.d/realtime start
[18:09:01] <psha> i've already loaded iso in kvm :)
[18:09:21] <psha> is there equivalent of 'realtime start' for RIP?
[18:09:34] <mhaberler> iso.. kvm... duh.
[18:09:58] <mhaberler> I dont think that's needed
[18:10:00] -!-
motioncontrol has quit [Ping timeout: 272 seconds]
[18:10:06] <psha> mhaberler: it's a virtualization system
[18:10:13] <mhaberler> could be its done through userland pthreads or so
[18:11:12] <mhaberler> in german we call it Aküfi, which stands for Abkürzungsfimmel, or Abbreviation madness (note nice recursive definition ;-)
[18:12:32] <mhaberler> but I guess all you need is gdb to nail that one, if you can load the failing component's main into gdb
[18:12:39] -!-
ries has quit [Read error: Connection reset by peer]
[18:23:47] <psha> all i needed was 'realtime start' :)
[18:24:01] <mhaberler> hm. duh. sorry
[18:24:06] -!-
skunkworks [
[email protected]] has joined #emc-devel
[18:26:43] -!-
EmcRules_Cad has quit [Ping timeout: 240 seconds]
[18:33:20] -!-
KimK has quit [Quit: Leaving]
[18:35:34] <psha> jepler: i've not found how to fix external links in rst but i've found very useful instruction in asciidoc for included documents
[18:35:46] -!-
KimK [
[email protected]] has joined #emc-devel
[18:36:03] <psha> you may say 'shift all sections in subsequent included docs for some levels'
[18:36:13] <psha> and normal standalone docs will be included properly
[18:43:09] <mhaberler> psha: I'm beginning to understand why tx and m6 on seperate lines work fine and txm6 on a single line breaks... the first o-sub sets the return point to beginning of next line because there's supposed to be only one osub call per line... which makes it skip the second call ... aaaaaaaaaarggg
[18:43:31] -!-
motioncontrol has quit [Ping timeout: 265 seconds]
[18:43:57] <mhaberler> this oword stuff is so broken..
[18:45:12] -!-
LawrenceG [
[email protected]] has joined #emc-devel
[18:47:19] <micges> jepler: proposed patch: fix clearing dacs of motenc card at shutown:
http://pastebin.com/2FjzxcgW
[18:47:41] <micges> jepler: I think this should go to 2.4 branch
[18:51:06] -!-
vezza has quit [Client Quit]
[18:52:46] <micges> seb_kuzminsky: I got this one while push: git_buildbot: ERROR: Could not connect to buildbot.linuxcnc.org:5133: Connection was refused by other side: 61: Connection refused.
[18:59:36] <CIA-53> EMC: 03micges 07master * r6b81de9ccf3c 10/scripts/.gitignore: Add latencyplot to .gitignore
[19:01:01] <cradek> micges: definitely for 2.4 - if DAC_CHANNELS < MAX_DEVICES I think the loop will never exit
[19:01:38] <cradek> (well, it's currently not)
[19:01:48] <cradek> but still, that loop is all kinds of wrongness
[19:01:55] <micges> ok
[19:02:23] <cradek> how did you find the problem?
[19:04:31] <micges> was looking for card simmilar to mesa with some adc channels
[19:04:39] <micges> I've found motenc
[19:04:52] <micges> and I want to know who did the driver
[19:04:57] <cradek> oh good - nice that a developer has one
[19:05:05] <cradek> so you could even test this fix
[19:05:16] <cradek> you could try looking at the top of the file :-)
[19:05:58] <micges> and I looked at all commits to driver and spot this bug
[19:07:22] -!-
ries [
[email protected]] has joined #emc-devel
[19:08:50] <cradek> now I'm checking all the other loops for silly mistakes
[19:09:07] <psha> mhaberler: notice that even if python-gtkglext1 is in debian/control deps it is not installed when you build RIP
[19:09:20] <mhaberler> hm, why?
[19:09:42] <cradek> because it has nothing to do with apt
[19:09:53] <cradek> I mean, RIP doesn't
[19:09:53] <mhaberler> excellent point ;-)
[19:10:18] <cradek> (rightfully, imo)
[19:10:29] <psha> mhaberler: btw here is same problem as i mentioned already
http://thread.gmane.org/gmane.linux.distributions.emc.user/25073/focus=25110
[19:11:15] <mhaberler> sure. bugger
[19:11:16] <mhaberler> ok, that needs to go to the wiki build from source instructions; affects others too (configobj, python-xlib and friends)
[19:11:48] <psha> yes
[19:12:04] <mhaberler> hm, actually it should eventually come in through emc-build-dep?
[19:12:05] <psha> and this (shared memory bug) has to go to troubleshooting
[19:12:11] <psha> no
[19:12:24] <psha> build deps are calculated from available source package
[19:12:25] <cradek> it would be good to say where to find a list of deps corresponding to your source tree
[19:12:30] <psha> and that's will be 2.4.6 deb src
[19:13:18] <cradek> micges: I didn't find any other loop problems in motenc source
[19:13:27] <mhaberler> aha. well lets cons up a apt-get line which doesnt hurt and pull in the whole mishpoche
[19:14:55] <mhaberler> I guess that's all staring from -tk:
[19:14:56] <mhaberler> python@PYTHON_VERSION@-gnome2, python@PYTHON_VERSION@-glade2,
[19:14:58] <mhaberler> python@PYTHON_VERSION@-numpy | python-numpy,
[19:14:59] <mhaberler> python@PYTHON_VERSION@-imaging,
[19:15:00] <psha> also i think gladevcp have to work even without deps
[19:15:01] <mhaberler> python@PYTHON_VERSION@-imaging-tk | python-imaging-tk,
[19:15:02] <mhaberler> python-xlib, python-gtkglext1, python-configobj,
[19:15:14] <micges> cradek: me either but I'll recheck all again
[19:15:21] <cradek> can't hurt
[19:15:28] <cradek> so you don't have the card yet?
[19:15:34] <mhaberler> psha: interesting indian rope trick
[19:15:36] <psha> just guard imports of hal_gremlin and hal_sourceview
[19:15:44] <cradek> you might bother pcw about adcs - lots of people ask about them.
[19:15:49] <psha> with 'except ImportError'
[19:16:10] <micges> cradek: yes I was also asked him :)
[19:16:31] <mhaberler> you mean drop support for those when packages not available?
[19:16:52] <micges> I don't have card yet, my friend ordered it and asked for help with setup
[19:17:24] <cradek> I think at least a few people are actively using them (always because they need adc, I think)
[19:17:34] <cradek> edm folks for instance
[19:18:05] <psha> mhaberler: yes
[19:18:13] <psha> with warning
[19:18:28] <mhaberler> sounds good
[19:18:29] <psha> glade would not load them
[19:18:41] <psha> and if you try to load UI with them it will fail too
[19:19:12] <mhaberler> and the imports are done when RIP is off?
[19:20:08] <psha> RIP or not - not important
[19:20:39] -!-
tlab has quit [Ping timeout: 240 seconds]
[19:20:40] <mhaberler> duh
[19:20:54] <mhaberler> so, only when installing a .deb
[19:21:05] -!-
ewidance has quit [Quit: ewidance]
[19:21:59] -!-
DaViruz has quit [Ping timeout: 255 seconds]
[19:24:23] -!-
coldelectrons has quit [Ping timeout: 240 seconds]
[19:28:11] -!-
mozmck [mozmck!~moses@client-173.225.233.241.dfwtx.partnershipbroadband.com] has joined #emc-devel
[19:29:53] <mhaberler> psha: python-imaging is for your camview stuff?
[19:30:51] <mhaberler> numpy too, I assume?
[19:32:32] <psha> python-imaging is not mine req
[19:32:48] <psha> camview is external package
[19:33:05] <mhaberler> hm, could be preview
[19:33:09] <psha> i've added only gtkglext1 (really it's jeff) and gtksourceview2
[19:33:18] <psha> i guess it's for image2gcode
[19:33:27] <mhaberler> aja
[19:33:41] <mhaberler> darn, we'll leave them all in, doesnt hurt.
[19:34:28] -!-
tom3p [
[email protected]] has joined #emc-devel
[19:35:12] <mhaberler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?GladeVcpSetup
[19:37:42] <psha> imaging and numpy may be replaced with gtksourceview2
[19:38:06] <mhaberler> ok
[19:38:29] <jepler> micges: that patch is OK to push to v2.4_branch
http://pastebin.com/2FjzxcgW
[19:38:30] <psha> they are in 2.4 deb deps so they are already installed if emc2 is there
[19:38:36] <jepler> particularly if you can test it on actual hardware
[19:39:14] <mhaberler> but they wont be there if the user starts with a 2.5 master source install
[19:39:24] <mhaberler> delete 2.5
[19:41:03] <jepler> you can check the build deps of any particular tree against your running debian system: debian/configure -r OR debian/configure sim, then dpkg-checkbuilddeps
[19:41:14] <jepler> .. if they are up to date, which I strongly desire to be the case
[19:43:27] -!-
fsr_ [
[email protected]] has joined #emc-devel
[19:44:01] <mhaberler> hm, maybe such an incantation would be helpful in the Installing_EMC2 section
[19:45:13] <mhaberler> I'll add it
[19:47:31] -!-
L84Supper2 has quit [Quit: puff of smoke]
[19:48:47] -!-
L84Supper has quit [Changing host]
[19:58:43] -!-
L84Supper has quit [Quit: puff of smoke]
[20:00:59] <mhaberler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2 sections 2.12 and 2.13
[20:02:39] <seb_kuzminsky> micges: thanks, i see it too... hmm
[20:04:33] <CIA-53> EMC: 03micges 07v2.4_branch * r364a37fb5ef1 10/src/hal/drivers/hal_motenc.c: hal_motenc: fix setting dacs and outputs to zero on exit
[20:06:44] <micges> guys digital in and out hal names on motenc don't follow hal canonilcal reference docs
[20:16:50] -!-
seb_kuzminsky has quit [Ping timeout: 240 seconds]
[20:17:03] <JT-Shop> are the docs wrong?
[20:17:52] <micges> docs are ok
[20:18:18] <JT-Shop> ok
[20:25:45] -!-
emc2-buildmaster [
[email protected]] has joined #emc-devel
[20:27:24] <micges> cradek: I propose after making 2.5 branch and merging ja3 to master, fixing all hal drivers, modules etc to follow hal canonical naming scheme
[20:28:41] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[20:28:45] <mhaberler> psha: short of rewriting the o-word call code to support multiple calls per line, it seems easier to call them like an MDI o-word call. Aproved?
[20:29:26] <seb_kuzminsky> micges: the buildbot problem was a messed-up routing table on the buildmaster vm
[20:29:30] <seb_kuzminsky> should be fixed now
[20:29:45] <micges> cool, thanks
[20:31:54] -!-
emc2-buildmaster has quit [Quit: buildmaster reconfigured: bot disconnecting]
[20:32:03] <seb_kuzminsky> bounce the machine to see if it comes up right now
[20:32:28] -!-
emc2-buildmaster [
[email protected]] has joined #emc-devel
[20:32:39] <seb_kuzminsky> lucid reboots fast :-)
[20:32:55] <seb_kuzminsky> no, hm, that's still wrong
[20:37:36] <skunkworks> Like I say - I think the bios splash screen is up about the same amount of time that the os take to boot.
[20:37:37] -!-
micges has quit [Read error: Connection reset by peer]
[20:37:39] -!-
emc2-buildmaster has quit [Quit: buildmaster reconfigured: bot disconnecting]
[20:37:51] -!-
micges [
[email protected]] has joined #emc-devel
[20:37:55] -!-
emc2-buildmaster [
[email protected]] has joined #emc-devel
[20:38:50] -!-
mhaberler_ has quit [Ping timeout: 240 seconds]
[20:39:08] <seb_kuzminsky> the new buildmaster machine is a multihomed vm, with one nic facing a virtual network with the buildslave VMs, and the other nic facing my local net in my house
[20:39:28] -!-
mhaberler has quit [Ping timeout: 255 seconds]
[20:39:58] <seb_kuzminsky> /etc/network/interfaces created a default route to each of the two nics, the virtual network won, so syn-acks to non-localnet ips went to the virtuam build cluser network
[20:40:31] <micges> logger[psha]: hi
[20:41:33] <seb_kuzminsky> quick, someone commit something to test it!
[20:42:36] <seb_kuzminsky> \/e/n/i doesnt let you turn off default routes afaik, but it does let you set the metric, per interface
[20:43:44] <seb_kuzminsky> i think the gearchange.comp in master needs some attention
[20:44:02] <seb_kuzminsky> i tried to upgrade a machine that uses gearcomp from 2.4 to master, and it totally broke
[20:44:20] <seb_kuzminsky> the commit of the new gearchange claims that it's backwards compatible, but it's not
[20:44:43] <seb_kuzminsky> the manpage does not claim general backwards compatibility, but notes a couple of specific points of compatibility
[20:45:30] <seb_kuzminsky> some of the discrepancies should be recorded in a new UpdatingTo2.5 wiki page, but some i think are bugs
[20:46:04] <seb_kuzminsky> if you don't change the loadrt line from 2.4, you get 3 gears instead of 2
[20:46:15] <seb_kuzminsky> in 2.4 the gears are numbered starting at 1, in 2.5 they start at 0
[20:46:48] <seb_kuzminsky> the .scale pin is used in the reciprocal way compared to what it used to be (this is described correctly in the manpage, but it's opposite from 2.4)
[21:01:38] -!-
mhaberler [
[email protected]] has joined #emc-devel
[21:04:58] <psha> mhaberler: 'macro substitution' way for M6/T commands failed?
[21:05:40] <psha> i've fixed installation page - i've posted invalid package name
[21:06:29] <mhaberler> that's still what I pursue; the question is how to execute it
[21:06:30] <mhaberler> when macro substitution results in two oword sub calls due to replacment, major breakage results because of the one-oword-call-per-line assumption
[21:08:23] -!-
EmcRules_Cad has quit [Ping timeout: 240 seconds]
[21:23:18] -!-
fsr_ has quit [Ping timeout: 250 seconds]
[21:26:23] -!-
elmo40 has quit [Ping timeout: 240 seconds]
[21:30:16] <psha> jepler: example of external links
[21:30:18] <psha> http://psha.org.ru/tmp/adoc/part1.html
[21:30:20] <psha> http://psha.org.ru/tmp/adoc/part2.html
[21:30:35] <psha> done using simple script and small config file
[21:31:43] -!-
pjm has quit [Ping timeout: 265 seconds]
[21:32:40] -!-
mhaberler has quit [Ping timeout: 272 seconds]
[21:34:38] -!-
fsr_ [
[email protected]] has joined #emc-devel
[21:35:22] -!-
mhaberler [
[email protected]] has joined #emc-devel
[21:53:38] -!-
coldelectrons has quit [Ping timeout: 250 seconds]
[21:54:40] <psha> it's done only for xhtml though...
[21:55:03] <psha> for docbook based rendering it's better to pick something from docbook-xsl land
[21:55:13] <psha> but i'm not confident there...
[21:58:17] -!-
fsr_ has quit [Quit: Ex-Chat]
[22:08:39] -!-
mikeggg has quit [Read error: Connection reset by peer]
[22:19:43] -!-
xcncx has quit [Client Quit]
[22:20:06] -!-
motioncontrol has quit [Quit: Sto andando via]
[22:35:03] <jepler> psha: when creating html output, can either of these systems do multipage documents in which cross-links just work? Back when using latex2html I had trouble getting LyX to output .tex files that worked right when included (they had \end{document} at the bottom), so I did it the way it's done now, one document per html page
[22:35:32] <jepler> if the toolchain is better and can work by inclusion of multiple inputs followed by splitting to multiple outputs for html, that's fine too
[22:49:14] <psha> i've created 3 docs - two parts (part1, part2) with cross references (part1 -> part2 and reverse)
[22:49:52] <psha> then i've built parts with 'substitute foreign links' configs (it's just overrides handling of xrefs and leaves everything else)
[22:50:13] <psha> whole document was compiled in stock mode - with all references treated as internal
[22:50:54] <psha> other way i've found is using 'olink's in docbook - but i don't know docbook enought
[22:52:50] -!-
Fox_Muldr has quit [Ping timeout: 276 seconds]
[22:59:41] <psha> so i think for asciidoc anwser is 'yes': with some limitations it may be used to build proper multipart and single-part documents from one source
[23:00:23] <psha> limitations - cross reference links are either internal (all) or external (all)
[23:00:37] <psha> but external xref pointing back to same document is harmless i guess
[23:02:27] -!-
mhaberler has quit [Ping timeout: 276 seconds]
[23:05:23] -!-
mhaberler [
[email protected]] has joined #emc-devel
[23:06:37] -!-
odiug has quit [Ping timeout: 255 seconds]
[23:09:58] <psha> also it may be fixed (e.g internal xrefs) but comparing current doc name with xref table
[23:14:36] -!-
tom3p [
[email protected]] has parted #emc-devel
[23:30:31] <psha> i believe that rst may be better suited in very-very-very-long term perspective but now asciidoc seems better
[23:30:57] <psha> it has limited _complex_ extensibility, but nearly unlimited in simple extensions
[23:44:38] -!-
mhaberler has quit [Ping timeout: 265 seconds]
[23:48:02] -!-
Roguish [
[email protected]] has joined #emc-devel