On 05/06/13 20:20, Adam Wolf wrote:
> I think at this point all my concerns have been addressed via off-list email.
> Thanks folks!
Well, that's _very_ nice to read :) Thanks to everyone involved. I've
noticed that almost every time something gets um, "difficult" it's
either misunderstanding, qui
I think at this point all my concerns have been addressed via off-list email.
I'll discuss refactoring options with Miguel over the next few days in
another thread.
Thanks folks!
Adam Wolf
Wayne and Layne, LLC
On Sun, May 5, 2013 at 10:54 AM, Adam Wolf
wrote:
> Hi Dick,
>
> I'm not concerned a
On Sun, May 05, 2013 at 10:54:17AM -0500, Adam Wolf wrote:
> Launchpad in order to report the possible bug. The usual response is
> "I'd rather not. I don't really want to get yelled at."
That's strange... if you follow the user mailing list they seem
sufficiently satisfied about bug response..
Hi Dick,
I'm not concerned about my patch at this point. I'm concerned about
the level of respect on the Kicad-devs mailing list. Regardless of
the merits of my patch, after I spend a bunch of time volunteering, I
should be treated with respect, right?
When people report Kicad bugs to me, think
On Sun, May 05, 2013 at 10:09:59AM -0500, Dick Hollenbeck wrote:
> *) how many functions, say member functions, are there that operate on a
> BOARD, that need
> Clearly this is a small problem space. However, the size is somewhat
> unknown, in as much
> as we don't know what will really be need
On 05/03/2013 04:23 PM, Adam Wolf wrote:
> Hi Dick,
>
> I appreciate the 1187 commits. If I didn't, I would have simply
> created another PPA and maintained a testing branch, selling this
> functionality to board houses.
>
> Can you tell me (privately if need be) how much Wayne and Layne would
>
BOARD_ACTIONS:
was/is a potential solution to a relatively small problem space, whose size is
given by
the answer to the following question:
*) how many functions, say member functions, are there that operate on a BOARD,
that need
no GUI, and must be used by both the frame and by top level pyth
On Sat, May 04, 2013 at 03:27:41PM -0400, Wayne Stambaugh wrote:
> The advantage of the proxy object is that the bloat and/or coupling
> is contained within the object which tends to make it more visible.
Possibly. Never had the issue in the first time so I don't really know.
Most of the programmi
On 05/03/2013 05:02 PM, Adam Wolf wrote:
> Thanks.
>
> My company has a little money and a little time to help out a Free and
> Open Source ECAD tool. So far, we've chosen Kicad. We spend time
> every week doing things like maintaining build servers (time *and*
> money), working on the Mac packa
On 5/4/2013 12:57 PM, Lorenzo Marcantonio wrote:
On Sat, May 04, 2013 at 12:22:55PM -0400, Wayne Stambaugh wrote:
gate keeping object to prevent coupling. We will never be able to
factor out the board (or schematic) code into a dso/dll until we
start being disciplined enough to prevent this kin
A note: swig can be teached to capture C++ exceptions and convert back to
python , try:
grep try *.i
Enviado desde un móvil
El 04/05/2013, a las 18:57, Lorenzo Marcantonio
escribió:
> On Sat, May 04, 2013 at 12:22:55PM -0400, Wayne Stambaugh wrote:
>> gate keeping object to prevent couplin
On Sat, May 04, 2013 at 12:22:55PM -0400, Wayne Stambaugh wrote:
> gate keeping object to prevent coupling. We will never be able to
> factor out the board (or schematic) code into a dso/dll until we
> start being disciplined enough to prevent this kind of coupling. I
> think this really gets to
On 5/3/2013 5:04 PM, Lorenzo Marcantonio wrote:
On Fri, May 03, 2013 at 02:45:01PM -0500, Dick Hollenbeck wrote:
If they are not in one class, this makes the mix-in tougher back up at the
PCB_BASE_FRAME.
You end up with 2,3,4 classes, each holding a BOARD*, and each being mixed in
via multiple
Thanks.
My company has a little money and a little time to help out a Free and
Open Source ECAD tool. So far, we've chosen Kicad. We spend time
every week doing things like maintaining build servers (time *and*
money), working on the Mac packaging scripts, answering people's
questions about the
I haven't even had time to read what Lorenzo is thinking yet. And as I said, I
would not
do anything this big without talking to the key share holders, excuse me, lead
developers,
JP and Wayne.
So at some point, providing I can catch up in time to satisfy you, by me
executing those
steps, that
Hi Dick,
I appreciate the 1187 commits. If I didn't, I would have simply
created another PPA and maintained a testing branch, selling this
functionality to board houses.
Can you tell me (privately if need be) how much Wayne and Layne would
have to pay to have you implement enough of your desired
On 05/03/2013 03:07 PM, Adam Wolf wrote:
> Hi folks,
>
> Can I selfishly suggest something?
>
> Since Dick has a plan for where this goes and how the future interface
> works, can we do the minor changes in my patch so that folks that
> choose to use the experimental Python features can get to th
On Fri, May 03, 2013 at 02:45:01PM -0500, Dick Hollenbeck wrote:
> If they are not in one class, this makes the mix-in tougher back up at the
> PCB_BASE_FRAME.
> You end up with 2,3,4 classes, each holding a BOARD*, and each being mixed in
> via multiple
> inheritance? Instead of one class.
I a
Hi folks,
Can I selfishly suggest something?
Since Dick has a plan for where this goes and how the future interface
works, can we do the minor changes in my patch so that folks that
choose to use the experimental Python features can get to the drill
calls?
I tried to propose a solution to create
On 05/03/2013 02:23 PM, Lorenzo Marcantonio wrote:
> On Fri, May 03, 2013 at 02:02:01PM -0500, Dick Hollenbeck wrote:
>> What about what I think Lorenzo? Is that important to you in any way?
>
> I reread this:
> https://lists.launchpad.net/kicad-developers/msg07515.html
> (is this what you were t
On Fri, May 03, 2013 at 02:02:01PM -0500, Dick Hollenbeck wrote:
> What about what I think Lorenzo? Is that important to you in any way?
> > I think that separating 'just because they should be separated' in many
> > case is too extreme.
^^ Maybe you were referring to this?
I think that *if* th
On Fri, May 03, 2013 at 02:02:01PM -0500, Dick Hollenbeck wrote:
> What about what I think Lorenzo? Is that important to you in any way?
I reread this:
https://lists.launchpad.net/kicad-developers/msg07515.html
(is this what you were talking about, right?)
Quote your message:
> We also talked a
On 05/03/2013 01:56 PM, Lorenzo Marcantonio wrote:
> On Fri, May 03, 2013 at 01:38:58PM -0500, Adam Wolf wrote:
>> Lorenzo,
>>
>> I've already done the SWIG magic to hook up FILE * to Python file like
>> objects. It was about 5 lines in the SWIG files. It works, today,
>> using my patch and drill
On Fri, May 03, 2013 at 01:38:58PM -0500, Adam Wolf wrote:
> Lorenzo,
>
> I've already done the SWIG magic to hook up FILE * to Python file like
> objects. It was about 5 lines in the SWIG files. It works, today,
> using my patch and drill.py. This did not involve mmap, or rewriting
> anything
On Fri, May 03, 2013 at 10:40:43AM -0500, Adam Wolf wrote:
> I need to finish my Maker Faire demo, but expect a full test suite for
This maker faire stuff seems fun. I am (somewhat) busy for finishing
a couple product for Autopromotec, but that's a more conventional
business fair:D
Also our clie
Lorenzo,
I've already done the SWIG magic to hook up FILE * to Python file like
objects. It was about 5 lines in the SWIG files. It works, today,
using my patch and drill.py. This did not involve mmap, or rewriting
anything to think of files as strings. I do not understand why you
think this w
On Fri, May 03, 2013 at 01:33:33PM -0500, Dick Hollenbeck wrote:
> Follow some of the links, then you have my thoughts, no reason they should
> have changed.
Yes, I remember that. I don't particularly like the 'forced' inheritance
but it should work, if needed.
However most probably this could
On 05/03/2013 10:27 AM, Adam Wolf wrote:
> Because there's logic in the dialog box.
Google this string please:
"BOARD_ACTIONS site:https://lists.launchpad.net/kicad-developers";
Follow some of the links, then you have my thoughts, no reason they should have
changed.
On Fri, May 03, 2013 at 05:31:48PM +0200, Miguel Angel Ajo wrote:
> I like your idea Adam, specially because you can change file for a stringio,
> and it could work..
>
> Lorenzo, what do you think?,
>
> do you like Adam refactor idea for the plot controller?
>
>I think it's impor
Lorenzo,
When I said file-like object, I was speaking in a Python context. In
Python, a file like object supports seek() and other things you do on
files. That's why I mentioned StringIO--it's a helper class to treat
strings like file-like objects. I believe this mitigates all your
complaints a
On Fri, May 03, 2013 at 10:27:12AM -0500, Adam Wolf wrote:
> Because the call that opens the file doesn't know anything about what layer
> you're on, there's no way for the PLOT CONTROLLER to honor your "Use Gerber
> Extension" option. Because there's logic in the dialog box, PLOT
That's by desig
Before I propose any refactoring on the drill or plot code, I'm
writing tests for the current drill or plot code. I'll lose all
goodwill from the Kicad team if I end up breaking someone's gerbers...
I need to finish my Maker Faire demo, but expect a full test suite for
the drill and plot code nea
I like your idea Adam, specially because you can change file for a stringio,
and it could work..
Lorenzo, what do you think?,
do you like Adam refactor idea for the plot controller?
I think it's important that we have similar interfaces at both sides, and
also that we have a drill
I agree that the plot and drill generation could have a similar API.
However, if I'm going to put time into the Kicad C++ half, I want to
improve PLOT CONTROLLER.
Because the call that opens the file doesn't know anything about what layer
you're on, there's no way for the PLOT CONTROLLER to honor
On Fri, May 03, 2013 at 10:55:16AM +0200, Miguel Angel Ajo wrote:
> And , that the new drill code should have something equivalent, so our
> interfaces
> were uniform somehow :-)
Implicit meaning detected: "would be good if 'someone' wrote the drill
controller" :D :D :D
In queue, but don't be in
Lorenzo, don't get me wrong by my bad english, I was in fact saying thanks
to your abstraction :)
And , that the new drill code should have something equivalent, so our
interfaces
were uniform somehow :-)
Yes, that drill controller could serve for scripting, but later, when finished,
to
refac
On Fri, May 03, 2013 at 10:07:02AM +0200, Miguel Angel Ajo wrote:
> Hi Adam,
>
>I'm rereading your work, and It's something we all love to have, but, I
> have a concern:
>
> Plot controller, works in some way (thanks to lorenzo abstraction)
> different to the drill.
As I said it's a *p
Hi Adam,
I'm rereading your work, and It's something we all love to have, but, I have
a concern:
Plot controller, works in some way (thanks to lorenzo abstraction)
different to the drill.
With the plot controller you just open a plot controller, tell it the
format and filename, etc
Hi Dick,
Thanks. Let me know if there's anything I can do to help get this or
similar functionality built-in. Wayne and Layne volunteers to do any
desired refactoring to drill/plotting in order to reduce logic in the
dialogs and create a solid and small API. If this is something you want,
pleas
On 05/01/2013 09:39 AM, Adam Wolf wrote:
> Hi folks,
>
> One of the tasks I've been doing for Wayne and Layne for Kicad is
> command line plot and drill generation. Internally, we're going to
> use it to generate files upon commit to better track progress in the
> distributed team, but externally
On Thu, May 02, 2013 at 07:35:00AM -0500, Adam Wolf wrote:
> Hi Lorenzo,
>
> The print script uses plot controller--thanks for writing that! Right
If you're using the plot controller then it's being used as designed :D
As for the drill, the collection/sorting step is a little convoluted,
but it
Hi Lorenzo,
The print script uses plot controller--thanks for writing that! Right
now, it does basically only what it needs to do to support gerber
generation--there are no "per layer" settings.
There is about as much logic in the drill generation script as there
is in the plot script--that is t
On Thu, May 02, 2013 at 09:16:23AM +0200, Miguel Angel Ajo wrote:
> I haven't worked very much with the plotters & drillers, but may be Lorenzo
> could help us take a look at it before committing, he was working
> on the PLOT_CONTROLLER / python integration later (may be more, I'm
> unsure).
I'm
HI Adam, it looks good to me,
I haven't worked very much with the plotters & drillers, but may be Lorenzo
could help us take a look at it before committing, he was working
on the PLOT_CONTROLLER / python integration later (may be more, I'm
unsure).
I reader the diff and both .py's and they lo
Hi folks,
One of the tasks I've been doing for Wayne and Layne for Kicad is
command line plot and drill generation. Internally, we're going to
use it to generate files upon commit to better track progress in the
distributed team, but externally, we're working with a friend of ours
who runs a PCB
45 matches
Mail list logo
