Back
[00:10:27] -!- rob_h has quit [Ping timeout: 245 seconds]
[00:24:13] -!- tjb1 has quit [Ping timeout: 276 seconds]
[00:28:46] -!- tjb1_ has quit [Ping timeout: 276 seconds]
[00:32:40] -!- tjb1 has quit [Ping timeout: 276 seconds]
[00:35:47] -!- jmk-mcfaul [jmk-mcfaul!~jmkasunic@adsl-75-33-35-218.dsl.bcvloh.sbcglobal.net] has joined #linuxcnc3
[00:37:58] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:42:48] -!- adb has quit [Remote host closed the connection]
[00:43:30] -!- logger[mah] has quit [Remote host closed the connection]
[00:45:20] -!- logger[mah] [logger[mah]!~loggermah@mah2.mah.priv.at] has joined #linuxcnc3
[00:54:10] -!- mhaberler has quit [Quit: mhaberler]
[00:59:03] -!- plushy has quit [Quit: Leaving.]
[01:06:33] -!- atom1 has quit [Changing host]
[01:10:49] -!- zzolo has quit [Client Quit]
[01:17:03] -!- cmorley has quit [Ping timeout: 256 seconds]
[01:18:20] -!- JesusAlos has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]]
[01:21:25] -!- jmk-mcfaul has quit [Quit: Ex-Chat]
[01:25:33] -!- Teht has quit [Quit: Page closed]
[01:30:37] -!- atom1 has quit [Quit: Leaving]
[01:32:03] -!- Thetawaves has quit [Quit: Leaving]
[01:39:22] -!- joe9 has quit [Quit: leaving]
[01:44:34] -!- joe9 has quit [Client Quit]
[01:45:14] -!- dimas has quit [Ping timeout: 252 seconds]
[02:07:05] -!- micges has quit [Quit: Leaving]
[02:12:45] -!- mattions has quit [Read error: Operation timed out]
[02:16:02] -!- cmorley1 has quit [Ping timeout: 252 seconds]
[02:39:08] -!- ravenlock has quit [Ping timeout: 252 seconds]
[02:58:30] -!- tjtr33 has quit [Read error: Connection reset by peer]
[03:02:02] -!- Connor1 has quit [Remote host closed the connection]
[03:26:39] -!- nOStahl has quit [Quit: nOStahl]
[03:35:03] -!- AFarnsworth has quit [Ping timeout: 245 seconds]
[03:43:06] -!- tjb1 has quit [Quit: tjb1]
[04:03:17] -!- AFarnsworth has quit [Quit: Page closed]
[04:07:23] -!- toxx has quit [Remote host closed the connection]
[04:16:23] -!- cmorley has quit [Ping timeout: 255 seconds]
[04:18:03] -!- skorasaurus has quit [Ping timeout: 245 seconds]
[04:23:33] -!- L84Supper has quit [Quit: <puff of smoke>]
[04:30:20] Connor1 is now known as Connor_CNC
[04:39:10] -!- Valen has quit [Quit: Leaving.]
[04:59:15] -!- Thetawaves_ has quit [Remote host closed the connection]
[05:01:02] -!- sumpfralle has quit [Ping timeout: 252 seconds]
[05:16:11] -!- hashfail has quit [Read error: Connection reset by peer]
[05:23:15] -!- ve7it has quit [Remote host closed the connection]
[05:33:45] -!- FinboySlick has quit [Quit: Leaving.]
[05:55:45] hdokes is now known as hdokes_snoooozin
[06:02:15] -!- Fox_Muldr has quit [Ping timeout: 260 seconds]
[06:19:55] -!- hashfail has quit []
[06:21:12] -!- i_tarzan has quit [Ping timeout: 264 seconds]
[06:25:30] hdokes_snoooozin is now known as hdokes
[06:33:59] -!- i_tarzan has quit [Ping timeout: 244 seconds]
[06:38:43] -!- tandoori has quit [Read error: Connection reset by peer]
[06:39:09] -!- tandoori has quit [Changing host]
[06:50:31] -!- Connor_CNC has quit [Quit: Leaving.]
[07:01:19] -!- tandoori has quit [Read error: Connection reset by peer]
[07:02:32] -!- tandoori has quit [Changing host]
[07:02:38] -!- pcw_home has quit [Ping timeout: 246 seconds]
[07:12:54] -!- davec has quit [Ping timeout: 252 seconds]
[07:13:12] -!- Keknom has quit [Quit: Leaving.]
[07:24:42] -!- capricorn_1 has quit [Quit: Konversation terminated!]
[07:42:55] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc3
[08:04:56] -!- jpk has quit [Quit: Leaving.]
[08:14:01] -!- racycle has quit [Quit: racycle]
[08:35:06] -!- rob_h [rob_h!~rob_h@5e0860c9.bb.sky.com] has joined #linuxcnc3
[08:40:08] -!- shurshur has quit [Remote host closed the connection]
[08:45:13] -!- mozmck has quit [Ping timeout: 244 seconds]
[09:54:08] -!- plushy has quit [Quit: Leaving.]
[10:27:00] -!- JT-Shop has quit [Read error: Connection reset by peer]
[10:29:36] -!- hashfail has quit [Ping timeout: 245 seconds]
[10:32:06] -!- sirdancealot1 has quit [Ping timeout: 245 seconds]
[10:48:22] -!- odogono has quit [Quit: odogono]
[11:51:52] -!- V0idExp has quit [Read error: Connection reset by peer]
[12:06:08] -!- dhoovie has quit [Read error: Connection reset by peer]
[12:39:25] -!- mhaberler_ [mhaberler_!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc3
[12:41:11] -!- Valen has quit [Quit: Leaving.]
[12:42:08] -!- mhaberler has quit [Ping timeout: 256 seconds]
[12:42:09] mhaberler_ is now known as mhaberler
[13:04:08] -!- Wildhoney has quit [Client Quit]
[13:05:26] -!- Wildhoney has quit [Client Quit]
[13:13:57] -!- V0idExp1 has quit [Ping timeout: 248 seconds]
[13:19:18] -!- putnik has quit [Quit: leaving]
[13:24:21] -!- putnik has quit [Client Quit]
[13:24:34] putnik_ is now known as putnik
[13:42:46] hdokes is now known as hdokes_snoooozin
[13:48:49] -!- JesusAlos has quit [Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]]
[13:49:53] hdokes_snoooozin is now known as hdokes
[13:57:45] -!- mattions has quit [Read error: Operation timed out]
[14:49:57] -!- gmag has quit [Ping timeout: 248 seconds]
[14:59:03] JT-Shop-2 is now known as JT-Shop
[15:12:07] -!- jmk-mcfaul [jmk-mcfaul!~jmkasunic@adsl-75-33-35-218.dsl.bcvloh.sbcglobal.net] has joined #linuxcnc3
[15:12:31] <jmk-mcfaul> mhaberler, hello
[15:12:44] <mhaberler> Hi John!
[15:13:11] <jmk-mcfaul> got your email and thought this might be more efficient than mail
[15:13:21] <mhaberler> great
[15:13:30] <mhaberler> waht do you think overall?
[15:14:17] <jmk-mcfaul> I have some big-picture questions (even before today's mail), I want to understand a bit better what the goals are
[15:14:46] <jmk-mcfaul> it sounds like the goal is to allow non-realtime HAL components to live on a different computer than the realtime ones
[15:15:12] <mhaberler> yes, cordon off RT part, and break 'single CPU' limitation
[15:15:37] <mhaberler> to also free frontends from RT limitations
[15:15:42] <jmk-mcfaul> when HAL was first integrated into EMC, that would have actually been easier than it is now
[15:16:01] <jmk-mcfaul> motion was the only LCNC part that connected to HAL
[15:16:11] -!- L84Supper has quit [Quit: <puff of smoke>]
[15:16:21] <jmk-mcfaul> the non realtime parts of LCNC talked only to motion
[15:16:28] <mhaberler> hm, no going back I guess
[15:16:42] <jmk-mcfaul> but then we got VCP, and HALUI stuff
[15:17:00] <mhaberler> well that was basically a NML bypass operation IMV
[15:17:19] <jmk-mcfaul> yes - because of the things you mentioned - NML is compile time binding
[15:17:20] <mhaberler> folks rather dealt with HAL than NML, understandably
[15:17:47] <mhaberler> I think I retroactively understand how it came about
[15:18:06] <jmk-mcfaul> NML came first, in 1995 or so
[15:18:24] <mhaberler> right, it was very early 'middleware'
[15:18:27] <jmk-mcfaul> HAL was a way to get late binding at the hardware driver level
[15:18:46] <jmk-mcfaul> HAL turned out to be usable for more than just hardware drivers
[15:18:49] <mhaberler> well if for HAL linuxcnc wouldnt be around anymore I guess
[15:19:10] <jmk-mcfaul> I bet it would
[15:19:32] <mhaberler> that is by any measure the strongest part, both in terms of configurability as also code quality and design, kudos
[15:19:33] <jmk-mcfaul> mach doesn't have a HAL-like thing, and it is still around
[15:19:45] <jmk-mcfaul> thank you (blush)
[15:19:49] <mhaberler> you know I#ve been dablling with the interpreter too, so I can tell
[15:21:02] <jmk-mcfaul> anyway, if I understand correctly, you aim to keep motion on the RT computer, correct?
[15:21:07] <mhaberler> I think the whole thing is quite doable with my current choice of support packages; it is next to impossible without (I mean NML alone is some 36k lines)
[15:21:11] <mhaberler> yes, definitely
[15:21:25] <mhaberler> the task/motion interface will go messaging, too
[15:21:34] <mhaberler> it almost is (usrmotif)
[15:21:46] <jmk-mcfaul> so there are two things that would have to travel over the network. task<-->motion and the HAL stuff that is used elsehwere, like VCP
[15:21:57] <mhaberler> (I have to admit a second planned attack.. but later.)
[15:22:27] <mhaberler> yes, plus any explicit hal setsig operations from GUIs for instance
[15:22:50] <jmk-mcfaul> stand by a second while I look for something
[15:23:01] <mhaberler> the other direction _into_ HAL if you will
[15:23:13] <jmk-mcfaul> yes, that will be needed
[15:23:43] <mhaberler> I just wrote up protobuf command.proto for that...
[15:24:06] <mhaberler> but yes, it's these three channels, plus the error channel
[15:24:49] -!- maurog has quit [Client Quit]
[15:24:59] <jmk-mcfaul> meh, I can't find what I was looking for
[15:25:14] <mhaberler> about what issue?
[15:25:21] <jmk-mcfaul> several years ago we were talking idly about emc3, and I drew up some block diagrams
[15:25:33] <mhaberler> oh. hand those over ;)
[15:25:41] <jmk-mcfaul> can't find them :(
[15:25:41] <mhaberler> now! ;)
[15:25:50] <mhaberler> will come, I assume
[15:25:57] <jmk-mcfaul> I will look later
[15:26:07] <mhaberler> doesnt matter
[15:26:19] <jmk-mcfaul> they are on the PC I was using for emc development back then
[15:26:30] <mhaberler> I would like to address the following themes:
[15:27:07] <mhaberler> namespace and glueing messaging into the HAL conceptual model, as I talked about in my last mail
[15:27:49] <mhaberler> 2) communication pattern & separation from encoding and support mechanism (I'll explaint that later)
[15:27:59] <mhaberler> the namespace thing is my #1 issue
[15:28:27] <mhaberler> I think we need something like a 'remote signal/pin link' concept
[15:29:10] <mhaberler> right now neither observers like halreport, or setters like the rpcserver for setsig ops will be visible at the halcmd layer
[15:29:29] <mhaberler> which is, uh, suprising
[15:29:31] <mhaberler> a signal changed and no writer? duh
[15:30:08] <mhaberler> but if it can be tagged with the remote setter (say gladevcp instance X) then there's a trace
[15:30:28] <mhaberler> same goes for reported signals, it's just not that surprising
[15:31:12] <mhaberler> the above issues are more cosmetic. The bummer is the signal/pin linking which goes away as I laid out. Dont know what to do here.
[15:31:55] <jmk-mcfaul> I have a proposal, something that was in my mind a couple years ago but I never did anything with it
[15:32:10] <jmk-mcfaul> background: HAL is really two things:
[15:32:22] <jmk-mcfaul> 1) the pins/signals interconnect, in shared memory
[15:32:28] <jmk-mcfaul> 2) threads that can run realtime functions
[15:32:55] <jmk-mcfaul> the proposal: make a HAL-lite that can run on non-RT worthy computers, and implements only #1
[15:33:47] <jmk-mcfaul> then, make a HAL component that is a data-hose. It would consist of one part on each computer
[15:34:00] <jmk-mcfaul> each part would have the same configurable set of pins
[15:34:10] <mhaberler> oh I see. You mirror the HAL namespace, or establish it remotely.
[15:34:10] <jmk-mcfaul> any pin would be input at one end and output at the other
[15:34:15] <jmk-mcfaul> yeah
[15:34:23] <jmk-mcfaul> not the whole space
[15:34:34] <jmk-mcfaul> just the signals that you want to run between machines
[15:35:20] <jmk-mcfaul> you groups/members idea could be the way to define those signals, including the part about how often to poll, etc.
[15:35:39] <mhaberler> right, thats just mechanism, not policy
[15:35:49] <mhaberler> so lets make an example, the gladevcp thing, running on non-RT, and some RT outboard
[15:36:20] <mhaberler> the gladevcp comp has some HAL pins, which tie into.. well what, a mirrored signal at the frontend?
[15:36:49] <jmk-mcfaul> the gladevcp comp is identical (even binary) to todays gladevcp
[15:37:09] <mhaberler> sounds good so far, or cmorley will kill me
[15:37:19] <jmk-mcfaul> suppose it has a pin called meter.0.input
[15:37:36] <jmk-mcfaul> and in the rt HAL there is a pin called ups.battery.volts
[15:38:14] <jmk-mcfaul> if you were working on one PC, the gladevcp would be on that pc, and you would do "net volts ups.battery.volts -> vcp.meter.0.input"
[15:39:02] <jmk-mcfaul> if remote, then first you would load the datapipe on both, and tell it "volts is a float signal going from computer #1 to computer #2"
[15:39:26] <jmk-mcfaul> then on #1 you say "net ups.battery.volts -> datapipe.volts"
[15:39:47] <jmk-mcfaul> and on #2 you say "net datapipe.volts -> gladevcp.meter.0.input"
[15:39:55] <mhaberler> ok, so you re-export the tracked signal at the frontend
[15:40:02] <jmk-mcfaul> right
[15:40:03] <mhaberler> ah, double linking. get it
[15:40:17] <jmk-mcfaul> so you can use halcmd show at each end to see all the connections
[15:40:47] <jmk-mcfaul> btw, datapipe would also work between two non-rt HALs, or two rt HALs, (but the signals would not be RT)
[15:40:59] <mhaberler> provided the frontend halcmd can 'see through' to the backend HAL instance
[15:41:23] <mhaberler> to followup the linking 'over there'
[15:43:17] <jmk-mcfaul> well, I haven't thought that far ahead
[15:43:51] <jmk-mcfaul> in any two-computer system, you must have ssh or something anyway, right? How do you start EMC on that side otherwise?
[15:44:00] -!- rizo has quit [Ping timeout: 264 seconds]
[15:44:24] <mhaberler> well the nice part about zeromq is that rendezvous is taken care of, that is startup order dont matter
[15:44:35] <jmk-mcfaul> I was thinking of the datapipe as being peer-to-peer, rather than master-slave
[15:44:58] <jmk-mcfaul> meanwhile starting up EMC is master-slave, you initiate it from the UI computer
[15:45:10] <mhaberler> there would be a variety of mechanisms available, for instance reliable multicast, which is great in context of publish/susbcribe
[15:46:26] <mhaberler> or TCP pipes; or socket IPC (unix domain), or in-memory lockfree queues, which are blazing fast
[15:46:45] <mhaberler> but that is a secondary aspect
[15:47:08] <mhaberler> p2p is entirely feasible with both doing reliable multicast
[15:47:34] <jmk-mcfaul> I'm afraid I don't understand most of what you just said :-/
[15:48:02] <mhaberler> I head to read through this when I got around tmq
[15:48:09] <jmk-mcfaul> I'm not familiar with messaging really
[15:48:20] <jmk-mcfaul> the aspect I was talking about was basically the setup part.
[15:48:22] <mhaberler> it supports the PGM ('pretty good multicast') IETF proto
[15:48:35] <mhaberler> doesnt matter, thats just mechanism
[15:48:54] <mhaberler> standing back I understand this:
[15:49:29] <mhaberler> you'd suggest coupled HAL namespaces, and provide a means by linking 'through them'
[15:49:33] <jmk-mcfaul> today, you start LCNC by invoking a runscript. That script reads the ini file, then executes one or more HAL files, loads user space parts, starts the gui, etc
[15:49:39] <jmk-mcfaul> yes
[15:50:02] <mhaberler> let me relativize that for a moment.
[15:50:13] <mhaberler> I understand fully where you're coming from
[15:50:52] <jmk-mcfaul> actually I'm thinking more of two independent hal namespaces, with a pipe that transfers selected signals between them
[15:50:54] <mhaberler> however. see this: there _is_ already messaging into and out of HAL, albeit it a very specific, non-reusable way. the pipes are:
[15:51:03] <mhaberler> usrmotif - task->hal
[15:51:20] <mhaberler> error channel - Jeff's dbuf.c mystery code
[15:51:24] -!- nOStahl has quit [Quit: nOStahl]
[15:51:55] <mhaberler> there is really two philosopical approaches here, one:
[15:52:31] <mhaberler> extend the HAL namespace model through replication (what we just discussed)
[15:53:04] <mhaberler> 2) accept the fact of life that the whole thing doesnt make a lot of sense for linuxcnc without any messaging into/out of it to start with
[15:53:53] <jmk-mcfaul> yes, there is a linuxcnc specific problem, and a general HAL "problem"
[15:54:13] <mhaberler> it really is a question how far you drive the HAL linking model (all the way to remote guis), or if you say, ok, messages are a bona-fide way into/out of hal, and this is how it should be done
[15:54:20] <jmk-mcfaul> my proposal is mostly aimed at the HAL problem, it would allow HALs on multiple computers to communicate
[15:54:36] <mhaberler> I fully understand that
[15:55:10] <jmk-mcfaul> I must admit that I don't understand the term "messaging" when applied to a single PC system
[15:55:25] <mhaberler> see also that the linuxcnc specific 'problem' came about because there's no generalized in/out path for messages
[15:56:01] <mhaberler> let me pull another thing by you, to relativize this a bit
[15:56:11] <jmk-mcfaul> ok
[15:56:13] <mhaberler> folloowing observation:
[15:56:37] <mhaberler> HAL components are perfectly combinable with pins, signals etc.
[15:57:11] <mhaberler> when it comes to command processing, that fails completely. And that is one major reason why motion is such a whale
[15:57:32] <jmk-mcfaul> yes, HAL deals only with scalars
[15:57:38] <mhaberler> you cant have inter-component command/response passing
[15:58:04] <jmk-mcfaul> I don't want inter-component command/response passing
[15:58:06] <mhaberler> assume you modularize motion, say into joint, and spindle, homing
[15:58:13] <jmk-mcfaul> (only partly in jest)
[15:58:37] <jmk-mcfaul> ok, I think I understand
[15:58:59] <jmk-mcfaul> I would argue that HAL isn't the appropriate way to do that modularization
[15:59:11] <jmk-mcfaul> you propose making HAL capable of doing it
[15:59:15] <mhaberler> likely so
[15:59:33] <mhaberler> it is _very_ complex, and I dont want it either in a general form.
[15:59:44] <jmk-mcfaul> some background - I am an electrical engineer, not a programmer (by education and work)
[16:00:08] <jmk-mcfaul> so the electrical circuit analogy of HAL is natural to me. electrical circuits carry scalar signals
[16:00:21] <mhaberler> what could be done is to generalize the input and output channels a bit, so you can have more than one comp taking commands like motion
[16:00:39] <jmk-mcfaul> that doesn't mean I'm rejecting the idea of extending HAL to handle commands/responses, just that it will be harder for me to wrap my mind around it
[16:00:49] -!- ktchk has quit [Read error: Connection reset by peer]
[16:00:49] <mhaberler> ah
[16:01:24] <mhaberler> well whatever path we go the task/motion interface must become networked, and better a public API
[16:01:44] <jmk-mcfaul> yes
[16:01:46] <mhaberler> so the techniques can be reused by other applications; that is currently next to impossible
[16:02:16] <mhaberler> but it isnt all that hard to to; the biggest question is actually non-HAL
[16:02:38] <mhaberler> it is 'do we have to live with kernel threads, or can we give up on them'
[16:02:44] <jmk-mcfaul> what are the major interfaces in LCNC now? 1) gui <--> task, 2) task <--> motion, 3) motion <--> HAL, and 4) gui <--> HAL
[16:02:51] <mhaberler> the answer to this question has dramatic impact on apis
[16:03:05] <mhaberler> looks good
[16:03:18] <mhaberler> missing:
[16:03:26] <jmk-mcfaul> I started going one way and you another :-) lets talk about threads first
[16:03:30] <mhaberler> task/interpreter and vice bersa
[16:03:37] <mhaberler> fine
[16:04:08] <jmk-mcfaul> all RT stuff is a hal component, and HAL provides threads that you can attach component functions to
[16:04:21] <mhaberler> yes
[16:04:30] <jmk-mcfaul> at a high level, the user doesn't care about the implementation of threads
[16:04:46] <mhaberler> no
[16:04:50] <jmk-mcfaul> at a low level, the performance varies widely based on the implementation
[16:04:57] <mhaberler> coding bums like me do
[16:05:06] <jmk-mcfaul> (I'm just saying stuff we both aleady know
[16:05:24] <jmk-mcfaul> maybe because I don't have any good answers for the other stuff :-(
[16:05:37] <mhaberler> fair enough; it _is_ hard
[16:06:04] -!- skorasaurus has quit [Ping timeout: 276 seconds]
[16:06:13] <jmk-mcfaul> I have not been following the linux world at all for several years. I use Linux for all my home PCs, and for my CNC machine, but I have no clue where the devs are going
[16:06:20] <mhaberler> I did a PhD thesis about error detection in protocols, so IÄ've been around a bit
[16:06:24] <jmk-mcfaul> this box is running ubuntu 9.10, and it is the newest one I have
[16:06:29] <jmk-mcfaul> my CNC machine is running 6.06
[16:06:50] <mhaberler> I have some hardware for you, hold on a sec:
[16:06:59] <jmk-mcfaul> so for things like "is RT_PREEMT the way to go", I have no clue
[16:07:24] <mhaberler> http://mah.priv.at/zenphoto/index.php?album=diesdas/album35&image=pentinum.jpg
[16:07:56] <mhaberler> you mean where things are going in terms of kernels
[16:08:01] <jmk-mcfaul> lol
[16:08:41] <mhaberler> well it's fairly driven by 'how invasive is the patch', 'how likely is it to go into mainline', and 'does the originating project have chances of survival'
[16:09:16] <jmk-mcfaul> back when I was involved, RTAI was bad on #1 and #2, but #3 seemed pretty decent
[16:09:28] <jmk-mcfaul> and it was pretty much the only deal in town, so that is what we used
[16:09:35] <mhaberler> so re second question the answer is RT_PREEMPT for sure; Xenomai once it adopts RT_PREEMPT, which is underway, and RTAI: no chance
[16:09:43] <mhaberler> right
[16:09:50] <jmk-mcfaul> personally I like the kernel module programming style - it is a lot like programming a microcontroller, just a really really powerfull and fast one
[16:09:52] <mhaberler> it made total sense, no contest
[16:10:28] <mhaberler> are you aware that some folks have better results with userland threads than with kernel threads _on the same hardware_?
[16:10:38] <jmk-mcfaul> wow
[16:10:42] <jmk-mcfaul> how can that be?
[16:10:48] <mhaberler> not for all of them, but not isolated either
[16:10:59] <mhaberler> well, one factor for sure is
[16:11:12] <mhaberler> 'newer kernels'
[16:11:39] <mhaberler> We had schooner reporting figures today, maybe you saw that - exactly what I just said
[16:11:55] <jmk-mcfaul> who is schooner?
[16:12:01] <mhaberler> so the assumption 'kernel threads are faster' is just that, it doesnt necessarily hold up
[16:12:09] <mhaberler> Mick something (dunno)
[16:12:10] <jmk-mcfaul> I haven't been on IRC in a long time, I only read the mailing lists
[16:12:35] <mhaberler> well you'll find it, he posted today under 'Schooner'
[16:12:47] <mhaberler> then #2: future
[16:12:53] <jmk-mcfaul> oh, I see it
[16:13:28] <mhaberler> there is one consistent picture: things are migrating away from doing RT as kernel threads
[16:13:44] <mhaberler> xenomai started dual usr/kernel, is dropping kernel threads
[16:13:48] <jmk-mcfaul> as a user, I have no problem with that
[16:13:53] <mhaberler> rt_preempt is exclusively usr threads
[16:14:05] <mhaberler> rtai is out on a limb here, too
[16:14:40] <mhaberler> I accidentially did the xenomai port #1 to kernel mode and was really pissed off when I found out they'll deprecate it
[16:15:08] <mhaberler> I finally saw the deprecation warning of the include file flying by.. I had ignored it. Duh.
[16:15:17] <jmk-mcfaul> so the question might be "does RTAPI/HAL need to support both kernel and user threads, or can it move to user threads only?"
[16:15:39] <mhaberler> well yes. Assume the answer is: user threads only.
[16:15:51] <jmk-mcfaul> user only must be less work for you and john and others who are digging deep into the bowels
[16:16:15] <jmk-mcfaul> at least eventually. lots of work now as some key assumptions change
[16:16:18] <mhaberler> yes, and debugging - gdb -p <pid>, done
[16:16:29] <jmk-mcfaul> heh, I never got used to using gdb
[16:16:31] <mhaberler> that is one major aspect
[16:16:36] <jmk-mcfaul> I debug with printk
[16:17:07] <mhaberler> right, I was about to say 'real men use printk'. Andy would love it.
[16:18:03] <jmk-mcfaul> btw, with regard to you, and Andy, and John Morris, and others - I am thrilled to see all the new blood and new activity
[16:18:16] <mhaberler> if the answer is 'user threads only', this opens a wide range of options to modularize, in particular motion, and how that interworks
[16:18:50] <mhaberler> that is refreshing, and it is actual quite close collaboration
[16:21:16] -!- chillly has quit [Quit: Leaving]
[16:38:43] -!- mephux has quit [Excess Flood]
[16:41:57] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[16:45:54] -!- L33TG33KG34R has quit [Ping timeout: 240 seconds]
[16:49:50] -!- dimas has quit [Ping timeout: 256 seconds]
[17:14:26] -!- sirdancealot1 has quit [Ping timeout: 246 seconds]
[17:31:33] -!- mattions has quit [Ping timeout: 248 seconds]
[17:34:43] -!- Pitu_ has quit [Client Quit]
[17:39:31] -!- racycle has quit [Quit: racycle]
[17:58:24] -!- zzolo has quit [Quit: zzolo]
[18:21:50] -!- Loetmichel has quit [Ping timeout: 252 seconds]
[19:03:13] -!- s1dev has quit [Quit: Oh shit!]
[19:04:09] -!- motioncontrol has quit [Quit: Sto andando via]
[19:11:30] -!- s1dev_ has quit [Ping timeout: 264 seconds]
[19:20:52] -!- micges has quit [Quit: Leaving]
[19:42:24] Cylly is now known as Loetmichel
[19:44:01] toudi_ is now known as micges
[19:44:57] -!- micges has quit [Client Quit]
[19:55:30] -!- Sendoushi has quit [Remote host closed the connection]
[20:08:49] -!- fatpandas has quit [Quit: leaving]
[20:20:32] -!- wildbilldonovan has quit [Quit: Zzzzzzz]
[20:48:00] -!- andypugh has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
[20:54:48] -!- s_faraday has quit [Quit: Leaving.]
[20:56:18] -!- Sendoushi has quit [Read error: Connection reset by peer]
[20:57:02] -!- Wildhoney has quit [Ping timeout: 246 seconds]
[21:03:07] -!- Pitu has quit [Quit: Page closed]
[21:04:48] -!- psha has quit [Quit: Lost terminal]
[21:13:18] -!- L33TG33KG34R has quit [Ping timeout: 252 seconds]
[21:20:03] -!- micges has quit [Quit: Wychodzi]
[21:33:04] -!- RagingComputer has quit [Read error: Operation timed out]
[21:36:01] -!- DJ9DJ has quit [Quit: bye]
[21:37:24] -!- i_tarzan has quit [Read error: Connection reset by peer]
[22:30:45] -!- chillly has quit [Quit: Leaving]
[23:07:01] -!- micges has quit [Ping timeout: 248 seconds]
[23:12:03] toudi_ is now known as micges
[23:27:51] -!- Sendoushi has quit [Remote host closed the connection]
[23:30:34] -!- firephoto has quit [Quit: ZNC - http://znc.in]
[23:56:17] -!- firephoto_ has quit [Quit: ZNC - http://znc.in]
[23:57:05] -!- zzolo has quit [Quit: zzolo]
[23:58:59] firephoto_ is now known as firephoto
[23:59:52] -!- LeelooMinai has quit [Remote host closed the connection]
