EMC: 03jepler 07TRUNK * 10emc2/src/Makefile:
EMC: Michael Buesch reports that this fixes a crashing problem on x86_64 systems.
EMC: I still have not had the time to test it myself for 2.3 (and it doesn't affect
EMC: our supported platforms anyway), but there'll be a lot of time to test it on
SWPLinux: It'd be interesting to know wheter you can run a vismach model
that's python + tk + hal but without most of axis
I think you can 'loadusr' them inside a halrun
without the need to start emc or connect anything
jmkasunich@mahan:~/emcdev/emc2head$ cat gantry.hal
loadusr -Wn gantrypanel pyvcp -c gantrypanel gantry.xml
loadusr -Wn jmkgantrygui src/emc/usr_intf/axis/scripts/jmkgantrygui.py
net gantry gantrypanel.gantry-f jmkgantrygui.gantry
net crotary gantrypanel.crotary-f jmkgantrygui.crotate
net vertical gantrypanel.vertical-f jmkgantrygui.ram
net saddle gantrypanel.saddle-f jmkgantrygui.saddle
I use this ^^^ hal file to run vismach + pyvcp without EMC
gantrypanel lets you jog the gantry around?
I was using vismach as crude 3-D cad
I'm back now
lemme see about vismach
hmmm. on an installed system, how does one run vismach?
the visualization programs should be installed in /usr/bin and loadable by loadusr
$ halrun halrun: loadusr scaragui
hmmm. not by make install
no, not really :)
halcmd: loadusr scaragui
halcmd: alloc: invalid block: 0x7fa2d1081558: 0 0 0
strangely, the joints are still there in HAL, but there's no display window
and ps shows scaragui as defunct:
22023 pts/0 S+ 0:00 halcmd -kf
22073 pts/0 Z+ 0:00 [halcmd] <defunct>
22450 pts/0 Z+ 0:00 [scaragui] <defunct>
the pins probably stay around until you shut down hal
unload didn't get rid of them
(they only get removed by clean shutdown of the creating component, or clean shutdown of hal)
hm, zombie -- I wonder if halcmd has a duty to waitpid on the userspace components it creates .. quite possibly it does
it seems that it shouldn't for loadusr
anyway, it sure looks like a bug or bad interaction with my "togl" (opengl tk widget) or "minigl" (python opengl api) modules
which narrows it down considerably
and based on your traceback, it's probably not in minigl
it happens when first touching togl which would be before touching minigl
do you think it would help for me to try it with python 2.4?
I think it used 2.6 by default
"it" being configure ...
I think the error isn't in the exact same place as before
that's not necessarily a huge surprise
I thought it was in the "Tcl_PkgPresent" line before
the line numbers must be screwed up, because it seems like it's on "return NULL" Now
unless I understand what rows and columns are - duh
yes, it's still the pkgpresent line in PyObject *install()
I had tried sticking a printf just above that stanza, but there were other problems with that :)
the other time you reported this problem, was it in sim?
no. same system as now
oh, realtime both times?
I can try a sim build
I'm installing a jaunty in vmware but I don't intend to spend a day building a realtime kernel
it only takes 30 minutes, including modules
but not in a VM
there's the part where I have to get it right :-P
why'd the put a coffee cup stain on the background image?
well, I can give you some config files that seem to work
hm this can't be right
it is spewing "starting file manager" across the bottom of the screen
it gets up to about 6, then gets back down to about 2
sounds like Windows
same problem with sim
FWIW, I've had defunct vismach related processes before
good to know
usually when I've done something that made vismach/foogui.py crash
but since I got basically the same error, I think they may be related :)
yep, that's what happened here
I do my "3D cad" by editing the python, running, editing, running, editing, running, etc, so mistakes do happen
coredump, and both scaragui and the halcmd child end up as zombies
scaragui shouldn't be crashing tho
[01:51:08] <jepler> https://bugs.launchpad.net/ubuntu/jaunty/+source/nautilus/+bug/325973/+viewstatus
jmkasunich: right, that's the problem -- *gui and axis crash on jaunty
I just threw my two cents in there in case the debugging was going into "why the zombie", rather than "why the crash"
hmmm. I have python 2.5 and 2.6 installed, and /usr/bin/python is 2.6.1
* jmkasunich goes back to the cursed CIM jigs
ok, same problem with python 2.4
I'll see if I can reproduce it after I have jaunty installed
thanks. sorry I'm mostly useless at debugging this stuff
hm, this vmware is running at totally the wrong speed
it thinks those packages took 17 minutes to download, it was more like one minute
weird. I'd expect the opposite
$ ssh 10.0.3.248 date; sleep 10; ssh 10.0.3.248 date
Mon Mar 23 22:19:31 CDT 2009
Mon Mar 23 22:20:29 CDT 2009
time passed 6x too fast in the virtual machine during that ten seconds
Need to get 396MB of archives.
After this operation, 887MB of additional disk space will be used.
ugh, that's quite a lot (build-dep emc2)
yeah, that does seem like a lot
but then again, I've gotten used to downloading 3-400 MB/day in updates
it would be interesting to look at a list of EMC2's build deps, sorted by size
including obvious ones like gcc?
I wouldn't be surprised if stuff for building the documentation is biggest, followed by stuff to build user interfaces, followed by stuff to actually do stuff
(most others are probably optional, but a compiler is sure needed)
gcc is tiny compared to all the crap that gets pulled in for tex and lyx
build-essential is a given anyway
I think gcc and a couple of libraries are all you need for the core
the reason for the sort order is to see what would gain you the most if you made it optional (or eliminated it completely)
but yeah, tcl/tk, python, gtk ... are all optional
in principle they're optional
probably configure and/or make have bitrotted to the point where they're required for some stupid reason
since everyone has them
or we force them to get it anyway
I think I remember when gtk made that step (optional to required)
I have an interest in small systems, and several others have mentioned a similar interest
when it was just halscope and halmeter, it was optional
pickconfig should also be optional
I'm not sure what else needs it, that isn't also optional
all that's needed is to do the work to make it truly optional again
we need a different package scheme before that's really useful IMO
for 2.3, firmware is moved outside the EMC2 package - was anything else done on that front?
ok. then I vote to wait until at least 2.4 to mess with the dependencies :)
TRUNK's for development again
so if you think you'll benefit from it .. knock yourself out
I probably would, from hitting my head against a wall :)
I have nothing but gratitude for the folks who have worked on packaging
since I haven't a clue about how any of that works
well it's all made of perl scripts and C code, compressed until they become a diamond
not a beautiful diamond, but some industrial artificial diamond
I just end up scratching myself or shattering them :)
I suppose "works" is the wrong word
I don't know what it is supposed to do, OR how it does it
the sad part is that I don't want to know
I'd probably have to study graph theory to really understand how it does the work
and large chunks of debian project docs to figure out what it is supposed to do
well I'm sure this will not clarify things: http://arxiv.org/abs/0811.3620
yes, it doesn't
2.2.1 Result: Installability is NP-complete
NP stands for Nasty Problem
"completely Nasty Problem" :)
the biggest chunk of emc build-dep is lyx and associated texlive-fubar packages
pushing the docs into a different deb package won't help though
if that package gets built from the same sourcedir, then the build-dep remains (as the build-dep needs to provide packages to build all packages from the current source)
well that's silly
that's the debian policy
we need to split the emc2 source in more than one source package
then each of those will have it's own build-dep
docs used to be a separate repository but they got merged to synchronize with the source code
I think they can still reside in the same dir and have a single debian/ folder..
yes, and it's pretty good they did
so.. i dont really know what counts as a "sourcedir"
something defined in debial/control I think
a source directory is a directory tree with a debian/ directory. it's turned into one source package and one or more binary packages by dpkg-buildpackage.
jepler: wonder if a debian/configure can be used to "bastardize" that convention
debian/configure docs (generates rules and control to build docs)
I don't like that idea much.
that means the docs source package carries around all the source code, and the source code package carries around all the docs
it's a waste that, over time, adds up to as much as the build-deps you're trying to decrease
I can see that
so it's either move the docs to a new module
or create some dirs in the emc2 module
one for docs/ one for source/, etc
but that means moving all the source tree around.. which is probably a HUGE pita
oh, I forgot: you *have* to have the source tree to build docs, because there's all the manpages generated by comp
or at least, you have to have the .comp files
so it's a big mix-and-match
not easily divided into two buckets with no duplication
except if the docs/ only takes care of html and pdf (without manpages)
and the source/ takes care of manpages
(but should rather duplicate pdf and html building)
surely there must be a good solution to this :)
there are html manpages
i'd be happy if just pdf was in a separate package
but i dont see how that would work with debian's silliness
the other way would be to keep the big build-deps
how about providing a meta package which depends (not build-depends) on the minimum stuff needed to build emc2
without docs & all
I mean, the users who want to apt-get build-dep emc2 usually just want to build TRUNK, not build packages & all
cradek did that with emc2-cvs-build-dep or something like that
I don't know that it ever really cured any problems
it's a separate package list that has to be maintained, and maintainers are lazy
step 0: find a developer who will actually pledge to keep the list up to date
it isn't me; I install the doc-building stuff on all machines where I work with emc anyway
right, and even if you don't.. I'm sure you don't spend more than 5 minutes to figure out what deps you're missing
as for the docs: someone enterprising should replace tetex-extra with whatever the correct texlive package name(s) is/are
it's tetex-extra that pulls in an astonishing amount of texlive
such as all the -lang- packages
on TRUNK, IMO you only need to look at how this affects hardy (or newer, if you care); on 6.06, tetex-extra is still a real package, not a replacement
SWPadnos: I get the same crash running scaragui
alex_joni: will you contact Floca Alexandru <firstname.lastname@example.org> about the romanian translation?
EMC: 03jepler 07TRUNK * 10emc2/src/po/pl_axis.po: updated translation from micges
EMC: 03jepler 07v2_3_branch * 10emc2/src/po/pl_axis.po: from TRUNK: updated translation from micges
bbl, going to the office..
* alex_joni stayed home sick today
alex_joni: on what system you are now ?
on this machine I have a hardy install, a doze install with hardy & dapper VMs on it
2.3 packages are for what system builded now ?
and they will be built for dapper too
not sure if the beta is built for dapper yet
no, it's not.. only hardy beta packages so far
why are you asking?
I've installed emc2.3 beta on hardy and it's not working
what isn't working?
looks like axis.py is updated and axis.tcl isn't
alex_joni: uff everything works now
./configure was run without --inplace
uh. I thought you said you had installed from packages ...
when you have 3xcvs and one misconfigured and the you install emc2.3 from packages, none of them will be working :)
too bad you can only run one at a time
but I guess PC's are cheap today
and if you want sim, there's alwasy VMware and Xen & co
is there any tutorial/how-to about making firmwares (hostmot2?) for MESA cards?
are you wondering how to get the Xilinx tools to generate a bitfile you can use, or how to create the VHDL/Verilog source to get the FPGA to do what you want?
[14:53:38] <jepler> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BuildingHostmot2
however I think the paths have changed in the meantime
there's now a single copy of the firmware in firmware/src
there should also be some useful information in the src/hal/drivers/mesa_5i2x directory, maybe in the mesa-configtools branch
I'm not sure how to select to build a specific board and pinout with the current setup (we simply receive the .pin, .bit and source files from peter wallace at mesa and put them in our CVS; we don't build the firmwares ourselves)
there are makefiles that will generate bitfiles from your source
what mean Leadscrew Pitch ? (stepconf)
number of turns per unit
turns per inch or mm per turn of the screw (assuming you're using a leadscrew)
if you have a rack and pinion, it's the travel per revolution of the pinion
"Steigung" in german
and if you have a multiple-start screw, then you don't actually enter its pitch
and the calculation is inverted if you select mm machine units
you enter its advance, which is pitch * starts
right, for inch you enter "8" if you have a 1-start, 1/8TPI screw
oh I see now
not sure all that matters if you're just translating stepconf strings :)
sure it does
for mm you enter "5" if you have a screw that advances by 5mm in one turn
after hearing all that, it's _waaaay_ more complicated to translate the simple string
alex_joni, sure, but for translating the help and/or docs :)
I know what it is but I didn't get it why it is inverted
micges: mm screws are labeld in mm/turn
lead screws are specified differently, similar to machine screws
american screws are labeled turn/inch
ok I see now
Enter the pitch of the leadscrew here. If you chose "Inch" units, enter the number of threads per inch here (e.g., enter 8 for 8TPI). If you chose "mm" units, enter the number of millimeters per thread here (e.g., enter 2 for 2mm/rev). If the machine travels in the wrong direction, enter a negative number here instead of a positive number or invert the direction pin for the axis.
should this say "millimeters per rev"?
BJT-Work: yes that would be correct
ok, I'll fix that
Direction Hold time?
and direction setup time ?
what are they mean?
[18:26:26] <jepler> http://www.linuxcnc.org/docview/html/hal_rtcomps.html#sub:Stepgen-Step-Types
the minimum time of various parts of the step+direction waveform
minimum time - thanks
EMC: 03jepler 07TRUNK * 10emc2/src/po/pl_axis.po: updated translation from micges
jepler, did you do a 32-bit or a 64-bit Jaunty VM install yesterday?
well, 32 or 64 would be 96 ;)
SWPadnos: 99 bit
this looked like it could be relevant to the crashes, but it seems not: http://mail.python.org/pipermail/python-list/2008-July/672444.html
then again, I should be absolutely sure I did everything correctly before saying that
since jepler reproduced the problem, I'm not sure it's something you might have done wrong
yeah, I'm pretty sure I didn't screw anything up, since I first saw the problem with unmodified sources
I'm just trying a little debugging, which I may have done wrong
SWPadnos: I had to *remove* python2.5 tcl8.4 tk8.4 and *install* python2.6-dev tcl8.5-dev tk8.4-dev
the crash is because parts of emc2 were compiled with tcl8.4 and python was compiled with tcl8.5
that mix&match doesn't work
so changes to debian/configure et al to adapt to this will be necessary
right now tk8.4 is hardcoded on all versions, and that'll have to change
KimK_ is now known as KImK
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/config/stepconf.lyx: expand a bit on the leadscrew desc