[5971] possible topics: emcfest details, next steps for emc2, and something else that picnet mentioned last night but I forgot [6012] Oh, I remember - something about localization of user interfaces [6014] i18n support ? [6020] I worked just a bit with ??? to develop a way to tag emc error messages across languages. [6021] It is something that needs to be addressed. [6022] I must admit that such things make my head spin [6023] We had a version of tkemc running that would allow the user to select a language and error messages would be looked up in a table. [6026] were button labels and such translated too? [6027] I'd think that if we had a complete list of possible error messages we could do this rather easily. [6028] in the GUIs perhaps - but there are smaller amounts of text throughout the system [6029] No in the prototype. There are big issues here because for some languages the words carry much different lengths. [6030] All we need to do is tag translatable strings [6033] so they don't fit on the buttons.... [6034] The most popular approach is to make all of the "text" graphic icons so that size can be equalized. [6035] ick [6036] Right. And since tickle uses text length to determine button width unless you specify one it makes a mess quickly. [6037] I hate icons - some of the standard ones are OK, but what kind of an icon do you use for spindle on? [6040] I've seen a drill or endmill with an arrow below. [6041] what about tooltips (those messages that pop up when you hold the mouse over a button). [6042] does tcl/tk support them? [6043] would have to be a curvy arrow, otherwise it would look like Z or X motion [6044] and then how do you do spindle off? [6047] Yes and balloons are supported in tkemc. [6048] X over it. [6049] so maybe we could use more icons, with balloons/tooltips in the selected language for clarity [6050] That would help quite a bit. It would require a major redo of tkemc because it is all sized by the text size. [6051] I'd have to enable balloons in mini in order to use that setup there. [6054] but button size in mini is a product of real-estate rather than text size. [6055] hard coded pixel sizes in mini? [6056] I used what tickle calls gridding. It looks a bit like a spreadsheet where the individual boxes expand to fill the space. [6057] ok, gtk has something similar [6058] I'd think that we would need a couple of icon sets, large and small. [6061] Tickle will be slow if we use tables for everything to do with a display. [6062] There has been a push into i18N but IMO it has not worked very well. [6068] I would think that with appropriately located lookup tables, c's pointers could be used to a real speed advantage. [6069] And here, knowing no c, I am arguing myself into obsolesence. [6070] yeah, c could do that... personally I would load only the selected language's strings into memory [6071] IOW, at startup, the program would read "english.str" or "finnish.str" into memory. So you wouldn't be selecting a language every time you display something [6072] You bet. And if they were located in the same region, assuming that we could produce an equivalent set for each language the pointers would work slick. [6075] to add another languate, you just need to make a new "str" file [6076] still would only address ascii languages - no chinese or japanese [6077] getting into unicode and alternate character sets is too much for me to handle [6078] It is even easier than that.... [6079] No I disagree a bit. The i18 stuff uses the larger ASCII set. But I suspect that paul is thinking icons all round. [6082] tag each string that needs to be translated [6083] and use the gettext toolset to extract them all to a po file [6084] I will fight "icons all around" tooth and nail unless they have balloons or such [6085] then if anyone wants a translation, the po file is the only one that needs editing. [6086] Okay. I'll bet a tooth that ... [6089] No need to create icons for everything [6090] In the interpreter, Tom uses numbers to define error messages. Then a single file rs274ngc_errors.cc defines the text to be displayed. [6091] how does the po file interact with the code? [6092] I've only had a brief look at it, so here goes... [6093] for instance, how does printf ( "error: broke the drillbit") get transmogrified [6096] I can understand that the string winds up in the po file, and then the translated one is also in another po file [6097] but how does the printf get changed to pull from the file? [6098] printf(_("error: broke the drillbit")); [6099] note the _( ) [6100] right- so _() is a function that gets the string from the po file? [6103] or is it done at compile time? [6104] it is the translateable string marker. [6105] Translation robots are famous for trashing the meaning of technical expressions -- if that is what you are thinking here. [6106] ok, so it tells gettext to pull the string out for translation [6107] running gettext over the sources extracts the tagged strings and places them in a master.po file [6110] ray__: actual translation would be done by humans [6111] we're talking about how the program would substitute the translated strings for the original ones [6112] each language would then have it's own file (es.po, fi.po, fr.po) [6113] ok, I follow that... I don't understand how they get pulled back in at runtime [6114] main() would have a couple of lines added to read in the locale settings of the system [6117] and then at compile time, libintl is linked to the app. [6121] I'm guessing libintl pulls in the appropriate strings from xxx.po at runtime [6124] as long as liibintl.h is included, the _( ) gets expanded so that any translatable string is pulled from the relevent po file. [6125] if no translation is found, it defaults to the master file. [6126] What would the po file look like in an editor. [6127] ok, I think I understand - _() is a macro that expands to a pointer, so the original code is happy - but the lib can make that pointer point anywhere [6128] after compilation, new language files can be created with plain text editors [6131] the lines added to main() would read in the local and master po files and set up the pointers, right? [6132] in a nutshell, yes [6133] is libintl part of the standard clib, or a package you need to install? [6134] checking.... [6135] rt code couldn't use that scheme, because of the file I/O - but rt code has little or no text interaction with the user [6138] wouldn't be able to link with libintl [6139] so: the good news - libintl already exists, and can be used to internationalize user code written in C (and presumably C++) [6140] now the bad news: doesn't help tcl much [6141] also, I wonder if standard dialogs like file open would remain in english? [6142] thought Tcl/Tk had i18n support [6145] Does in some of the newer versions. [6149] libintl.h is part of glibc-devel [6150] can't find libintl.a or so, so it may be part of libc as standard now. [6153] was reading the docs at http://www.debian.org/doc/manuals/intro-i18n/ [6154] seems there can be more to it than just gettext translation when you start allowing non-ascii character sets [6155] Since we are on today's meeting minutes, let me say that I think that internationalization is a good topic for EMC-Monday. [6156] right [6160] There is a yahoo group for tcl and i18n. [6161] I assume we won't try to translate the ini file? "axis" will remain "axis" and "period" will remain "period"? [6162] Looks like unicode is used in tickle. [6163] why would we ant to do that ? [6164] (translate ini params) [6167] we wouldn't [6168] The INI should remain in english if we keep the present format. The configuration stuff could be easily internationalized however. [6170] Right. I don't see any reason why the help files and even the variable names can not be in French for those who want to configure it using my configuration scripts. [6171] you have scripts that generate an ini file? didn't know that [6174] That script would simply write the final INI using english variable names. [6175] Been in the dropbox at linuxcnc for a couple years now. [6177] another of the things a newbie might never find without help [6178] Well they were experimental at the time and I never got enough comments to finish the project. [6182] ray - any more info from smithy or webers? [6183] It can work from a new generic ini or from a customized one. [6184] Webers was sending out a contract. [6185] We are good to go there. [6188] I'm visiting Smithy this week. [6189] as the time gets closer, I'll have networking questions [6190] We are good to go there for Fest as well. [6191] dhcp, dns, etc [6192] They have dhcp enabled and a gateway to the web. [6195] I was wondering about local dns on the lan - for instance the compile farm machines - we'll want to rsh to them from other local machines - at home, I use static IP and etc/hosts files, so I can rsh to "cubix1" and it works... [6196] I don't think that will work with DHCP, unless they also have a DNS that knows where "cubix1" is [6197] if the farm needs re-configured, I'd like to do that before I arrive, rather than wasting too much time while we're there [6198] I'm thinking that we need a lan of our own which we could configure anyway that we wish. [6199] Subnet I guess they call it. [6202] I will bring my 16 port switch, even with all 8 farm boxes, that still leaves 8 free drops. [6203] if someone can set up a machine as a router, we'd be all set [6204] I'm certain that between Mike and Jim we can do it. [6205] in fact, we could use on of the farm machines as a router - I can add another ethernet card [6206] There you go. [6209] mike & jim are at smithy? [6210] Jim is at Smithy. Mike is at Sherline. [6211] mike is coming to names? [6212] when it gets closer, I should talk to them about it, and get things set up [6213] I've never configured a linux router - I use one of those little netgear boxes [6216] less power and noise than keeping a computer on 24/7 [6217] but I can dedicate a farm slot for the fest - I'll load linux and preconfig as much as I can [6218] Right, Mike will be there for NAMES and the full Fest. [6220] O we would connect one box on the farm to both your switch and to the Smithy net. [6224] so if it is configured right, we'll have our own little subnet [6225] I have another 5 port switch that I might be able to bring as well [6226] Great. Then if we need more than 8 connections for fest we can add a hub. [6227] so we could have 12 people and 8 farm slots [6230] Smithy has an extra hub but I don't remember how many. [6231] which brings up a question. how many folk will we have at the fest? [6234] We will need to put out a call for volunteers. [6237] should we do that soon? or do we need to lock in a few details first before we go public? [6238] I know of Matt, Mike, DaveE, and you'se guys 'eh. [6239] Plus at least two from Smithy. [6240] me, paul, and maybe robin [6241] and you [6244] 9 so far [6246] btw, can smithy provide an extra monitor for the farm? [6247] I've got 3 2.2 Gig Athalon boxes running various versions. [6248] 2 800 via boxes. One of these is tripple boot live/tng/2.20b. [6252] you have a lot of monitors, or a nice big kvm switch? [6253] All can network if I can figure out the driver for 2.20b [6254] 3 flat dells and 2 crt's. [6255] I'll be bringing the farm and my main devel machine. Right now thats a 233Mhz, but I have a 600Mhz PIII I might be moved to by then [6258] and a 2 in kvm. [6259] I have a CRT and a 2 in kvm [6260] but if we can dedicate a monitor to the farm, someone can use it (it has an internal 8 way kvm, so they can use any slot, while others rsh into the other slots) [6261] Oh. There is also the Walmart/Sherline 800 via box with the stepper driver and mill. [6266] we're gonna need another switch [6267] Wasn't that a rock song from the sixties, motown it think. [6269] so anyway, there will be significant networking details to work out, but that can probably wait until about march, right? [6272] I'd think that we should work out a complete listing of the central machines. [6273] And what stuff needs to be where. [6274] Then if we spec what clients need to be on each other box we should be in good shape. [6275] hmmm - how about we use the scratch file in CVS for such things.... that way we can add to it as we define stuff [6276] GOOD thought! [6279] we can list who is coming, what they are bringing, and how it fits in the net [6280] Why not create a new file there called fest04 and build in all of this. [6288] watcher: emcfest is http://cvs.sourceforge.net/viewcvs.py/emc/documents/fest04.txt [6291] file created and committed [6292] nothing in there yet except a single line - I'll add some stuff later. [6293] the webers address/phone number, hotel info, everything can go in there [6294] Right. It will be a few days before I can do much with it. [6295] no problem - we have a couple months [6298] I'll get lodging info from the three closest places while I'm down there this week. [6299] good - should make reservations soon [6300] ok, how about another topic - emc2 progress [6301] paul_c: you said you have a hybrid working yesterday [6302] freqmod from emc, and minimilltask/io/tkemc compiled against rcslib-redux [6305] with a mix-and-match makefile to build it? [6306] Have core parts of emc in the emc2 tree and a suitable makefile [6307] something that you could commit into emc2? [6308] the makefile or the whole lot ? [6309] the lot [6312] tcl code too ? [6313] I dunno about that - my interest is being able to start hooking hal I/O devices to emcmot and emcio [6314] to do that, the source needs to be in the emc2 tree [6315] I have a few loose ends on halscope, but then I need to get serious about integrating with emc [6316] so far, I've been concentrating on the usr space side. [6319] so freqmod hasn't been touched. [6320] what I was getting at was to have something in emc2 that builds - even if its mostly the old code (but using a simplified, emc2 style configure / make process) [6321] then hal can be added incrementally [6322] matt mentioned that he had rtapi'ified emcmot.c already [6323] but that isn't in cvs either [6326] The RT code will need the biggest changes - I had thought Matt was doing some work in that area [6327] it starting to be time for us all to come together and _really_ use CVS [6328] emcmot.c would benefit from being split into three (or four) smaller files. [6329] agreed [6333] I can commit the rcs/nml stuff along with the core emc files I've made small changes to... [6334] BUT I do intend to make some serious changes to the NML code which will break other stuff. [6335] good! [6336] all the overloaded functions in emc.cc are not needed - Some are, but not all of them [6337] I just discovered I could log into SF twice and download on each. [6340] Added a few things to fest04.txt [6341] committed already? [6342] concurrent checkouts ? [6343] makes sense if you have the lock... [6348] paul_c: do you think you might commit something in a week or so? [6352] concurrent checkouts of different parts of the repository. [6353] I could do it today, but I'd like to clean up a couple of files first. [6354] like emc2 and documents [6357] paul_c: no rush - I have about a week left on halscope - want to get the triggering stuff added [6358] I checked out fest04 okay and made changes but I can see it browsing the repository yet. Perhaps the browse function is from the annon server. [6359] I think so, there's probably a lag of a few hours [6360] up to 24Hrs [6361] I did a cvs up and see your changes [6364] Darn 640x480 user. Sherline driver box and wants to run. [6463] jmkasunich: Have removed most of the changelog comments from the files I'm working with... [6464] sounds good - some of the files had 2-3 pages of changelog at the beginning - that's a bit much [6465] but should we keep a minimal amount? should there be something in CodingStyle about it? [6466] and some of the changes are not documented. [6467] just committed more info to fest04.txt... [6470] Hmmm.. Could add something to the CodingStyle - Any significant changes/bug fixes should have a comment added to the source file. [6471] in the Changelog section [6472] I must admit I haven't been changelogging rtapi or hal [6473] in the format of [6474] don't know if it's needed during the chaotic pre-release stage... but once we release things, then changelogging becomes more important [6477] but the CVS logs should provide the same info [6478] yes - but commit messages are short and vague [6479] they needn't be. [6480] the keyword is _significant_ [6481] significant changes should be documented in the source file [6528] watcher: what is emcfest [6529] emcfest is http://cvs.sourceforge.net/viewcvs.py/emc/documents/fest04.txt [6532] the file isn't visible on the webpage yet, but you can cvs up it, add your bits, and commit it [6534] added details for Red Roof Inn [6535] Re: Emc2: [6539] I tried out the scope demo last night... WOW!!! [6541] there is talk that mshaver has some RT code ready to commit [6542] emcmot.c ? [6543] Well, I've started on it... It's RTAPIified and stripped of all the stepper stuff. [6547] I have some of the usr space stuff ready to commit [6555] Matt: - scope suggestions and comments welcome, please email [6557] mshaver: Do you have a makefile ready for emcmot in emc2 ? [6560] Actually, with the emcmot.c thing, my next step was to get it to compile in the emc2 directory. I need posemath, etc. [6561] has posemath [6562] it looks like we can do away with smallmath.o [6563] paul_c: No, I was wondering whether to put emcmot in a subdirectory under components since it has multiple sourec files [6564] emc/src/emc/emcmot [6567] as per Roadmap [6568] ok, that's ok by me (I guess I didn't remember the roadmap) [6569] I'll try to get it to at least compile w/out errors and then commit ti. The main job left is to hook it to the HAL by putting pins on it. [6571] use the extintf for the HAL connections [6574] Re: scope demo: On a BDI 2.20b system the bash2 deps in hal_demo are gone (Thanks!) [6576] also, to get the gtk stuff to compile you need to install glib-devel and gtk+-devel packages from the CD [6577] hal_demo should probably check if -x bin/halscope before it tries to run it (it's not built if GTK_VERSION=none) [6582] We also need to work on an emc run script [6583] also, hal_demo might need an extra step to tell the user to reduce the # of samples from 16k to 4k so that they can watch more than 1 signal. [6584] I thought that was in there, but it's part of a larger step, easily missed [6585] perhaps the default should be 4 anyway - 1 would be used only rarely [6588] would like to drop the emc part of emcmot directory [6589] call it src/emc/motion [6590] sounds good to me [6591] In the scope app itself, the "Cancel" button in the resolution/signal selecting window probably shouldn't exit the whole app, it should just kill that window with the params unchanged. [6592] paul_c: I thought of that too - motion it is then! [6596] I'm not crazy about that either, but it's a hack - whenever you are in the main window, the rt code is guaranteed to be running. if it's not, then other stuff might not work. If I allowed you to cancel out of the sample rate dialog, the rt code would be stopped. [6597] Re: the scope app - It's AWSOME!!!! What a useful tool that's gonna be! [6598] we had something like it that the software guys at work wrote for one of our drive products - we found it _very_ usefull, thats why I wanted one here [6599] Maybe just relabel the button "QUIT" or only provide an OK button? [6602] good idea [6603] I'd like to revisit that part - it's the first I wrote, and not too elegant [6604] mshaver: Don't be afraid to use sub-dirs if it helps to seperate the code into more logical sections. [6606] I'll see about commiting the motion stuff later and I'll keep testing new emc2 stuff as it comes [6635] paul_AWOL: If you see this, I'm looking for the posemath sources you talked about. I't not in swarfware, and I'm wondering if it differs from HEAD/rcslib/src/posemath? [6641] no change to posemath (yet), so it is the same as rcslib main [6642] to continue, or if it differs from the posemath in wps_multiplat_dev_branch (which is different from HEAD/.../posemath). [6644] I'll follow directory.map for where to put things... [6647] ... now to figure out Makefiles :( [6648] what directories do you have so far ? [6649] CVS + emc2/src/emc/motion [6650] I'll add emc2/src/posemath. [6651] ... I have posemath under libnml [6654] maybe not the best place for it... [6655] I don't have a preference, just following directory.map. I can be happy with most any arrangement. [6656] Where're you going to put user stuff like guis, etc. [6657] tkemc goes under emc2/tcl [6658] OK, according to language, I see that now... [6661] any GTK GUIs would go in bin [6662] If you commit the motion stuff, I can hack out a makefile (if you get stuck) [6666] I may just get stuck... It'll take a little while to make sure I've got all the files I need in there. [6689] mshaver: What emc sources are you going to commit where ? [6690] (want to avoid any conflicts with the stuff I've got) [6691] I guess I'd commit emc2/src/emc/motion/ and emc2/src/posemath/ [6692] Sorry for the delay, I was kvm'ed into another machine... [6693] in emc2/src/emc, I have ini/ motion/ nml_intf/ rs247ngc/ and task/ [6696] ini/ contains all the ini* sources [6697] motion/ emcmot.h emcmotcfg.h emcmotglb.c emcmotglb.h emcmotutil.c usrmotintf.c & usrmotutil.h [6698] hmmm... It may be easier if I commit the stuff I have here first... [6699] my /motion has: cubic.c emcmotglb.c emcmotlog.h Makefile tc.c trivkins.c cubic.h emcmotglb.h emcmotutil.c tc.h usrmotintf.c emcmot.c emcmot.h emcpid.c mmxavg.c tp.c emcmotcfg.h emcmotlog.c emcpid.h mmxavg.h tp.h, so far that is... ;} [6700] but then, I may not know what I'm doing... [6703] don't need emcmotlog.c as none of the coded functions are called. [6704] will probably get some conflicts from emcmot.h as I cut'n' pasted a bunch of enums and structs from other places. [6706] usrmotintf & emcmotcfg are usr space sources, so the .c & .h can be skipped [6707] The changes to emcmot.h are in HEAD? Or are they in your special emc2/src/emc/motion files only? [6710] only local copies here at the moment [6711] OK, -2 more! (although we should probably make usrmot as a diagnostic tool) [6712] But you had to make changes to make your local copy work? [6713] usrmot provides the core comms between usr and RT space [6714] right, and its got a main() too... [6717] making you a little teletype style UI