Back
[00:55:49] <jmkasunich> hi guys
[00:56:15] <SWPadnos> hiya
[00:58:22] <jmkasunich> trying to decide whether to delete the original vcp code from cvs
[00:58:49] <SWPadnos> it's pretty much just got bits, right? (LEDs and buttons)
[00:59:26] <SWPadnos> the thing to do may be to create a tag just before removing it (something like pre_vcp_removal), then delete it
[00:59:42] <SWPadnos> if anyone wants it, it's still in CVS, and easy to find with the tag
[01:01:48] <jmkasunich> that sounds like a good idea
[01:02:07] <jmkasunich> hmm
[01:02:26] <jmkasunich> unfortunately there are several vcp files in the sample configs
[01:02:35] <jmkasunich> until those are changed to use halvcp, we need to keep it
[01:02:42] <SWPadnos> those should probably be left until they're changed over
[01:02:54] <jmkasunich> s/halvcp/pyvcp
[01:03:09] <jmkasunich> as long as they exist, the code needs to exist too
[01:03:12] <SWPadnos> true
[01:03:34] <SWPadnos> maybe it should be marked as deprecated, and removed in a later version (like 2.2/2.3)
[01:03:58] <jmkasunich> I wonder how hard it would be to write a program that reads a vcp file and exports .xml for pyvcp?
[01:04:04] <SWPadnos> unless someone adds something that can't easily be done with pyvcp
[01:04:07] <SWPadnos> hmmm - dunno
[01:04:45] <jmkasunich> well, we definitely don't want people adding more features to vcp
[01:04:52] <SWPadnos> does vcp have any advantage over pyvcp? (assuming that all widgets in pyvcp are ported, for the sake of argument)
[01:05:08] <SWPadnos> ie, fewer dependencies, faster execution, better portability ...?
[01:05:17] <jmkasunich> ported which way?
[01:05:32] <SWPadnos> assuming that all widgets exist in both programs ...
[01:05:49] <jmkasunich> if you ported all the nice shiny pyvcp widgets over to vcp, then they'd be equivalent, more or less
[01:05:50] <SWPadnos> (ie, we know that there are more widgets in pyvcp, but if vcp had all those, would it be better in any way)
[01:06:07] <SWPadnos> yeah - I'm not sure what the more and less are ;)
[01:06:23] <jmkasunich> the whole point of pycvp however, is that it has nicer shiner widgets
[01:06:36] <SWPadnos> in essence, this is a similar question to "should we remove mini, since we have tkemc"
[01:06:43] <jmkasunich> I seriously doubt anyone is going to port those widgets over to vcp, so the assumption is flawed
[01:07:07] <SWPadnos> well, that's why I'm wondering if would be any advantage to doing so
[01:07:24] <jmkasunich> I don't seen any advantage to porting stuff over to vcp
[01:07:53] <jmkasunich> mini isn't a clone of tkemc, each has a purpose
[01:07:53] <SWPadnos> ok
[01:08:12] <jmkasunich> vcp and pyvcp do _exactly_ the same thing
[01:08:15] <SWPadnos> the only one I could think of would be less stuff needed at runtime, or fewer library/package dependencies
[01:08:16] <jmkasunich> only pyvcp does it better
[01:08:37] <jmkasunich> python being the dependency
[01:08:47] <SWPadnos> python and tcl/tk
[01:08:49] <jmkasunich> if you can run axis, you can run pyvcp
[01:08:49] <SWPadnos> I think
[01:09:30] <SWPadnos> ok. just wondering if there's any advantage. I like compiled standalone programs, personally :)
[01:09:59] <jmkasunich> I think maybe I'll restore the documentation, and add a note saying its deprecated
[01:10:05] <SWPadnos> anyway, VCP would still be around in CVS, it's just a question of what needs to be done before removing it
[01:10:30] <jmkasunich> but leave the code in place, some people may prefer it - like you said, its a compiled standalone program
[01:12:10] <SWPadnos> the vcp source is what, 30k?
[01:12:14] <SWPadnos> if that
[01:12:19] <jmkasunich> not big at all
[01:12:32] <SWPadnos> so it doesn't impact people much if it's left in
[01:12:41] <jmkasunich> the main issue isn't code size, its confusing people with two similarly named things
[01:12:49] <SWPadnos> ok
[01:14:33] <jmkasunich> hmm
[01:14:40] <jmkasunich> pyvcp isn't in 2.1
[01:14:52] <SWPadnos> it's a "new feature" ...
[01:15:00] <SWPadnos> since the branch
[01:15:12] <jmkasunich> if we don't back port it (which we shouldn't do, its not a bugfix), then between the time we release 2,1 and the time we release 2.2 I bet it will gather users
[01:15:22] <jmkasunich> even if we want to deprecate it, we won't be able to
[01:15:41] <jmkasunich> unless we write that .vcp to .xml translator
[01:16:25] <SWPadnos> I think there was some discussion on the pyvcp/vcp thing earlier
[01:17:16] <jmkasunich> yeah, I read back and saw that
[01:21:58] <SWPadnos> hmmm - cool:
http://www.intellesale.com/item.asp?referid=161160&id=85817
[01:22:38] <jmkasunich> neat
[01:23:03] <SWPadnos> that one is inexpensive enough to use, and probably big enough for Ubuntu
[01:31:23] <jmkasunich> I wonder if pyvcp lets you put an LED inside a button?
[01:31:35] <SWPadnos> good question
[01:31:46] <SWPadnos> I'm not sure if buttons are containers
[01:31:52] <jmkasunich> in VCP they are
[01:32:03] <SWPadnos> right. I don't know about tk
[01:32:11] <jmkasunich> I tried to make everything a container unless there was a very good reason not to
[01:32:22] <jmkasunich> you can even put a button in a button if you are feeling perverse
[01:32:27] <SWPadnos> yep. that makes sense where possible
[01:32:29] <SWPadnos> heh
[02:12:22] <jmkasunich_> jmkasunich_ is now known as jmkasunich
[04:17:45] <cradek> has anyone tried M64/65 lately? :-)
[04:18:25] <SWPadnos> nope ;)
[04:18:34] <SWPadnos> is that in 2.0.5?
[04:20:24] <cradek> I don't know
[13:51:05] <jepler> does anybody else's browser go into a weird font when loading
http://linuxcnc.org/docs/2.1/html/gcode/main/index.html ?
[13:52:05] <lerneaen_hydra> I seem to get a generic serif font
[13:52:33] <skunkworks> looks fine here in IE - define 'wierd font'
[13:52:49] <alex_joni> looks OK here.. (Opera)
[13:53:11] <lerneaen_hydra> serif font (firefox 2.x), sans-serif (konq)
[13:53:14] <jepler> a weird double-wide monospace font --
http://emergent.unpy.net/files/sandbox/weird-font.png
[13:53:15] <alex_joni> jepler: same font as on the other pages
[13:53:34] <alex_joni> jepler: definately not
[13:53:45] <lerneaen_hydra> I don't have that, not at all
[13:53:56] <jepler> the "devel" version of that page looks normal in my browser:
http://emergent.unpy.net/files/sandbox/normal-font.png
[13:54:30] <jepler> cradek: I tried MDI M64 P0 / M65 P0 in HEAD and it worked as expected -- halshow of motion.digital-out-00 changed
[13:56:18] <jepler> I hate latex2html
[13:56:28] <jepler> but I like documentation in HTML
[13:56:46] <alex_joni> http://dsplabs.cs.utt.ro/~juve/blog/index.cgi-files/sandbox/normalfont.PNG
[13:57:24] <jepler> that "merge" from HEAD seems to have fixed it
[13:57:39] <jepler> there was a non-ASCII character in the HTML output that should have been a lyx "bullet item"
[13:59:04] <jepler> this change (which also displays in that weird font in my browser):
http://cvs.linuxcnc.org/cvs/emc2/docs/src/gcode/main.lyx.diff?r1=1.14;r2=1.15
[13:59:43] <alex_joni> your browser is not tolerant enough :D
[14:00:57] <jepler> looks like it thinks it's detecting a chinese-language page without a proper coding declaration
[14:01:18] <jepler> when I turn View > Character Encoding > Auto Detect to Off, it doesn't do it anymore
[14:01:30] <jepler> anyway -- it's good because it made me back-port those doc improvements
[14:03:29] <alex_joni> jepler: right
[16:50:26] <SWPadnos> hiya Ray
[16:50:33] <rayh> Hi Steven
[16:50:46] <rayh> How you doing today?
[16:51:11] <SWPadnos> ok. I'm just writing up some product treatments for a meeting in - err - 40 minutes :)
[16:51:31] <rayh> Yep. So leave you alone, 'eh.
[16:52:06] <SWPadnos> heh - just in time for me to start getting nervous :)
[16:53:43] <rayh> I know that feeling.
