Back
[01:17:00] <dgarr> i'm having a problem with git am -- it seems to be related to a recent commit, notes,transcript:
http://www.panix.com/~dgarrett/stuff/git_am.log
[01:17:30] <dgarr> suggestions appreciated, bbl
[02:37:32] <seb_kuzminsky> dgarr: 88f0d removed plasma-thc, but left plasma-thc-sim, so your clone looks correct to me
[02:38:05] <seb_kuzminsky> i'm not sure about those am conflicts...
[05:43:10] <memleak> Tor doesn't do much without obfsproxy and the "hide the fact I'm using Tor from my ISP" option checked
[07:13:20] <skunkworks> alex_joni, didn't you have a new 3d_chips gcode that was a bit more detailed?
[07:40:21] <dgarr> $ git log --oneline -10|grep 88f0d5c
[07:40:21] <dgarr> 88f0d5c Configs: remove old plasma config that is too complicated this config has many issues and is not supported by the author.
[07:40:27] <dgarr> 88f0d5c: removed (for example): configs/plasma-thc/SheetCam/SheetCamEMCPlasma.post
[07:40:28] <dgarr> but: $ git ls-files configs/plasma-thc-sim/*.post
[07:40:28] <dgarr> configs/plasma-thc-sim/SheetCam/SheetCamEMCPlasma.post
[07:41:17] <dgarr> so i don't understand why files removed by 88f0d5c are still in place and shown by git ls-files ?
[07:49:36] <dgarr> also: $ git log --reverse configs/plasma-thc-sim/SheetCam/SheetCamEMCPlasma.post
[07:49:36] <dgarr> does not show 88f0d5c
[08:01:13] <dgarr> oh -- now i see what seb said: plasma-thc-sim SIM SIM SIM is still supposed to be there , not awake yet
[09:43:52] <dgarr> ok -- i believe i have isolated the problem i am seeing with configs/plasma-thc-sim/SheetCam/* . When i try to 'git mv' the .post,.scpost files, the resulting patch will not apply
[09:44:00] <dgarr> session transcript:
http://www.panix.com/~dgarrett/stuff/mv_test.log
[09:44:20] <dgarr> i imagine the problem relates to the dos line terminations in the files
[09:48:56] <jepler> dgarr: afaik the 'git format-patch' + 'git am' workflow doesn't work well with files which aren't proper text files :-/
[09:49:07] <jepler> what are .post / .scpost files anyway?
[09:50:01] <dgarr> i have no idea -- some SheetCam files. i'veused git am like this before, what is an alternate workflow to mv these files
[09:51:16] <dgarr> i get the same failure using 'git mv thesefiles' or 'git rm thesefiles'
[09:52:50] <jepler> the other problem here is that these files contain code which has no gpl-compatible license and which notes it's based on other work which was almost certainly not intended to be GPLv2-compatibly licensed :-(
[09:56:06] <cradek> odd, I can just git rm them, and git commit
[09:56:38] <jepler> dgarr: if you really want to do this by a "git am" workflow, you can try git am --keep-cr
[09:56:39] <dgarr> but can you make a patch that applies to a fresh branch from that commit?
[09:56:46] <jepler> as suggested by
http://stackoverflow.com/questions/6289001/git-am-format-patch-control-format-of-line-endings
[09:57:08] <jepler> dgarr: I think maybe cradek was suggesting that he could fix the problem by just removing the files and "git push"ing; not that he didn't reproduce your problem...
[09:57:54] <cradek> I was testing the "i get the same results trying to remove the files with git rm *.post" which was the most surprising to me
[09:58:22] <cradek> but I see now you mean followed by making the patch
[09:58:25] <jepler> cradek: oh I assumed git rm ; git commit ; git format-patch ; git am was the whole workflow
[09:58:28] <jepler> (switching mv to rm)
[09:58:31] <cradek> right, sorry
[09:58:49] <cradek> dgarr: do you want me to just remove them for you?
[09:58:56] <jepler> OK, well, *I*'m tempted to solve the problem by simply pushing removal of the files with no permission to distribute
[09:59:04] <cradek> yes
[09:59:35] <dgarr> getting rid of them in any way would be helpful to me
[09:59:59] <cradek> jepler: in 2.5 branch
[10:00:47] <cradek> ... there are two copies of each
[10:01:42] <jepler> dgarr: you might also use "git format-patch -M -C" to directly represent the renames. it makes for a substantially smaller patch too
[10:02:14] <jepler> (I suppose the reason that's not the default is that standard gnu patch can't handle the result?)
[10:04:05] <jepler> cradek: are you saying I have your approval to remove those 4 files in v2.5_branch?
[10:04:37] <cradek> yes, I see no reason to believe we can distribute them
[10:04:43] <jepler> OK, I'll do that
[10:04:46] <cradek> thanks
[10:06:24] <dgarr> ok : -M -C worked for me -- those are very useful options -- thanks to cradek,seb_kuzminsky, jepler for helping
[10:07:24] <cradek> and thanks for teaching me another reason to be vigilant about those stupid line endings
[10:07:37] <dgarr> if you remove the files in v2.5_branch, how soon will master be updated?
[10:07:50] <cradek> jepler could do the merge immediately
[10:07:59] <jepler> dgarr: I'll do the merge to master branch as well. Unless there are ugly conflicts, I should have it done within the hour.
[10:08:19] <dgarr> thanks!
[10:18:17] <KGB-linuxcnc> 03Jeff Epler 05v2.5_branch 450b0fc 06linuxcnc 04configs/plasma-thc-sim/SheetCam/SheetCamEMCPlasma.post 04configs/plasma-thc-sim/SheetCam/SheetCamEMCPlasma.scpost 04configs/plasma-thc/SheetCam/SheetCamEMCPlasma.post 04configs/plasma-thc/SheetCam/SheetCamEMCPlasma.scpost configs: remove files with no permission to distribute * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=450b0fc
[10:18:17] <KGB-linuxcnc> 03Jeff Epler 05master 9f59d5e 06linuxcnc 10docs/src/gcode/gcode.txt 10docs/src/index.tmpl 10docs/src/index_fr.tmpl 10src/emc/task/emccanon.cc Merge branch 'v2.5_branch' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f59d5e
[10:18:29] <jepler> surprise of the morning: the second 'gitk' shows more commits than the first one
[10:18:32] <jepler> $ gitk 57e44d0..9f59d5e bfb837e..450b0fc
[10:18:35] <jepler> $ gitk 57e44d0..9f59d5e
[10:19:00] <cradek> jepler: aside from waiting for skunkworks to find more flakyness, is there a way to verify all those initializers in that c++ change I don't understand?
[10:20:10] <jepler> cradek: you can try to go field by field and make sure all of them are listed
[10:20:26] <jepler> you could run rs274 under valgrind; it might have reported that this one was uninitialized
[10:20:41] <cradek> ooh that sounds smart
[10:20:50] <jepler> it's not strictly a bug to not initialize all fields in the constructor
[10:21:06] <jepler> e.g., if you have an array and a count, setting the count to 0 might make it redundant to set all the elements in the array to zero
[10:21:09] <jepler> bbl
[10:29:35] <dgarr> this is what i'm trying to accomplish bygit mving files around:
http://youtu.be/EM6dBd4pS0Y
[10:30:55] <cradek> I appreciate you working on the first-run-is-not-weird goal
[10:31:31] <seb_kuzminsky> i wonder if coverity would squawk about uninitialized fields. i know it catches many kinds of "use before initialization" problems
[10:31:47] <seb_kuzminsky> i checked our clang results, and clang did *not* complain about it :-(
[10:32:09] <seb_kuzminsky> on an unrelated note, something cool happened at the boulder hackspace last night
[10:32:33] <seb_kuzminsky> i got there kind of late, as i usually do, and everyone was crowded around the cnc mill that we recently got running
[10:33:16] <seb_kuzminsky> one of the guys had machined a bottle opener out of aluminum sheet (1/8" plate), from a dxf he found online
[10:33:30] <seb_kuzminsky> the interesting part is this:
https://github.com/shapeoko/makercam
[10:33:47] <seb_kuzminsky> it's a fairly capable open-source 2.5d cam program
[10:33:54] <cradek> !
[10:34:09] <seb_kuzminsky> i was really excited, until i noticed it's written in flash
[10:35:28] <cradek> ... but that makes no sense
[10:44:57] <skunkworks> wait - Am I tasked at finding all these odd errors?
[10:50:24] <jepler> skunkworks: it's kind of you to offer!
[10:50:37] <cradek> yeah that's awesome
[10:50:57] <skunkworks> heh
[10:51:02] * archivist counts the votes 2 for 0 against
[10:51:11] <archivist> carried
[10:57:39] <JT-Shop> dgarr: the config picker is simple and easy to navigate now! I love it!
[11:01:25] <dgarr> good -- we'll have to see how many configs i've broken
[11:03:03] <jepler> dgarr: what causes "sim" to appear first? is an order for sample configs hardcoded or something?
[11:03:57] <dgarr> modified pickconfig.tcl to reorder according to a hard coded preferred list -- intended to put guis with most support at top
[11:04:34] <jepler> will someone adding a new sample configuration need to edit pickconfig.tcl then?
[11:05:35] <dgarr> no, it would appear according to the preferred order, changing the preferred order would require change to pickconfig.tcl, i'm open to other suggestions for altering order
[11:06:25] <jepler> did you link your patch somewhere above?
[11:07:13] <dgarr> patch is not ready until i fix the mess i made due to those SheetCam files, maybe tomorrow
[11:07:19] <jepler> OK
[11:13:02] <dgarr> i think i would like to make a configs/atic (as cradek mentioned) for obsolete or declining-usage files. I need a suggestion for particular configs to put there as a starting basis
[11:16:22] <cradek> IMO everything is attic (and I think attic should not be available in the config picker, only installed for reference) unless it's for widely used and currently available hardware and NOT simple stepconf-style setups
[11:17:20] <seb_kuzminsky> that sounds right
[11:18:03] <seb_kuzminsky> the configs in the configpicker are really only to help noobs on their first few runs, after that they'll run their own customized configs
[11:19:19] <cradek> so remaining are a sim for each well-supported gui, hm2 samples, pico samples, GM samples (they're new?), and current manufacturer-specific configs like smithy?
[11:21:20] <cradek> oh tormach configs might be current too
[11:22:18] <cradek> manufacturer-maintained might belong in their own subtree? they are meant to work as-is for a particular machine, which is pretty different from the rest of them
[11:27:19] <seb_kuzminsky> maybe a 'vendor/' subtree?
[11:27:47] <seb_kuzminsky> vendor/{smithy,tormach,sherline,...}
[11:28:18] <cradek> that sounds fine to me
[11:30:02] <skunkworks> would mesa/pico be under that?
[11:30:20] <seb_kuzminsky> i dont think so
[11:30:29] <jepler> I think what they are proposing is intended to apply to whole machines, not driver boards
[11:30:39] <skunkworks> ok
[11:30:42] <seb_kuzminsky> right
[11:33:09] <dgarr> if you look at the video, the top categories i made are: sim (always runnable), by_interface(mesa,pico,...),by_machine(smithy,tormach,...),complex_examples(didnt fit anywhere else) its going to be difficult tosatisfy everyone, i will have a patch in a day or so
[11:34:04] <cradek> ah ok, it sounds like you are already making the distinctions I think are important, cool
[11:34:11] <seb_kuzminsky> dgarr: i missed it, where's the video?
[11:34:17] <jepler> http://youtu.be/EM6dBd4pS0Y
[11:35:16] <cradek> this is a bike shed, and I trust your judgment, thanks for tackling it
[11:35:21] <seb_kuzminsky> that looks great dgarr!
[11:36:10] <seb_kuzminsky> hmm, isnt sim/remap examples of how to do gcode remapping? that sounds useful, but maybe doesn't belong in that spot?
[11:37:40] <cradek> there is a basic question of what are the sim configs for, and I don't have the answer
[11:38:13] <dgarr> my take, is a config that is runnable on a machine with no specific hw requirements (including parport), it is a candidate for a sim
[11:38:45] <dgarr> in that view, runnable remap configs would be great as sim configs
[11:39:16] <dgarr> bbl
[11:42:27] <seb_kuzminsky> remap's not really its own thing, imo
[11:42:53] <seb_kuzminsky> maybe some/all of the sim configs should use some remapping, and remove remap as its own sim configs
[11:48:17] <cradek> sim configs have at least two purposes: to let you play with a demo before configuring anything, and as documentation/tutorials for finicky-to-configure features like remapping
[11:48:36] <cradek> are there others aside from remap that are the tutorial type?
[11:50:49] <cradek> some are/were for testing features, like axis/random_tc, and could just be removed because they serve neither purpose
[11:50:54] <seb_kuzminsky> classicladder/cl-estop
[11:51:02] <cradek> aha yep
[11:51:20] <cradek> demo_*_cl
[12:18:09] <KGB-linuxcnc> 03Norbert Schechner 05master ac75df9 06linuxcnc 10lib/python/gladevcp/combi_dro.py Combi_DRO - shows warnings invalid font-size * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac75df9
[12:18:09] <KGB-linuxcnc> 03Norbert Schechner 05master 1c688dd 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy.glade 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_4 - fixed some warnings * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c688dd
[12:18:09] <KGB-linuxcnc> 03Norbert Schechner 05master 50c7659 06linuxcnc Merge branch 'master' of ssh://norbert@git.linuxcnc.org/git/linuxcnc.git * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=50c7659
[12:29:04] <seb_kuzminsky> cradek, dgarr: also halui_pyvcp
[13:03:22] <skunkworks> Old TP 2:37:42 New TP 1:38:49
[13:03:28] <skunkworks> http://electronicsam.com/images/KandT/testing/internet.ngc
[13:03:38] <skunkworks> (named because I found it on the internet...
[13:03:40] <skunkworks> )
[13:03:51] <skunkworks> that is with g64p.005
[13:04:20] <skunkworks> (still can't run strait g64 with the new tp - but I think he said he had a handle on it..
[13:10:36] <seb_kuzminsky> that's an impressive increase in cutting speed
[13:10:54] <seb_kuzminsky> has anyone looked at robert's code yet? i haven't
[13:11:33] <skunkworks> 533228 line program
[13:11:56] <skunkworks> I have :) (but I just stare blankly)
[13:13:17] <seb_kuzminsky> heh
[13:13:51] <seb_kuzminsky> i would like to keep that change out of master until we make the 2.6 branch, then it can go in (if it's ready)
[13:30:11] <skunkworks> looks like the read-ahead depth is set to 40 at the moment. That seems like more than enough for most thinggs
[13:53:36] <skunkworks> cradek, this is a program that steveP was complaining about. I finally ran it to see
[13:53:37] <skunkworks> http://electronicsam.com/images/KandT/testing/steve.ngc
[13:56:32] <skunkworks> It is pretty hurky jurky. Mach seems to keep the velocity at 3600 throughout the curve while linuxcnc dip pretty far at each endpoints.
[13:56:52] <skunkworks> (short enough to stay under the 500 line limit) ;)
[14:01:57] <skunkworks> I wonder if those arc-line, line-arc transitions are tangent...
[14:04:05] <skunkworks> I am wondering because tort.ngc runs about the same between linuxcnc and mach. I wonder if mach has a special case for tangent arcs that maybe we could also have in the new TP. Check to see if the arc is tangent to the line then if it is - then figure out the velocity that can be tranistioned to the arc
[14:04:44] <skunkworks> I might not know what I am talking about
[14:06:18] <jepler> isn't that part of what robert's code is doing?
[14:08:01] <skunkworks> not at the moment. He is just working with line segments. arcs are harder it sounds like
[14:09:13] <skunkworks> the steve.ngc program actually runs just a bit faster with the current TP vs roberts. (as do other mixed line/arc programs)
[16:26:37] <skunkworks> logger[mah]:
[16:26:38] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-12-04.html
[17:54:06] <alex_joni> skunkworks: nope
[17:54:31] <alex_joni> or at least I don't remember :)
[17:57:07] <alex_joni> skunkworks: err.. it seems I did
[17:57:16] <alex_joni> http://dsplabs.upt.ro/~juve/emc/tux/
[17:57:18] <alex_joni> this one?
[17:58:53] <alex_joni> wow.. 2006 :)
[18:37:30] <dgarr> candidate patch for rearranging configs:
http://www.panix.com/~dgarrett/stuff/rearrange_configs.mbox
[18:46:28] <seb_kuzminsky> i wonder if dgarr reads the irc logs? here's my comments on his patch set:
[18:46:52] <seb_kuzminsky> firstly, it's a huge improvement - much cleaner than before
[18:48:13] <seb_kuzminsky> in sim, some of the entries are guis (like axis, touchy, gscreen, gmoccapy) and some are extensions to guis (like ngcgui, gladevcp, and halui_pyvcp), that seems wrong to me
[18:50:04] <seb_kuzminsky> i'd prefer to have the extensions be filed along with the thing they're extending, rather than by that extension applied in other ways, if that makes sense
[18:50:34] <seb_kuzminsky> so as sim/axis/axis-ngcgui instead of as sim/ngcgui/axis
[18:50:45] <seb_kuzminsky> just personal preference i guess
[18:51:23] <seb_kuzminsky> anyway, that kind of feels like fine tuning, i think we should merge this patch set and fiddle with it as a second step.
[18:52:14] <seb_kuzminsky> sim/ngcgui/pyngcgui_axis.ini fails with "Could not open command file 'core_sim.hal'"
[18:53:06] <seb_kuzminsky> sim/gmoccapy/gmoccapy_4_axis.ini fails with "Could not open command file 'axis_manualtoolchange.hal'"
[18:53:28] <seb_kuzminsky> so far no config i've tried has started. so that should probably be fixed before we merge it
[18:53:49] <seb_kuzminsky> but aside from details, the reorg looks very good
[19:02:45] <cradek> dgarr: seb_kuzminsky had some comments while you were out:
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-12-05.html
[19:14:30] <dgarr> no idea why they are not starting for you. the ones you mention start for me on a rip build. maybe you could pastebin ls -lR for the directory created by pickconfig if that is how you are testing
[19:34:16] <seb_kuzminsky> dgarr: i configured for run-in-place, make, linuxcnc
[19:43:13] <dgarr> maybe it needs make clean? i would suggest deleting (moving to save?) ~/linuxcnc, then repeat, then pastebin $ ls -lR ~/linuxcnc
[19:44:10] <seb_kuzminsky> i dont think pickconfig has tried to copy anything by the time i get these errors
[19:45:47] <seb_kuzminsky> i just cleaned by configs tree with 'git clean -fdx configs', and i have a symlink named sim/gmoccapy/axis_manualtoolchange.hal, pointing to .., but i have no sim/axis_manualtoolchange.hal, even after 'make' does 'copying shared configs'
[19:49:17] <dgarr> ok -- good clue, i probably had not done git clean in my dir and need to work on the Makefile more, i'll post here when I've revised the patch -- thanks for your help
[19:58:11] <dgarr> revised: (applys to master not on top of earlier mboxpatch):
http://www.panix.com/~dgarrett/stuff/v2_rearrange_configs.mbox
[20:37:44] <skunkworks> alex_joni: :) thanks