the commit email script seems to be broken (or missing) for the documents tree jmkasunich: Ray asked for the Docs commits to be left out of the email logs I asked Paul to do that before I committed a whole batch so it wouldn't spam everyone. I can't speak for everyone, but the reason I subscribed to that list is to see when and what is changing. I don't consider it spam... (I get a little annoyed by Will's commits with "." as a log message, but they are easy to delete... I for one would like to see everything logged - that way I know when I need to do cvs up Thought about those missing reports when I added the hal file and saw your update. can reinstate the mail reports easily enough... I did miss them when we started working on hal-- lyx. BTW, the log normally truncates very large files, doesn't put the whole thing in the message I don't thing that there will be such major overhauls in the future. Should be no problem with single files at a time. cool, sounds like we all agree... * jmkasunich likes agreement Dave E is writing a servo tune chapter for int. That and hal are the current pushes. jmk: I liked the additions to hal. I tried adding the comments out of pid and they work after a fashion. Doc commits *should* generate an email now. Thanks again, Paul. thanks paul rayh: when I do a cvs up, it complains about directory temp_html/part3/images... has that been deleted or something? Don't know. The only thing that should be left in there is Tom's 274 doc. jmkasunich: delete the tep_html dir on your box and do a "cvs up -d" again. on my box there are 3 gifs and 10 jpgs I should remove everyting under that and ask sf to remove it. the whole temp_html dir? Temp doesn't work will with cvs. How would we do these sorts of things. temp is used when converting lyx to html, pdf, and such? should we put a list of dirs together and get them removed in one hit ? That's what I intended when I put the old handbook in there. Now there are just a whole bunch of empty directories. could make be used to create temp dirs and also perform the lyx->whatever conversion? Even Tom's pages are getting a bit dated. also - would something like the directory.map file in emc2 be usefull for documents? Yes! note the last couple lines in emc2/directory.map - those .dirs are not in CVS - they are created by make I'm beginning to think that we might store stuff like Tom's pages, and other stuff that we want to push into the emc docs in linuxcnc. We don't get cvs there but we can save things, work on them as we see fit and then move them into the cvs when we have a better idea where they ought to go. paul_c: I'm with you about making a single list of dirs to be removed. Clean the whole structure up a bit. I have two nominations... emc/emcnml & emc_HAL paul_c: agreed about emc_HAL and emc/emcnml jmkasunich: rcslib/plat ? I'm not qualified to comment on rcslib Are we keeping rtapi up to date? rayh: you mean emc2/src/rtapi? No the module by that name. paul_c: re: rcslib - I'd not touch any of that - the NIST guys might still want it rayh: oh, you mean the rtapi top lebel CVS tree... emc/scripts -- I'd think that everything but generic should go away. rtapi is finished with - Had been using it as a sandbox for testing ideas all rtapi development is now in emc2/src/rtapi so that could go away too emc/emcnml is empty the list is longer than I expected.... i did a hell of a lot of work on tcl/lib but it isn't used now?? emc/src/classicladder ought to go. emc/src/emcmot/experimental??? that can go too I have no hesitation about tossing empty trees like emc_HAL, rtapi, and emc/emcnml but trees or subtrees with code in them? I'd rather label them as obsolete in directory.map, but keep them for reference emcdevelop/emc/src/emctask/XmEmc is a project John Moore started back when we had a gui committee. gui committee sounds like one should wash one's hands. Perhaps we should revive it as HMI committee. these kind of facts should be transferred from Ray's memory to directory.map Yep -- cause oldtimers is starting to set in. ;-) emc/src/ncutils is the brand new stuff from dean. Matt thought that we might want to move that from where it is to a module by itself. then put cp1 and cp2 and bmp2cnc in there also. Then Tom K offered a bunch of stuff that could work in that same concept. the advantage of keeping it under src/ is that everything makes at one time I'd be inclined to leave ncutils where it is now and perhaps put cp* & co in as sud-dirs ??? ncutils/cp1 ncutils/cp2 ncutils/bmp2cnc But right in the source tree of emc? yes. K Let's do it. think of emc as a package, not a program... the package comes with emc the program, and with some usefull utils. I just created a directory.map in emc/ I'll contact Tom and see what sort of dir tree he needs. I'll capture a few of the recent comments, but hopefully the "veterans" can flesh it out. Some of Tom's stuff was perl but that should be okay cause we'll have tickle in there as well. * paul_c sees emc as a scratchpad and testing area with emc2 being a clean offshoot * rayh sees it as a very real and vital area for sherline, smithy, and several other unnamed entities. * jmkasunich agrees with ray... even tho I think of emc2 as the future of emc, I don't want to start using emc1 as a scratchpad... (but I still see emc2 as the clean offshoot) and I hope that eventually (a year or more from now) sherline, etc, will make the move to emc2 Scratch in emc as much as we want as long as the core of it will still compile and run. Sooner if possible. if possible, yes - but not at the expense of quality - I'd still like to revisit each and every file, and decide "is this needed? is it as good as it can possibly be?" that takes time when (if ?) NIST starts playing around with stepNC in EMC, stuff is going to get broken and the make PLAT is going to get even worse... * rayh laughs at the mess that we could make in emc. the root dir is way too cluttered that's why I really only want to drop empty trees and add a directory.map its not a question of visiting each file. its a question of structure and encourages emc2 I suspect by the time we are through, adding StepNC support to emc2 will be much easier than reworking emc robinz: yes, come up with a structure, then decide if each file fits that structure... delete or modify as needed As much as I dislike, distrust, and am confused by branching, can we scratch in a branch of emc actually if the scratching is something that we want to put into emc2 if it works, the branch should be from emc2 scrtaching? except in the short term... if you need to scratch something that interacts with a working emc/nml system, emc1 is the only choice oh, prototype, doodle etc talk of where to put "scratchpad" or "sandbox" code - stuff that might or might not pan out in a branch thats what branching is all about, make a branch, play without upsetting the main trunk, merge if its good, abandon if its no use right requires a level of CVS-fu that many of us are unsure of and of course branch files don't even clutter up checkouts of the main trunk but a good reason to learn... * paul_c invites robinz to give a CVS presentation @ emcfest I've been using Tortoise CVS under 'doze awesomely good software * jmkasunich seconds pauls invite * robinz stares at mounting piles of work paul: I'll put Robin down as a morning presenter. I have three machines to build and ship in the next 6 weeks Are you up for Fest, Robin? its looking possible still, but very tight on time paul_c: your mission is to kidnap robin and put him on a plane If I devaluate the dollar a bit more??? well, money is not so much of a problem anymore I now have some, not a lot, but enough Well in that case!!! * paul_c checks shipping costs with fedex.com time however is *very* valuable at the moment (read 14 hour + days as far as the eye can see) That presentation could be a cvs cheat sheet and a demo? I could just handout copies of the RedBean book :) I could pay richardc to do it ... Yea. But a condensed and aimed thing for EMC would help me a lot more. robinz: your presence at Fest is for more than CVS - you have a good grasp of object oriented design, and have realworld experience with both emc and the competition yeah, I do want to go .. honest :) And I want to get a sitdown and work for a bit on what you've done with tkemc. Back to directories to remove -- what about rs274 and new? rs274_new is the current interp I think there may be some old targets that use rs274 So we leave them both for a while? that would be my recomendation... suggest we mark directories to be deleted in directory.map over the next week or two... when we are all happy with it, we extract the list to be deleted from there and submit to SF Sounds good to me. I'll commit the first pass directory.map a little later today for emc/ that is.. ray - you willing to tackle the one for documents? emc_HAL and rtapi don't need one - we already know those whole trees are going away Uh. Sure. you know what is what in that tree better than anyone else I'll try to model it after what you are doing. I just copied the one from emc2, and I'm sitting here ls'ing the emc tree and editing the map There is a lyx README in there already but it doesn't try to deal with information structure. the map is just to give a quick overview of the structure - one line per directory even if a particular directory has 100 files in it What is missing from emc2 to enable it to be used with a "real" machine ? real? as in a Sherline at the low level end, it should be able to run step/dir thru parport now (as far as HAL and driver are concerned) I don't know where motion and the higher level modules stand the GUI and the rest of the usr space stuff works. Matt said that he wanted to have it running NIST's sherline at the show. what about emcio, or iotask, or whatever that part is called? was leaving the IO side to the HAL expert the NML <--> HAL layer is what I was referring to... I'm willing, but need help on the NML side a Sherline doesn't need most of it anyway. I see directory.map lists each file and what it does. We need that for documents/images? rayh: it doesn't lists files, just dirs (mostly - a few files might be mentioned) If I don't include any files, the directory.map looks pretty sparse. If I include files it looks pretty l o n g. sparse is good - it means we don't have a fscking huge tree. if you want to include a few key files and describe them, that is good... but don't include them all, or you can't see the forest for the trees first pass emc/directory.map committed - everyone should feel free to review and mark it up " tree -d | grep -v CVS | wc " says there are 41 directories in the documents tree hmmm... same command in the other trees: emc: 75 dirs rcslib: 136 emc2: 50 and you don't want to list all the files in rcslib.... dropped the -d in tree: emc2: 570 emc: 1193 documents: 501 rcslib: 1719 of which, only 80 or so make up the core right... and those counts also include object files, etc... would be interesting to do it after a "make clean" What would you think of cleaning up and moving Tom's stuff on SF into documents/RS274NGC. It would be nice to lyx it all but I don't know how. rayh: if we can't lyx it, just refer to it in the lyx and let people go there. Let me correct that last statement about lyx. I can import html and will try. but I like the idea of moving it into cvs I just committed a first draft of documents/directory.map cool... I see paul has revised the emc one already too just cleaned up the white spaces.. Imperator_: do you mind if I use your driver as the basis for the skeleton driver? i was thinking in the same way maybe i make a succestion for such a driver during the next week, because when i understand that skeleton, than others will understand that also :-) so much to do, so little time to do it in... I've been working on a document to explain HAL to integrators (also good for explaining the concepts, but not the details to developers) but perhaps I should take a little break from that and make the skeleton driver for developers i can do that also, if you want please do... I would be most grateful ok, then i will send it you during the next week for signing :-) thank you