On 09/05/2013 10:55 PM, Lorenzo Marcantonio wrote:
On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote:
You are correct about the model being somewhat exposed. But the model is
working nicely
everywhere else, and it is fast.
I could argue about the 'fast' thing. The indexed by
On Fri, Sep 06, 2013 at 08:53:12AM +0200, Maciej Sumiński wrote:
BTW: This is the way how it is done in the VIEW class in the GAL -
items are held using R-trees, which are created for every layer. It
was also necessary to know which layers are occupied by a single
item, so there is
On 09/06/2013 09:26 AM, Lorenzo Marcantonio wrote:
On Fri, Sep 06, 2013 at 08:53:12AM +0200, Maciej Sumiński wrote:
Other than being a technique listen even in '80 computer graphics books,
I suppose that's needed also for 1) culling the primitives using the
rtree and 2) sorting the draw
On 09/05/2013 03:55 PM, Lorenzo Marcantonio wrote:
On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote:
You are correct about the model being somewhat exposed. But the model is
working nicely
everywhere else, and it is fast.
I could argue about the 'fast' thing.
You have no
On Fri, Sep 06, 2013 at 06:46:16AM -0500, Dick Hollenbeck wrote:
Iteration and iteration only, was the topic of discussion with Tom. This was
a discussion
between Tom and me, only. Walking a linked list is a fast means of
iteration. I don't
know how hard that is to understand. A good
PS. about more than 64 layers - I attached an example flag set class. Of
course it's not as fast as a bare int/int64 (4 assembly instructions
instead of one/two), but it brings type safety and automatic
serialization (it's just a demo written in 20 minutes, not a quality code).
Tom,
On Thu, Sep 05, 2013 at 07:12:40AM -0500, Dick Hollenbeck wrote:
That looks excellent.
Yep, quite.
I was also thinking bit set. The fact that std::bitset takes a size
suggests it is
putting the bits in the instance block, not in a separate block of memory.
I think the issue is not the
On Thu, Sep 05, 2013 at 02:14:03PM -0500, Dick Hollenbeck wrote:
You are correct about the model being somewhat exposed. But the model is
working nicely
everywhere else, and it is fast.
I could argue about the 'fast' thing. The indexed by layer structure IMHO is
very promising (the bounding
On 09/05/2013 09:38 AM, Lorenzo Marcantonio wrote:
On Thu, Sep 05, 2013 at 07:12:40AM -0500, Dick Hollenbeck wrote:
That looks excellent.
Yep, quite.
I was also thinking bit set. The fact that std::bitset takes a size
suggests it is
putting the bits in the instance block, not in a
On Thu, Sep 05, 2013 at 11:02:36AM -0500, Dick Hollenbeck wrote:
Says you. Says me: having the the bits in the instance block matter.
I guess if what I have to say is going to be labelled as irrelevant right out
the box, I'd
be wasting my time continuing.
Strange that, said by someone
- Original Message -
From: Dick Hollenbeck d...@softplc.com
To: kicad-developers@lists.launchpad.net
Cc:
Sent: Friday, September 6, 2013 3:49 AM
Subject: Re: [Kicad-developers] Experiments and considerations for more
layer
On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote
On Thu, Sep 05, 2013 at 05:26:46PM -0700, Cirilo Bernardo wrote:
I think Tom's class is adequate. I don't think Brian S.'s idea about
dynamically
assignable layer slots is optimal. I think fixed layer slots are easier to
code, but I
don't see why you have to limit the number of slots
- Original Message -
From: Brian F. G. Bidulock bidul...@openss7.org
To: Kicad Developers kicad-developers@lists.launchpad.net
Cc:
Sent: Tuesday, September 3, 2013 12:55 PM
Subject: Re: [Kicad-developers] Experiments and considerations for more
layer
Lorenzo,
While
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Mon, Sep 02, 2013 at 08:55:31PM -0600, Brian F. G. Bidulock wrote:
that's another 26 (or more) layers. Still think 64 will be
enough?
I said it was a mid-term solution.
Mid-term in the wrong direction. Kicad is like that...
Cirilo,
On Mon, 02 Sep 2013, Cirilo Bernardo wrote:
Hi Brian,
It looks like an awful lot of work you've done there. Has any of
it made its way back into the main tree?
None. I hear you guys might have got internal units done after three
years.
I'm also interested in knowing the
On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote:
5000 module descriptions to extract the 5000 pieces of placement
data is the horror of kicad's internal representation.
There is a reason for components being copied and not instantiated.
Often you need to 'tweak' a
On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote:
a layer number is a copper layer or not. For things like holes, range
comparisons are done mostly and bitmasks are useless. For non-copper
I do not agree on that. Everything that's related to a pad need to be
masked. Unless
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote:
5000 module descriptions to extract the 5000 pieces of placement
data is the horror of kicad's internal representation.
There is a reason for components being
- Original Message -
From: Lorenzo Marcantonio l.marcanto...@logossrl.com
To: Kicad Developers kicad-developers@lists.launchpad.net
Cc:
Sent: Tuesday, September 3, 2013 8:26 PM
Subject: Re: [Kicad-developers] Experiments and considerations for more layer
On Tue, Sep 03, 2013
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
I do not agree on that. Everything that's related to a pad need to be
masked. Unless you add a list of layers, which is just another
(less efficient) representation for a bitmask. Or esplode the pad in
multiple instances to represent a
On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote:
Mid-term in the wrong direction. Kicad is like that...
Look. I have this board due to fabrication for the end of month.
I simply can't implement the whole object model in time *and* do the
board layout to produce it.
It's a
On Tue, Sep 03, 2013 at 03:35:16AM -0700, Cirilo Bernardo wrote:
That may be the case, but personally I would have preferred to treat that as
being a different component with its own footprint, even if it ultimately
refers to the same part number on the BoM. So many copies doesn't make much
On Tue, Sep 03, 2013 at 04:38:13AM -0600, Brian F. G. Bidulock wrote:
You don't need list of layers: just from and to--a pair.
How do you fit mask, silk and other technical layers in a range? I agree
that it would work for copped layers. But IMHO the 'right' solution
would be to have a pin
- Original Message -
From: Lorenzo Marcantonio l.marcanto...@logossrl.com
To: Kicad Developers kicad-developers@lists.launchpad.net
Cc:
Sent: Tuesday, September 3, 2013 8:51 PM
Subject: Re: [Kicad-developers] Experiments and considerations for more
layer
On Tue, Sep 03
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote:
Mid-term in the wrong direction. Kicad is like that...
Look. I have this board due to fabrication for the end of month.
I simply can't implement the whole object
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 04:38:13AM -0600, Brian F. G. Bidulock wrote:
You don't need list of layers: just from and to--a pair.
How do you fit mask, silk and other technical layers in a range? I agree
that it would work for copped
Cirilo,
On Tue, 03 Sep 2013, Cirilo Bernardo wrote:
A down side to keeping things manageable (such as merging components
into the PCB) would be that there has to be a mapping which KiCAD
enforces for the integer layer ID and the usage. That is certainly
possible and when implemented I
On Tue, Sep 03, 2013 at 04:15:39AM -0700, Cirilo Bernardo wrote:
A down side to keeping things manageable (such as merging components into the
PCB) would be that there has to be a mapping which KiCAD enforces for the
integer layer ID and the usage. That is certainly possible and when
On Tue, Sep 03, 2013 at 05:21:58AM -0600, Brian F. G. Bidulock wrote:
Want to generate a Gerber for copper layer 4? Just iterate. No
masking required.
Major column versus major row... you optimize one thing and slow down
the other. A design decision like any other. What if you want to know
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
See my other note. Just remember what layers things are on instead
of messing around with bitmasks. So, when you place pin 1, you place
it in the cells occupied by its shape and clearance, and place it (by
reference) in
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
See my other note. Just remember what layers things are on instead
of messing around with bitmasks. So, when you place pin 1, you place
it in the cells occupied
On 09/03/2013 02:24 PM, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 05:29:12AM -0600, Brian F. G. Bidulock wrote:
See my other note. Just remember what layers things are on instead
of messing around with bitmasks. So, when you place pin 1, you place
it in the cells occupied by its
On 09/03/2013 12:33 PM, Brian F. G. Bidulock wrote:
Lorenzo,
On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:
On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bidulock wrote:
5000 module descriptions to extract the 5000 pieces of placement
data is the horror of kicad's internal
On Tue, Sep 03, 2013 at 03:23:46PM +0200, Tomasz Wlostowski wrote:
BTW. Judging from Altium's ASCII file format, it also copies every
component - and it's a pretty decent PCB program...
Also: until 2009 it only had 16 mechanical layers, and even today that
you have 32 you have to be consistent
- Original Message -
From: Lorenzo Marcantonio l.marcanto...@logossrl.com
To: Kicad Developers kicad-developers@lists.launchpad.net
Cc:
Sent: Tuesday, September 3, 2013 10:09 PM
Subject: Re: [Kicad-developers] Experiments and considerations for more
layer
On Tue, Sep
At last I tried to broke the 32 layer barrier in pcbnew. Needed the
assembly and courtyard on both sides, so the ECO are not enough. Also
they need to be flippable, too.
Result: succesful, learnt things that could be useful later.
First, the huge LAYER_NUM/LAYER_MSK work I done previously was in
On Mon, Sep 02, 2013 at 10:30:47AM +0100, Brian Sidebotham wrote:
I could really do with more layers too. Although when I say *more* layers,
I mean that I could really do with dedicated assembly and courtyard layers.
Exactly what I have done... probably for your same reasons, too.
The
On Mon, 9/2/13, Brian Sidebotham brian.sidebot...@gmail.com wrote:
Subject: Re: [Kicad-developers] Experiments and considerations for more layer
To: Kicad Developers kicad-developers@lists.launchpad.net
Date: Monday, September 2, 2013, 5:30 PM
On Mon, Sep 02, 2013 at 03:45:23AM -0700, Cirilo Bernardo wrote:
Using IDF also gives us another method of specifying the board outline, but
to be honest the specification has severe defects; for example, arcs are not
correctly constrained so for any arc specified in IDF there are 4 different
On 2 September 2013 10:39, Lorenzo Marcantonio
l.marcanto...@logossrl.comwrote:
On Mon, Sep 02, 2013 at 10:30:47AM +0100, Brian Sidebotham wrote:
I could really do with more layers too. Although when I say *more*
layers,
I mean that I could really do with dedicated assembly and courtyard
On Mon, Sep 02, 2013 at 12:13:07PM +0100, Brian Sidebotham wrote:
Actually, I think I want to change my answer a bit. Because as I hinted, I
don't need more layers, I need better layer versatility. I want to be able
to rename layers (Already achievable!), but I also want to be able to
Well...
On Mon, Sep 02, 2013 at 08:55:31PM -0600, Brian F. G. Bidulock wrote:
that's another 26 (or more) layers. Still think 64 will be
enough?
I said it was a mid-term solution.
BTW, long long is part of the C standard and excluded from the C++
standard. Good luck with Windows (it doesn't
42 matches
Mail list logo
