kicad-developers team mailing list archive

[Simon Wells <swel024@xxxxxxxxx>]

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