Re: [Kicad-developers] STEP export

[Drew Van Zandt]

https://gitlab.com/kicad/code/kicad/issues/3695


*Drew Van Zandt*


On Thu, Dec 19, 2019 at 10:26 AM Drew Van Zandt 
wrote:

> Y'all,
>Who would I talk to about this?  I am seeing a bug, but it is so
> confusing I am not entirely sure how to report it - I could use help in the
> form of questions from someone with more STEP knowledge than I have.  I
> also can't put sample files on the public wiki, but would be open to
> sharing them with an individual with the understanding that they stay
> nonpublic.
>
> It seems like when I update this particular PCB model, some of the update
> comes through in the STEP file, and some things don't get changed.  One of
> the files I have still has a "ghost" PCB outline from the project I copied
> it from, before days of modifications.
> (5.1.4)-1.
>
> I will submit it as a bug with as much info as I can.
>
>
> *Drew Van Zandt*
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

Thanks Marcos,

 I'll see if OCE has some scheme for guessing at progress; otherwise the best
I can do is capture stdout and print information on the file which is
to be loaded
next such as the name and file size.

- Cirilo

On Tue, Sep 27, 2016 at 5:06 AM, Marcos Chaparro  wrote:
> Hi Cirilo,
> quick comment: a progress bar, progress %, or any kind of feedback while
> performing the 3D export would come in handy. I spent some time deleting
> footprints to find the problematic step file because the kicad2step process
> seemed locked up, but it was only a matter of waiting some minutes. The
> board had 58 step models, exported file was 4.8MB.
>
> Great work by the way.
>
>
> Marcos
>
> On Sat, Sep 24, 2016 at 1:04 PM, Wayne Stambaugh 
> wrote:
>>
>> On 9/22/2016 10:13 PM, Cirilo Bernardo wrote:
>> >
>> >
>> > On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh > > > wrote:
>> >
>> > On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>> > > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh
>> > > 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.
>> >
>> >
>> > The stderr was a diagnostic print that I forgot to rip out. I need to
>> > make a habit
>> > of checking for stderr before I commit something.
>>
>> No problem, send me a patch when you get a chance.
>>
>> >
>> >
>> > 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.
>> >
>> >
>> > From an MCAD point of view the traces etc are not nice since they bloat
>> > the
>> > model and  make the MCAD UI painfully slow. Maybe one day people will
>> > want
>> > more extensive information for heat flow analysis and such, but at the
>> > moment
>> > there's no point in guessing what data people will want.  There's a STEP
>> > AP
>> > (310) for electronic assemblies but I'm not familiar with what it covers
>> > or if
>> > anyone actually uses it in production. Otherwise, for eyecandy I'd
>> > recommend
>> > using the VRML export rather than the STEP export which is intended more
>> > for professionals who need the model solely for work related to
>> > mechanical
>> > design.
>>
>> I was just curious why you would export that level of detail with vrml
>> and not step.  I understand the higher the level of detail, the harder
>> the modeling software has to work to render it.  I've worked for several
>> companies who worked with that level of detail and the cad jockeys that
>> did this kind of work had ridiculously powerful computers.  I'm fine
>> with the way it is because I don't need that level of detail but I can
>> imagine someone asking for it.
>>
>> Cheers,
>>
>> Wayne
>>
>> >
>> > - Cirilo
>> >
>> >
>> > >
>> > >>>
>> > >>> 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 

Re: [Kicad-developers] STEP Export

[Marcos Chaparro]

Hi Cirilo,
quick comment: a progress bar, progress %, or any kind of feedback while
performing the 3D export would come in handy. I spent some time deleting
footprints to find the problematic step file because the kicad2step process
seemed locked up, but it was only a matter of waiting some minutes. The
board had 58 step models, exported file was 4.8MB.

Great work by the way.


Marcos

On Sat, Sep 24, 2016 at 1:04 PM, Wayne Stambaugh 
wrote:

> On 9/22/2016 10:13 PM, Cirilo Bernardo wrote:
> >
> >
> > On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh  > > wrote:
> >
> > On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
> > > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh <
> stambau...@gmail.com > 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.
> >
> >
> > The stderr was a diagnostic print that I forgot to rip out. I need to
> > make a habit
> > of checking for stderr before I commit something.
>
> No problem, send me a patch when you get a chance.
>
> >
> >
> > 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.
> >
> >
> > From an MCAD point of view the traces etc are not nice since they bloat
> the
> > model and  make the MCAD UI painfully slow. Maybe one day people will
> want
> > more extensive information for heat flow analysis and such, but at the
> > moment
> > there's no point in guessing what data people will want.  There's a STEP
> AP
> > (310) for electronic assemblies but I'm not familiar with what it covers
> > or if
> > anyone actually uses it in production. Otherwise, for eyecandy I'd
> recommend
> > using the VRML export rather than the STEP export which is intended more
> > for professionals who need the model solely for work related to
> mechanical
> > design.
>
> I was just curious why you would export that level of detail with vrml
> and not step.  I understand the higher the level of detail, the harder
> the modeling software has to work to render it.  I've worked for several
> companies who worked with that level of detail and the cad jockeys that
> did this kind of work had ridiculously powerful computers.  I'm fine
> with the way it is because I don't need that level of detail but I can
> imagine someone asking for it.
>
> Cheers,
>
> Wayne
>
> >
> > - Cirilo
> >
> >
> > >
> > >>>
> > >>> 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 

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

Oops .. I meant STEP AP210 for electronic assemblies rather than
AP 310.  At any rate, what the kicad2step tool creates at the moment
is AP214; I don't believe OCE currently has support for AP210.

- Cirilo

On Fri, Sep 23, 2016 at 12:13 PM, Cirilo Bernardo  wrote:

>
>
> On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh 
> wrote:
>
>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>> > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh 
>> 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.
>>
>>
> The stderr was a diagnostic print that I forgot to rip out. I need to make
> a habit
> of checking for stderr before I commit something.
>
>
>> 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.
>>
>>
> From an MCAD point of view the traces etc are not nice since they bloat the
> model and  make the MCAD UI painfully slow. Maybe one day people will want
> more extensive information for heat flow analysis and such, but at the
> moment
> there's no point in guessing what data people will want.  There's a STEP AP
> (310) for electronic assemblies but I'm not familiar with what it covers
> or if
> anyone actually uses it in production. Otherwise, for eyecandy I'd
> recommend
> using the VRML export rather than the STEP export which is intended more
> for professionals who need the model solely for work related to mechanical
> design.
>
> - Cirilo
>
>
>> >
>> >>>
>> >>> 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 

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

On Fri, Sep 23, 2016 at 12:18 AM, Wayne Stambaugh 
wrote:

> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
> > On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh 
> 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.
>
>
The stderr was a diagnostic print that I forgot to rip out. I need to make
a habit
of checking for stderr before I commit something.


> 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.
>
>
>From an MCAD point of view the traces etc are not nice since they bloat the
model and  make the MCAD UI painfully slow. Maybe one day people will want
more extensive information for heat flow analysis and such, but at the
moment
there's no point in guessing what data people will want.  There's a STEP AP
(310) for electronic assemblies but I'm not familiar with what it covers or
if
anyone actually uses it in production. Otherwise, for eyecandy I'd recommend
using the VRML export rather than the STEP export which is intended more
for professionals who need the model solely for work related to mechanical
design.

- Cirilo


> >
> >>>
> >>> 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 

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

On Fri, Sep 23, 2016 at 2:09 AM, Simon Wells  wrote:

> 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?
>
>
I'll be working on that this weekend; it's *only* a matter of redirecting
the
process' stdout + stderr to a window and wxWidgets already has such a
scheme in place - I'll find out soon how difficult it is to use.

- Cirilo


>
>
> On Fri, Sep 23, 2016 at 4:04 AM, Simon Wells  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  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
> >>  wrote:
> >>> … hardcoded /Applications is always a really bad idea …
> >>>
>  On 22 Sep 2016, at 17:42, Simon Wells  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
>   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  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 <
> stambau...@gmail.com> 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 <
> stambau...@gmail.com> wrote:
> >> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
> >>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh <
> stambau...@gmail.com> 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?

Re: [Kicad-developers] STEP Export

[Simon Wells]

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  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  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
>>  wrote:
>>> … hardcoded /Applications is always a really bad idea …
>>>
 On 22 Sep 2016, at 17:42, Simon Wells  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
  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  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  
>> 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 
>  wrote:
>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh 
>>>  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 

Re: [Kicad-developers] STEP Export

[Simon Wells]

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  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
>  wrote:
>> … hardcoded /Applications is always a really bad idea …
>>
>>> On 22 Sep 2016, at 17:42, Simon Wells  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
>>>  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  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  
> 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 
  wrote:
> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh 
>>  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 

Re: [Kicad-developers] STEP Export

[Simon Wells]

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
 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  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  
>> 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  
> wrote:
>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh 
>>>  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 

Re: [Kicad-developers] STEP Export

[Bernhard Stegmaier]

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  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  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  
 wrote:
> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh  
>> 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 

Re: [Kicad-developers] STEP Export

[Wayne Stambaugh]

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:


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  wrote:
>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh  
>>> 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 

Re: [Kicad-developers] STEP Export

[Simon Wells]

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  wrote:
> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote:
>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh  
>> 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 

Re: [Kicad-developers] STEP Export

[Wayne Stambaugh]

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.

> 
> 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 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?

> 
> 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.

> 
> - Cirilo
> 
> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh  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" >> >:
>>>
>>> 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
>>> 
>>> 
>>>
>>> - Cirilo
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> More help   : 

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

I forgot to mention (3) quoted all filenames (application path, input
file, output file).

On Thu, Sep 22, 2016 at 9:27 AM, 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).
>
> 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?
>
> 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?
>
> 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. :)
>
> - Cirilo
>
> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh  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" >> >:
>>>
>>> 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
>>> 
>>> 
>>>
>>> - Cirilo
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: 

Re: [Kicad-developers] STEP Export

[Cirilo Bernardo]

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).

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?

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?

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. :)

- Cirilo

On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh  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" > >:
>>
>> 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
>> 
>> 
>>
>> - Cirilo
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 
>> Post to : kicad-developers@lists.launchpad.net
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> 
>> More help   : https://help.launchpad.net/ListHelp
>> 
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] STEP Export

[Wayne Stambaugh]

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"  >:
> 
> 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
> 
> 
> 
> - Cirilo
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] STEP Export

[Nick Østergaard]

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" :

> 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
>
> - Cirilo
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp