date:20160922

Re: [Kicad-developers] STEP Export

2016-09-22 Thread 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] export_vrml.cpp warnings

2016-09-22 Thread Cirilo Bernardo

Thanks, that's probably a bad C habit on my part. :)  The most ancient of
C++ specs
were more lenient with magic int-enum casts. All the more reason to use
"enum class"
from now on; after all it was explicitly to address problems like this.

Fix attached; the patch also removes the few instances of wxT() in that
file.

- Cirilo

On Fri, Sep 23, 2016 at 5:01 AM, Simon Wells  wrote:

> i am getting the following warning
>
> /Users/simon/kicad-app/kicad/pcbnew/exporters/export_vrml.cpp:1624:18:
> warning:
>   comparison of constant -1 with expression of type 'VRML_COLOR_INDEX'
> is
>   always false [-Wtautological-constant-out-of-range-compare]
>
> if( colorIdx == -1 )
>  ^  ~~
>
> the enum is specified as
>
> enum VRML_COLOR_INDEX
> {
> VRML_COLOR_PCB = 0,
> VRML_COLOR_TRACK,
> VRML_COLOR_SILK,
> VRML_COLOR_TIN,
> VRML_COLOR_LAST
> };
>
> as the expression is if (colorIdx == -1 ) colorIdx = VRML_COLOR_PCB
> would it not be worth adding a value for -1 into the enum (not sure
> whether it should be VRML_COLOR_AUTO or VRML_COLOR_UNSPECIFIED)
>
> thanks
>
> Simon
>
> ___
> 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
>
From dee93d77eab2072a4b11551557884fe39abf5008 Mon Sep 17 00:00:00 2001
From: Cirilo Bernardo 
Date: Fri, 23 Sep 2016 08:20:17 +1000
Subject: [PATCH] Fix bad enum compare (VRML_COLOR_INDEX) and remove wxT()
 instances
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.9.3"

This is a multi-part message in MIME format.
--2.9.3
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 pcbnew/exporters/export_vrml.cpp | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)


--2.9.3
Content-Type: text/x-patch; name="0001-Fix-bad-enum-compare-VRML_COLOR_INDEX-and-remove-wxT.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-bad-enum-compare-VRML_COLOR_INDEX-and-remove-wxT.patch"

diff --git a/pcbnew/exporters/export_vrml.cpp b/pcbnew/exporters/export_vrml.cpp
index f6c617a..7fc0a76 100644
--- a/pcbnew/exporters/export_vrml.cpp
+++ b/pcbnew/exporters/export_vrml.cpp
@@ -2,7 +2,7 @@
  * This program source code file is part of KiCad, a free EDA CAD application.
  *
  * Copyright (C) 2009-2013  Lorenzo Mercantonio
- * Copyright (C) 2014  Cirilo Bernardo
+ * Copyright (C) 2014-2016  Cirilo Bernardo
  * Copyright (C) 2013 Jean-Pierre Charras jp.charras at wanadoo.fr
  * Copyright (C) 2004-2016 KiCad Developers, see AUTHORS.txt for contributors.
  *
@@ -131,6 +131,7 @@ struct VRML_COLOR
 
 enum VRML_COLOR_INDEX
 {
+VRML_COLOR_NONE = -1,
 VRML_COLOR_PCB = 0,
 VRML_COLOR_TRACK,
 VRML_COLOR_SILK,
@@ -831,9 +832,8 @@ static void export_vrml_board( MODEL_VRML& aModel, BOARD* pcb )
 
 if( !pcb->GetBoardPolygonOutlines( bufferPcbOutlines, allLayerHoles,  ) )
 {
-msg << wxT( "\n\n" ) <<
-_( "Unable to calculate the board outlines;\n"
-   "fall back to using the board boundary box." );
+msg << "\n\n" <<
+_( "Unable to calculate the board outlines; fall back to using the board boundary box." );
 wxMessageBox( msg );
 }
 
@@ -863,8 +863,8 @@ static void export_vrml_board( MODEL_VRML& aModel, BOARD* pcb )
 
 if( seg < 0 )
 {
-msg << wxT( "\n\n" ) <<
-_( "VRML Export Failed:\nCould not add holes to contours." );
+msg << "\n\n" <<
+  _( "VRML Export Failed: Could not add holes to contours." );
 wxMessageBox( msg );
 
 return;
@@ -1413,7 +1413,7 @@ static void export_vrml_module( MODEL_VRML& aModel, BOARD* aPcb, MODULE* aModule
 
 if( srcModTime != destModTime )
 {
-wxLogDebug( wxT( "Copying 3D model %s to %s." ),
+wxLogDebug( "Copying 3D model %s to %s.",
 GetChars( srcFile.GetFullPath() ),
 GetChars( dstFile.GetFullPath() ) );
 
@@ -1459,14 +1459,14 @@ static void export_vrml_module( MODEL_VRML& aModel, BOARD* aPcb, MODULE* aModule
 if( USE_RELPATH )
 {
 wxFileName tmp = dstFile;
-tmp.SetExt( wxT( "" ) );
-tmp.SetName( wxT( "" ) );
+tmp.SetExt( "" );
+tmp.SetName( "" );
 tmp.RemoveLastDir();
 dstFile.MakeRelativeTo( tmp.GetPath() );
 }
 
 wxString fn = dstFile.GetFullPath();
-fn.Replace( wxT( "\\" ), wxT( "/" ) );
+fn.Replace( "\\", "/" );
 output_file << TO_UTF8( fn ) << "\"\n} ]\n";

Re: [Kicad-developers] STEP Export

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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

2016-09-22 Thread 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] [PATCH] Added explicit conversion from wxstring to cstring

2016-09-22 Thread Wayne Stambaugh

I pushed your patch to the product master branch.  Thanks!

On 9/22/2016 10:50 AM, Simon Wells wrote:
> ---
>  utils/kicad2step/kicad2step.cpp | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> 
> 
> ___
> 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

2016-09-22 Thread 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

2016-09-22 Thread 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

[Kicad-developers] export_vrml.cpp warnings

2016-09-22 Thread Simon Wells

i am getting the following warning

/Users/simon/kicad-app/kicad/pcbnew/exporters/export_vrml.cpp:1624:18: warning:
  comparison of constant -1 with expression of type 'VRML_COLOR_INDEX' is
  always false [-Wtautological-constant-out-of-range-compare]

if( colorIdx == -1 )
 ^  ~~

the enum is specified as

enum VRML_COLOR_INDEX
{
VRML_COLOR_PCB = 0,
VRML_COLOR_TRACK,
VRML_COLOR_SILK,
VRML_COLOR_TIN,
VRML_COLOR_LAST
};

as the expression is if (colorIdx == -1 ) colorIdx = VRML_COLOR_PCB
would it not be worth adding a value for -1 into the enum (not sure
whether it should be VRML_COLOR_AUTO or VRML_COLOR_UNSPECIFIED)

thanks

Simon

___
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

Re: [Kicad-developers] export_vrml.cpp warnings

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] [PATCH] Added explicit conversion from wxstring to cstring

Re: [Kicad-developers] STEP Export

Re: [Kicad-developers] STEP Export

[Kicad-developers] export_vrml.cpp warnings

12 matches

Site Navigation

Mail list logo

Footer information