From:    jmkasunich@att.net
To: robin@redpoint.org.uk
Subject:    Re: log file
Date:    Tue, 30 Mar 2004 03:30:50 +0000
Content-Type: Multipart/alternative;
 boundary="NextPart_Webmail_9m3u9jl4l_1939_1085346706_1"


--NextPart_Webmail_9m3u9jl4l_1939_1085346706_1
Content-Type: application/octet-stream; name="chat040321.log"
Content-Transfer-Encoding: 7bit

<jmkasunich> what I'm trying to do is make the pdf version of a LyX doc publically available.  I was gonna use my ISPs webspace, but if there is a way to put it on linuxcnc that would be better
<SteveStallings> We can put it on LinuxCNC, but bandwidth may become a problem. Why not put it on the SourceForge?
<jmkasunich> that works too.
<jmkasunich> I'm just trying to find someplace to put it where I can update it from the command line... so each time I commit a new version of they Lyx, reviewers can see a new version of the pdf
<paul_c> I'd agree with Steve - Use the SF web space...
<jmkasunich> perhaps it's time I get (and learn to use) access to the SF webspace
<paul_c> more docs to read I'm afraid.
<jmkasunich> what else is new... how bad?
<paul_c> It's not too bad - I uploaded the original mail archives with no real problem.
<SteveStallings> Hey guys, I'm still looking for someone to share a room at Webbers during the EMC fest. Any takers or ideas?
<jmkasunich> I was planning on my own room at one of the cheaper places
* paul_c was looking @ Super-8
* jmkasunich hasn't shared a room with someone not his wife for many years
<jmkasunich> paul_c: speaking of the archives - I don't see a link to them on the emc SF homepage
<jmkasunich> looks like you have to go to linuxcnc.org and then link back to SF to find them
<SteveStallings> OK, getting my own room at at cheaper place is fine. I just thought I would be "isolated" since I will not have a car during the fest. I'll look into the Super-8 in hopes that ride sharing will work out better.
<jmkasunich> I heard ray say that the super 8 didn't have phone into the rooms... if you don't have a cell phone that might be a problem... I was planning on the middle priced one for that reason.
<SteveStallings> Oops, I have a cell but that does not help with internet. I really need that to stay on top of remote server administration.
<paul_c> we *should* have full access from Smithy
<jmkasunich> SteveStallings: I believe you can dial out no problem... I intrepreted ray's statement as you can't dial into the room directly, or something like that... we need to ask ray directly if/when he joins us
<jmkasunich> speaking of ray... he's usually here by now
<jmkasunich> paul_c: yeah, the URL is available at linuxcnc... but only there
<jmkasunich> so even if I put my pdf on SF, nobody could find it unless we also add a link at linuxcnc, or I post the url, etc
<jmkasunich> anyway, I'll read SF docs and figure out how to upload the file
<paul_c> Or get you set up with an account so that you can alter the links...
<jmkasunich> an account at linuxcnc.org?
<paul_c> Steve ?
<SteveStallings> Checking.... I thought John already had one....
<jmkasunich> if so, I never used it (or even learned how to log in)
<jmkasunich> morning ray
<jmkasunich> we were talking about the phones at the super 8
<jmkasunich> did you say something about them being a problem
<rayh> Call out but don't expect any outside calls to get in.
<jmkasunich> that's what I thought you said
<jmkasunich> room to room calls work?
<rayh> It was a mess, wife, girlfriend, sherline users, even Matt couldn't get through.
<jmkasunich> wife and girlfriend?
<rayh> And we all know how persistent Matt can be.
<rayh> Might've been a wee bit of hyperbole there.
<jmkasunich> I'm not so worried about calls from home - I'll call home rather than the other way around... but coordinating with guys at the other hotel might be a problem
<rayh> Right.
<rayh> Eric R. had some advice about conventions on his site.
<jmkasunich> what did he have to say
<rayh> He said that these kinds of events need a central source for info.
<rayh> At least a message board with updates about where folk are meeting
<paul_c> web or wooden ?
<rayh> A courtesy suite would be even better.
<jmkasunich> web is pretty useless for me at least... I won't have web unless I'm at smithy, and if I'm there I won't need the board
<rayh> No problem with web from webers or best but no nets at s8
<jmkasunich> does best have inet, or just phones so you can dial out to your own isp?
<rayh> They say they have inet in the rooms.  I saw an rj45 by the phone.  Didn't try it.
<jmkasunich> splitting a room at webers is starting to look better
<jmkasunich> being scattered over three hotels might get old pretty quick
<rayh> They are all within a few hundred feet of each other.
<rayh> 30 feet between s8 and western.
<rayh> Would have to use the front doors at western after hours.
<paul_c> what's the longest CAT5 cable are you bringing John ?
<jmkasunich> I have a 50 foot if we need it (wasn't planning on bringing that one but I can)
<rayh> Don't think you can get into s8 without a key after hours.
<jmkasunich> the rest are 10ft or so
<jmkasunich> maybe 20
<jmkasunich> My original plan was western, I think I'm gonna stick with that
<rayh> There is a really nice open area where informal meets can take place at western.
<jmkasunich> sounds good to me
<rayh> We really need a granny conference coordinator.
* jmkasunich takes a big step backwards
<rayh> But perhaps if we simply say that after dinner all meets will be in western.
<jmkasunich> other than sunday dinner and monday meeting, do we have any other activities actually at webers?
<rayh> Nothing scheduled.
<jmkasunich> well I'm convinced - I'm staying at western
<jmkasunich> steve - if you are at western or s8, you can ride with me to smithy, etc
<SteveStallings> OK, I guess the dust has settled, I'll book a room at the Best Western.
<rayh> I'd think that we could get some floorplans and make up a list room numbers and phone numbers so folk can find each other.
<jmkasunich> rayh: what is the neighborhood like around there
<rayh> residential north and south.
<jmkasunich> I'm thinking about a computer back of my truck (with a locked cap over the top - but if they like what they see thru the window, the cap can be broken into)
<rayh> The hotels sit between major roads.
<jmkasunich> maybe a tarp would be a good idea to hide the goodies
<rayh> I don't think you'll have a problem at western.  Plenty of lights.
<rayh> Quite a bit of commercial and industrial to the west.  It is a way east to the less desirable parts of Ann Arbor.
<jmkasunich> rayh: just a word of thanks for setting all this up, and being our "eyes on the ground" with hotel details
<rayh> Course, being one of the cleanest cities in MI.  It's pretty good.
<rayh> No problem.  I like doing it.
<rayh> But next year we really need a conf coord.
<rayh> Cause my work is more like a shotgun.
<rayh> Three shots at best and a fuzzy target.
<SteveStallings> Shotguns have coordinated lots of things... like marriages.
<jmkasunich> rayh: did you see my latest adds to Hal_Intro?
<rayh> I suppose a real conf coordinator wouldn't schedule a room for 35 and put up his card as guarantee.
<rayh> Not had a chance yet, John.  Will soon.
<jmkasunich> you mean the meeting room?
<jmkasunich> so $13 * 35?
<rayh> Right.
<SteveStallings> OUCH!
<rayh> I'm thinking that we might get a corporate sponsor for that dinner.
<jmkasunich> there are 11 on the list for the fest... I expect we'll have more for the meeting (I hope we'll have more)
<rayh> Still twisting arms.
<jmkasunich> I thought the dinner was "pay your own way"
* paul_c is also bending ears
<rayh> I've talked with several who are not on the list, yet.
<rayh> If pablo and Robin can make it that would be a good addition.
* paul_c prods picnet
<rayh> I've not talked with the profs from Grand Valley state yet.  Or Hassan.
<rayh> I'm working on Abdul.  I'll see him in a couple weeks and will ...
<SteveStallings> Good thing the conference is after the show. We can promote it at NAMES and possibly get a few more.
<rayh> Right.
<rayh> I know that George Tecos wants to come.  Not certain he will be in the states then.
<rayh> He claims to be the first person to apply pc to motion using a dsp chip.
<jmkasunich> I'm looking forward to the fest, but at the same time I wish I had a couple more months to prepare
<jmkasunich> every time I write more HAL doc, I find a few changes I want to make to the code itself...
<rayh> This is exactly what happens every year as we get ready for NAMES.
<rayh> Matt's got five projects in the fire, Steve four more.
<jmkasunich> we're gonna introduce HAL to folks, and as soon as I go home I'm gonna start changing things to confuse them
<rayh> I was told, back in my teaching days, that a moving target was harder to hit.
<jmkasunich> harder to learn too
<jmkasunich> it's four weeks from today, right?
<jmkasunich> no, five weeks
<rayh> My impression of HAL is that once people see how it fits together, it will just be a matter of configuration tools.
<jmkasunich> rayh: how bummed will you be if I stop docs for a week and work on code?
<jmkasunich> there are a few key changes like read only vs r/w parameters and the new threads api that I'd like to revise _before_ we teach folks the old way
<rayh> I'd teach them the new even though it isn't quite ready.
<jmkasunich> hard to do a demo that way
<paul_c> Then we also have a few issues looming with the 2.6 kernels
<jmkasunich> paul_c: those issues will be (mostly) hidden from users/integrators
<jmkasunich> so I'm content to address them after NAMES
<paul_c> It is a concern for the code writers only.
<jmkasunich> there are other changes I want to make to hal_lib as well, but if they're internal, I don't mind doing them later
<rayh> jmkasunich: I see you moved threads and procs back into chapter 1.  That works for me.
<rayh> No problem, John.  You do what you need to do.
<jmkasunich> that is still subject to some fine-tuning.. but I wanted the examples to be a chapter 
<jmkasunich> matt - where does motion.c and friends stand right now?
<paul_c> Still needs more comments added...
<jmkasunich> but does it work?
<paul_c> a few grey areas that need to be gone through with Fred
* jmkasunich wonders if we can run a machine (even poorly) at NAMES
<mshaver> jmkasunich: about where it stood last week ;) haven't had time to work on it lately, but dac write & encoder read all work, so it should be usable
<paul_c> I have had it running - But not hooked up to anything
<jmkasunich> ok... understand what you mean about time
<mshaver> I'm going to pick up NIST's machine next week (unless more unknown things intervene), and try to get it going
<jmkasunich> my projects for now until names:
<jmkasunich> 1) HAL_Introduction.lyx
<jmkasunich> 2) changes to HAL that are visible to integrators (and thus change HAL_Intro.lyx)
<jmkasunich> I had hoped I could work on integration with the rest of emc, but I just don't have the time
<rayh> HAL_Introduction.lyx is starting to read really nice, John. 
<jmkasunich> thanks ray:  the bad news is that I can see how much work it will take to get the rest of it to the same level....
<rayh> You talked about giving folk access to the papers ahead of time.
<jmkasunich> yes - more reviewers is better, I think?
<rayh> We could do that at linuxcnc.org if we posted a pdf and a link on the fest page.
<jmkasunich> uh... we may be talking about two different things here
<paul_c> Will we have an OHP on the Monday ?
<rayh> Good plan, Steve.
<jmkasunich> this morning before you arrived, we were discussing posting the pdf _now_, and updating it every time the .lyx is updated.  that would be for our benefit as writers, cause folk could review and comment
<rayh> We can have an overhead.
<rayh> We'll also have a pc projector from NIST.
<jmkasunich> the other thing is posting or having paper copies of the "finished" doc at names, or maybe 1 week before, for integrators to read so they don't come into the presentation blind
<dave-e> If Matt can't test I may be able to.
<rayh> I agree with the idea of read ahead.
<paul_c> The Projector sounds as if it will be more use than an OHP.
<rayh> I'm thinking that the linuxcnc may be enough.  
<dave-e> OHP works well for ad hoc stuff
<jmkasunich> yes - I was thinking of doing the HAL demo with the projector... use scope, the whole nine yards
<rayh> Certainly copies of the papers at the door.
<jmkasunich> HAL_Intro.pdf is 29 pages already... it will be close to 100 when finished (maybe 50 by NAMES)
<rayh> Yep.  I think that's great and I'll pay kinko for the copies.
<rayh> My comments will be long but the paper short so that should balance out some.
<jmkasunich> I'm glad you pushed me into starting... I knew I needed to do it, but I was procrastinating.  Another week or so and it would have been too late
<rayh> I'll see if Fred can bring copies of the jitters paper.
<rayh> If you need images of halmeter and halscope I can make then here and put them in images.
* paul_c needs to get BDI-2.21 and BDI-Live started
<jmkasunich> that reminds me: how do you do a screen capture under linux (TNG, KDE)
<paul_c> jmkasunich: K->Graphics->ScreenCapture
<mshaver> rayh: I gather from your comment that you got halscope running -- impressive ain't it!
<paul_c> or run ksnapshot from a terminal
<jmkasunich> thanks paul
<rayh> I did but didn't try it on any sigs.
<rayh> Didn't know enough.
<rayh> I will know enough as soon as you write two more examples.
<jmkasunich> rayh: the next step in the doc is to load another component - probably stepgen - and connect them... then meter and scope stuff
<rayh> When we put graphics in Lyx, it works a little better to put them in a float.
<rayh> Dave just started doing this with an integrator chapter on servo tuning.


<dave-e> speaking of servo tuning, what is the easy way to get info over IP from my shop machine to house, both linux?
<paul_c> once you can ping the machines on the network
<paul_c> you have several choices to transfer data
<dave-e> paul- would you lay out choices for me...an email would be fine
* paul_c uses IPCop for dhcp & routing.
<rayh> could paul explain?
* paul_c has IPCop to assign IP addresses to most of the machines on the network
* jmkasunich uses a stripped RH7.2 (no X) with udhcpc for inet side, and dnsmasq for dhcp/dns on the local side, iptables firewall
<paul_c> dhcp avoids the hassle of setting each computer up with static addresses
<jmkasunich> right
<jmkasunich> at the fest, boxes with dhcp clients should be able to plug and go... and dnsmasq serves their names on the local net
<paul_c> Once each machine has it's own IP address, setting up nfs and ssh is almost trivial.
<rayh> Good.  We should tell all folk bringing machines that they need a dhcp client.
<jmkasunich> if they have linux, they have a client
<jmkasunich> may need a minor tweak to a config file to enable it if they normally connect using dialup
<jmkasunich> if they use DSL or something like that (or have a home network), they will probably be set already
<rayh> The boot from knoppix has it but the hd inst doesn't.
<rayh> I had to get it from a mirror.
<jmkasunich> I think I'm gonna bring the farm into NAMES and hide it under the table... so we can connect individual boxes to it if we have a few spare moments
<rayh> This next is a change in direction.
<rayh> I got a note from a fellow who had been handed by knoppix hd inst paper by his boss.
<rayh> Boss loves knoppix.
<rayh> Boss has a mill.
<rayh> Wants employee to make them work together with emc.
<rayh> Employee can't get it all to work.  Posts a note to me.
<rayh> We're working on it but the interesting thing is that no ome would have heard a word if it had worked the first time.
<rayh> It makes me wonder how many of those 1.5 T that Sherline uploaded are running machine tools that we will never hear about.
<rayh> Except by accident.
<rayh> jmkasunich: You should feel free to edit the stuff I offered for the HAL_Int.
<jmkasunich> rayh: you mean your paragraphs and sections?
<rayh> Right.  Anything I offer is a suggestion only.
<jmkasunich> well if I don't like it, I will edit it... so far I haven't seen much I don't like.  You should feel free to do the same... this is an open project after all
<rayh> Okay.
<rayh> I need to go away in a bit.  Any more questions about fest?
<SteveStallings> Nope, I am settled for now. Got to get to work on PCB layout anyway.
<rayh> Shall I go ahead and make pages for the papers and link to pdf versions? 
<jmkasunich> rayh: yes
<rayh> Okay.  I'll see if I can get a copy of Fred's as well.
<jmkasunich> rayh: you mentioned making link... this is on linuxcnc.org?
<jmkasunich> we should have a link there to robin's page where the minutes of these meetings are posted
<rayh> Right john.
<rayh> I'll put the link to the irc in the front page at linuxcnc as well.
<jmkasunich> did we decide where we want to actually host the pdf?  we want a link to it at linuxcnc, but host it at SF for bandwidth reasons?
<rayh> Would bandwidth be a problem with pdfs, Steve?
<jmkasunich> depends on how many folk take it into their heads to read the file
<jmkasunich> the pdf is 162K right now
<SteveStallings> John, that would be my first choice. If web site at SourceForge is difficult to get going, it is OK to put content on LinuxCNC for now. Large files just seem to be a magnet for some people who download everything even if they have no idea what it is about.
<SteveStallings> John, Files under 1 Meg should not pose a problem with bandwidth.
<paul_c> Sherline is running close to 1 terabyte/month
<jmkasunich> I expect it will start to bloat once we put images in there... but my goal for now is just to let folks review and comment on the doc in progress.  when it is ready for wide public distribution, we'll move it
<rayh> I'm thinking of intermediate pages.  One for each of the presentations so that we can put up links to background material and such.
<rayh> We could also put up the latest versions or when a pdf was changed. 
<jmkasunich> I was thinking about an intermediate page too - one that would tell folks "This doc is a work in progress, if you want to review and comment, please do so, but don't just download it for the sake of downloading"
<rayh> And if there were comments about a part of the report that we wanted others to see we could put it there as well.
<jmkasunich> sounds like we're on the same page
<rayh> Okay.  I'll make the intermediate right now. 
<paul_c> jmkasunich: Re emc2 for 2.6.x kernels
<paul_c> Support looks as if it should be fairly easy to incorporate into the existing makefile structure.
<jmkasunich> that's good to hear
<paul_c> at the source code level, only the RT/kernel modules will need any signifcant changes.
<jmkasunich> any possibility of hiding the changes in RTAPI?
<jmkasunich> after all, that's what RTAPI is for
<paul_c> initial review of the docs would seem to suggest the changes would be limited to headers and params
<jmkasunich> you mean things like MODULE_PARM()?
<paul_c> yup
<jmkasunich> maybe we #define RTAPI_PARM in rtapi.h, so hal components and such use RTAPI_PARM() regardless of version, let the RTAPI_PARM macro figure out the version stuff
<paul_c> Got a topic for discussion at the 'fest
<rayh> Got the page open on vt4
<paul_c> Writing & compiling modules for the 2.6 kernel.
<paul_c> and also "The evils of autotools (and why we may need them)"
<rayh_> Love it!
<rayh_> You thinking of autotools in emc2?
<paul_c> If we are going to support 2.6.x kernels as well as 2.2 & 2.4, I fear it is a case of we will have to use them.
<rayh_> So we will need to talk about which and how much?
<paul_c> the two main tools are autoconf and automake
<paul_c> only the code writers need to worry about autotools - The end users will still just see a configure script
<paul_c> http://freshmeat.net/articles/view/889/ will form the basis of a report.
<rayh> I'll still need to add pages for the discussion as more stuff comes in.
<jmkasunich> paul_c: mshaver: I just noticed that make depend is busted for the emc2/emc tree.  I changed something in hal.h, and did a make.  Everything in the hal tree that includes hal.h got rebuilt, but nothing anywhere else did
<jmkasunich> I know there are at least a few files in emc that depend on hal.h
<jmkasunich> emc2/src/emc/hal_intf/exthalmot.c should be rebuilt whenever hal.h is touched, and it isn't - makefile bug or something

<jmkasunich> paul_c: did you see my note about make depend?
<paul_c> yup.
<jmkasunich> maybe another sign that we need to bite the bullet on auto-tools?
<paul_c> did you see my propsals for a presentation ?
* jmkasunich looks at fest page again
<jmkasunich> my criteria for a build system:
<jmkasunich> a non-make expert should be able to add a simple driver to the make system minimal pain
<paul_c> If automake is used, makefiles disappear...
<jmkasunich> hopefully with HAL folks like Jon E and Abdul can cut/paste their way to drivers for their hardware - they shouldn't need to be make or autotools gurus to add the drivers to emc2
<jmkasunich> from the comments that followed the article yesterday, it seems like autoconf is much nicer than automake
<paul_c> autoconf is only part of the solution (if we can call it that)
<jmkasunich> some folks disagreed with the article, said the author was blaming automake problems (which they acknowledge are bad) on autoconf (which they say is not so bad)
* paul_c sees both as being the work of a devil
<jmkasunich> they also said you can use autoconf without automake
<jmkasunich> yeah, but the concensus is that they are no worse than the alternative
<jmkasunich> I for one have no interest in the perl based tools the original author was proposing
<paul_c> eeuuww... Perl...
<jmkasunich> right
<paul_c> pearls are for hanging round the necks of pretty women
<paul_c> not for programming
<Imperator_> Hi John, I have added a new function to your halcmd utility, it is to set signals
<paul_c> didya commit it ?
<jmk_away> what do you mean set signals? you mean change their value?
<Imperator_> jep, I have copyd the code for seting parameters
<Imperator_> and it seams to work fine
<jmk_away> I'm not sure how I feel about setting signals... 
<Imperator_> I have to edit also the man page, then it is ready
<Imperator_> why ??
<Imperator_> it is very good for testing drivers
<jmk_away> using the electical analogy that HAL is based on, that is the equivalent of over-riding the output of a part
<jmk_away> the supply component that Matt works for testing things - I'd rather see it extended than add forcing of signals
<jmk_away> if a signal is connected to a source, the value you write would be over-written by the source anyway
<jmk_away> if the signal is not connected to a source, then perhaps the force might be usefull...
<jmk_away> commit your changes... I'll revise it so it only allows forcing signals that have no source
<Imperator_> yes, it is good for quick testing
<jmk_away> (the hooks are in there, it won't be too hard)
<Imperator_> ok, i send you a mail
<jmk_away> look at line 681 of hal_lib.c (I hope that line number is correct, I've been editing in there)
<jmk_away> comment is /* are we linking write only pin to sig that already has writers */
<jmk_away> that code (or something like it) could be used to allow force only to signals with no source
<jmk_away> but I have serious reservations about allowing force if the signal already has a source
<jmk_away> I think all you have to do is "if (sig->writers > 0 ) refuse to force"
<Imperator_> jep i have seen this
<jmk_away> as long as signals have no source, forcing is more convenient than using the supply component... the more I think about this, the more I like it
<jmkasunich> Imperator mailed me his code...
<jmkasunich> I went ahead and added it here, since he doesn't have CVS running
<jmkasunich> he intended to use it to test drivers, etc, by twiddling their pins (without needing to load another component)
<jmkasunich> wouldn't it be better to extend halcmd to let you set _unconnected_ component pins, instead of signals?
<jmkasunich> that skips the nuisance of having to connect a signal to a pin before you can twiddle it
<jmkasunich> old way:
<jmkasunich> load component under test
<jmkasunich> load supply
<jmkasunich> make signal(s)
<jmkasunich> link signals to pins of component under test
<jmkasunich> link signals to supply pins
<jmkasunich> twiddle supply params
<jmkasunich> his way:
<jmkasunich> load component under test
<jmkasunich> make new signals
<jmkasunich> link signals to pin of comp under test
<jmkasunich> twiddle signals
<jmkasunich> pins way:
<jmkasunich> load component under test
<jmkasunich> twiddle it's pins
<jmkasunich> paul_c: comments? (I'd like to ask Imp, but he's gone)
* paul_c hasn't gotten into the HAL mindset yet...
<jmkasunich> paul will get dragged kicking and screaming at NAMES ;-)
<jmkasunich> I'm tempted to change to the pins way... but wanted to run it past someone first
<jmkasunich> (biggest problem I see with the pins way is that "setp" is already taken for "set parameter"...
<jmkasunich> If I didn't have to worry about pins/sigs/params with the same name I could just call it set, and let it automatically figure out if it is setting a pin, or a param, or a signal
<jmkasunich> right now each type of entitiy (pins, etc) has it's own namespace
<jmkasunich> what if there was one big namespace - then no duplicate names
* jmkasunich is talking to himself

--NextPart_Webmail_9m3u9jl4l_1939_1085346706_1--