… hardcoded /Applications is always a really bad idea … > On 22 Sep 2016, at 17:42, Simon Wells <[email protected]> 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 > <[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
