Hmm weird, kicad2step: /Volumes/simon/kicad-app/bin/kicad.app/kicad2step
i think its to do with the embedding of the other application .apps, i have a dodgy fix but i will wait for comments from cirilo before providing a proper patch On Fri, Sep 23, 2016 at 3:44 AM, Simon Wells <swel...@gmail.com> wrote: > 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 >>>> >>
kicad2step-path-fix.patch
Description: Binary data
_______________________________________________ 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