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
