Hey Cirilo, is there any chance of being able to get output/log either written out to file or in the dialog (or another dialog) like how it is in the netlist read dialog?
On Fri, Sep 23, 2016 at 4:04 AM, Simon Wells <[email protected]> wrote: > 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 <[email protected]> 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 >> <[email protected]> wrote: >>> … 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
