well should i say where the .app is rather than where the actual executable file is based on my 10second glimpse at the source before you distracted me :)
On Fri, Sep 23, 2016 at 3:43 AM, Bernhard Stegmaier <stegma...@sw-systems.de> wrote: > … hardcoded /Applications is always a really bad idea … > >> On 22 Sep 2016, at 17:42, Simon Wells <swel...@gmail.com> wrote: >> >> yeah apparently so, i am just trying to figure out where its looking. >> Which might be /Applications instead of inside the bundle >> >> On Fri, Sep 23, 2016 at 3:37 AM, Bernhard Stegmaier >> <stegma...@sw-systems.de> wrote: >>> If I remember correctly this should only be enabled when some external tool >>> is in the right place? >>> Don’t know if this works yet on OSX? >>> >>>> On 22 Sep 2016, at 17:27, Simon Wells <swel...@gmail.com> wrote: >>>> >>>> i am sure i have done something stupid but for me the export->STEP >>>> option is greyed out. any hints? >>>> >>>> On Fri, Sep 23, 2016 at 2:45 AM, Wayne Stambaugh <stambau...@gmail.com> >>>> wrote: >>>>> >>>>> On 9/22/2016 10:43 AM, Wayne Stambaugh wrote: >>>>>> Simon, >>>>>> >>>>>> Using .mb_str() is valid. Using static_cast is more c++ish. Take a >>>>>> look at the "Conversion to C string" section of the wxString >>>>>> documentation: >>>>> >>>>> http://docs.wxwidgets.org/3.0/classwx_string.html >>>>> >>>>> I'm ok either way. >>>>> >>>>> Sorry about the fat fingered send. >>>>> >>>>> Wayne >>>>> >>>>>> >>>>>> >>>>>> On 9/22/2016 10:42 AM, Simon Wells wrote: >>>>>>> Hey wayne, >>>>>>> >>>>>>> the commit broke my build... >>>>>>> >>>>>>> in kicad2step.cpp >>>>>>> >>>>>>> lines 61-81 have _( "BLAH BLAH") which errors out as not convertible >>>>>>> from wxstring to char *. I have patched it with .mb_str() and was >>>>>>> preparing a patch but i am not sure if this is the correct way, care >>>>>>> to comment before i send a patch? >>>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Simon >>>>>>> >>>>>>> On Fri, Sep 23, 2016 at 2:18 AM, Wayne Stambaugh <stambau...@gmail.com> >>>>>>> wrote: >>>>>>>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote: >>>>>>>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh >>>>>>>>> <stambau...@gmail.com> wrote: >>>>>>>>>> On 9/21/2016 7:27 PM, Cirilo Bernardo wrote: >>>>>>>>>>> OK, I've updated the branch with the following changes: >>>>>>>>>>> >>>>>>>>>>> 1. removed wxT() from kicad2step and dialogs. The remaining wxT() >>>>>>>>>>> instances are created by wxFormBuilder. >>>>>>>>>>> >>>>>>>>>>> 2. refined the Export STEP GUI for cases in which the exporter >>>>>>>>>>> fails (returns an error or segfaults). >>>>>>>>>> >>>>>>>>>> Thanks for the fixes. I got everything merged on my computer at >>>>>>>>>> work so >>>>>>>>>> I'll just pick up where I left off tomorrow. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No problem; thanks for testing the branch. >>>>>>>> >>>>>>>> I tested this and everything looked fine. I did notice in your last >>>>>>>> commit that you used stderr. I'm not sure that has any meaning on >>>>>>>> windows but it didn't seem to break anything. I committed you kicad >>>>>>>> step export branch to the product repo. Great job. Thanks. >>>>>>>> >>>>>>>> I do have one comment. The vrml exporter includes the silk screen and >>>>>>>> traces which results in a much more detailed board model. It would be >>>>>>>> nice if step export had this as well. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> It also just occurred to me that sometimes the OCE library may >>>>>>>>>>> cause a hang. I can work on a generic dialog to launch an >>>>>>>>>>> external app which connects to the apps stdout + stderr and >>>>>>>>>>> which has a CANCEL button to kill the process - any comments? >>>>>>>>>>> Should I put such a dialog into the "common" library? >>>>>>>>>> >>>>>>>>>> I'm wondering if you could make something abstract enough to work in >>>>>>>>>> all >>>>>>>>>> the places where we run external apps. These dialogs always seem >>>>>>>>>> pretty >>>>>>>>>> task specific like the netlist and bom dialogs? You could try I >>>>>>>>>> guess. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The best abstraction I can think of at the moment is to instantiate a >>>>>>>>> dialog >>>>>>>>> which simply has a window showing the stderr + stdout of the running >>>>>>>>> app >>>>>>>>> and a cancel button to kill the process if necessary. All other >>>>>>>>> customizations >>>>>>>>> should be done in a parent window. I'll come up with something and >>>>>>>>> apply it >>>>>>>>> to the BOM and netlist generation as well. >>>>>>>> >>>>>>>> Given that we've never had any issues with the bom and netlist external >>>>>>>> processes, it may not be worth the effort although I'm not opposed to >>>>>>>> the idea. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The fact that a process using OCE can hang brings up the >>>>>>>>>>> question of whether it is better to leave kicad2step as a >>>>>>>>>>> separate app or whether it is generally OK as a plugin and >>>>>>>>>>> the odd crash due to bugs in OCE and/or the STEP/IGES >>>>>>>>>>> models would be acceptable. We can stuff the plugin >>>>>>>>>>> invocations into their own thread and check for completion, >>>>>>>>>>> but unlike the case with a separate process, we cannot >>>>>>>>>>> guarantee there is no memory corruption or leakage. >>>>>>>>>>> Any thoughts? >>>>>>>>>> >>>>>>>>>> Ughh! You're not making me feel any better about oce. It would be >>>>>>>>>> nice >>>>>>>>>> to be able to kill a rouge process though. Doesn't the oce library >>>>>>>>>> api >>>>>>>>>> provide some kind of error reporting capability? >>>>>>>>>> >>>>>>>>> >>>>>>>>> OCE does have an error reporting scheme but I've seen it hang >>>>>>>>> indefinitely while performing some operations such as shape healing >>>>>>>>> on defective STEP models. In other instances it eventually stops >>>>>>>>> after it has hogged the maximum memory that the system would >>>>>>>>> give it. In both cases it's not possible to get error information from >>>>>>>>> within OCE. Unfortunately such bad behavior is not unique to OCE; the >>>>>>>>> MCAD world in particular seems to be full of buggy libraries, but to >>>>>>>>> be fair the tasks involved are incredibly difficult and users no doubt >>>>>>>>> are always coming up with cases that the developers hadn't checked >>>>>>>>> for. >>>>>>>> >>>>>>>> Are we the only project that pushes these libraries that hard? We do >>>>>>>> seem to find our fair share of library issues. >>>>>>>> >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Somewhat off-topic: grep shows me that the source code >>>>>>>>>>> and headers are full of wxT(). Since wxT() had been >>>>>>>>>>> deprecated years ago and KiCad is no longer compatible >>>>>>>>>>> with versions of wxWidgets which required wxT(), perhaps >>>>>>>>>>> we should ask devs to purge wxT() from the headers and >>>>>>>>>>> sources which they touch? I think that might also get devs >>>>>>>>>>> into the habit of not using wxT() - even I still use it without >>>>>>>>>>> realizing it - bad habits die hard. :) >>>>>>>>>> >>>>>>>>>> I caught myself using wxT() while writing the legacy schematic plugin >>>>>>>>>> several times. It will take time to get used to it but we will get >>>>>>>>>> there. If you happen to be working on a file, please feel free to >>>>>>>>>> remove them. I don't think we need to do the mass purge just yet. >>>>>>>>>> >>>>>>>>> >>>>>>>>> OK; I might create some patches for the bits I'd worked on in the >>>>>>>>> past like VRML export and IDF export. >>>>>>>> >>>>>>>> For small change sets (<= 5 commits), please send me patch sets using >>>>>>>> format-patch or send-email. It's easier than me having to add remotes >>>>>>>> and go through the whole pull rebase cycle. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Wayne >>>>>>>> >>>>>>>>> >>>>>>>>> - Cirilo >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Cirilo >>>>>>>>>>> >>>>>>>>>>> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh >>>>>>>>>>> <stambau...@gmail.com> wrote: >>>>>>>>>>>> Cirilo, >>>>>>>>>>>> >>>>>>>>>>>> I just tested this since you fixed the windows extension issue. >>>>>>>>>>>> The >>>>>>>>>>>> menu item is enabled but I always get an "Unable to create step >>>>>>>>>>>> file >>>>>>>>>>>> whenever there are spaces in the file name and/or path." You >>>>>>>>>>>> didn't by >>>>>>>>>>>> chance forget to double quote the command line string did you? If >>>>>>>>>>>> you >>>>>>>>>>>> don't, spaces in file and/or path names in command strings will >>>>>>>>>>>> fail. >>>>>>>>>>>> >>>>>>>>>>>> Just a couple of quick comments nothing major. wxT() macros are no >>>>>>>>>>>> longer required in wx3 so try to remember not to use it anymore >>>>>>>>>>>> since >>>>>>>>>>>> it's slated to be deprecated in the future. It's also not >>>>>>>>>>>> necessary to >>>>>>>>>>>> convert path separators in strings when you are already using >>>>>>>>>>>> wxFileName. You can use wxFileName::GetFullPath() which will >>>>>>>>>>>> return the >>>>>>>>>>>> native separators no matter what you feed it with. You can also >>>>>>>>>>>> convert >>>>>>>>>>>> to the unix file separator for storage by using >>>>>>>>>>>> wxFileName::GetFullPath( >>>>>>>>>>>> wxPATH_UNIX ). This removes the need for #ifdef WINDOWS/#endif to >>>>>>>>>>>> do >>>>>>>>>>>> the separator conversion. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Wayne >>>>>>>>>>>> >>>>>>>>>>>> On 9/19/2016 3:53 AM, Nick Østergaard wrote: >>>>>>>>>>>>> Looks good, I will test it soon. But I noticed that it looks like >>>>>>>>>>>>> you >>>>>>>>>>>>> did not use the copyright template copyright.h from the root of >>>>>>>>>>>>> the source. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Den 19/09/2016 09.46 skrev "Cirilo Bernardo" >>>>>>>>>>>>> <cirilo.berna...@gmail.com >>>>>>>>>>>>> <mailto:cirilo.berna...@gmail.com>>: >>>>>>>>>>>>> >>>>>>>>>>>>> The kicad-step feature branch now implements a STEP Export. The >>>>>>>>>>>>> menu >>>>>>>>>>>>> item may need a new icon (I lazily reused the IDF icon). Any >>>>>>>>>>>>> testing and >>>>>>>>>>>>> comments would be appreciated. The kicad2step utility which >>>>>>>>>>>>> performs >>>>>>>>>>>>> the conversion is of course dependent on OCE and is only built >>>>>>>>>>>>> when >>>>>>>>>>>>> KICAD_USE_OCE is defined. The "Export STEP" menu item is >>>>>>>>>>>>> disabled >>>>>>>>>>>>> if the kicad2step executable is not found in the same directory >>>>>>>>>>>>> as the >>>>>>>>>>>>> pcbnew executable. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step >>>>>>>>>>>>> >>>>>>>>>>>>> <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step> >>>>>>>>>>>>> >>>>>>>>>>>>> - Cirilo >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>>>>>> <mailto:kicad-developers@lists.launchpad.net> >>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>> Post to : kicad-developers@lists.launchpad.net >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : kicad-developers@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp >>> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp