Brian,
I have the %I and %O support in place, see netform.cpp.
How's the BOM work coming?
Dick
Excellent, I'll take a look. Hopefully I should have something for you
in the next day or two. Sorry this has taken so long!
I will mail ASAP.
Best Regards,
Brian.
Wonderful.
Wayne Stambaugh a écrit :
On 8/6/2010 2:13 PM, Dick Hollenbeck wrote:
On 08/06/2010 11:49 AM, Brian F. G. Bidulock wrote:
Dick,
On Fri, 06 Aug 2010, Dick Hollenbeck wrote:
--X--snip--X--
Curious about scala now. Later I came to refer to the lower level
languages as programming
On Thu, 5 Aug 2010, Dick Hollenbeck wrote:
Good question! We were told recently that there are a number of
projects out there that might come under an umbrella of contrib. I
wonder if we opened that gate how many would arrive carrying their own
language and tool requirements? Own programming
On 08/04/2010 08:30 PM, Frank bennett wrote:
Dick:
Good to see this effort.
Back in 2008-03-26 I left a xml4pcb project @ sourceforge to do an
import xml
from PCB123 to KiCad-pcbnew. I had used PCB123 for some prototype dev
board
expansions (before I used KiCad) and wanted to learn xml
On Thu, 5 Aug 2010, Dick Hollenbeck wrote:
The more I look at PyQt4, the better it looks. It has a python layer on
top of a decent Qt XML library. How's your python?
Are you sure we aren't imposing too much dependencies?
We have wxWindows (and that's ok, the primary toolkit);
then python
On 08/05/2010 01:53 PM, Lorenzo Marcantonio wrote:
On Thu, 5 Aug 2010, Dick Hollenbeck wrote:
The more I look at PyQt4, the better it looks. It has a python layer on
top of a decent Qt XML library. How's your python?
Are you sure we aren't imposing too much dependencies?
On 1 August 2010 01:45, Dick Hollenbeck d...@softplc.com wrote:
On 07/31/2010 03:42 PM, Karl Schmidt wrote:
Dick Hollenbeck wrote:
For eventual BOM generation, we may have to provide even more
flexibility, so this may not be the final behavior, but with this email
I am trying to get you the
On 07/30/2010 12:03 PM, Dick Hollenbeck wrote:
I am trying to reach the right comprise between clarity and lack of
verbosity, and to avoid situations where we have to change ' ' with
'_' by keeping things wrapped with proper XML syntax.
The attached file is a revision that actually
On 07/31/2010 03:32 AM, Dick Hollenbeck wrote:
On 07/30/2010 12:03 PM, Dick Hollenbeck wrote:
I am trying to reach the right comprise between clarity and lack of
verbosity, and to avoid situations where we have to change ' ' with
'_' by keeping things wrapped with proper XML syntax.
On 07/31/2010 03:42 PM, Karl Schmidt wrote:
Dick Hollenbeck wrote:
For eventual BOM generation, we may have to provide even more
flexibility, so this may not be the final behavior, but with this email
I am trying to get you the ability to generate these files here, nothing
more yet.
On Thu, 29 Jul 2010, jean-pierre charras wrote:
But I must say: indeed, BOM C++ code is garbage.
Well it was... retouched... a few times too much :P
Some features (like the labels list) are more a debug tool than an
usefulfeature.
I disagree with that. On a sizeable board of 10+ pages
This sounds like a sane workflow to me. Dick, please feel free to
forward me example XML when you are ready.
Best Regards,
Brian.
In my experience with XML, working with lower case element and attribute
names leads to better clarity and leaves the values in the lime light
since they
Lorenzo,
On Fri, 30 Jul 2010, Lorenzo Marcantonio wrote:
I fact I use very few the BOM generator.
It's meant to be used as a final reporting tool, I'm not surprised of
this...
One of the most important iterative uses BOM generation is for
price estimation. A BOM that is easily
Dick,
I have between 500 and 1000 0.1uF X5R 0402 bypass capacitors on
my card. You are going to have 1000 repetitions of this
component structure in the file, where the only difference is
the 'ref' attribute in the first line (resplendent with
repetitions of my user-defined fields
Dick,
I like the scratch your own itch approach.
Just trying to let you know some use requirements.
Not trying to dictate your time. I didn't want
to touch EESCHEMA (just PCBNEW), but there are
other adjustments to netlist that need to be made
(differential pairs, busses, signal types, stub
On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
This is one thing that could be done to the BOM generator. I don't like
the current dialog window there at all, and am not too exciting about
fixing something for which I have no enthusiasm for. I am not sure it
is worth salvaging. A few lines of
On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
What do people think?
Like very much. IMO Python is the way to go for default scripts. I
was positively surprised to see that Mac OS X ships with Python when I had
to use a Mac. Not that I much care about Macs, but just to mention Python
being
On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
Up until seeing this BOM C++ code, I never knew a CSV file could or
would use a tab or a semicolon as a separator. I thought the C in CSV
Originally it was a comma only. With quoting rules for embedded commas.
Then it was extended, so everyone does
On 07/29/2010 08:22 AM, Brian Sidebotham wrote:
On 29 July 2010 06:39, Dick Hollenbeck d...@softplc.com wrote:
I have spent most of the day in eeschema's BOM support code.
One idea I have is to simplify that code significantly, because of a
belief that we will be unable to meet all needs
On Thu, 29 Jul 2010, Brian Sidebotham wrote:
scripting. I like python so much it tends to pain me to write some
code in other languages when I know how easy it would be to do in
python.
I'd say the same for a lot of languages which are not python :P:P (I'm
actually more proficient in 3
On 7/29/2010 9:07 AM, Dick Hollenbeck wrote:
On 07/29/2010 01:25 AM, Lorenzo Marcantonio wrote:
On Thu, 29 Jul 2010, Dick Hollenbeck wrote:
This is one thing that could be done to the BOM generator. I don't like
the current dialog window there at all, and am not too exciting about
On 29 July 2010 14:55, Dick Hollenbeck d...@softplc.com wrote:
On 07/29/2010 08:22 AM, Brian Sidebotham wrote:
On 29 July 2010 06:39, Dick Hollenbeck d...@softplc.com wrote:
Hi Dick,
A script may not need a compiler or build environment, but it does
require an interpreter. Python is my
Jean-Pierre,
First, I apologize for saying the BOM C++ code is garbage. (I had my
special hat on, :) you know the one that says any code I have not
written is garbage. It's a
silly self-misleading hat, but I sleep in it.)
Does the output of netform.cpp's Write_GENERIC_NetList() have what is
Dick Hollenbeck a écrit :
Jean-Pierre,
First, I apologize for saying the BOM C++ code is garbage. (I had my
special hat on, :) you know the one that says any code I have not
written is garbage. It's a
silly self-misleading hat, but I sleep in it.)
Well, a lot of guys have the same
What we need is almost entirely present in the existing *generic
netlist exporter*. (EESCHEMA - Netlist - Add Plugin).
I am happy you are thinking to use this approach.
Write_GENERIC_NetList() could have some minor problems in complex
hierarchies (about timestamp/sheet path). (I can fix
On 07/29/2010 11:58 AM, Brian Sidebotham wrote:
On 29 July 2010 16:04, Dick Hollenbeck d...@softplc.com wrote:
Jean-Pierre,
First, I apologize for saying the BOM C++ code is garbage. (I had my
special hat on, :) you know the one that says any code I have not
written is garbage. It's a
I have spent most of the day in eeschema's BOM support code.
One idea I have is to simplify that code significantly, because of a
belief that we will be unable to meet all needs in C++. It will take a
user modifying a script for him to get truly what he wants. Using a
script means it requires
27 matches
Mail list logo
