00:55:01 rayh has joined #emc-devel 00:58:22 LawrenceG has quit 00:59:08 LawrenceG has joined #emc-devel 02:20:06 rayh has quit 03:25:30 LawrenceG has quit 04:00:56 LawrenceG has joined #emc-devel 08:52:36 [Global Notice] Hi all. Apologies for not getting back with you on that main rotation server split. We're looking at the problem. Meanwhile, US donor tax receipts for paypal donations have been sent to your paypal email address. If you need a receipt and haven't received one, please message me. Thanks! 08:54:09 [Global Notice] Those are the 2005 tax receipts. We're about to start our 2006-2007 fundraiser for PDPC, so if you would like to help get us going a bit early, please take a look at the freenode website ( http://freenode.net/pdpc_donations.shtml ). Thanks, and have a great morning! 14:15:25 rayh has joined #emc-devel 16:43:07 SWPadnos is now known as SWP_Away 17:13:07 SWP_Away is now known as SWPadnos 19:45:07 weird - I wonder if CIA is having trouble 19:46:42 Regarding? 19:47:08 the docs directory you just added - I got no CIA message, but I did get a SF commit message 19:48:20 There you go. Proves it. 19:48:26 heh 19:48:41 of course, it could have been freenode, or chatzilla as well 19:49:08 I want to replace all instances of # Path to help file 19:49:08 HELP_FILE = docs/help.txt 19:49:28 with the new. Is there a handy way to do this. 19:49:43 other than babelfish 19:49:52 cradek can tell you the correct incantation of find, xargs, and sed 19:50:06 you're trying to replace the text in all the ini files, right> 19:50:08 ? 19:50:10 thanks 19:50:17 Yep. 19:51:14 ok - something like find . -name *.ini -print | xargs {something} sed -e 's/docs\/help.txt/new\/path\/to\/docs/' 19:51:21 rayh: we need to figure out how to handle this properly. Whatever you change this to, it will fail to work for make-install or run-in-place 19:51:21 but the something is where I'm fuzzy 19:51:47 rayh: so changing it is a waste of time right now. 19:52:09 too bad there's no include for ini files 19:52:17 I suppose adding a help variable like the tcl vars in ,in is the proper way to go. 19:52:31 SWPadnos: that's one possible answer. 19:52:49 or an env var that has the EMCDOCROOT 19:52:50 SWPadnos: also, configure could write appropriate changes to the ini files we distribute. 19:52:50 Course I've got no use for install and think it is a great waste of effort for near zero gain. 19:53:04 other than a perceived "correctness." 19:53:08 rayh: you can't simultaneously say that and be happy that there are deb packages. 19:53:49 it allows people to test out new versions, but not destroy the default installation in the process 19:53:58 Sure I can. I'm blissfully ignorant of the finness and know that synergy does it every day. 19:54:12 ie, shop foreman looks at new capabilities, but bonehead still runs the default install from his desktop icon 19:54:45 rayh: I don't want to debate about it right now. I'm busy working on deb packages. 19:54:51 I've got zero faith right now in reversion to previous installs. That doesn't work any better than my broken snowblower. 19:54:51 heh 19:55:12 cradek: I know the feeling. 19:55:22 that's the point - you never have to revert if you test in one dir, then only install as default when you're satisfied that nothing (new) is broken 19:55:50 But I would like to get at least the start of help at the ability level of the old system. 19:56:07 do the tcl programs know where they are? 19:56:29 rayh: you could add a hack to tkemc that searches a few likely relative and absolute paths to find its help file. That's how it finds its resources already. 19:56:47 if so, make the doc file ../docs/help.txt or whatever 19:57:19 Do these debs know the difference between install and run in place? 19:57:34 it coud search ../docs/tkemc-help.txt /usr/share/doc/emc2/tkemc-help.txt for instance 19:57:45 .debs are always "install", unless you explicitly tell them otherwise 19:57:48 a deb always installs to the system directories 19:57:54 /usr/bin etc. 19:58:09 actually, it's already a relative path to the docs, just make it relative to ../../ 19:58:17 Unless you build them to install in a single directory. 19:58:27 (or whereever EMC2DIR is, relative to the tcl dir) 19:59:15 ah forget it.who needs help anyway. wish I could revert the directory I just added. 19:59:16 the debian policy manual explicitly disallows debs from installing files in /usr/local, for instance. We can't make a conforming package that slaps everything in /usr/local/emc. 20:00:00 rayh: for now, just do the list of paths to search, like it does for the resource file. 20:00:37 Um that is not relative at all 20:01:13 you can search relative and absolute paths the same way. 20:01:20 what isn't relative? 20:01:34 Unless you are thinking of the work that aj did to define variables that hold relative position. 20:01:48 no, hold on a second. 20:01:58 look at the code that starts at # read the application defaults 20:02:21 That is aj's work. 20:02:23 it checks several paths. One is broken out of the foreach, but it's the same test. 20:02:31 oh, ok 20:03:10 The alternative is to have configure write a file with these paths in it (or generate tkemc.tcl from tkemc.tcl.in) 20:03:11 The only testing I do inside the tickle itself is to find tcl/scripts and make a menu 20:04:03 so tkemc expects to run from the emc dir? 20:04:09 emc2, in this case 20:04:20 only as far as finding a couple files. 20:04:24 IMO the location of help docs is completely broken now. 20:04:45 right, just make a var HELPDIR that's "help/" 20:04:47 true 20:05:13 then load the file "$HELPDIR$helpfilename" 20:05:51 I did some experimentation some time ago, trying to find out where the help file needed to be so that it would show up. I can't get at it now (and I don't remember what I found out) 20:06:50 I'm guessing that this "help" directory will not always be relative to emc2 20:06:58 right 20:07:00 and that is the only way I know to get at em 20:07:10 so I'll do nothing. 20:07:15 it will be in /usr/share somewhere 20:07:35 If you want to write a search like aj's, I can give you a list of likely paths 20:07:46 if you want to let aj or me handle it, that's cool too. 20:08:43 I thought maybe in my humble way I could contribute to one small error... Do it your way. 20:09:30 I suppose that a better way is to have several helps. Like the README in configs. 20:10:07 SWP is right that includes in ini files would be really nice 20:10:32 then everything dealing with paths would be easier 20:12:41 well - it might be possible by changing only inifind 20:15:02 Am I being overreaching to think that there might be some common help info for the axis interface and the tickle interfaces. 20:15:38 I think it would be bad to assume that forever, but it's true that many keystrokes are the smae 20:15:41 same 20:16:31 g-codes, m-codes 20:16:45 I think most key shortcuts are the same 20:16:50 ah - the emc-related stuff - that would hopefully remain the same ;) 20:17:05 definitely there is a lot of help that would be useful that is not dependent on the particular gui 20:18:23 This whole notion of emc help started early on with plain text files saved in emc/doc along with lots of other junk 20:18:31 right now, unfortunately most of that is pdf/latex so it's a little hard to view online - more geared toward printing 20:18:52 moving to good online help might be a trick (unless it's just html) 20:19:01 make should run latex docs through a pdf or ps conversion 20:19:03 heck, we could distribute the wiki 20:19:12 if we thought it was somewhat up-to-date 20:19:16 so they're readable 20:19:32 lyx can easily be converted to html 20:20:10 html would be fine as well - just something that looks better to the end user than a tex file 20:20:23 after all, it is documentation source code - it should be compiled as well 20:20:38 a bit primitive by the standards of todays db related stuff. 20:21:06 tex or text? 20:21:16 tex, like latex source 20:21:40 tex is not very readable 20:22:12 nope - that's why I suggested converting to some user-readable form during make ;) 20:22:15 like make docs 20:22:53 One of the small problems with the lyx repository is that 20:23:25 lyx needs to read em and make them intelligible to a latex converter. 20:23:58 funny - there is a make docs target, but it only runs doxygen for source code documentation, nothing for end-user documentation 20:24:13 Right. 20:24:35 but there is a command-line method of converting from the source form to a .pdf or .html file, right? 20:25:22 I'm not certain how lyx does that. 20:26:06 it would have to be lyx2latex and latex2 whatever using one of several converters. 20:27:12 ok - there's a TEx2pdf program, and another one called lyxport 20:28:29 I don't see the name of the lyx to latex at least not from the lyx gui. 20:29:35 lyx has a command-line option for export, I'm looking for the supported formats 20:32:53 ok - you're right, it looks like it calls latex2{whatever} internally 20:34:36 true but many of these can run standalone or in a pipe. 20:34:40 yep 20:34:52 http://amath.colorado.edu/faculty/fperez/lyxport/lyxport.html 20:35:14 relyx comes to mind as a custom converter for lyx. 20:39:21 but that is the other way around. 20:39:59 I don't see it right off. 20:40:36 If we saved in latex we could do command line conversion. 20:43:26 so the source is in lyx format? 20:45:19 Yes. 20:45:50 there's a command-line option -e (or --export) fmt, but I haven't found a list of supported formats 20:46:04 I suspect that ps, pdf, and html are in the list, but I can't tell for sure 20:46:26 http://wiki.lyx.org/LyX/ManPage 20:46:53 I would not think so. Those are achieved through latex to whatever using many different converters. 20:47:13 I'd bet that lyx will just call the appropriate converter(s), and exit 20:47:32 it can do that, since you can vire as various things from within lyx 20:47:36 view 20:55:41 I do get a pdf from the commandline using lyx -e halconfig.lyx 20:56:01 let me try html 20:57:17 Got it. 20:58:14 * rayh moves to the other box and tests with the repository. 21:00:14 rayh_ has joined #emc-devel 21:00:30 rayh_ has left #emc-devel 21:00:38 rayh_ has joined #emc-devel 21:01:05 * rayh_ shakes his head from the pain. 21:02:07 in the documents/lyx directory it is possible to run lyx -e pdf and say hal_introduction.lyx and get a good pdf. 21:03:12 ok - where's the pain from? ;) 21:03:45 so much to learn so little time. 21:03:58 heh - I know the feeling 21:04:29 I believe that if I setup my lyx configuration for hevea or ttl I can also get html. 21:04:48 err - what? 21:07:03 Those are html converters for latex. 21:07:13 ok ;) 21:07:15 This is wierd wild stuff. 21:07:24 it looked like terribly botched helvetica nad ttf? 21:07:27 and 21:10:54 works fine. 21:11:18 cool. does it introduce more build-time dependencies? 21:11:27 or are those programs included with lyx / latex 21:11:37 So the short answer is that we could write a command line option for make 21:11:57 that would yield the latest lyx stuff in either of several formats. 21:12:29 problem becomes one of do we want to and what do we do with the sources. 21:12:57 the sources are just that - source. they should be treated the same as C file IMO 21:13:29 make docs (or make pdfdocs or htmldocs) should create the documentation (in $DOCDIR/) 21:13:59 make install should put the documentation into whatever documentation directory is "standard" (or specified) 21:14:50 This isn't going to be a developers vesion of make, is it? 21:15:08 how do you mean? 21:15:41 we would have to ship all of the document/lyx files and the images 21:15:54 we would be looking at several meg. 21:16:19 that should come along with the cvs checkout (of the docs, if they're a separate cvs checkout from the source) 21:16:46 They are documents is a module at sf just like emc2 is 21:17:02 well, it can be done two ways 21:17:22 someone building a .deb can either have separate emc2.deb and emc2-docs.deb 21:17:32 or they can build them together into one larger .deb 21:18:06 I guess a developer would just have to check out the extra module, and make whatever version of the docs they want 21:18:30 and have lyx on board and properly configured. 21:18:48 yep, just like having c/c++/python/make ... 21:18:57 but only if they choose to build the docs 21:19:09 right. 21:20:23 blue sky here --> given that we can do this, what kind of a file would be easiest for us to use for help? 21:21:02 I think the most obvious thing to do is use html, since everyone has a web browser. 21:21:03 Every system has some sort of web/html browser. 21:21:13 great minds... 21:21:15 depends. if the html output is in small pages that the user can navigate through (table of contents -> sections ...), that's the best 21:21:36 if it's all one pagem then it's not really better than pdf, which is also better for printing 21:22:07 have we checked lately to see whether modern browsers (firefox) still print badly? 21:22:26 It would be as easily possible to build a menu in tkemc or mini that shows the names of files available 21:22:27 firefox is pretty good, with non-frame stuff 21:22:44 it also allows you to scale by whatever percentage you want to fit to page (at least on Windows) 21:23:03 what it doesn't do is paginate well - I'm not sure if the pdf export does widow/orphan control 21:23:10 I know firefox doesn't 21:23:14 lyx can wrap figures and min pages better to pdf than html 21:24:37 I just finished a 90 letter size page book for SO. Fantastic printing, wrapping images, tables, and references. 21:24:39 right - HTML has no concept of a page 21:25:09 breaks images tables and boxes across pages. 21:25:32 I wonder how much longer it takes kghostview to open a doc as konqueror. 21:25:50 how about kpdf? 21:26:04 not used it. 21:26:18 it's pretty nice. has thimbnails of all the pages on the left side 21:26:22 thumbnails 21:26:42 has "continuous" mode, so you can have part of multiple pages visible at once 21:27:04 that's one thing that really bugs me about gpdf and ghostview, you get one page at a time 21:27:19 got it on the deb box. looks the same as kghostview. 21:27:47 ChanServ has quit 21:27:57 oops 21:28:04 hmmm - I wonder if it's different in KDE 3.4 (or whatever I have on my Ubuntu box) 21:28:09 or is that 3.3.4? 21:28:19 yeah - oops 21:29:49 In view of your notion of lyx as source we ought to have a emc2/src/lyx 21:30:18 or src/docs 21:30:21 that gets built into a set of emc2/docs/xx 21:30:28 ChanServ has joined #emc-devel 21:30:50 or, have a top-level makefile that will drp into src/ by default, and has targets for documentation 21:31:08 ie, a makefile in the emc2/ dir (as people would often expect anyway) 21:31:52 pdf is famous for bandwidth consumption. 21:32:10 but it has a huge advantage in printing. 21:32:35 latex2pdf is a version 3 pdf now. 21:32:56 don't know if that is clickable links in the table of contents or not. 21:32:57 the pdfs shouldn't be any bigger than the images and text combined - they are compressed (or it's an option, I think) 21:33:56 This would make for a very attractive help system. Even if we had to write some files specifically for it. 21:34:05 yep 21:35:05 If you were producing such a thing, what would the file structure for lyx and images look like inside emc2 21:35:54 depending on how lyx expects to get the images, I'd have docs/ contain the lyx source files, images in docs/images/ 21:36:09 that should be no problem for lyx. 21:36:13 and make the actual documentation go into subdirs off docs, docs/pdf, docs/html ... 21:36:46 the html docs should refer back to the same copy of the images, if that can work well for run-in-place and installed documentation 21:37:13 um. I 21:37:19 'd have to check that 21:37:42 and then they would be different for the installed v run-in-place systems. 21:39:01 the images/ dir would need to be copied for installed versions 21:39:16 the html docs would have to refer to ../images/blahblah 21:39:42 this all depends on how many documents are created as well 21:40:35 if there are separate docs for each UI, plus G-code, then HAL and CL, then a separate dir for pdf vs. html makes a lot of sense 21:41:55 Yes and that is a lot like some systems provide their docs as well. 21:42:36 yep 21:42:44 If we had both html and pdf versions. "Click here for print ready." might work 21:43:06 it would be good to generate an "overview" doc as well, like the master index.html, that has links to the other docs 21:43:22 yep - make both, and link to the pdf files in the html, for printing 21:43:26 Sure. 21:43:36 I'm not sure what that does to the lyx source, or the cmd-line options though 21:43:44 might get a bit complex 21:44:40 Well something to ponder and play with a bit. 21:44:52 yep 21:53:31 rayh_ has quit 22:16:18 logger_devel has joined #emc-devel 22:16:18 topic is: "Welcome to the Enhanced Machine Control development place. | Regular Developers' meetings 24/7 !" 22:16:18 Users on #emc-devel: logger_devel @ChanServ rayh LawrenceG cradek steves_logging SWPadnos anonimasu alex_joni jtr_ 22:28:53 hello 22:31:30 Hi alex 22:42:11 still reading back, give me 5 mins 22:43:40 k 22:43:46 brb 22:45:30 back 22:47:44 me to 22:47:58 ok.. care to talk about tcl help? 22:48:10 seen you & chris started to talk about it.. 22:48:13 sure. 22:48:24 What are your impressions of the need 22:48:27 ok.. I see the docs/help as needed 22:48:32 very much so 22:48:55 certainly even more so after reading user emails from the list (those people don't really have a clue) 22:49:21 It is easy enough to add help.txt to that and mod the ini files. 22:49:41 right, but the problem is what we enter in the ini file? 22:49:50 But there was concern about the installed version 22:50:21 if you enter HELPFILE=../../docs/help/help.txt then it works for run-in-place 22:50:37 Right I've done that here. 22:50:40 it might be with only one ../ (can't recall right now) 22:50:46 2 22:51:14 ok, the problem with the installed version is that configs get installed in /etc/emc2 (for ubuntu for example) 22:51:22 in that case ../../ makes no sense 22:51:35 agreed? 22:51:59 okay but configs doesn't matter to help. 22:52:17 Unless we also want to try to get at some config specific help. 22:52:35 redefine 'configs doesn't matter to help' 22:53:05 I think the problem was that docs will get moved to /usr/share.emc2/... 22:53:30 oops /usr/share/emc2/... 22:53:52 no, the real problem is that the runscript gets executed inside the configs dir 22:54:08 oh crap. 22:54:16 it first cd's to the stepper/ dir, then runs the rest of the commands 22:54:29 that's why you had to enter ../../docs/help/ 22:54:39 in your run-in-place case 22:54:59 but that doesn't work for installed versions, as the location might vary 22:55:01 In emc the run was from emcs main directory. 22:55:19 is it not possible to make the same thing happen for emc2 22:55:32 yup, but that meant you can't install it like configure wants 22:55:51 with --prefix=usr, then configs in /etc, help in /usr/share etc 22:56:13 you basicly can specify all that at configure time, and during make install data gets copied in flexible locations 22:56:26 so there isn't an 'main directory' 22:56:34 but let me ask you one thing: 22:56:51 what if the ini would say HELPFILE=tkemc.txt 22:57:08 and the runscript or even tkemc will work out where the file is 22:57:22 runscript exports $HELPDIR, tkemc uses that 22:57:45 Then it ain't an ini in the old sence of the notion. 22:58:03 in that case $HELPDIR can be easily exported as emc2/docs/help for r-i-p, or /usr/whatever for installed 22:58:24 I really don't see a reason for users to change the place where the helpfile gets found 22:58:39 not even for integrators 22:59:15 It's no wonder that Bob at Synergy refused Paul when he demanded that synergy be installed like an ordinary package. 22:59:50 well.. synergy is pretty badly hacked together 22:59:56 I see that we are talking about installing TkEmc in the xll stuff. 23:00:06 that is where it was originally when we wrote tkemc 23:00:15 no, TkEmc IS installed in the x11 stuff 23:00:20 ;) 23:00:24 but 5 times out of 6 it was useless there. 23:00:30 how so? 23:00:37 never got found. 23:00:44 ??? 23:00:50 and if you wanted to change it you had to be root. 23:01:38 IMO this installed version of emc2 is a huge waste of time when we are short of it. 23:01:43 you need that to run emc (or needed) 23:01:52 root that is.. 23:02:08 well, the problem is the following: the installed version of emc2 is DONE 23:02:19 a waste of time would be to revert it 23:02:22 Not for any of the user space stuff except ioshow 23:02:49 what kind of user space stuff? 23:02:51 because that depended upon inb and outb 23:03:04 tkemc, mini, 23:03:35 I don't follow 23:03:50 Yes if the installed version is ready for daylight then reverting is a waste. 23:04:11 rayh: if I just ran: apt-get install emc2 and it worked as it should 23:04:22 then I must say it is ready for daylight 23:04:49 probably at the moment it might be a bit better than run-in-place 23:04:53 and were you able to revert to the previous version? 23:05:11 meaning removing this one, and installing an earlier emc2 deb? 23:05:25 I see no reason why not 23:05:27 no using apt get to undo the install 23:05:33 sure 23:05:34 if it didn't work. 23:05:42 apt-get remove emc2 23:05:44 Paul's updates have never worked properly 23:05:54 guess they are busted then 23:06:06 but when you try to step back using apt you can not do it. 23:06:10 but it depends on what you expect an update to do 23:06:28 if you apt-get install emc2, and it pulls along a new kernel & rtai 23:06:35 apt-get remove emc2 will only remove emc2 23:06:40 Say for a moment that a shop floor has machines running last months emc2 23:06:42 and leave the new kernel & rtai 23:06:49 that is how apt works 23:06:56 ok 23:07:11 last months emc2 is a emc2-fooversion.deb 23:07:17 how do they know that the newest version will work in their environment 23:07:21 released by us 23:07:44 we will not advice anyone (or at least I won't) to use CVS on a shop floor machine 23:07:55 If they could run in place from an apt that would allow them to test 23:08:06 there is no runin-place from apt 23:08:13 except if the get a source deb 23:08:21 that can work 23:08:27 Sorry I'm being so difficult. 23:08:35 no, we need to get this straight 23:08:53 we can't miss something and be in the rain afterwards 23:08:54 but I have had dozens of my customers kill their systems because they tried to apt-get update emc 23:09:11 The only way to recover is to reinstall from the original CD 23:09:16 that is only because of faulty packages 23:09:30 and if that happens the packages need to be fixed 23:09:47 and that by first backing up to the old kernel and 23:09:55 but I'd NOT want that to happen in the first place, so every realease will be thoroughly fixed 23:10:15 I'm afraid that I don't trust any update. 23:10:21 right now. 23:10:24 rayh: yeah, I know .. I didn't managa with BDI myself 23:10:32 If a customer can test then okay. 23:10:38 but I didn't have the time/patience to run enough apt foo magic 23:10:43 but with apt-get update you can not test. 23:11:02 apt-get upgrade actually ;) 23:11:05 So all of my customers will run in place. 23:11:17 yes 23:11:21 apt-get update doesn nothing (except pulls the new lists) 23:11:41 we can release packages like debian does (stable, testing, unstable,..) 23:11:47 Now that means my customers will not use the deb packages that you guys are working so hard to produce. 23:11:49 although I don't see that as a need 23:12:02 that would be too bad 23:12:14 Right my point exactly. 23:12:18 and something I would advise against 23:12:28 Weber systems builds a deb that installs okay. 23:12:31 run-in-place from CVS is not very safe 23:12:33 And it runs in place 23:12:50 yes, and disregards most of the debian rules 23:13:22 in the process of doning that 23:13:31 s/doning/doing/ 23:13:56 but that's not really the issue 23:14:10 the issue is what version of emc2 do we advise users to use 23:14:30 imho that will be emc-2.0.0 (the stable release we are working for) 23:14:44 and the next one will be 2.0.1 or whatever, again after a few rc's 23:15:03 so between 2.0.0 and 2.0.1 there will be planty CVS versions, but no deb updates 23:15:17 only stable emc2 releases should get an deb package 23:16:19 I hear what you are saying but I don't know of any customer that is going to update unless I tell them to. 23:16:42 and in spite of my best testing the mess from bdi-4.30 got past me. 23:16:55 right, and I EXPECT you not to tell them to update unless there is a new STABLE emc2 version 23:17:18 But BDI 4.30 was supposed to be stable. 23:17:32 says who? 23:17:39 It looked like on all of my machines. 23:17:50 It was customer machines that failed. 23:18:13 that is one of the problems we want to overcome 23:18:22 not to worry about the linux part.. 23:18:31 That is why I'd like a customer to be able to run in place and change between installed versions 23:18:50 ubuntu certainly has a lot more users (and machine/setup experience) than we will ever have 23:19:17 until bdi-4xx we have always been able to install and run in place. 23:19:17