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