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 <swel...@gmail.com> 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 <swel...@gmail.com> 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
>> <stegma...@sw-systems.de> wrote:
>>> … hardcoded /Applications is always a really bad idea …
>>>
>>>> On 22 Sep 2016, at 17:42, Simon Wells <swel...@gmail.com> 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
>>>> <stegma...@sw-systems.de> 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 <swel...@gmail.com> 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?
>>>>>>>>>>>>
>>>>>>>>>>>> I'm wondering if you could make something abstract enough to work 
>>>>>>>>>>>> in all
>>>>>>>>>>>> the places where we run external apps.  These dialogs always seem 
>>>>>>>>>>>> pretty
>>>>>>>>>>>> task specific like the netlist and bom dialogs?  You could try I 
>>>>>>>>>>>> guess.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The best abstraction I can think of at the moment is to instantiate 
>>>>>>>>>>> a dialog
>>>>>>>>>>> which simply has a window showing the stderr + stdout of the 
>>>>>>>>>>> running app
>>>>>>>>>>> and a cancel button to kill the process if necessary. All other 
>>>>>>>>>>> customizations
>>>>>>>>>>> should be done in a parent window. I'll come up with something and 
>>>>>>>>>>> apply it
>>>>>>>>>>> to the BOM and netlist generation as well.
>>>>>>>>>>
>>>>>>>>>> Given that we've never had any issues with the bom and netlist 
>>>>>>>>>> external
>>>>>>>>>> processes, it may not be worth the effort although I'm not opposed to
>>>>>>>>>> the idea.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The fact that a process using OCE can hang brings up the
>>>>>>>>>>>>> question of whether it is better to leave kicad2step as a
>>>>>>>>>>>>> separate app or whether it is generally OK as a plugin and
>>>>>>>>>>>>> the odd crash due to bugs in OCE and/or the STEP/IGES
>>>>>>>>>>>>> models would be acceptable. We can stuff the plugin
>>>>>>>>>>>>> invocations into their own thread and check for completion,
>>>>>>>>>>>>> but unlike the case with a separate process, we cannot
>>>>>>>>>>>>> guarantee there is no memory corruption or leakage.
>>>>>>>>>>>>> Any thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> Ughh!  You're not making me feel any better about oce.  It would 
>>>>>>>>>>>> be nice
>>>>>>>>>>>> to be able to kill a rouge process though.  Doesn't the oce 
>>>>>>>>>>>> library api
>>>>>>>>>>>> provide some kind of error reporting capability?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OCE does have an error reporting scheme but I've seen it hang
>>>>>>>>>>> indefinitely while performing some operations such as shape healing
>>>>>>>>>>> on defective STEP models. In other instances it eventually stops
>>>>>>>>>>> after it has hogged the maximum memory that the system would
>>>>>>>>>>> give it. In both cases it's not possible to get error information 
>>>>>>>>>>> from
>>>>>>>>>>> within OCE. Unfortunately such bad behavior is not unique to OCE; 
>>>>>>>>>>> the
>>>>>>>>>>> MCAD world in particular seems to be full of buggy libraries, but to
>>>>>>>>>>> be fair the tasks involved are incredibly difficult and users no 
>>>>>>>>>>> doubt
>>>>>>>>>>> are always coming up with cases that the developers hadn't checked 
>>>>>>>>>>> for.
>>>>>>>>>>
>>>>>>>>>> Are we the only project that pushes these libraries that hard?  We do
>>>>>>>>>> seem to find our fair share of library issues.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Somewhat off-topic: grep shows me that the source code
>>>>>>>>>>>>> and headers are full of wxT().  Since wxT() had been
>>>>>>>>>>>>> deprecated years ago and KiCad is no longer compatible
>>>>>>>>>>>>> with versions of wxWidgets which required wxT(), perhaps
>>>>>>>>>>>>> we should ask devs to purge wxT() from the headers and
>>>>>>>>>>>>> sources which they touch? I think that might also get devs
>>>>>>>>>>>>> into the habit of not using wxT() - even I still use it without
>>>>>>>>>>>>> realizing it - bad habits die hard. :)
>>>>>>>>>>>>
>>>>>>>>>>>> I caught myself using wxT() while writing the legacy schematic 
>>>>>>>>>>>> plugin
>>>>>>>>>>>> several times.  It will take time to get used to it but we will get
>>>>>>>>>>>> there.  If you happen to be working on a file, please feel free to
>>>>>>>>>>>> remove them.  I don't think we need to do the mass purge just yet.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> OK; I might create some patches for the bits I'd worked on in the
>>>>>>>>>>> past like VRML export and IDF export.
>>>>>>>>>>
>>>>>>>>>> For small change sets (<= 5 commits), please send me patch sets using
>>>>>>>>>> format-patch or send-email.  It's easier than me having to add 
>>>>>>>>>> remotes
>>>>>>>>>> and go through the whole pull rebase cycle.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>> Wayne
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Cirilo
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Cirilo
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh 
>>>>>>>>>>>>> <stambau...@gmail.com> wrote:
>>>>>>>>>>>>>> Cirilo,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I just tested this since you fixed the windows extension issue.  
>>>>>>>>>>>>>> The
>>>>>>>>>>>>>> menu item is enabled but I always get an "Unable to create step 
>>>>>>>>>>>>>> file
>>>>>>>>>>>>>> whenever there are spaces in the file name and/or path."  You 
>>>>>>>>>>>>>> didn't by
>>>>>>>>>>>>>> chance forget to double quote the command line string did you?  
>>>>>>>>>>>>>> If you
>>>>>>>>>>>>>> don't, spaces in file and/or path names in command strings will 
>>>>>>>>>>>>>> fail.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just a couple of quick comments nothing major.  wxT() macros are 
>>>>>>>>>>>>>> no
>>>>>>>>>>>>>> longer required in wx3 so try to remember not to use it anymore 
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>> it's slated to be deprecated in the future.  It's also not 
>>>>>>>>>>>>>> necessary to
>>>>>>>>>>>>>> convert path separators in strings when you are already using
>>>>>>>>>>>>>> wxFileName.  You can use wxFileName::GetFullPath() which will 
>>>>>>>>>>>>>> return the
>>>>>>>>>>>>>> native separators no matter what you feed it with.  You can also 
>>>>>>>>>>>>>> convert
>>>>>>>>>>>>>> to the unix file separator for storage by using 
>>>>>>>>>>>>>> wxFileName::GetFullPath(
>>>>>>>>>>>>>> wxPATH_UNIX ).  This removes the need for #ifdef WINDOWS/#endif 
>>>>>>>>>>>>>> to do
>>>>>>>>>>>>>> the separator conversion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Wayne
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 9/19/2016 3:53 AM, Nick Østergaard wrote:
>>>>>>>>>>>>>>> Looks good, I will test it soon. But I noticed that it looks 
>>>>>>>>>>>>>>> like you
>>>>>>>>>>>>>>> did not use the copyright template copyright.h from the root of 
>>>>>>>>>>>>>>> the source.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Den 19/09/2016 09.46 skrev "Cirilo Bernardo" 
>>>>>>>>>>>>>>> <cirilo.berna...@gmail.com
>>>>>>>>>>>>>>> <mailto:cirilo.berna...@gmail.com>>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   The kicad-step feature branch now implements a STEP Export. 
>>>>>>>>>>>>>>> The menu
>>>>>>>>>>>>>>>   item may need a new icon (I lazily reused the IDF icon). Any 
>>>>>>>>>>>>>>> testing and
>>>>>>>>>>>>>>>   comments would be appreciated. The kicad2step utility which 
>>>>>>>>>>>>>>> performs
>>>>>>>>>>>>>>>   the conversion is of course dependent on OCE and is only 
>>>>>>>>>>>>>>> built when
>>>>>>>>>>>>>>>   KICAD_USE_OCE is defined. The "Export STEP" menu item is 
>>>>>>>>>>>>>>> disabled
>>>>>>>>>>>>>>>   if the kicad2step executable is not found in the same 
>>>>>>>>>>>>>>> directory as the
>>>>>>>>>>>>>>>   pcbnew executable.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step
>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   - Cirilo
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   _______________________________________________
>>>>>>>>>>>>>>>   Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>>>>>>   <https://launchpad.net/~kicad-developers>
>>>>>>>>>>>>>>>   Post to     : kicad-developers@lists.launchpad.net
>>>>>>>>>>>>>>>   <mailto:kicad-developers@lists.launchpad.net>
>>>>>>>>>>>>>>>   Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>>>>>>   <https://launchpad.net/~kicad-developers>
>>>>>>>>>>>>>>>   More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>   <https://help.launchpad.net/ListHelp>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>>>>>>> Post to     : kicad-developers@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
>>>>>
>>>

_______________________________________________
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

Reply via email to