Back
[18:21:21] <Imperator_> Nope
[18:21:42] <Imperator_> have tried to install the new BDI on my P1 system
[18:22:02] <Imperator_> but the kernel is compiles for P2 and newer systems :-(
[18:22:12] <alex_joni> 686
[18:22:18] <Imperator_> jep
[18:22:25] <alex_joni> tough ;)
[18:23:09] <alex_joni> well, maybe paul_c will add a 586 kernel
[18:24:09] <Imperator_> my development system is a P1 it runs fine and if i burn it because of a wrong soldered ISA or PCI Card it's no problem, i have some boards more
[18:24:37] <Imperator_> maybe
[18:26:20] <alex_joni> you can test the board first in the P1 then move it to the final EMC-PC
[18:26:30] <alex_joni> build a simple non-rt app
[18:26:32] <alex_joni> for debug
[18:29:02] <Imperator_> jep, but i don't want to have so much computers in my room
[18:36:32] <anonimasu> hello
[18:37:55] <alex_joni> hello an0n
[18:38:11] <anonimasu> I got the probe fitted to the mill now, and the plc program written..
[18:38:21] <alex_joni> coo
[18:38:26] <alex_joni> does it work?
[18:38:26] <anonimasu> the only thing thats left is to write the part to talk to the plc..
[18:38:32] <anonimasu> and send the message to emc
[18:38:33] <alex_joni> serial?
[18:38:38] <anonimasu> yes?
[18:39:09] <alex_joni> not that hard... ;)
[18:39:25] <anonimasu> I just installed the box like 20 minutes ago
[18:39:37] <anonimasu> going to leave for a lan in a bit..
[18:39:44] <anonimasu> going to take the box with me and write the program :)
[18:39:54] <alex_joni> nice
[18:40:39] <anonimasu> I am not that happy with the installation of the sensor, really but I'll re-do it. and mill myself a slotted disk and turn it so I wont get imbalance..
[18:40:45] <anonimasu> :)
[18:44:34] <anonimasu> I'll be back in a bit..
[19:26:34] <gezr> EMC EMC is CNC software that takes Gcode and carves metal blocks into nuclear bomb parts or small carvings of Tux depending on your inclinations.
[19:26:38] <gezr> buahahahahahaha
[19:27:48] <gezr> um any one here?
[19:27:51] <gezr> http://www.cadcam.co.at/freiter/gCAD3D.htm
[19:27:57] <gezr> what is that?
[19:46:46] <gezr> well its interesting at the least
[19:47:39] <zwisk> indeed.
[19:47:43] <zwisk> I looked at version 0.77 sometime ago.
[19:50:03] <gezr> all this cad/cam stuff is huge
[20:34:18] <zwisk> jmk!
[20:34:42] <zwisk> greetings!
[20:37:24] <jmkasunich> hi
[20:38:01] <zwisk> have I made a big enough mess outa things yet? :)
[20:38:26] <jmkasunich> just logged in, gotta catch up on emails and do a cvs up
[20:38:42] <zwisk> k. I think I'll be here a while...
[20:45:52] <jmkasunich> * jmkasunich is caught up
[20:48:52] <zwisk> any comments?
[20:49:04] <jmkasunich> well, partially caught up ;-)
[20:49:29] <jmkasunich> my make failed... the fresh checkout doesn't have a /rtlib directory, and apparently the makefiles don't create it
[20:49:59] <zwisk> hmm... that's ... very odd? I don't think I played there... At least not on purpose :)
[20:50:02] <jmkasunich> I wonder how long that bug has been there - it only shows up with a fresh checkout
[20:50:07] <jmkasunich> I doubt it was you
[20:52:47] <jmkasunich> hmmm, bin, lib, rtlib, include - none of those directories was created
[20:53:14] <zwisk> Hmm... you did make at in src, right?
[20:53:25] <zwisk> argh... I mean... you did make in src, right?
[20:53:48] <zwisk> (I checked out a fresh copy when I started and didn't run into that...)
[20:53:52] <jmkasunich> I did the "standard" emc2 make - cvs checkout, then run ./configure and Make in the top level directory
[20:53:52] <zwisk> are you maybe out of disk space?
[20:54:05] <jmkasunich> nope, 3G free
[20:54:49] <jmkasunich> the directory names in Makefile.inc are correct
[20:54:58] <jmkasunich> but the directorys themselves don't exist
[20:55:12] <picnet> Evening
[20:55:23] <zwisk> howdy picnet
[20:55:30] <picnet> blimey no paul?
[20:56:00] <picnet> delrin 6.35mm hole, 10mm hole = solidish coupling?
[21:02:08] <jmkasunich> hmm... went back into my regular EMC2 tree, deleted the contents of the include directory, deleted the directory, and the same thing happens - make fails to create the dir
[21:02:59] <zwisk> wow... I haven't run into that, and I bet I've done pretty much the same process you're doing...
[21:04:03] <jmkasunich> running "make headers" with no include directory results in each header being copied to the file "include", so after it's done, the "include" contains the final header
[21:04:09] <jmkasunich> and of course the make crashes
[21:04:21] <jmkasunich> s/crashes/fails/
[21:13:53] <jmkasunich> zwisk: do "make clean", followed by "cvs up -dP" and see if you have an include directory afterwords
[21:14:29] <zwisk> hmm... I'm almost afraid to... mine works :)
[21:14:52] <jmkasunich> it's easily fixable if the directory disappears...
[21:15:02] <jmkasunich> I think I know what happened
[21:15:36] <zwisk> nope... no include directory ... (Was I supposed to do ./configure and make? )
[21:16:03] <jmkasunich> it was the "cvs up -dP" that did it
[21:16:27] <zwisk> hmm... ok. So what's the fix?
[21:16:45] <jmkasunich> short term fix: mkdir include, mkdir bin, etc
[21:17:03] <jmkasunich> but I'm gonna add code to the makefile that will make the dirs if they don't exist
[21:17:44] <jmkasunich> -dP says "make any new directories that are needed (-d) and prune empty directories (-P)"
[21:18:10] <jmkasunich> after the initial checkout, you have empty dirs from CVS
[21:18:28] <jmkasunich> if you run a make, they get files in them, and aren't pruned by later cvs updates
[21:18:39] <jmkasunich> in my case, I did the checkout, but no make yesterday
[21:19:04] <jmkasunich> today I did an update to get the latest, that removed the empty dirs
[21:19:46] <zwisk> I see.. so what's the best way to get your directories back now?
[21:20:05] <jmkasunich> just to mkdir include, etc
[21:20:17] <jmkasunich> just _do_ mkdir include
[21:20:21] <jmkasunich> can't spell
[21:22:23] <anonimasu> hm, weird..
[21:22:28] <anonimasu> emc wouldnt run on my box..
[21:23:33] <anonimasu> it loads ok with the generic config..
[21:23:38] <anonimasu> although when I run emc.run it locks up
[21:26:58] <zwisk> sorry anonimasu, I think I'm not much help to you there...
[21:32:31] <CIA-5> 03jmkasunich 07halrefactor-0-1 * 10emc2/Makefile: fixed makefile so it will create include, bin, lib, and rtlib directories if needed
[21:34:37] <jmkasunich> zwisk - do a "make clean", then "cvs up -dP", then try make - it should now recreate the missing directories
[21:34:54] <zwisk> in which branch?
[21:35:00] <jmkasunich> halrefactor
[21:37:04] <zwisk> yup... seems happy..
[21:39:06] <CIA-5> 03jmkasunich * 10emc2/Makefile: fixed makefile so it will create include, bin, lib, and rtlib directories if needed
[21:39:41] <jmkasunich> applied the fix to the trunk as well - it will be a while before we merge the hal refactor stuff
[21:40:29] <jmkasunich> the make in the branch still failed while compiling hal_lib, right?
[21:40:58] <jmkasunich> that was to be expected I think
[21:41:20] <zwisk> erm... shouldn't have... I've been trying to checkin only compileable things...
[21:41:26] <zwisk> what error did you get?
[21:42:07] <jmkasunich> In file included from hal_lib.c:70:
[21:42:21] <jmkasunich> /usr/src/linux/include/linux/malloc.h:4: warning: #warning linux/malloc.h is deprecated, use linux/slab.h instead.
[21:42:45] <zwisk> that's just a warning, right?
[21:42:48] <jmkasunich> followed by a couple more warnings from hal_procfs.h
[21:42:51] <zwisk> (I don't think I added that...)
[21:43:01] <jmkasunich> followed by:
[21:43:04] <zwisk> yes... hal_procfs was unclean I think.
[21:43:14] <jmkasunich> ok
[21:43:24] <zwisk> but it did make hal_lib.o, right?
[21:43:28] <jmkasunich> I know that we're gonna break things pretty good before we fix them
[21:43:43] <jmkasunich> nope
[21:43:53] <zwisk> doh... shoulda.. What was the fatal error?
[21:44:03] <jmkasunich> In file included from hal_lib.c:46:
[21:44:10] <jmkasunich> hal_procfs.c:19: `hal_data' undeclared (first use in this function)
[21:44:21] <jmkasunich> In file included from hal_lib.c:92:
[21:44:29] <jmkasunich> hal_priv.h:286: `hal_data' used prior to declaration
[21:44:32] <zwisk> oh nuts... yeah... That's a mistake on my part. I'm about ready to checkin another that will fix that.
[21:44:41] <jmkasunich> ok
[21:44:43] <zwisk> (maybe 5-10 minutes)
[21:53:30] <jmkasunich> a terminology issue... I used "component" instead of "module" to avoid confusion with generic kernel modules (especially since user space components are _not_ kernel modules)
[21:53:46] <jmkasunich> should hal_module_info be called hal_comp_info?
[21:54:03] <zwisk> yeah... I'm grappling with how to deal with that, as much of the kernel stuff will be kernel modules...
[21:54:27] <zwisk> I'm not sure... we should definitely continue our terminology discussion and then do a great big search and replace to get everything consistent when we get it all worked out.
[21:55:10] <jmkasunich> I want to get the terminology straight as soon as possible tho, to avoid confusion
[21:55:43] <zwisk> agreed
[21:56:13] <jmkasunich> to date, we have "component" or "module" for a thing which can contain one or more types of blocks
[21:56:25] <jmkasunich> and "block" for an instance of a block
[21:57:05] <zwisk> I think I've also confused "component" and "block" on a few occasions. A component reminds me in EE terms of a specific instance of a chip on a board... I place components on the board...
[21:57:49] <jmkasunich> agreed... now that we have the idea of more than one possible "thing" inside a single module, "component" seems a better fit to the thing, not the wrapper
[21:58:26] <jmkasunich> if anything, "library" would be a good word for the module that makes multiple blocks available... but library already has meaning in programming
[21:58:31] <jmkasunich> I hate overloading terms
[22:00:07] <jmkasunich> we have things which you can "place", and we have larger things that can contain several different varieties of the former
[22:00:30] <jmkasunich> and I don't know what to call either one of those things
[22:00:40] <zwisk> yeah... I sort of start thinking about device families somewhere in there... but that doesn't seem to make sense.
[22:01:17] <jmkasunich> there is no physical analogy for something that makes several types of components available
[22:01:34] <jmkasunich> but there is an electronic CAD analogy - a component library
[22:02:15] <zwisk> hmm.. definitely the cad analogy makes sense.
[22:02:28] <jmkasunich> loading a library makes all the parts in it available
[22:02:48] <zwisk> well, there are 'portfolios' of chips, 'families' of chips, 'brands' of chips, 'product groups', ... hmm... just braind storming...
[22:03:17] <jmkasunich> brainstorming is good
[22:03:35] <jmkasunich> what about "part" for the instances themselves (instead of block)
[22:05:24] <jmkasunich> a "part" is an instance of a "part type", which is made available by a "???" that may be either a user space program or a kernel module
[22:06:15] <zwisk> hmm... perhaps. Have I seen 'part' refer to a type a chip rather than a specific one though?
[22:06:37] <jmkasunich> I think of R1, C23, U5, etc as "parts"
[22:07:08] <zwisk> I think digikey and many other vendors have 'part selection guides' which help you find the chip within a spefic family that you want to use... Then you also order parts... hmmm... I dunno...
[22:07:54] <jmkasunich> is "1K 1/4W" or "74LS04" a part or a part type?
[22:07:57] <jmkasunich> it can be both
[22:08:33] <zwisk> yeah... I'm afraid it can be both. There may not be a perfect solution...
[22:08:45] <jmkasunich> if a bill of materials calls out qty 3 of 1K, and qty 4 of LS04, then there are 7 "parts" on the board
[22:08:57] <jmkasunich> but you have to order two different kinds of parts
[22:09:17] <zwisk> or are there 7 components? I guess part placement machines place individual parts...
[22:10:00] <jmkasunich> the CAD package we use at work (PowerLogic/PowerPCB) calls the individual things "parts" and the different kinds "part types"
[22:10:16] <jmkasunich> "1K 1/2W" is a parttype
[22:10:21] <jmkasunich> R12 is a part
[22:10:30] <anonimasu> what are you discusssing?
[22:10:51] <jmkasunich> refactoring of some of the HAL code
[22:11:20] <jmkasunich> HAL is based on a component analogy, that is much like designing electronic hardware by placing and interconnecting integrated circuits
[22:11:25] <zwisk> I could be ok with "part" and "parttype"...
[22:11:30] <anonimasu> ok
[22:11:55] <jmkasunich> * jmkasunich tries to remember what Orcad used for terminology
[22:12:52] <jmkasunich> both Orcad and PowerLogic refer to collections of parttypes as "libraries", but that's a word with a very distinct meaning already for programmers
[22:14:25] <zwisk> hmmm... we can always prepend things...
[22:14:34] <zwisk> "hallibrary" or "partlibrary"
[22:14:45] <jmkasunich> I could live with either "part" and "parttype" or "block" and "blocktype"
[22:14:47] <jmkasunich> true
[22:15:03] <jmkasunich> not hallibrary tho... sounds like halliburton
[22:15:04] <jmkasunich> ;-)
[22:15:20] <zwisk> ok... :)
[22:16:10] <jmkasunich> I could live with "module" as the thing that makes one or more parttypes/blocktypes available for use
[22:16:31] <jmkasunich> even tho it might not actually be a kernel module, it might be a user process
[22:16:42] <zwisk> I think you have a good point about modules meaning something in the kernel. I'm really good with the idea in the kernel, not as hot on it when it's in userspace...
[22:17:15] <jmkasunich> there will definitely be some asymmetry between kernel and user space
[22:17:50] <jmkasunich> in kernel, you _must_ be able to make more than one instance of a parttype without reloading the module, because you _can't_ load a module twice
[22:18:07] <jmkasunich> however, in user space, if you want two of something you can just start two copies of it
[22:18:39] <jmkasunich> in fact you probably would have to start to copies of it... each one probably needs its own process/thread of execution
[22:19:02] <zwisk> I was thinking about this...
[22:19:35] <zwisk> for symetry sake... I'm thinking the user space hal_lib should have main in it, and fork / create threads to use the same create mechanism we make for modules in kernel space...
[22:20:08] <jmkasunich> hmmm
[22:20:33] <zwisk> I've also been thinking that we might consider shared objects for user space 'modules', so that a hal_main can load shared objects in (and link with them) in much the same way that the kernel doe sfor kernel modules.
[22:20:39] <zwisk> (Again, mostly for symetry.)
[22:21:15] <jmkasunich> I don't know how we would do that (never done anything with shared libraries, etc, under Linux)
[22:21:36] <zwisk> we have time to ponder that...
[22:21:49] <jmkasunich> I was assuming that user space components would be ordinary binaries... you just run them from the command line
[22:22:22] <jmkasunich> (halcmd would be able to fork and run them, to have a "loadusr" command analogous to "loadrt", but it wouldn't strictly be needed
[22:22:38] <jmkasunich> I'm open to other methods though...
[22:23:22] <jmkasunich> I think we need some sample components for thinking this thru
[22:23:38] <jmkasunich> we'll have "VLSI" realtime parts, like motmod - a complete motion controller
[22:23:50] <jmkasunich> and MSI realtime parts like stepgen or PID
[22:23:54] <zwisk> One of the unfortunate things (to me) about emc/emc2 is that it has a zillion different binaries all over that have to work together. In some ways, this is great, and the 'unix' way to do things. In other ways, it's a big old distributed mess where nothing knows about anything... I'm not sure where the right balance is.
[22:23:59] <jmkasunich> and SSI ones like "AND", "SUM", etc
[22:24:55] <jmkasunich> I like the unix way. I'm a strong believer in partitioning, with _very_ well defined interfaces
[22:25:03] <jmkasunich> (hence the HAL concept ;-)
[22:25:08] <zwisk> the problem is the interfaces are not well defined.
[22:25:18] <jmkasunich> right
[22:25:27] <zwisk> HAL is much much much cleaner (IMHO) than the unixy binaries every where that emc currently uses.
[22:26:15] <jmkasunich> I don't think the problem is the number of binaries, I think it is that the comms between them aren't kept simple
[22:26:49] <jmkasunich> normal "unixy" binaries only have stdin and stdout
[22:27:11] <jmkasunich> emc binaries use NML messages and/or shared memory, so they can have much more complex interaction
[22:28:13] <zwisk> could be... paths are a huge problem to me.... It's *very* hard to package emc in an arbitrary directory right now.
[22:28:54] <jmkasunich> yep
[22:28:59] <jmkasunich> don't know the answer to that
[22:30:13] <jmkasunich> you said: " it's a big old distributed mess where nothing knows about anything..."
[22:30:24] <jmkasunich> in a way, that also describes HAL
[22:30:53] <jmkasunich> a bunch of parts - a knowledgable person could build hundreds of different things with them
[22:31:07] <zwisk> I disagree...
[22:31:11] <jmkasunich> but a less knowledgable person doesn't even know where to start
[22:31:43] <jmkasunich> as opposed to something like Mach2, where you can only build one thing, a CNC control, but it's already assembled
[22:31:44] <zwisk> I think hal has a central hal_lib that managed what it needs to to keep it's sub-parts working.
[22:32:08] <zwisk> generic.run doesn't do a good job of being that same thing for EMC.
[22:32:37] <anonimasu> :)
[22:32:58] <jmkasunich> generic.run merely parses the ini file and loads the pieces you asked for in the file
[22:33:09] <jmkasunich> not to different from halcmd
[22:34:09] <jmkasunich> "generic.run -ini mymachine.ini" and "halcmd -f mymachine.hal" are conceptually the same thing, just operating at different levels
[22:34:42] <jmkasunich> mymachine.* tells it what things you want and how they are connected
[22:34:49] <zwisk> I see those levels as being very important though.
[22:34:59] <jmkasunich> yes
[22:35:02] <zwisk> halcmd has the chance of being able to help you put peices together... generic.run ... well.. I don't see that potential.
[22:35:08] <jmkasunich> hal is low level, where things are simple
[22:35:37] <jmkasunich> the pieces that halcmd assembles range from SSI to LSI
[22:35:42] <zwisk> I think emc at higher levels could be made just as simple. It's all about assembling bricks that have compatible ins and outs...
[22:36:01] <jmkasunich> but generic.run is hooking together VLSI stuff with much more complex functionality and interfaces
[22:36:07] <zwisk> think lego mindstorms graphical programming.
[22:36:36] <jmkasunich> NML is supposed to enable you to do exactly that
[22:36:54] <jmkasunich> I don't think there is a fundamental problem with the way the higher level parts of emc are broken up
[22:37:14] <jmkasunich> I do think there is a severe lack of documentation of the interfaces between the parts
[22:37:45] <jmkasunich> and some sloppiness, where folks allowed more coupling between parts than they should have because it made things a little easier
[22:37:56] <zwisk> well... perhaps that's all. I know I got scared off when I first starting diving into all of that in the original emc code. I haven't revisisted in emc2, though I know paul has done a LOT of cleanup.
[22:38:23] <jmkasunich> it's still tough to understand. There is a lot of coupling
[22:38:28] <jmkasunich> and a lot of asymmetry
[22:38:52] <jmkasunich> some, but not all, commands that get sent to the motion controller have corresponding NML messags
[22:39:11] <jmkasunich> the ones that do can be sent from anywhere. the ones that don't can only be sent from the main task controller
[22:39:31] <jmkasunich> there's very little consistency in deciding which ones are which
[22:40:14] <zwisk> Hopefully that changes one day.
[22:41:25] <jmkasunich> yeah... but for now I'll stay with the HAL where I know what I'm doing
[22:41:56] <jmkasunich> anyway, I was going somewhere with my SSI/MSI/LSI crap
[22:42:21] <jmkasunich> in realtime, we can have all levels
[22:42:40] <jmkasunich> I don't think the SSI type stuff will be as usefull in user space
[22:42:59] <zwisk> here comes a new checkin...
[22:43:16] <jmkasunich> I expect that most user space components will be VLSI (like an IO controller, not an AND gate)
[22:43:19] <CIA-5> 03zwisk 07halrefactor-0-1 * 10emc2/src/hal/ (hal_lib.c hal_priv.h hal_procfs.c hal_procfs.h):
[22:43:19] <CIA-5> More changes, mostly allowing for dynamic registration of modules
[22:43:19] <CIA-5> and block_types in kernel space using kernel space structures.
[22:43:19] <CIA-5> Also some early work on the mechanism for creating blocks.
[22:43:19] <CIA-5> This should build hal_lib.o and blocks.o successfully for testing.
[22:43:27] <zwisk> OK... I'm not into EE daily enough to have a good feel ...
[22:43:53] <zwisk> LSI = Large Scale Integration... VLS = Very Large ... MSI? SSI? Small Scale? What differentiates all of those?
[22:44:47] <jmkasunich> sorry about that... you got it... VLSI is very large scale, things like microprocessors and such. MSI is medium scale, things like counters... SSI is small, individual gates
[22:45:18] <jmkasunich> for EMC, the motion controller and IO controllers would be VLSI or LSI (one in kernel space, one in user space)
[22:45:30] <jmkasunich> things like a PLC would also be LSI, and could be realtime or user
[22:45:49] <jmkasunich> something like stepgen or a stg or parport driver are MSI
[22:46:06] <jmkasunich> and things like summers, AND gates and such are SSI
[22:46:21] <zwisk> ok... cool...
[22:46:46] <jmkasunich> think about the relative sizes of the data sheets for SSI, MSI, and VLSI parts
[22:46:57] <jmkasunich> and gate needs a pinout and that's about it
[22:47:13] <zwisk> that just means more complicated types. No big deal.
[22:47:13] <jmkasunich> a counter needs a page or so to describe counting modes and such
[22:47:20] <jmkasunich> a microprocessor has a book
[22:47:34] <zwisk> (We should talk about that sometime too... allowing hal to create new arbitrary types from previous primitive types...)
[22:48:03] <jmkasunich> oooooohhhhh.... hiercharical design - I like it (even tho I can't spell it)
[22:48:17] <zwisk> absomalutely! :)
[22:49:04] <zwisk> (Can you tell I have big plans for hal? :) )
[22:49:17] <jmkasunich> one thing that will be almost a neccessity if we get into that kind of flexibility is automatic management of threads and functions
[22:50:21] <jmkasunich> having to decide exactly where in a thread an AND gate's function must execute such that the blocks feeding its inputs execute before it does, and the blocks fed by it execute after, will get really nasty with many parts
[22:50:56] <jmkasunich> I also have plans for HAL beyond EMC... in fact at one time I was considering spinning it off into it's own SF project
[22:51:57] <zwisk> I remember talking to you in passing about that once before.
[22:52:12] <jmkasunich> about thread/funct management, or about spinning off?
[22:52:22] <zwisk> So, any feedback or course correction on the changes I'm making would be great :)
[22:52:40] <zwisk> spinning off. Thread/funct management is still conceptually passed where I fully grok the system :)
[22:53:23] <jmkasunich> I really don't know what to think about spinning off
[22:53:47] <jmkasunich> some of the things I want to do for HAL are far beyond what EMC needs, and might simply make it harder for a novice to use EMC
[22:54:18] <jmkasunich> Paul and I have had words about that... he's not convinced that things like PID should become HAL modules
[22:55:18] <jmkasunich> and within the confines of EMC, maybe he has a point
[22:55:21] <zwisk> well.. we know they should :)
[22:55:45] <zwisk> That may be true, but PIDs can be used for more than just EMC.
[22:55:59] <jmkasunich> the downside of spinning off is that (prior to today) I expected that I'd suddenly find myself working all by my lonesome
[22:56:32] <zwisk> I have that problem too. I have lots of big ideas, and lots of started projects, but without someone to work with, I tend to get bored/stuck/unmotivated at some point.
[22:57:52] <jmkasunich> anyway, we've managed to digress again
[22:58:22] <zwisk> true... and eventually I'm gonna segfault in the kenrel and have to reboot... I'm just sure of it! :)
[23:00:43] <zwisk> have you looked at all at the 2.6 kernel compile rules? I'd like as part of this refactor to get 2.6 in there as well...
[23:01:46] <jmkasunich> I'm afraid I don't know anything about 2.6
[23:01:51] <jmkasunich> it scares me ;-(
[23:02:28] <zwisk> why? (Should I be scared too?)
[23:02:31] <CIA-5> 03zwisk 07halrefactor-0-1 * 10emc2/src/hal/ (hal_lib.c hal_procfs.c): cat /proc/hal/show_components now lists the 'modules' registered
[23:02:43] <jmkasunich> dang - you been busy
[23:02:50] <zwisk> I'm havin' fun :)
[23:04:35] <jmkasunich> make fails, hal_lib.c:324: parse error before *
[23:05:51] <zwisk> hmm.. how come it works for me, I commit, and then it's broken. I must be doing something wrong in my process....
[23:06:14] <jmkasunich> looks like you are declaring a variable right in the middle of the code?
[23:06:33] <jepler> That's legal in c99 and c++ -- do you have an old compiler?
[23:06:50] <jmkasunich> gcc 2.96
[23:06:54] <jepler> yeah, that's old
[23:07:02] <zwisk> I did do that in a few spots where I was doing new stuff...
[23:07:03] <zwisk> gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-6)
[23:07:11] <jmkasunich> old my ass
[23:07:17] <jmkasunich> ;-)
[23:07:36] <zwisk> hmm... ok... I guess I need to be careful of that...
[23:07:50] <zwisk> (This code is a bit loose, for sure!)
[23:08:10] <jmkasunich> * jmkasunich moves the decls to the top of the function
[23:08:18] <jepler> zwisk: Maybe you can arrange to use -std=c90 locally?
[23:08:19] <zwisk> thx...
[23:08:30] <jepler> er, -std=c89
[23:08:47] <zwisk> Hmm... is that what I should do?
[23:09:09] <zwisk> I guess I think we should make emc compile by default with whatever level of compiler we want to support... (If we can)
[23:09:13] <jmkasunich> hal_lib compiles now... still a number of warnings
[23:09:47] <jmkasunich> IMO, we need to support BDI-2.xx, which is based on RH6
[23:09:57] <jmkasunich> I'm using BDI-TNG, based on RH7
[23:10:33] <jepler> hm, -std=c89 doesn't stop declarations-in-midblock from building, unless I messed something up in my test program
[23:10:34] <jmkasunich> HAL in particular may be used on small, old systems, almost as an embedded thing
[23:10:43] <zwisk> ok... so... gcc -std=89 will make most newever version honor that?
[23:11:10] <jepler> zwisk: on gcc 3.3.3 it took '-std=c89 -ansi -pedantic' to get even a warning
[23:11:17] <jepler> /tmp/decl.c:1: warning: ISO C90 forbids mixed declarations and code
[23:11:40] <jepler> hm, there's also "-Wdeclaration-after-statement" in gcc 3.3.3
[23:11:54] <jmkasunich> I use -Wall
[23:12:04] <jmkasunich> and strive for zero warnings
[23:12:24] <jmkasunich> I don't know if -Wall includes decl after statement or not
[23:12:35] <jepler> jmkasunich: that -W didn't exist in your gcc
[23:12:49] <jepler> jmkasunich: the question is whether zwisk could find a compiler flag to use so he won't write declarations after statements anymore
[23:12:58] <jmkasunich> right
[23:13:14] <zwisk> hehe.. yeah. Basically if I do it, and my compiler compiles cleanly, I assume it's alright :)
[23:13:16] <jmkasunich> I was wondering if -Wall includes that -W in _his_ version
[23:14:11] <cradek> -std=c89
[23:15:19] <cradek> wait, that doesn't work
[23:15:20] <cradek> hmm
[23:15:21] <jmkasunich> I must admit I'm a dinosaur as far as C dialects go... I learned from the K&R book, and other than adopting newer style function prototypes, I haven't evolved much
[23:15:53] <cradek> -ansi -pedantic gives a warning
[23:16:13] <jmkasunich> I did lots of programming on DOS in the mid '90s using Watcom C, then winblows took the fun out of it. I only started again on Linux a couple years ago
[23:16:25] <jmkasunich> so I missed the adoption of C99
[23:16:48] <robin_sz> meep!
[23:16:53] <jmkasunich> !peem
[23:16:59] <robin_sz> hi :)
[23:17:43] <robin_sz> I keep seeing you about, but you seem to have been a bit busy lately
[23:18:06] <jmkasunich> busy? as in busy coding, or busy with life and not coding much?
[23:18:19] <robin_sz> both from what I could tell?
[23:18:30] <jmkasunich> yeah, last month it was the latter, this week the former
[23:19:02] <robin_sz> making progress? I saw the .ini was gettign a beating the other day
[23:19:14] <jmkasunich> a little
[23:19:25] <robin_sz> stuck?
[23:19:35] <jmkasunich> not enough time
[23:19:39] <robin_sz> ahh
[23:19:44] <robin_sz> thats a common problem
[23:20:01] <robin_sz> robin_sz has changed the topic to: Welcome to the Enhanced Machine Control forum | Regular Developer's meetings every Sunday between 14:00 & 18:00 GMTcould have some of mine, but im using it
[23:20:01] <ChanServ> ChanServ has changed the topic to: Welcome to the Enhanced Machine Control forum | Regular Developer's meetings every Sunday between 14:00 & 18:00 GMT
[23:20:08] <robin_sz> grr
[23:20:26] <robin_sz> you could have some of mine, but im using it
[23:26:23] <jmkasunich> zwisk, you there?
[23:26:30] <zwisk> yup
[23:26:55] <jmkasunich> looking at hal_register_module
[23:27:16] <jmkasunich> it looks like you have a second linked list to hold the mb struct contents
[23:27:36] <jmkasunich> why didn't you just add them as new fields in the comp struct?
[23:27:38] <zwisk> indeed. I may be getting myself into big trouble here on memory usage.
[23:28:13] <zwisk> Well, my thought is that the comp structure is in shared memory, and that all of this config information is meta data which will be in kernel memory. (Is this flawed? :) )
[23:28:30] <jmkasunich> the comp list is metadata that we want to move into kernel memory
[23:29:31] <zwisk> So, IIRC, the comp data structure has int's which are offsets into the shared memory buffer rather than pointers... so I thought it best to do a kernel memory based one using pointers.... I hadn't though all of comp would be moved out of shared memory...
[23:29:57] <jmkasunich> the int offset mess is something that will go away if the list is moved into kernel memory
[23:30:30] <zwisk> right... so my new linked list structure is a functional replacement for comps. (Hopefully I'm not stepping on anything or anyones toes with that notion...)
[23:30:57] <jmkasunich> the problem with my approach (moving it into kernel) is that it is all or nothing... making the move can't be done incrementally
[23:31:32] <jmkasunich> there should be only _one_ list of components, regardless of where it lives.
[23:31:43] <zwisk> hmm... ok. My confusion on that I guess is in that it's one big shared memory map with stuff stuck on the top of it. Maybe the whole comp structure needs to come out.
[23:32:30] <jmkasunich> it is a mess... I _really_ wish I could include pictures in the comments
[23:32:47] <zwisk> pdf in the docs folder is great for that...
[23:32:52] <jmkasunich> highly cross-linked data structures are both very powerfull and very confusing
[23:32:56] <jmkasunich> I know
[23:33:23] <jmkasunich> on my "to do" list is a coders level extension (appendix maybe) to the HAL_Introduction document
[23:34:10] <jmkasunich> we probably need two pics, one showing the data structs as the are now, and one showing what we want when we're done
[23:34:29] <zwisk> that'd be fab. Alas, I'm not very good with drawing.. :)
[23:34:56] <jmkasunich> I have the ability and tools do make the drawings (see the block diagrams in the HAL_Intro doc)
[23:35:02] <jmkasunich> just lack the time
[23:35:09] <zwisk> yeah... I hear you there.
[23:35:24] <jmkasunich> your interest in the HAL refactor is a double edged sword.
[23:35:39] <zwisk> yup. helping (I hope) but also eating away at your time.
[23:35:43] <jmkasunich> one the one hand, you are doing stuff, _and_ you are motivating me to get off my hump
[23:35:59] <jmkasunich> on the other hand, you are getting ahead of me
[23:36:48] <jmkasunich> one big change I want to make is converting the linear linked lists to binary trees
[23:36:53] <zwisk> yep. Keep in mind, too, that I don't have a huge amount of pride in this. I'm making a lot of changes, but understand if we back lots of 'em out, rename tons of stuff, or rework it.
[23:37:55] <zwisk> Hmm.. you'll have to tell me your thoughts on that at some time; especially with regards to the get root / get next concept.
[23:38:08] <jmkasunich> no time like the present
[23:38:20] <jmkasunich> halcmd.c
[23:38:45] <jmkasunich> wow... that's a little shorter than it used to be!
[23:39:10] <jmkasunich> I guess I'm looking for hal_cmds.c now ;-)
[23:39:47] <jmkasunich> hal_cmds.c:923
[23:39:51] <zwisk> haha... yeah :) Hope that's all good :)
[23:39:54] <jmkasunich> print_comp_list()
[23:39:55] <jmkasunich> sure
[23:40:27] <zwisk> ok...
[23:40:30] <jmkasunich> that funct gets the mutex, then traverses the list while printing, then releases the mutex
[23:40:34] <jmkasunich> pretty straightforward
[23:40:52] <zwisk> yep...
[23:40:57] <jmkasunich> _if_ it is running in user space and has direct access to the linked listthe user space code
[23:41:01] <jmkasunich> oops
[23:41:16] <jmkasunich> that should have said:
[23:41:21] <jmkasunich> _if_ it is running in user space and has direct access to the linked list
[23:41:43] <jmkasunich> but the plan is to move the list (which is metadata) to kernel space
[23:42:01] <jmkasunich> it is trivial to traverse the list in kernel space too,
[23:42:09] <jmkasunich> however you can't print the results from kernel space
[23:42:23] <jmkasunich> you need to pass the results back to the user space caller
[23:42:43] <jmkasunich> choices: 1) pass the entire list back to user space
[23:42:58] <jmkasunich> 2) pass one entry at a time back, let the user call again for the next one
[23:43:17] <jmkasunich> the problem with 1) is that it means passing an arbitrarly large amount of data back to user space
[23:44:15] <jmkasunich> the problem with 2 is that you must release the mutex after each item... what if by the time the user space prog calls again for the next item, that item has been deleted?
[23:44:27] <zwisk> right...
[23:45:36] <jmkasunich> I want to do 2, and get around the issue of list modifications by having the caller pass the _name_ of the previous entry
[23:45:55] <jmkasunich> it would then return the entry that is after that name, even if that name is no longer present
[23:46:19] <zwisk> Couldn't an index do the same thing?
[23:46:23] <jmkasunich> if you have a list that contains "A", "B", "F", "G", and someone asks you
[23:46:43] <jmkasunich> "what comes after "C", you can answer "F", even if "C" isn't there
[23:47:07] <jmkasunich> but if someone passed you an index to a "C" that has since been deleted, you're up a creek with a bad pointer
[23:47:45] <jmkasunich> am I making sense?
[23:48:16] <zwisk> yeah...
[23:48:28] <robin_sz> sort of ... do the bit about the million monkeys with typewriters again
[23:48:30] <zwisk> But inserting is still an issue, right? You could miss an item if one is inserted.
[23:48:34] <jmkasunich> I'm assuming that one instance of halcmd is running the "show comp" command, while another instance attempts to manipulate things - adding comps, deleting them, etc
[23:48:55] <jmkasunich> go back to the A,B,E,F example
[23:49:13] <jmkasunich> I'm traversing the list, just finished B
[23:49:33] <jmkasunich> when I say "next(B)", if a C has been inserted, I'll get it
[23:49:39] <jmkasunich> if not, I'll get E
[23:50:07] <jmkasunich> if C is inserted after I've already made it to E, then I'll miss C, but that's life
[23:50:33] <zwisk> yes, true...
[23:50:53] <zwisk> But it's imperfect either way, right? Just a matter of where you don't get data... on insert of delete...
[23:51:05] <jmkasunich> suppose the list was ABCDEF
[23:51:11] <robin_sz> better to miss someting than get a ref to soemthig thats gorn
[23:51:22] <jmkasunich> I'm reading it, just finished C, and ask for next(C)
[23:51:26] <jmkasunich> but C's been deleted
[23:51:58] <jmkasunich> if the search is name based, it will still find D, but it will do it by starting at A and looking for name > "C"
[23:52:46] <jmkasunich> if it was next(ptr_to_C), and C was deleted, I have a pointer to nothing (C may have been freed, even if not, it's next pointer likely doesn't point to D anymore
[23:53:39] <jmkasunich> so "starting at A and looking for name > C" always works
[23:54:18] <zwisk> cool... that works.
[23:54:27] <zwisk> It assumes that your data is sortable, and unique.
[23:54:37] <jmkasunich> the only problem is that to traverse a linear list of N items using that method results in searching the list N times, and if it's a linear search, I do N*N*0.5 accesses to the list
[23:54:54] <jmkasunich> a binary tree lets you search the list with logN accesses
[23:55:05] <jmkasunich> so traversing it will take N*logN accessses
[23:55:32] <zwisk> right...
[23:56:15] <jmkasunich> note that _all_ access to the list will be by name... if you want to know any field in the comp/mb struct associated with "B", you will search for "B"
[23:56:43] <jmkasunich> if you do the search only once, then remember a pointer to B, you risk problems if someone deletes B in the meantime - your pointer is no good
[23:57:21] <robin_sz> there is another solution
[23:57:22] <jmkasunich> just about every API will take a name, and go something like this:
[23:57:27] <jmkasunich> lock mutex
[23:57:31] <jmkasunich> search for name
[23:57:48] <jmkasunich> do whatever the API is supposed to do - get/set a field, etc
[23:57:51] <jmkasunich> release the mutex
[23:58:01] <jmkasunich> robin_sz: what is it?
[23:58:20] <robin_sz> well ... in Java, this problem is solved with an 'enumerator'
[23:58:55] <jmkasunich> how?
[23:59:16] <robin_sz> the lists is traveresed, a copy of references is made, and then you can always get the next item in the list from where you are by calling next
[23:59:25] <robin_sz> but . the key is that stuff cant be deleted
[23:59:40] <jmkasunich> right - it assumes you are single threaded
[23:59:54] <jmkasunich> but HAL can be modifed at any time