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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>>>> wrote: >>>>>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote: >>>>>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh >>>>>>> <[email protected]> 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 >>>>>>>>> <[email protected]> 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" >>>>>>>>>>> <[email protected] >>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>> >>>>>>>>>>> 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 : [email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> 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 : [email protected] >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
