Back
[07:25:19] <jepler> norbert__: If you believe sim_spindle_encoder.hal is wrong I wish you'd say how so that someone could potentially fix it
[07:25:27] <jepler> (I know, a day late on that remark)
[08:53:20] <Tom_itx> probably should say it when he's here too
[09:06:05] <skunkworks> jepler, how is the delta coming?
[09:12:21] <jepler> skunkworks: problems with the extruder that I haven't resolved yet
[09:12:26] <jepler> right now it's not printing
[09:13:48] <jepler> it jammed up while printing the second thing, and I haven't been able to fix it yet
[09:14:25] <jepler> I may need to order some parts or a whole new "hot end", and either way I probably won't be trying another print until after the trip I'm leaving on later this week (maine)
[09:19:04] <skunkworks> Oh - nice. We took a camping trip to maine a few years ago
[09:19:14] <skunkworks> beautiful out there
[09:21:49] <jepler> it should be fun
[09:22:23] <skunkworks> we came in from the canadian side and camped in the mountains
[09:53:00] <jepler> skunkworks: we'll be spending a few days by the coast, then driving down to someplace in mass. close enough to ride the train to boston, then driving up into the mountains in NH. About 9 days in all.
[10:47:55] <seb_kuzminsky> cradek: thanks for sending out the reminder about the irc meeting
[10:56:49] <cradek> sure
[10:57:45] <cradek> archivist: I don't understand most of your response to my message
[10:59:20] <archivist> its on the dev list only, channel name includes a # on freenode
[10:59:38] <cradek> I did send it to both lists
[10:59:58] <cradek> ah, you're right, please add the # so it's more clear
[11:00:00] <archivist> I only noticed it on one sorry
[11:00:19] <zultron_> Whoops, did you already send one? :P My mail client doesn't always update quickly.
[11:00:32] <cradek> sorry, send what?
[11:00:58] <zultron> IRC meeting reminder. Now we've got two. :)
[11:01:07] <cradek> haha
[11:01:20] <archivist> I still only have one :0
[11:02:01] <cradek> well the headers say I got it right
[11:02:05] <archivist> gmail is bugger for hiding what it thinks are duplicates though
[11:02:20] <zultron> Mine *just* went out. Anyway, cradek's is the best one & thread already begun.
[11:02:23] <cradek> fuck gmail
[11:02:56] <cradek> I hope people don't copy over tabled items wholesale (those where no discussion has happened over the last month), but whatever
[11:03:35] <zultron> I'm ok if they copy them over wholesale simply so they don't get dropped.
[11:03:54] <zultron> If they're no longer relevant, we can move to throw them out. :)
[11:05:01] <archivist> wholesale repetition of the same thing time and time again in meetings.....I hate that :)
[11:05:19] <zultron> Then let's throw them out!
[11:05:33] <zultron> I don't want to waste time either, don't get me wrong. :)
[11:06:28] <cradek> jmk also thinks the copy should happen (but I notice he didn't do it)
[11:06:38] * cradek shrugs
[11:20:26] <cradek> who would present the argument for the things that are previously tabled but then copied to the new agenda?
[11:20:53] <cradek> in june, the person who added the item presented the argument
[14:51:18] <seb_kuzminsky> jthornton: i'm sympathetic to getting rid of our half-baked translations, but i'm not sure what you're proposing exactly
[14:58:34] <seb_kuzminsky> i don't love the po system we use for translating strings in the software, but i like it much better than our "copy and ignore (except for french)" method of translating the docs
[14:58:59] <seb_kuzminsky> i've been meaning to look more at po4a (
http://po4a.alioth.debian.org/) but i haven't started playing with it yet
[15:05:27] <cradek> no solution to this problem doesn't suck :-/
[15:07:09] <mhaberler> jepler: still around?
[15:12:33] <mhaberler> delaying to rtapi_init() unfortunately does not solve the problem
[15:13:43] <mhaberler> the issue is: your sim api rests on the assumption rtapi_shm*() and friends work in isolation, and it doesnt matter who inits the HAL data segment (ulapi or rt environment)
[15:14:55] <jepler> that is OK to give up, because the rtai implementation never acted that way
[15:15:49] <mhaberler> I am talking your e30812ef6
[15:16:22] <mhaberler> oh I see - you get the error only if you do hal_init()
[15:16:48] <mhaberler> you do not assume it will work the way sim does in v2.5 onwards (without realtime) which isnt the same thing
[15:17:17] <mhaberler> well that certainly can be done, the dummy rtapi_switch idea works as conceived
[15:17:54] <jepler> since I don't have the code in front of me nor the test results I can only take your word for it
[15:18:53] <mhaberler> ok, lets narrow this down: what this means is: you can link any program and run it without realtime start; as soon as you do a hal_init() (actually an rtapi_init()) you get an error return -ENOSYS
[15:19:25] <mhaberler> that should take care of the runtests issue for rs274
[15:19:40] <jepler> isn't that approximately what happens (modulo the specific -errno) in rtai in v2.5_branch? if so that seems like what I am asking for
[15:20:03] <mhaberler> pretty much so, I just tried that to be bug compatible
[15:20:13] <mhaberler> it does a segfault though which I wont emulate ;)
[15:20:15] <jepler> It is not a bug that it worked that way
[15:20:30] <mhaberler> sure not, that was a joke
[15:20:48] <jepler> you might also make sure that python -c 'import hal' also works
[15:20:55] <mhaberler> sure will
[15:21:09] <jepler> heck it's dumb but we could codify it in a test
[15:21:34] <mhaberler> it really means component creation doesnt work without realtime start, which is what your change was about
[15:21:53] <mhaberler> (on the ulapi side that is)
[15:22:14] <jepler> that's not the intent of e30812ef at all
[15:22:27] <mhaberler> sure we can; actually what we will get for free - since I will wrap ulapi into a .so - is a standalone rtapi library
[15:22:57] <mhaberler> well but if you trace it - say build sim, dont run realtime, start halcmd - you see it wont fail
[15:23:37] <jepler> that is not true, but since rtai never worked that way it's not the part of the behavior that must be preserved.
[15:24:04] <jepler> errr that is true
[15:24:08] <mhaberler> see
[15:24:17] <mhaberler> that was the one I was talking about
[15:24:53] <mhaberler> well at least we're on the same page now
[15:24:54] <jepler> I sure hope so
[15:25:04] <jepler> it would help if I didn't type the opposite from what I intended
[15:25:29] <mhaberler> that is optional since only dumb folk never adjust positions
[15:27:39] <mhaberler> so this is what I can do, and I think it covers the common page: you can link and run any hal/ulapi client (including python) fine regardless of realtime stopped or not; if realtime not running then hal_init() (or rather the underlying rtapi_init()) will fail and return an appropriate error code
[15:28:00] <mhaberler> acuerdo?
[15:28:49] <jepler> ok
[15:29:04] <mhaberler> great, then we have a go
[15:58:00] <mhaberler> confirmed to work as planned - rs274 works fine without realtime start; halcmd will fail with 'realtime not started' because it creates a halcomp right away
[15:59:02] <mhaberler> python 'import hal' fine; fails at h = hal.component("foo")
[16:25:28] <seb_kuzminsky> the email from Frederic Rible makes me happy
[17:07:59] <cradek> yep that's just great