Back
[00:01:51] -!-
zlog has quit [Ping timeout: 248 seconds]
[00:03:28] -!-
theorbtwo has quit [Ping timeout: 248 seconds]
[00:07:53] -!-
theorb has quit [Ping timeout: 260 seconds]
[00:14:43] -!-
Loetmichel has quit [Disconnected by services]
[00:14:50] -!-
Cylly has quit [Client Quit]
[00:15:12] -!-
skunkKandT has quit [Remote host closed the connection]
[00:27:52] -!-
ries has quit [Quit: ries]
[00:29:15] -!-
cevad has quit [Quit: Leaving]
[00:41:14] -!-
stormlight has quit [Quit: stormlight]
[01:12:40] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #emc-devel
[01:25:53] -!-
cevad has quit [Quit: Leaving]
[01:42:05] -!-
ve7it has quit [Remote host closed the connection]
[01:50:21] -!-
andypugh has quit [Quit: andypugh]
[01:51:59] -!-
ve7it [
[email protected]] has joined #emc-devel
[02:32:29] -!-
Tom_L has quit []
[02:54:12] theos is now known as
itheos
[02:54:23] itheos is now known as
theos
[03:09:24] -!-
Ze1982 has quit [Quit: Leaving]
[03:41:04] -!-
Turtl3boi has quit [Ping timeout: 252 seconds]
[03:41:04] -!-
toastydeath has quit [Ping timeout: 252 seconds]
[03:41:16] Turtl3boi_ is now known as
Turtl3boi
[03:45:14] -!-
emcrules_D510 has quit [Quit: Ex-Chat]
[04:11:22] -!-
grommit has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.23/20110921065534]]
[04:11:49] -!-
atom1 has quit [Quit: Leaving]
[04:19:05] -!-
vladimirek [
[email protected]] has joined #emc-devel
[04:24:40] -!-
WalterN has quit [Read error: Connection reset by peer]
[04:40:18] -!-
FinboySlick has quit [Quit: Leaving.]
[04:54:03] -!-
mhaberler [
[email protected]] has joined #emc-devel
[05:04:01] <CIA-62> EMC: 03mhaberler 07master * r2908eab03d54 10/src/hal/components/orient.comp: orient.9: rewrite for readability
[05:26:47] -!-
Valen has quit [Quit: Leaving.]
[05:27:58] <seb_kuzminsky> heh
[05:28:21] <mhaberler> ;-)
[05:59:38] -!-
ve7it has quit [Remote host closed the connection]
[06:05:48] <alex_joni> hey seb_kuzminsky
[06:05:52] <alex_joni> still around>
[06:05:54] <alex_joni> ?
[06:08:57] -!-
psha[work] [psha[work]
[email protected]] has joined #emc-devel
[06:21:09] <seb_kuzminsky> uh sort of
[06:21:15] <seb_kuzminsky> what's up
[06:21:32] -!-
Eartaker has quit [Quit: OOOOOO Whats that....]
[06:21:37] <seb_kuzminsky> alex_joni, oh about the docs
[06:23:32] <seb_kuzminsky> yeah it seems like linuxcnc.org/docs is a little out of date, and i think it's currently a manual job to update them
[06:24:49] <seb_kuzminsky> i'd like to automate it, but i dont know if that's what the current maintainers want
[06:25:27] <seb_kuzminsky> i don't even really know who the current maintainers are....
[06:26:08] <seb_kuzminsky> i guess i should talk to the board of directors
[06:31:15] <alex_joni> yeah
[06:31:43] <seb_kuzminsky> which is, let's see, you and chris and jeff and jmk and swp
[06:31:44] <seb_kuzminsky> http://www.linuxcnc.org/content/view/12/10/
[06:34:57] <alex_joni> yup
[06:35:06] <alex_joni> you can join #emc-board
[06:35:12] <alex_joni> and ask there, or I will
[06:39:08] -!-
Valen has quit [Quit: Leaving.]
[06:40:44] -!-
e-ndy [e-ndy!jkastner@nat/redhat/x-uvpdhzebljdyhnap] has joined #emc-devel
[06:57:13] -!-
emc2-buildmaster has quit [Ping timeout: 258 seconds]
[06:58:36] -!-
seb_kuzminsky has quit [Ping timeout: 255 seconds]
[07:04:46] <mhaberler> great take on git:
http://www.youtube.com/watch?v=CDeG4S-mJts&feature=related
[07:10:07] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[07:15:52] -!-
WalterN has quit [Read error: Connection reset by peer]
[07:52:41] -!-
mhaberler has quit [Quit: mhaberler]
[08:03:29] -!-
robh__ [
[email protected]] has joined #emc-devel
[08:10:49] -!-
davec_ has quit [Ping timeout: 258 seconds]
[08:17:05] -!-
Turtl3boi has quit [Ping timeout: 260 seconds]
[08:27:40] -!-
Turtl3boi has quit [Ping timeout: 252 seconds]
[09:31:23] -!-
seb_kuzminsky has quit [Ping timeout: 256 seconds]
[09:43:08] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[09:46:22] <alex_joni> lol @ that git video :)
[10:06:06] -!-
H264 has quit [Read error: Operation timed out]
[10:08:53] -!-
seb_kuzminsky has quit [Ping timeout: 258 seconds]
[10:11:58] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[10:54:28] -!-
cnc-9-Achsen has quit [Quit: ChatZilla 0.9.87 [Firefox 3.6.8/20100723084720]]
[12:02:26] -!-
skunkworks has quit [Ping timeout: 276 seconds]
[12:43:55] -!-
mhaberler [
[email protected]] has joined #emc-devel
[12:59:12] -!-
ries has quit [Ping timeout: 240 seconds]
[13:07:36] -!-
Valen has quit [Quit: Leaving.]
[13:11:23] -!-
seb_kuzminsky has quit [Ping timeout: 244 seconds]
[13:23:08] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[13:45:01] -!-
theos has quit [Ping timeout: 240 seconds]
[13:58:04] <cradek> mhaberler: I tried last night - it works beautifully!
[13:58:13] <mhaberler> whoa!
[13:58:45] <cradek> I think you might be right that the recursive call should invoke the old/standard behavior
[13:59:13] <cradek> it seems somewhat natural, because a recursive call makes no sense otherwise
[13:59:18] <mhaberler> there is no good other use case for a recursive invocation, yes
[13:59:54] <mhaberler> I might have overlooked that folks might lean towards incremental mods to existing codes rather than writing new ones
[14:01:41] <mhaberler> I'm currently thinking this through what's needed; the first item is recursion detection and that is there now; that will be the trigger condition to cause builtin behaviour (not an error as it is now in
http://git.mah.priv.at/gitweb/emc2-dev.git/commitdiff/091813a08b8e7113609a6a09e6d3902ddb42f2a4?hp=28a8222972c3f405a99f4b56571ae826db9dea66)
[14:01:42] <cradek> well to be honest I'll probably never want to override any G codes, probably only M6
[14:02:09] <cradek> getting the old M6 behavior easily is very nice
[14:03:03] <mhaberler> did you have any issues building that branch?
[14:03:54] <cradek> iirc, I had to install some stuff, but found it in the docs (well actually I found it by reading the doc diffs in your commits)
[14:07:31] <cradek> seeing all the configurability using python made me wonder how bad it would be to rewrite the interp in python using a real parser
[14:07:44] <mhaberler> ok, I guess what I'll do is 'old behaviour on M6 on recursion'; potentially Tx and M61; and maybe G0 so people can play with the example; I'm shy to do such a massive change like 'everything is open to remapping' so late in the game barring a cry of the masses
[14:08:16] <mhaberler> re: python you're right - not much left
[14:08:18] <cradek> but the other half of me said that's silly and just making T/M remappable in gcode is 99% of what people need
[14:08:48] <mhaberler> yes - I think however another interp issue is more pressing, and that is the read/execute model
[14:09:01] <cradek> in the M6 remapped O sub, can you get the prepped tool number and/or pocket?
[14:09:41] <cradek> I got the new tool number by doing the old M6 and then reading #5400
[14:10:03] <mhaberler> yes, by the epilog accessing _setup and inserting a named param with 'self.params["foo"] = value
[14:10:22] <cradek> ah ok
[14:10:29] <mhaberler> that makes "foo" available as #<foo> in the remap procedure
[14:10:36] <cradek> nifty
[14:10:54] <cradek> so you could have access to old and new tool numbers/pockets
[14:11:03] <mhaberler> yes, the whole mafia
[14:11:33] <mhaberler> I think in fact a standard prolog and epilog would be very helpful for folks writing their m6 replacements
[14:11:50] <mhaberler> python is much rougher on them as are the interp internals
[14:11:57] <cradek> yes agreed 100%
[14:12:40] <mhaberler> ok, IMO it's current and selected tool, and current and selected pocket; anything else?
[14:13:10] <cradek> that seems like it
[14:13:19] <mhaberler> probably CC on/off
[14:13:38] <cradek> I'm sorry I brought up the G0 remap - it was mostly just a thought experiment
[14:14:02] <mhaberler> then a standard way to set an error message and abort - the only way I found was accessing a comment and using that as error text like so:
[14:14:17] <mhaberler> o<seterror> call (error message text)
[14:14:35] <mhaberler> this would make interp return INTERP_ERROR and cause an operator message
[14:14:39] <cradek> do we need a new magic comment that aborts with a message?
[14:15:02] <cradek> (ABORT,you idiot!)
[14:15:37] <cradek> err, why not just use (MSG,you idiot!) M2
[14:15:40] <mhaberler> hm, interesting idea. I'll think through that
[14:15:51] <mhaberler> because M2 has a lot of repercussions
[14:16:06] <psha[work]> btw great idea
[14:16:08] <cradek> sure
[14:16:20] <psha[work]> probably we should add other commands like 'you idiot'?
[14:16:53] -!-
e-ndy has quit [Quit: Ex-Chat]
[14:17:20] -!-
e-ndy [e-ndy!jkastner@nat/redhat/x-xxdnintiumhggial] has joined #emc-devel
[14:17:44] <mhaberler> note (ABORT,foo) is subject to block executiomn sequencing if there are several words on a block
[14:18:51] <mhaberler> I mean the potential of shooting oneselves in the foot shall never be limited ;-) probably a recommendation 'use (ABORT, text)' without another word on its own line
[14:18:53] <cradek> the defined order of execution includes comments I think...?
[14:18:58] <mhaberler> yes
[14:19:31] <cradek> not that I know what it is without looking
[14:19:33] <mhaberler> when did you last think of just when this comment was 'executed' in a block.. but its a minor issue
[14:20:03] <cradek> well if it was important I would put it on its own line, because that would be faster than finding it in the docs.
[14:20:06] <mhaberler> #2, after oword, so good:
http://emc.mah.priv.at/docs/remap/html/gcode/overview.html#_g_code_order_of_execution_a_id_sec_order_of_execution_a
[14:20:19] <cradek> yay
[14:23:43] <mhaberler> the way I used to create error messages so far was to have the ngc procedure return a certain value with return or endsub, and evaluate that retval in the epilog. the setError() method has a Python binding and is called from there. But the downside of this approach is: an error message pops up and it is NOT in the ngc procedure. So need to look at py code, which may not be obvious. So (abort, foo) looks better in terms of usability to me
[14:24:17] <cradek> yes very much
[14:24:49] <mhaberler> ok, issue decided, emacs started..
[14:25:11] <cradek> I think you are very right about letting users avoid the complexities of python and internal interp state when doing "common" things.
[14:25:24] <JT-Shop> :)
[14:25:46] <cradek> it was enough to make me say "no that's too complicated, I must be missing something" and I know both python and the interp just fine
[14:26:10] <cradek> s/just fine/better than 99% of the general population/
[14:26:15] <mhaberler> the only other alternative would be a new O-word because it is a control-flow statement, but that again involves the 'string from comment' cludge
[14:26:41] <cradek> yes, we already have magic comments, why not use them for this too, it's very simple
[14:26:45] <mhaberler> yep
[14:27:30] <JT-Shop> cradek: do you have any clue what the actual G2/3 with ijk arc tolerance is? testing shows 0.002" and 0.005mm will throw the error but the manual differs
[14:27:57] <cradek> you mean beginning vs end difference?
[14:28:03] <JT-Shop> yes
[14:28:16] <cradek> which version are you documenting?
[14:28:38] <JT-Shop> 2.4 and 2.5 show the same values
[14:29:07] <JT-Shop> I looked in the source for 2.5 but could not quite nail it down
[14:29:39] <cradek> looks like it is not a fixed amount
[14:30:30] <JT-Shop> what variable changes it besides inch and mm?
[14:30:37] <cradek> the radius
[14:32:04] <JT-Shop> so is it a percentage of difference or something like that?
[14:33:06] <cradek> my guess is it's an error if they differ by either .1% of the radius OR .0005 inch if in G20 OR .005 mm if in G21
[14:34:05] <cradek> er no
[14:34:07] <cradek> *sigh*
[14:34:36] <JT-Shop> problem?
[14:35:15] <cradek> I'm trying to tell you exactly the right thing
[14:36:49] <JT-Shop> ok
[14:37:08] <cradek> fails if ends differ by (.05 inch/.5 mm) OR ((.0005 inch/.005mm) AND .1% of radius)
[14:37:44] <cradek> so a huge arc can have more than .0005inch/.005mm error and still be allowed
[14:38:42] <cradek> it is not a simple test so should the docs just say "use an accuracy of 4 decimal places"?
[14:38:53] <cradek> brb
[14:40:14] <JT-Shop> one spot in the docs say "When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than 0.0002 inch (if inches are being used) or 0.002 millimeter"
[14:40:46] <JT-Shop> and another spot says "In particular, arc tolerance checks are made to .001 and .0001 depending on the active units."
[14:41:08] <cradek> neither of those is right at all...
[14:41:23] <JT-Shop> yes, I see that now
[14:41:39] <JT-Shop> thanks, I'll correct them
[14:50:17] <JT-Shop> I think the "use an appropriate decimal precision" should not even mention the arc tolerance and properly explain it in the G2/3 section. Easier to maintain if it is only in one spot
[15:14:35] <cradek> if you imagine the user finds the docs because he got the error, the thing he wants to see there is how to fix it
[15:14:43] <cradek> NOT what precisely caused it
[15:14:56] <cradek> the fix is to use appropriate precision in the gcode
[15:15:40] <cradek> I've seen a dozen people ask "how do I remove this check or make it sloppier" which is the wrong approach, and might be encouraged by documenting the exact check
[15:15:46] <jthornton> most of the time I see that they just didn't program the arc properly
[15:15:53] <cradek> yes
[15:15:59] <jthornton> that is a valid point
[15:16:05] -!-
Connor has quit [Quit: Leaving.]
[15:17:26] <archivist> or could the error give some sensible nearest number that would be acceptable
[15:17:32] <mhaberler> (ABORT,foo) is in including test case:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/remapping-preview-1
[15:24:22] -!-
Nick001 has quit [Ping timeout: 258 seconds]
[15:27:06] -!-
psha[work] has quit [Quit: Lost terminal]
[15:27:14] <cradek> I think the error currently shows the two radii and other information, so you can see how different they are. maybe the docs should explain what all those numbers mean? it's pretty terse.
[15:27:42] <jthornton> I'll give it a whirl
[15:27:57] <cradek> sorry about telling you how to do your job :-)
[15:28:11] <jthornton> :)
[15:28:25] <jthornton> thanks for the help in solving the mystery
[15:29:59] <jthornton> When programming arcs using a precision of less than 4 decimal places (0.0000) for inch and less than 3 decimal places (0.000) for millimeters can result in error due to rounding.
[15:34:53] <Jymmm> JT-Shop: "Everyone knows that" <rolls eyes> Eeeeesh ;)
[15:38:27] <Jymmm> jthornton: You can't even write 1/16" without 4 places, so I'm wondering if it should even be more than that? maybe 5? 1/32 = 0.03125, maybe 6? 1/64 == 0.015625
[15:41:28] <cradek> JT-Shop: upon more thought, you have a really good point. if people get that error and they hand-coded their arc, they probably just screwed it up. if they are using cam, either it is confused about abs/rel arc centers (if the r1,r2 are way different) or it is not using enough precision (if they are fairly close).
[15:41:45] <cradek> those are the three very common causes of the error
[15:44:07] <Jymmm> cradek: I notice that Sw defaults to 3 dec precision, I have to change it to 5 sometimes. Though I don't know if internally it's stored correctly or not.
[15:46:50] -!-
ve7it [
[email protected]] has joined #emc-devel
[15:47:16] <JT-Shop> Jymmm: just depends on what precision you set for that type of dimension on your drawing and/or part
[15:48:52] -!-
e-ndy has quit [Quit: Ex-Chat]
[15:57:34] -!-
micges [
[email protected]] has joined #emc-devel
[16:09:22] <Jymmm> JT-Shop: Yeah, just the default is 3
[16:15:20] <CIA-62> EMC: 03jthornton 07v2.4_branch * rd02f8097bb7b 10/docs/src/gcode/ (main.lyx overview.lyx): Docs: arc deviation error and suggested decimal precision
[16:38:18] -!-
e-ndy [
[email protected]] has joined #emc-devel
[16:46:34] -!-
psha [
[email protected]] has joined #emc-devel
[16:48:08] -!-
seb_kuzminsky has quit [Ping timeout: 258 seconds]
[16:59:38] -!-
seb_kuzminsky [
[email protected]] has joined #emc-devel
[17:00:36] -!-
micges has quit [Ping timeout: 240 seconds]
[17:02:01] -!-
micges [
[email protected]] has joined #emc-devel
[17:15:54] -!-
mhaberler has quit [Quit: mhaberler]
[17:17:23] -!-
stillme has quit [Remote host closed the connection]
[17:18:13] <seb_kuzminsky> the snow keeps knocking out power & internet here
[17:25:05] <micges> snow ? :|
[17:25:42] <seb_kuzminsky> first snow of the season, about 20 cm of heavy wet snow so far
[17:26:08] <seb_kuzminsky> a lot of trees still had leaves (we had a mild fall), so a bunch of tree limbs are breaking.
[17:26:41] <micges> where are you in usa?
[17:26:50] <seb_kuzminsky> boulder, colorado
[17:29:08] <micges> we had no snow so far but it was whole week about 3-6 degerees, brrr
[17:29:15] <seb_kuzminsky> heh
[17:29:21] <seb_kuzminsky> where do you live micges?
[17:29:27] <micges> Poland
[17:44:39] <psha> seb_kuzminsky: heh
[17:44:50] <psha> we have to send you some bears
[17:44:54] <psha> balalaykas and vodka
[17:44:59] <psha> since we have no snow here yet
[17:45:11] <psha> it seem that you should have rest of our attributes too
[17:45:54] <seb_kuzminsky> any accordions?
[17:46:27] <psha> probably bayans will satisfy you?
[17:46:44] <seb_kuzminsky> this satisfies me:
http://www.youtube.com/watch?v=PPv9VZQkxJI
[17:49:29] <JT-Shop> seb_kuzminsky: do you want me to take care of deleting the .lyx from 2.5?
[17:50:08] <seb_kuzminsky> oh! sure, that'd be great, thank you :-)
[17:50:25] <JT-Shop> no problem
[18:02:42] <micges> seb_kuzminsky: do you have few minutes to send me jumper list of your 3x20?
[18:07:47] <seb_kuzminsky> micges: oh, right, hold on
[18:57:12] -!-
micges has quit [Quit: Ex-Chat]
[19:02:41] -!-
micges [
[email protected]] has joined #emc-devel
[19:11:40] -!-
syyl_ has quit [Quit: Verlassend]
[19:55:17] -!-
cevad has quit [Quit: Leaving]
[19:56:59] -!-
e-ndy has quit [Quit: Ex-Chat]
[19:58:21] -!-
vladimirek has quit [Remote host closed the connection]
[20:03:34] <cradek> the 5i25 is so cool
[20:06:47] <micges> you got one already?
[20:07:05] <cradek> no, but I really want one
[20:07:25] <cradek> I could plug it in and not have to rewire anything
[20:07:34] <cradek> you have to admit that's awesome
[20:08:38] <micges> yes
[20:09:15] -!-
mhaberler [
[email protected]] has joined #emc-devel
[20:10:48] <micges> for me it's price is awesome
[20:14:12] <micges> cradek: you'r retriffits are on which mesa card?
[20:15:10] <cradek> 5i20, one in lathe; two in mill
[20:20:49] -!-
micges has quit [Quit: Ex-Chat]
[20:24:59] -!-
psha has quit [Ping timeout: 260 seconds]
[20:26:34] -!-
micges [
[email protected]] has joined #emc-devel
[20:38:24] -!-
|n0b0dy| has quit [Ping timeout: 240 seconds]
[21:19:23] -!-
FinboySlick has quit [Quit: Leaving.]
[21:26:02] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust492.basl.cable.virginmedia.com] has joined #emc-devel
[21:27:50] -!-
Gensor [
[email protected]] has joined #emc-devel
[21:27:56] -!-
syyl has quit [Quit: Leaving]
[21:31:45] <mhaberler> cradek: I did the M6 'detect recursive remap and then execute builtin semantics - straightforward and no surprises; I guess this is the way to go:
http://git.mah.priv.at/gitweb/emc2-dev.git/blobdiff/6f9ab1e7f6dfc19db22d65d9b2bf72c9b5ef7630..8578ddc07aa2c1f0f9a8e55f39b2f52635e72872:/src/emc/rs274ngc/interp_convert.cc
[21:32:57] <mhaberler> I'll do that for all remaps of builtins
[21:35:10] <andypugh> How does one add paths to the places that #include <somefilename> looks? is that different from $PATH?
[21:35:29] <mhaberler> -I in CFLAGS
[21:35:42] <mhaberler> Submakefile
[21:35:50] <andypugh> (I am trying to install FreeCAD, but with very limited success)
[21:36:03] <mhaberler> very different from $PATH - applies to cc only
[21:36:14] <andypugh> OK, let me look.
[21:39:54] <andypugh> Wait!
[21:40:23] <mhaberler> 'man 2 wait'
[21:40:24] <andypugh> I am trying to install FreeCAD from source, on my Mac.
[21:40:26] -!-
tom3p [
[email protected]] has joined #emc-devel
[21:41:03] <andypugh> So, lots of things are MacPorts installs to opt/localbin, opt/local/include etc
[21:41:04] <mhaberler> what build system does it use? configure/make? cmake?
[21:41:18] <andypugh> autogen / configure / make, yes
[21:41:44] <andypugh> Though there seems to be a parallel cmake in there too
[21:42:43] <mhaberler> very likely there's aconfigure option where you can add /opt/include to CFLAGS and /opt/lib for libs
[21:43:35] <andypugh> Well, there is an option to configure of --boost-includes-dir but that isn't working
[21:44:48] <mhaberler> does FreeCAD really refer to anything from MacPorts? surprises me - I'd never to that, MacPorts is a mess
[21:45:16] <mhaberler> maybe you'd try over at #cam
[21:46:01] <andypugh> mhaberler: It has a huge number of depencies, macports is the simplest way to get them without conflicitn with other darwin versions of certain libraries
[21:47:25] <andypugh> Also, is this valid syntax? in a .hxx file? typedef boost::shared_ptr<SMDS_Position> SMDS_PositionPtr;
[21:47:51] <mhaberler> looks like a c++ template invocation
[21:48:01] <andypugh> The compiler is not sure, but then this is #define hell
[21:48:03] <andypugh> ././inc/SMDS_Position.hxx:35: error: expected initializer before '<' token
[21:48:42] -!-
Turtl3boi has quit [Ping timeout: 255 seconds]
[21:49:48] <mhaberler> ok, this refers to a boost template, so that include seems missing
[21:50:22] <andypugh> Yeah, OK, that adds up then
[21:51:19] <andypugh> http://pastebin.com/DvfH67Gt
[21:51:33] <andypugh> (compiler errors and file)
[21:52:22] <andypugh> I could just put a literal path in, but there are lots of files, and then it still breaks.
[21:52:44] <mhaberler> on linux this include should be in the libboost-python1.40-dev package, whatever that is in MacPorts
[21:52:58] <mhaberler> no, thats simply missing
[21:53:00] <andypugh> I have the files
[21:53:15] <andypugh> (I think)
[21:53:28] -!-
Fox_Muldr has quit [Ping timeout: 260 seconds]
[21:53:36] <mhaberler> well those are c++ files so its CXX_FLAGS, not CFLAGS where the -I should come in
[21:54:08] <andypugh> shared_ptr.hpp is in opt/local/include/boost
[21:54:51] <mhaberler> paste output of configure --help
[21:55:29] <andypugh> The problem is that freeCAD has more than a sensible number of makefiles
[21:55:54] <mhaberler> yep, their wiki is 'rich in options'
[21:56:49] <andypugh> http://pastebin.com/cnNUasRZ
[21:58:28] <mhaberler> you could try 'export CXXFLAGS=-I/opt/local/include' before doing the configure
[21:58:36] <andypugh> I am using --with-boost-include= and --with-boost-lib= and I can see the values in the salomesmesh makefile as part of all_includes
[22:00:23] <mhaberler> --with-boost-include=/opt/local/include/ I assume?
[22:00:29] <andypugh> Yes
[22:00:52] <mhaberler> the #include is prefixed with boost so it shouldnt be /opt/local/include/boost
[22:01:38] <andypugh> <hysterical giggle> The export CXXFLAGS= had an interesting effect.
[22:01:39] <andypugh> checking whether the C++ compiler works... no
[22:01:48] <mhaberler> aha.
[22:02:06] <mhaberler> you do have Xcode
[22:02:26] <andypugh> Err, Yes
[22:02:31] <mhaberler> path to the Apple g++?
[22:02:56] <andypugh> I sort-of thought that setting it all up as an Xcode project would be more work than doing it as a makefile project
[22:03:25] <mhaberler> just asking because of g++, not the dev environment
[22:04:30] <andypugh> usr/bin/g++
[22:04:37] <mhaberler> I'm at wit's end but very interested in working results ;-) actually I'll try myself, maybe I hit a working config
[22:06:59] -!-
Gensor has quit []
[22:30:43] -!-
micges has quit [Quit: Ex-Chat]
[22:43:09] <andypugh> mhaberler: Interesting.. Curently seeing what cmake -G Xcode does for me :-)
[22:43:55] <mhaberler> easy to get lost in parameter space
[22:55:38] -!-
skunkworks [skunkworks!~chatzilla@str-bb-cable-south2-static-6-425.dsl.airstreamcomm.net] has joined #emc-devel
[23:00:14] -!-
Turtl3boi has quit [Ping timeout: 260 seconds]
[23:04:57] -!-
mhaberler_ [
[email protected]] has joined #emc-devel
[23:04:57] -!-
mhaberler has quit [Read error: Connection reset by peer]
[23:04:57] mhaberler_ is now known as
mhaberler
[23:11:54] -!-
chester88 has quit [Ping timeout: 256 seconds]
[23:19:21] -!-
dgarr [
[email protected]] has joined #emc-devel
[23:21:13] -!-
mhaberler has quit [Quit: mhaberler]
[23:23:03] -!-
robh__ has quit [Ping timeout: 252 seconds]
[23:45:05] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust492.basl.cable.virginmedia.com] has parted #emc-devel
[23:50:43] -!-
WalterN has quit [Read error: Connection reset by peer]
[23:54:24] -!-
Turtl3boi has quit [Ping timeout: 240 seconds]
[23:56:45] -!-
Eartaker has quit [Changing host]