#emc | Logs for 2006-12-31

[00:26:06] <rafa> heloo
[00:26:23] <rafa> a need one information
[00:26:34] <rafa> please help me
[00:27:37] <fenn> don't ask to ask, just ask
[00:33:59] <lerman> That's our motto "dataja" :-)
[01:39:44] <fenn_> fenn_ is now known as fenn
[01:40:24] <cradek> lerman: what's dataja?
[01:40:45] <cradek> oh, duh
[01:40:48] <lerman> don't ask to ask, just ask (what fenn said)
[01:41:07] <cradek> I figured it out, I'm a bit slow
[01:41:38] <jtr> so, can I ask a question?
[01:42:07] <jtr> ;-)
[01:42:36] <cradek> don't be so rude - first, ask whether it's ok to ask permission to ask
[01:44:04] <jtr> anyway, how can I update the pdfs? you fixed the emc user manual - I can see the changes in my checkout of head.
[01:44:14] <lerman> OK... I've got a version of smart comments going. I've just committed them. I suppose I had better document them.
[01:44:28] <cradek> jtr: I think they are updated automatically
[01:44:31] <jtr> but the one on the website is still old.
[01:45:08] <cradek> jtr: are these the updated ones? http://linuxcnc.org/docs/2.1/
[01:45:23] <cradek> or are they old too
[01:45:36] <jtr> looking...
[01:45:56] <lerman> How long does it take for the commit to show here? The CIA seems a little slow, right now.
[01:45:54] <cradek> jepler's auto-updating the ones that go ... somewhere
[01:46:26] <cradek> lerman: CIA isn't always fast, but the commits are there for everyone to get immediately
[01:47:11] <cradek> lerman: I did get the email already
[01:47:18] <lerman> I figured that they would be there. I just wondered when the world would see my latest creation :-) Of course without docs, it isn't worth that much.
[01:48:08] <cradek> sometimes CIA is fast, sometimes it takes a few minutes, and sometimes it doesn't work at all
[01:49:09] <cradek> * cradek kicks CIA-8
[01:50:11] <cradek> jtr: I wonder if I made that fix in the 2.1 branch too - can you remind me what it was?
[01:50:35] <jtr> cradek: Yes, that one is updated. It was V2.0 at http://www.linuxcnc.org/docs/EMC2_User_Manual.pdf
[01:50:50] <cradek> aha, great
[01:51:19] <cradek> I wonder what we should do about which version people see
[01:51:40] <jtr> to fix that, I'd have to do a co of emc2 v2.0, fix the source and ci?
[01:51:44] <jepler> `the docs at http://linuxcnc.org/docs/2.1 and /docs/devel are automatically updated several times a day
[01:51:58] <jepler> the 2.0 docs are not automatically updated, nor is there an HTML version
[01:52:41] <cradek> jepler: docs/devel is from head?
[01:52:51] <jtr> On the main docs page, I would show the version of the current release.
[01:53:01] <jepler> cradek: yes
[01:53:04] <cradek> jtr: the current release is still 2.0
[01:53:26] <lerman> I've added a note about smart comments to:
[01:53:28] <lerman> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Named_Parameters
[01:53:44] <jepler> the misleading thing is that /docs/html is a symlink to /docs/2.1/html
[01:53:51] <CIA-8> ow
[01:53:55] <jepler> maybe I should get rid of that (it's a symlink on the server)
[01:54:02] <lerman> They should make debugging a lot easier. I've tested one example of each.
[01:55:46] <cradek> lerman: I don't understand the explanation of (debug,
[01:55:58] <cradek> lerman: in particular all the $ in it
[02:01:36] <lerman> Ahh. I didn't mention that.
[02:01:37] <lerman> 1 -- named parameters are all ended by a $. It they begin with a $, they are local (to the subroutine in which they are used).
[02:01:37] <lerman> 2 -- I had a problem with numeric parameters in comments. In particular, it wasn't clear how to detect the end, so I just terminated with a $. (I should probably change that so that whitespace or end of comment terminate the number.)
[02:03:00] <CIA-8> 03lerman 07HEAD * 10emc2/src/emc/rs274ngc/ (interp_convert.cc rs274ngc.hh): Added smart comments that can show a parameter.
[02:08:23] <fenn> i dont like $ because they aren't pairs; it makes it hard to read
[02:09:12] <fenn> why cant you use []?
[02:09:29] <lerman> The ending is a terminator at the end of a named parameter. The first (optional) $ means the named param is local.
[02:10:32] <fenn> what's the usefulness of that?
[02:10:48] <lerman> [] is hard because #[sqrt[1.0] is legal. To recognize that would require a further lookahead. Since this parser looks ahead only one (I think), it would require a significant change.
[02:11:39] <cradek> I realize you can't use #[...] but I still think #<...> or #{...} is better. I don't know how to handle the local vs global case though.
[02:11:46] <lerman> Look at flowsnake.ngc to see one use. The issue is that if I write a subroutine and you write a subroutine, they might use the same names. The use of local parameters avoids polluting thename space.
[02:12:08] <fenn> how about.. all parameters are local unless declared global?
[02:12:14] <cradek> in subroutines they could all be local.
[02:12:22] <lerman> Yes, we could use <>, I think. I don't think those characters are used.
[02:12:55] <lerman> They could all be local, but that would be a restriction.
[02:13:20] <fenn> it would be less of a restriction than forcing some naming convention
[02:13:37] <lerman> A similar issue will exist for named owords. oMillAhole is global. o$loop is local.
[02:13:58] <cradek> what's a local subroutine?
[02:14:12] <lerman> That isn't a naming convention in the sense that the $ isn't part of the name.
[02:14:39] <lerman> Did I say that?. Local parameters and local labels (owords).
[02:15:04] <fenn> * fenn grumbles about poorly specified ad-hoc implementations of lisp
[02:15:32] <cradek> I think I'm really confused
[02:15:36] <lerman> lisp is pretty consistent -- and minimal at the language level.
[02:16:17] <lerman> If I wanted to return a value from a subroutine, I would use a global parameter.
[02:16:27] <cradek> O words can be labels that are like goto "targets", or subroutine names - I don't understand what global or local means for that.
[02:17:13] <cradek> other languages don't have global/local if, while, etc
[02:17:39] <lerman> Inside a subroutine defn, you might have loops. If you wrote the oword for that as oLoop, that label would be visible to the world. Another subroutine couldn't use a label oLoop.
[02:18:17] <cradek> ok sure
[02:18:42] <lerman> Yes, they do. In C, variables are: local in scope (visible only within {}, static (visible within a file), or extern (visible everywhere).
[02:19:09] <cradek> sure, variables - not if and while.
[02:19:36] <fenn> if and while is pushing the definition of subroutine a bit
[02:19:37] <lerman> I suspect part of the problem is that I think like a programmer. If you want to use programmer like stuff, you need to have the things avaiable.
[02:20:30] <cradek> fenn: I'm talking about the O word required before an if or while. they can be global or local, and I am trying to understand what that means
[02:20:33] <lerman> If and while are done in C by matching up brackets {}. I thought about that, but I thought it would require a significant rewrite of the parser.
[02:21:03] <cradek> ok I think I see
[02:21:18] <cradek> if you used only goto in C, you would have to name them all differently, because they don't have brakcets for scope
[02:22:09] <fenn> would it be much harder to have a python frontend with a function call that passed g-codes?
[02:22:28] <fenn> or a full api even
[02:23:14] <lerman> The interpreter uses a simple symbol table to keep track of owords. In particular, when jumping backwards, it needs to look them up. (Also when calling a subroutine.). The way I will handle local owords is that in the symbol table if the oword (say o$foo$) is defined in a subroutine oHol$e, I will store it as: Hole$foo in the symbol table.
[02:23:23] <fenn> instead of inventing a new language for no particular reason..
[02:24:10] <lerman> I view it as a small extension to the existing (rotten) language.
[02:24:29] <fenn> well, i hate g-code, and would welcome a python shell instead
[02:24:45] <cradek> fenn: you've used the AXIS filters right?
[02:24:54] <fenn> it could even be a module that could work with other programs that accept gcode input
[02:24:55] <cradek> fenn: with that you can do whatever you want really
[02:25:02] <fenn> no i havent, will check it out
[02:25:22] <fenn> can i run emc on an unpatched kernel yet?
[02:25:22] <cradek> look at involute.py and then load it directly in AXIS
[02:25:24] <cradek> yes
[02:25:28] <cradek> --enable-simulator
[02:25:34] <cradek> all userland
[02:25:55] <cradek> my main devel system is unpatched
[02:26:01] <lerman> When you look at the code in the axis window, it doesn't look at all like what you thought you wrote. I think that's the down side. Of course, you would make it so that wasn't the case.
[02:27:19] <cradek> lerman: I think that's a downside too, but I'm not sure what the actual penalty in usability is.
[02:27:55] <fenn> --enable-simulator should be in the .deb so people can try it out quickly to play around
[02:27:56] <cradek> flowsnake.ngc is similarly useless to see in the AXIS window.
[02:28:00] <lerman> Well, you could modify axis to show the new source language in the window.
[02:28:05] <cradek> fenn: there will be a simulator deb.
[02:28:17] <fenn> nice
[02:28:32] <cradek> lerman: but to what end? like flowsnake it could only highlight the "print" line which is very minimally useful.
[02:28:43] <cradek> lerman: (talking specifically about involute.py)
[02:29:51] <fenn> yep you'd need a source level debugger for it to be useful
[02:31:34] <lerman> We could buld some hooks to allow single step interpretation where a step was a line of source code and each line complete on the machine before the next was done -- zero lookahead. That would be good for debugging.
[02:34:42] <cradek> I think you want a full (gcode) programming language and gcode-based development environment built into emc.
[02:35:27] <cradek> I'm pretty sure I don't share that vision but I don't see any harm in it (except the cost in effort it would require)
[02:36:25] <fenn> i'd rather gcode stay a data format
[02:36:29] <cradek> the most basic gcode (g0, g1, g2) is trivially easy to generate in any existing language, and as programmers we know a few of them inside-out
[02:37:35] <fenn> its main utility is that it's interoperable with other software
[02:37:56] <cradek> well, sort of interoperable
[02:38:01] <fenn> yes, sort of
[02:38:20] <fenn> and the more "features" we add to it, the less it is
[02:38:22] <lerman> Yes, but reading some of the code to generate it isn't always so easy. Particularly if you want to use parameters.
[02:39:08] <fenn> do axis filters run in "real time"?
[02:39:11] <lerman> People who know how to generate 'standard' gcode can write for emc. You don't have to use the features.
[02:39:28] <fenn> or some approximation thereof
[02:39:32] <cradek> fenn: at program load/reload time
[02:39:59] <cradek> fenn: so to develop/debug I just change the code and hit reload in axis to see the new plot
[02:43:32] <fenn> * fenn wonders why there is no gcc-4.0 in debian archives
[02:45:22] <lerman> My 'vision' (to use the term loosely) is to use a conversational interface to invoke canned "wizards". So, the writer of the wiz would have to know how to write this stuff. The end user would use a combination of conversational interface and "standard" gcode.
[02:46:34] <fenn> that's what i was thinking too
[02:47:16] <fenn> i dont think its necessary to actually use gcode for the wizards though
[02:48:07] <lerman> That's true. They could all be written in C, or python, or lisp, or english.
[02:48:15] <fenn> heh maybe not english
[02:52:56] <skunkworks> * skunkworks has run linux all day - no xp at all.
[02:55:52] <cradek> do you have apps that require windows (and don't work under wine)?
[02:56:25] <cradek> tomp (I think it was) said his cad/cam programs all worked under wine
[02:56:58] <skunkworks> This is home stuff - mostly surfing and playing with emc
[02:57:11] <cradek> ah, then it's easy
[02:58:37] <skunkworks> :)
[03:07:03] <fenn> lets hope installing libc6 from ubuntu doesnt destroy my system
[03:07:20] <cradek> why do you need that?
[03:07:44] <fenn> * fenn mutters
[03:07:52] <fenn> emc2 wants gcc-4.0
[03:07:56] <fenn> which isnt in debian for some odd reason
[03:08:15] <cradek> why do you think it wants that?
[03:08:37] <cradek> I mean it's built with at least 3 and 4 on our ubuntu versions
[03:08:45] <cradek> and maybe still with 2 on bdi
[03:09:06] <fenn> apt-get build-dep emc2-axis gives me (only)
[03:09:07] <fenn> E: Build-dependencies for emc2-axis could not be satisfied.
[03:09:23] <fenn> i'm not sure what the problem is; now i dont remember why i thought it wanted gcc-4.0
[03:09:26] <cradek> you shouldn't mess with the ubuntu repositories if you're not running ubuntu
[03:09:35] <fenn> right
[03:09:35] <cradek> just get the source and compile it
[03:09:53] <cradek> those deps aren't going to be right at all for you
[03:09:56] <fenn> how can i get it to print a list of dependencies?
[03:10:16] <cradek> apt-cache showsrc emc2
[03:10:30] <fenn> i was hoping to make a simple set of steps to get a build environment for emc2 on debian
[03:10:32] <cradek> but those are for 2.0, and you're probably building head, so they're wrong anyway
[03:11:01] <cradek> run configure, see what it barfs on, guess a package that might satisfy it, lather, rinse, repeat
[03:11:08] <fenn> right...
[03:11:13] <cradek> at the end you'll have a list of packages and you can make a nice wiki page :-)
[03:11:23] <fenn> sounds like a plan
[03:11:48] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Sarge_Compile_EMC2
[03:11:56] <cradek> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Etch_Compile_EMC2
[03:12:03] <cradek> looks like that work is done already
[03:12:11] <skunkworks> isn't ubuntu 'debian'?
[03:12:24] <cradek> skunkworks: it's a descendent of debian
[03:12:25] <fenn> oops, thanks cradek :)
[03:12:42] <cradek> fenn: I bet that's for realtime - it will be easier for you
[03:14:41] <cradek> I don't understand why this person makes a copy of the cvs directory to compile
[03:14:55] <cradek> (I'd use the package list on those pages and ignore the rest of the instructions)
[03:30:30] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (configure configure.in): building outside the source tree doesn't work, so signal an error early if this is requested. other changes due to different autotools versions, yech
[03:32:39] <fenn> heh "Checking for stray cats"
[03:33:05] <cradek> does that mean you got a build?
[03:33:36] <fenn> yes
[03:33:55] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (configure configure.in): remove deprecated --with-rtai and --with-rtlinux: use --with-realtime= instead
[03:35:53] <jtr> Aha! I thought my eyes were playing tricks on me. There are stray cats!
[03:38:35] <fenn> gosh that was easy
[03:38:50] <cradek> I can't tell if that's sarcastic or not
[03:38:55] <fenn> it was easy
[03:39:05] <cradek> ok, good
[03:44:18] <CIA-8> 03jepler 07HEAD * 10emc2/src/ (configure configure.in): remove unused WFLAGS variable. when compiling without --enable-run-in-place, set EMC2_HOME to prefix
[03:48:26] <CIA-8> 03jepler 07HEAD * 10emc2/scripts/runtests: consistently use 3 stars to mark failures
[03:53:56] <skunkworks> so what exactly is a stray cat?
[03:54:00] <skunkworks> (we have 2)
[03:54:23] <jtr> they're not stray anymore, then. ;)
[03:54:32] <skunkworks> good point
[03:56:05] <jtr> During the build, a message pops up - checking for stray cats. I'm building docs as well, so it scrolled away...
[03:57:19] <skunkworks> I saw that too - after the make. or was it the configure.
[03:57:40] <jtr> now running my first emc2 compiled from source. Yay!
[03:57:47] <cradek> a catman page is an uncompressed manpage (ready to display)
[03:58:15] <jtr> oh, so it's a serious message?
[03:58:15] <cradek> so I think a stray cat is jokingly a catman page without its corresponding source
[03:58:43] <cradek> I'm sure it's written to be funny, but it does mean something real
[03:58:51] <cradek> it's not *only* a joke
[03:59:00] <skunkworks> I figured it was a funny way of getting the point across
[03:59:11] <cradek> yeah I think so
[04:00:15] <cradek> when computers were so slow to decompress files that you'd get impatient waiting for a man page to display (really) uncompressed versions were kept on disk. seems hard to believe today.
[04:00:51] <cradek> definitely not needed anymore
[04:01:10] <fenn> when i first saw that man pages were kept as .gz's i was like.. "wow, how do they read the files without uncompressing them first?"
[04:01:12] <cradek> although there's hardly reason to compress them either
[04:01:31] <fenn> could be helpful if you have a ram disk
[04:01:55] <fenn> or embedded systems
[04:01:58] <skunkworks> I used to play doom in a ram disk. A long time ago. loaded levesl fast.
[04:02:13] <cradek> yeah there are some special situations where storage is still tight
[04:03:12] <cradek> skunkworks: I used to run dos and procomm in a ramdisk to free up my (one) floppy drive for downloading from the BBSes
[04:03:17] <K`zan> Hi folks
[04:03:26] <cradek> hi
[04:03:45] <cradek> skunkworks: but I don't remember it doing anything fast... :-)
[04:04:15] <skunkworks> :)
[04:05:10] <CIA-8> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[04:05:42] <cradek> hmm, guess WFLAGS was used
[04:13:32] <CIA-8> 03cradek 07HEAD * 10emc2/src/Makefile.inc.in: fix bdi451 build failure
[04:13:46] <cradek> * cradek kicks compile-farm
[04:15:38] <Jymmm> No Chicken Kickin!
[04:30:13] <CIA-8> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build PASSED
[04:30:19] <cradek> whee
[04:33:51] <Jymmm> heh
[09:19:58] <awallin> from hal import *; import time
[09:19:58] <awallin> ImportError: No module named hal
[09:19:58] <awallin> ???
[09:50:27] <lerneaen_hydra> 'lo
[09:50:36] <awallin> gott nytt år
[09:51:27] <lerneaen_hydra> desamma! :)
[09:54:24] <awallin> from hal import *; import time
[09:54:25] <awallin> ImportError: No module named hal
[09:54:41] <awallin> any ideas ? I bet my python path is somehow wrong...
[10:07:31] <Welcome> It just ticked over into the new year in Kiritimati (Christmas Island) about 5 minutes ago, so to everyone there Happy New Year! If you want, please stop by our celebration channel #freenode-newyears :D
[10:11:32] <awallin> ok so now I can load the hal module
[10:11:47] <awallin> but I get: NameError: name 'HAL_U8' is not defined
[10:29:38] <jtr> I think they recently changed to 32 bit only - U8 and U16 are gone. Let me check...
[10:38:08] <jtr> yep - http://cvs.linuxcnc.org/cvs/emc2/docs/NEWS?rev=HEAD;content-type=text%2Fplain
[10:40:22] <A-L-P-H-A> I need to mail SWPadnos some funds.
[10:40:25] <A-L-P-H-A> has the order been placed?
[10:41:03] <robin_sz> meep?
[10:45:51] <jtr> shipped already to swp
[10:55:19] <awallin> jtr: thanks, I'll try u32
[10:56:44] <awallin> yeah, it works. thanks.
[10:56:56] <jtr> glad I could help
[10:58:50] <CIA-8> 03awallin 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/haltest.py: no such thing as hal_u8 anymore...
[10:58:56] <awallin> there.
[10:59:13] <jtr> that'll show it!
[11:35:38] <alex_joni> hi all
[11:38:01] <jtr> morning
[12:35:53] <anonimasu> damn I missed that awallin guy..
[12:45:00] <alex_joni> he goes by the name of etla usually
[13:05:51] <anonimasu> oh
[13:25:47] <alex_joni> anonimasu: now he's back
[13:26:29] <lerneaen_hydra> yay!
[13:31:11] <awallin> anyone know where the source for the hal python module is ?
[13:31:23] <awallin> I can't find any docs....
[13:34:07] <awallin> why does this happen:
[13:34:10] <awallin> AttributeError: 'module' object has no attribute 'TRAJ_MODE_FREE'
[13:34:21] <awallin> when I try to run emctop.py
[13:34:29] <alex_joni> clearly bogons
[13:34:49] <lerneaen_hydra> alex_joni: has 2.1 sim been released to the apt system yet?
[13:34:55] <alex_joni> awallin: emctop gets run from axis
[13:34:57] <lerneaen_hydra> ie. no RT parts at all
[13:35:12] <alex_joni> awallin: maybe it needs special params?
[13:35:12] <awallin> alex: yes, but I want to run it from the command prompt
[13:35:27] <awallin> yes, you might be right...
[13:35:30] <alex_joni> awallin: I suggest you look at the way it gets called from the menu
[13:35:36] <alex_joni> lerneaen_hydra: not yet
[13:35:55] <lerneaen_hydra> alex_joni: oh, ok. a few weeks or so?
[13:36:03] <alex_joni> might be
[13:36:18] <alex_joni> I only tested if RT packages build ok
[13:36:30] <alex_joni> not sure about sim
[13:36:49] <lerneaen_hydra> ok
[13:36:59] <lerneaen_hydra> I take it sim has nearly no requirements at all?
[13:37:10] <lerneaen_hydra> so it would be suitable to install on a standard workstation?
[13:37:19] <alex_joni> same as emc2 without the rt kernel
[13:37:32] <alex_joni> so you still need tcl, tk, python, etc
[13:37:43] <lerneaen_hydra> yeah. but that's just "normal" libs
[13:37:51] <lerneaen_hydra> nothing exotic
[13:38:32] <alex_joni> I suspect that you don't need anything else from a special repo than the emc2 package
[13:39:10] <lerneaen_hydra> ok, sounds promising
[13:43:31] <awallin> anyone know how timer() works in Tk ?
[13:44:46] <alex_joni> awallin: surely unlike any other language
[13:45:10] <alex_joni> found the hal stuff?
[13:45:13] <awallin> ;)
[13:45:38] <awallin> yeah, I got the hal module loaded by setting sys.path correctly
[13:46:02] <awallin> the run-in-place installations of emc don't install the libs where they are supposed to be...
[13:46:41] <alex_joni> emc2/src/hal/halmodule.cc
[13:46:49] <awallin> thanks.
[13:46:59] <alex_joni> awallin: there is a emc-environment thingie you could run
[13:47:08] <awallin> do you know how documentation is added that will show up with the pydoc command ?
[13:47:10] <alex_joni> in scripts/
[13:47:24] <alex_joni> * alex_joni knows nothing about py
[13:48:08] <alex_joni> I'm afraid you need to bug jepler
[13:51:46] <alex_joni> bbl
[14:30:39] <jepler> awallin: For functions written in Python, a string literal at the very beginning of the function is its documentation.
[14:30:41] <jepler> def f():
[14:30:45] <jepler> """ this is the docstring """
[14:30:48] <jepler> return 3.1415
[14:31:15] <awallin> thanks.
[14:31:33] <awallin> is the hal module written in python, so that docstrings can be added somewhere
[14:31:41] <jepler> no, that's written in "C"
[14:31:45] <awallin> now pydoc hal doesn't give anything
[14:32:00] <jepler> Help on module hal:
[14:32:00] <jepler> NAME
[14:32:00] <jepler> hal - Interface to emc2's hal
[14:32:03] <jepler> ...
[14:32:12] <jepler> but the rest of it is not very useful
[14:32:22] <awallin> no Python documentation found for 'hal'
[14:32:29] <awallin> I might have it in the wrong directory...
[14:32:58] <jepler> emc2 "run-in-place" doesn't install the python modules in a standard location
[14:33:10] <jepler> in your shell, execute: . scripts/emc-environment
[14:33:20] <jepler> then PYTHONPATH (as well as other variables) will be set so that the emc2 python modules will be found
[14:34:08] <awallin> ok, now it works
[14:34:15] <awallin> I'm tinkerking with tkinter and hal
[14:35:37] <jepler> you mentioned timer(); I'm not familiar with that
[14:35:57] <awallin> heh ;) I'm copy/pasting from emctop.py
[14:36:01] <awallin> it works now.
[14:36:37] <jepler> you asked about timer(). In Tk, you use the .after method of a widget to schedule something to happen later
[14:37:00] <jepler> t.after(100, timer) means: call the function timer after 100ms have passed
[14:37:16] <jepler> so timer() does some work, and then when it's all done arranges to be called 1/10 second later
[14:38:30] <awallin> right.
[14:39:01] <awallin> I'll try to get something rudimentary to work today, and I'll post it on the wiki later, then you can all laugh about it...
[14:39:31] <jepler> have fun
[14:41:08] <awallin> hal.error: Resource limit reached
[14:41:09] <awallin> ??
[14:41:59] <awallin> this happens when I call hal.component() the second time
[14:42:36] <jepler> hal only supports one component per userspace process
[14:43:10] <awallin> and the only way to create pin's is through component.newpin() ?
[14:43:14] <jepler> yes
[14:43:41] <awallin> so I need to have only one component, and pass that around as an argument to places where I want to create pins
[14:43:46] <jepler> yes
[14:44:45] <CIA-8> 03jepler 07HEAD * 10emc2/src/.swish_config: exclude more binary files from full-text indexing
[14:50:36] <awallin> hmm. in tkinter, how do I quory the state of a Button ?
[14:50:44] <awallin> query
[14:52:07] <jepler> there's what tk calls the button's -state ("normal" or "disabled") but I have a feeling that's not what you mean
[14:53:09] <awallin> it's probably something with command=
[14:53:17] <awallin> so there's no internal state telling me it's up or down
[14:53:29] <awallin> just command which get's called every time the button is pressed
[14:53:31] <jepler> the command= of a Button will be called when the button is clicked (pressed and then released)
[14:53:57] <awallin> I wan't the state, either pressed, or released
[14:54:19] <jepler> do you want a CheckButton?
[14:54:56] <awallin> I'll try that later, but I'd like to start with Button
[14:55:48] <jepler> you can create a binding on <ButtonPress> (after which the button will be pressed) and <ButtonRelease> (after which the button will be released)
[14:57:38] <jepler> here's an example with Checkbutton: http://pastebin.ca/298062
[14:58:17] <awallin> thanks.
[14:59:59] <jepler> and here's an example with Button: http://pastebin.ca/298063
[15:00:05] <awallin> that's useful, but it will stay down once pressed, I'd also like buttons that will spring up once released
[15:01:31] <awallin> yes, the second example is what I am looking for. thanks.
[15:01:45] <jepler> great, you're welcome
[15:04:04] <awallin> hmm. pressed() needs to be defined before the bind method is called
[15:04:23] <awallin> but I want to call the bind method in __init__
[15:05:53] <awallin> ah... self.
[15:05:59] <awallin> it's fixed.
[15:06:28] <jepler> I'll show you my solution anyway: http://pastebin.ca/298066
[15:06:57] <lerman> Folks. After yesterdays discussion of the named parameters, I'm considering a revision. Please take a look at:
[15:06:58] <lerman> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?AlternativeNamedParameterSyntax. I think this will be much more legible and easier to write.
[15:08:29] <jepler> I'd rather have [#1 < #2] -- it's a pity to use up less-than and greater-than on parameter names
[15:08:37] <jepler> there's {} available if you want matching characters
[15:09:24] <lerman> I know. But we use LT or GT for those operators. And {} are somewhat more obtrusive.
[15:10:32] <awallin> jepler: do you have an idea for how to make my inherited classes prettier: http://pastebin.ca/298071
[15:10:36] <jepler> does this do away with the leading # altogether? g0 x<x> not g0 x#<x>?
[15:10:45] <awallin> jepler: the fromval, toval etc. syntax seems ugly.
[15:11:38] <lerman> No. It doesn't. (I should make that clear. #1, #2, or #<named parameter>
[15:12:38] <jepler> awallin: you can use a **-arg which accepts any keyword arguments
[15:12:39] <jepler> def __init__(self, master, pycomp, halpin, **kw):
[15:12:41] <jepler> Scale.__init__(self, master, **kw)
[15:12:49] <jepler> so now your __init__ requires 3 arguments: master, pycomp, halpin
[15:12:51] <lerman> Damn. The '#' were taken out by the wiki software.
[15:13:01] <jepler> it also accepts any keyword arguments and passes them on to Scale.__init__
[15:13:08] <awallin> jepler: thanks, I'll try that
[15:16:19] <awallin> jepler: it works.
[15:17:28] <awallin> jepler: if I have halpin="text" and the do pycomp.newpin(halpin,HAL_BIT,HAL_OUT)
[15:17:41] <awallin> then that creates a HAL pin pycomp.text
[15:18:01] <awallin> but how can I reference it later in the program ? pycomp.halpin does not work
[15:21:50] <awallin> this illustrates what I mean: http://pastebin.ca/298079
[15:30:22] <lerneaen_hydra> bbml
[15:30:28] <lerneaen_hydra> tomorrow sometime
[15:30:50] <jepler> setattr(pycomp, halpin, newvalue) ?
[15:31:47] <jepler> oh, it looks like you can use pycomp[halpin] = newvalue as well
[15:32:03] <awallin> interesting, I'll try that
[15:33:28] <awallin> hmm, the argument to the constructor does not seem to be saved with the object ?
[15:33:43] <awallin> later, in a method I can't just do self.halpin
[15:34:08] <jepler> you'd have to write 'self.halpin = halpin' in the __ini__
[15:34:11] <jepler> __init__
[15:34:16] <awallin> yes.
[15:34:21] <jepler> ditto for pycomp
[15:34:46] <jepler> unless it's a global variable
[15:35:18] <awallin> it's defined in another file, which imports the file I am working in
[15:35:24] <awallin> so it's not needed for pycomp
[15:40:02] <jepler> bbl
[15:40:46] <awallin> bye
[16:11:39] <tomp> hello
[16:12:14] <awallin> hi
[16:12:27] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/drivers/ (Submakefile m5i20_HM5-4E.h): automatically regenerate m5i20_HM5-4E.h from HOSTM54E.BIT
[16:20:13] <awallin> hi dan
[16:22:38] <lerman> jepler: are you back?
[16:23:40] <lerman> I found a bug(let) in axis :-)
[16:23:58] <lerman> S/B :-(
[16:24:06] <awallin> what kind ?
[16:25:00] <lerman> A message text is wrong. Roll oever the jog increment and see that it says "ingrement"
[16:25:23] <awallin> hah
[16:25:43] <lerman> I found a place to fix it, but since I'm not familiar with how that stuff is built, I don't want to change it (perhaps in the wrong place).
[16:27:22] <lerman> Has anyone besides me noticed a difficulty with using IRC? I wanted to refer to a previous conversation and said "last night". In email, I refered to the date. But because of our international membership, date and time don't mean the same things to everyone.
[16:28:07] <awallin> there's something called internet time if you really think its a problem ;)
[16:28:09] <cradek> lerman: we all seem to compensate for that automatically
[16:28:16] <lerman> I don't even know where half of you are located.
[16:28:49] <lerman> cradek: Did you see my bug(let) comment, above?
[16:28:55] <cradek> yes thanks
[16:30:25] <cradek> brb
[16:30:49] <lerman> I attended a 'workshop' (sort of) in Linkoping many years ago, led by Gerry Weinberg, teaching 'review techniques'. He suggests saying something positive before making negative comments. Did I say that axis is *great*.
[16:31:43] <CIA-8> 03jepler 07HEAD * 10emc2/share/axis/tcl/axis.tcl: fix typo
[16:31:58] <lerman> Pardons requested from our Swedish friends for not knowing how to put two dots over the 'o' in Linkoping.
[16:32:07] <CIA-8> 03jepler 07HEAD * 10emc2/src/po/ (6 files): fix typo
[16:32:14] <jepler> lerman: thanks for noticing
[16:32:41] <jepler> I really wish one typo was the worst of the shortcomings in axis
[16:32:46] <lerman> That it is great -- or the typo.
[16:32:58] <jepler> both
[16:33:09] <lerman> :-) I couldn't help noticing (both).
[16:34:00] <lerman> After I finish the latest round of interpreter changes, I want to get back to my GWiz project.
[16:34:39] <lerman> I tried porting it to linux last night with mixed results. I need to make some code changes to even get it to build.
[16:34:51] <awallin> lerman: do you get the two dots: ö
[16:35:03] <jepler> I see the two dots
[16:35:11] <lerman> Yes.
[16:35:16] <awallin> so the solution is simple: get a FIN/SWE keyboard ! ;)
[16:35:31] <lerman> How would *I* make them.
[16:35:44] <cradek> nah, set up your compose key: ö
[16:35:53] <awallin> probably hold down alt and press some number config
[16:36:05] <awallin> then you need to know the ascii number for ö
[16:36:05] <cradek> [compose] o " => ö
[16:36:06] <lerman> How is this? ö
[16:36:17] <awallin> lerman: yes, that works
[16:36:44] <lerman> I don't see a compose key. (But I do know how to cut and paste.) :-)
[16:36:53] <awallin> so what VCP widgets would be nice to have ?
[16:37:12] <cradek> lerman: mine has a stupid flying window? on it
[16:37:52] <lerman> I guess mine does, too. How do I "set it up".
[16:38:06] <lerman> (In windoze.)
[16:38:21] <jepler> oh, in windows? who knows!
[16:38:27] <cradek> oh
[16:38:29] <cradek> no idea
[16:38:39] <cradek> xmodmap -e 'keycode 115 = Multi_key'
[16:38:42] <cradek> this will do it in linux
[16:39:07] <jepler> I prefer to use capslock: keycode 66 = Multi_key
[16:39:11] <cradek> you might have to buy a new copy of windows for a different language (really)
[16:39:21] <cradek> I use scroll lock on other machines (that don't have windows keys)
[16:40:06] <jepler> http://support.microsoft.com/kb/306560
[16:40:35] <jepler> apparently you'd follow these directions and then use right-alt+"p" for Ö
[16:41:41] <cradek> When you press the APOSTROPHE (') key, QUOTATION MARK (") key, ACCENT GRAVE (`) key, TILDE (~) key, ACCENT CIRCUMFLEX key, or CARET (^) key, nothing appears on the screen until you press a second key. If you press one of the letters designated as eligible to receive an accent mark, the accented version of the letter appears. If you press the key of a character that is not eligible to receive an accent mark, two separate characters appear.
[16:42:12] <cradek> (that seems like a terrible idea)
[16:43:38] <jepler> * jepler shrugs
[16:43:45] <jepler> who knows better -- you or microsoft?
[16:44:03] <awallin> jepler: how do I brake down long lines into many lines in python ? (since whitespace usually matters)
[16:44:24] <lerman> awallin: asked: so what VCP widgets would be nice to have ?
[16:44:26] <lerman> what's a VCP widget?
[16:44:30] <jepler> awallin: If it's inside (), [], or {} then just break the lines as you wish
[16:44:53] <lerman> ...and if it's not?...
[16:44:53] <cradek> lerman: run the halui/halvcp sample configuration
[16:45:14] <jepler> awallin: if it's in a string, use triple-quoted strings """...""" or '''...''' (the line breaks will be included in the resulting string
[16:45:20] <awallin> lerman: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Halui
[16:45:21] <jepler> awallin: otherwise, use \ at the end of the line, as in C
[16:45:43] <awallin> jepler: mostly I have many things in the function arguments.
[16:45:59] <cradek> lerman: it's an on-screen configurable 'control panel'
[16:46:10] <cradek> lerman: to hook up buttons/lights to hal pins
[16:46:40] <lerman> Ah.. Virtual Control Panel ???
[16:46:43] <jepler> awallin: then you should just be able to insert the newlines where you like
[16:47:01] <CIA-8> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[16:47:19] <jepler> I broke it again? *grumble*
[16:48:13] <lerman> Better than *He* broke it again? :-)
[16:49:18] <CIA-8> 03jepler 07HEAD * 10emc2/src/po/ (6 files): remove duplicate message introduced by last commit
[17:05:15] <awallin> how do I take a screenshot (of a window) in ubuntu ?
[17:05:53] <SWPadnos> press the <print-screen> key (or alt-prtsc, or ctrl-prtsc - don't remember)
[17:06:13] <awallin> thanks
[17:06:19] <SWPadnos> np
[17:06:19] <awallin> now I need to crop it...
[17:06:37] <SWPadnos> try alt-prt-sc - that'll be just the active application window I think
[17:07:01] <CIA-8> 03compile-farm 07BDI-4.51 ( * 10emc2head/: build PASSED
[17:09:37] <awallin> there was some site similar to pastebin, but for pictures
[17:09:41] <awallin> ?
[17:09:45] <SWPadnos> imagebin
[17:10:14] <awallin> I'll try uploading it there
[17:10:35] <SWPadnos> if it's less than 200k (I think) - you can upload it to the emc wiki
[17:11:18] <awallin> here http://imagebin.org/6823
[17:11:31] <awallin> that's what I've been doing today for some hours
[17:11:42] <awallin> not much, but those controls are all connected to HAL pins
[17:11:46] <SWPadnos> cool -analog :)
[17:11:51] <jepler> looks like a good start
[17:11:59] <awallin> so it's basically what's in VCP + a bit more
[17:12:12] <jepler> hard coded layout for now?
[17:12:24] <awallin> yes, evertyhing with pack
[17:12:37] <awallin> I've not thought about layout at all
[17:12:58] <awallin> I think I'll post the code on the wiki so that someone more experienced can comment
[17:12:59] <SWPadnos> can you add the "analog" controls to vcp?
[17:13:26] <awallin> SWP: I've looked a bit at vcp, but I can't really understand it. This python code is shorter and simpler
[17:13:31] <SWPadnos> heh -ok. :)
[17:13:41] <awallin> and potentially integrates with axis
[17:13:57] <SWPadnos> it should be simple to add to vcp - if you know how to draw bar graphs in gtk
[17:17:23] <tomp> SWPadnos , i submitted analog pots already, I guess JMK put them in cvs, they were tested ok on STG2, slide thumb on vscale, see analog voltage change on meter
[17:17:54] <SWPadnos> great - I didn't remember that
[17:18:04] <SWPadnos> or maybe I didn't notice it :)
[17:18:17] <tomp> small change
[17:18:58] <SWPadnos> yeah - slider -> HAL is the easier way, I think. of course, I don't know what kinds of bar graph widgets are available in gtk either (so that may be just as easy)
[17:20:58] <tomp> the slider is an input and an output ( not how i coded it for halvcp, but the defaut way..) that means the thumb can move according to the state of a hal output OR the thumb can report its posn to a hal input.
[17:21:11] <tomp> hal -> slider
[17:21:30] <SWPadnos> ok, that makes sense
[17:22:29] <tomp> not as pretty as regular meters and knobs, but do-able
[17:23:13] <tomp> and Happy New Year all! Thanks for all the great work.
[17:23:30] <SWPadnos> in that note, it's time to head out for the New Years festivities
[17:31:40] <froze> does anone know if there is a list of laptops that are known to *not* have problems running EMC?
[17:32:10] <awallin> for testing, or for running real hardware ?
[17:33:05] <froze> tesinting for now, but eventually the idea is to run homebuilt hardware.
[17:34:07] <tomp> awallin: your control panel is nice, did you just import tkinter? (can you use other tk widget sets?)
[17:34:59] <awallin> tomp: yes, just 'import tkinter'. I wan't to use only pretty standard widgets that come with the emc2 installation
[17:35:20] <awallin> froze: I'm running ubuntu on a lenovo t60, but only for testing/devel, not real hardware
[17:36:28] <froze> is there an issue with the laptop for real hardware? or is it just a preference thing.
[17:37:15] <awallin> well usually laptops are pretty bad at real-time stuff, so running real hardware might be tricky
[17:38:56] <froze> are there any problems with mini-atx boards or is it just the laptops?
[17:39:04] <awallin> tomp: did you have any particular tkinter widhet sets in mind ?
[17:40:26] <awallin> froze: mini-atx should be ok. Don't know about the really small ones like itx...
[17:41:45] <froze> Thanks for the info.
[17:47:10] <tomp> awallin: i dont understand 'tkinter widget set', i thought tk widgets belonged to tk, so i dont understand that relationship, other than an interface was made between python and tkinter, and a further interface was made to hal (by c i think )
[17:47:30] <tomp> i thought we might use any tk widget sets, blit bwidget, ....
[17:48:04] <tomp> there was one really nice looking one I showed to ray... lookin now
[17:48:52] <awallin> tomp: I'm not an expert, I just say 'import tkinter' at the start of my file, and then I use http://www.pythonware.com/library/tkinter/introduction/index.htm whenever I am in trouble (a lot!)
[17:53:36] <tomp> awallin: the spiffy widgets were in TkZinc & Tix , & sorry gotta run to airport for a pickup. Happy New Year! (am interested in the code you used for the pasteimage :)
[17:54:01] <awallin> happy new year !
[18:12:47] <cradek> froze: my PIII laptop is known to work - if you want to buy one especially for EMC use, I will go get its model for you (it's in the car)
[18:13:33] <froze> cradek: That would very nice of you, if it is not to much trouble.
[18:14:06] <cradek> ok, I will do it soon
[18:14:26] <froze> cradek: Thanks!
[18:36:26] <cradek> froze: gateway solo 5300
[18:37:03] <froze> cradek: Thanks! that is helpful
[18:37:31] <cradek> it has some kind of ATI video with direct rendering that works with ubuntu, and doesn't screw up the realtime
[18:38:42] <cradek> hmm, looks like the solo 5300 came as several speeds, maybe other differences too
[18:40:27] <froze> hopefully the discrepencies are not impairing
[18:40:53] <robin_sz> moo
[18:42:49] <cradek> mine is the PIII-900 BIOS Ver 22.07 Micom (?) version K22.04
[18:42:58] <cradek> http://cgi.ebay.com/Gateway-Solo-5300-Pentium-III-750-MHz-Laptop-No-Reserve_W0QQitemZ320065937099QQihZ011QQcategoryZ140081QQrdZ1QQcmdZViewItem
[18:43:14] <cradek> so this one is close but not the sam
[18:43:15] <cradek> e
[18:43:49] <cradek> my only complaint is the processor fan runs full speed all the time
[18:46:11] <A-L-P-H-A> SWPadnos, I'm not identified, so I can't reply.
[19:23:23] <CIA-8> 03jepler 07v2_1_branch * 10emc2/share/axis/tcl/axis.tcl: merge rev 1.13: fix typo
[22:37:26] <anonimasu> hm
[22:37:28] <anonimasu> what's up?=
[22:37:59] <awallin> 2007 !
[22:38:04] <anonimasu> not yet..
[22:38:12] <anonimasu> 23:38
[22:38:32] <awallin> 00:38 at the easterly longitude where I am..
[22:38:38] <anonimasu> ok
[22:39:01] <anonimasu> :)
[23:12:47] <cradek> lerman: I like http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?AlternativeNamedParameterSyntax a lot more
[23:13:08] <cradek> it looks a lot less confusing
[23:13:52] <lerman> cradek: How did you know that I just came back into the house after working in the wood shop. Not 5 minutes, ago. And I've been on the machine for less than two.
[23:13:58] <lerman> Good. I agree.
[23:14:29] <cradek> lerman: I type whether or not I think the person is there; eventually he'll see it if he's interested
[23:14:57] <lerman> Also, I was reading the oword docs about parameters 1-30 being saved and restored. The purpose of that was to provide some local parameters.
[23:15:40] <lerman> That won't be needed anymore. We probably shouldn't change it, though.
[23:16:56] <lerman> Happy New Year to you. And a special one to our colleagues (ap?) who have already celebrated.
[23:17:11] <cradek> thanks
[23:17:22] <cradek> I guess I don't have any opinion about #1-30
[23:17:57] <skunkworks> * skunkworks wishes everyone a happy new year also.
[23:18:15] <lerman> If you forget about that "feature", you might be surprised.
[23:18:38] <lerman> What do you think about my proposal for integrator defined canned cycles?
[23:19:00] <lerman> That's on my *list* of things to do.
[23:19:38] <cradek> ummm
[23:20:02] <cradek> I think it's a shame to discard the tested, working canned cycles we have - and I don't think you can reimplement them with your suggestion
[23:20:14] <lerman> The only down side that I see is that Axis would show the steps within the canned cycle instead of just the single command. (Or is that another up side.).
[23:20:43] <lerman> BBL time for dinner. Sorry to run in the middle of a conversation.
[23:20:53] <cradek> that's ok, we'll finish later
[23:20:58] <cradek> a hot dinner doesn't wait
[23:21:41] <skunkworks> cradek: no hot parties tonight?
[23:21:55] <cradek> nah, just another day
[23:22:24] <cradek> and a nice extra day off work
[23:22:27] <skunkworks> we are having a few friends over - mainly to drink a bit.
[23:22:46] <cradek> we do have a nice bottle of wine I think
[23:22:52] <cradek> we can share it with the cats ... or something like that
[23:22:57] <skunkworks> :)
[23:23:07] <skunkworks> our cat are on the wagan
[23:23:49] <skunkworks> crap biab...
[23:38:09] <skunkworks> I was told the reason why <>/ where used in java script is because they could be quicky typed on the keyboad.. being they where all in cclose proximity
[23:49:51] <lerman> I'm back. cradek: are you still here?
[23:49:55] <cradek> yes
[23:50:17] <lerman> Why can't my proposal implement all canned cycles?
[23:50:44] <cradek> because canned cycles currently can work in any plane
[23:51:04] <lerman> Not that I would discard the existing ones... but we could, (I think). But, so can normal gcode.
[23:51:50] <lerman> My understanding (even the name) is that canned cycles are predefined sequences of code with a special interface.
[23:52:19] <cradek> beware, I'm no expert on the canned cycles
[23:52:27] <lerman> Nor am I.
[23:53:04] <lerman> I've never used canned cycles, but I have written my own subroutines to do peck drilling.
[23:53:42] <cradek> I think the existing ones should do the same on every machine
[23:53:56] <cradek> I don't see any benefit to rewriting them
[23:54:40] <lerman> Absolutely. That's why I wouldn't rewrite them. I can't think of any benefit either.
[23:54:53] <cradek> I suspect your peck drilling subroutine can't work in another plane can it?
[23:55:07] <cradek> oh ok
[23:55:12] <cradek> I'll stop worrying about that then
[23:55:30] <cradek> maybe I need to read your proposal again in that case
[23:55:40] <lerman> No, it can't. But I didn't write it so it could. And what does it mean to drill in another plane?
[23:55:46] <cradek> I thought you were talking explicitly about rewriting the canned cycles ("I see no reason for them to be in the interpreter" I thought you said)
[23:57:45] <lerman> I probably did say that. But I didn't mean that we should take them out. What I meant was the things like new lathe canned cycles that do complex threading -- multiple passes, tapers, etc could be written as special gcode routines. Writing them as C code embedded in the interpreter doesn't make much sense to me -- if we had an alternative.
[23:58:39] <cradek> ok I see
[23:59:19] <lerman> That way, one of our developers could write this stuff and play with it without digging into the interpreter.
[23:59:35] <fenn> what if you write m-codes and just pretend they're g codes?
[23:59:41] <fenn> like m101