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 goo
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
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 op
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 ViewGetL
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 la
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
- Original Message -
> From: Dick Hollenbeck
> 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 M
On 09/03/2013 08:08 AM, Tomasz Wlostowski wrote:
> 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 p
On 09/05/2013 12:03 PM, Lorenzo Marcantonio wrote:
> 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
>>
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 so
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,
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 boundin
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 th
> 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,
- Original Message -
> From: Lorenzo Marcantonio
> To: Kicad Developers
> Cc:
> Sent: Tuesday, September 3, 2013 10:09 PM
> Subject: Re: [Kicad-developers] Experiments and considerations for more
> layer
>
> On Tue, Sep 03, 2013 at 04:15:39AM -070
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
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 representa
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 shape
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 oc
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
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 a
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
> imp
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 sus
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 copp
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 o
- Original Message -
> From: Lorenzo Marcantonio
> To: Kicad Developers
> Cc:
> Sent: Tuesday, September 3, 2013 8:51 PM
> Subject: Re: [Kicad-developers] Experiments and considerations for more
> layer
>
> On Tue, Sep 03, 2013 at 03:41:26AM -0600, Br
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 objec
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 muc
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
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 represen
- Original Message -
> From: Lorenzo Marcantonio
> To: Kicad Developers
> Cc:
> Sent: Tuesday, September 3, 2013 8:26 PM
> Subject: Re: [Kicad-developers] Experiments and considerations for more layer
>
> On Tue, Sep 03, 2013 at 04:21:59AM -0600, Brian F. G. Bid
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 be
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. Unles
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 compone
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 e
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 tha
- Original Message -
> From: Brian F. G. Bidulock
> To: Kicad Developers
> Cc:
> Sent: Tuesday, September 3, 2013 12:55 PM
> Subject: Re: [Kicad-developers] Experiments and considerations for more
> layer
>
> Lorenzo,
>
> While your thinking abo
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 sup
Lorenzo,
While your thinking about additional layers, consider the other
layers discussed here:
http://www.openss7.org/docs/NOTES.pdf
namely,
dielectric layers
resistance layers
plating layers
hole filling layers
keep-out layers
via pluggi
On Mon, Sep 02, 2013 at 08:53:45PM +0200, jp charras wrote:
> After reading mails about layers, I am happy you have *actually* the
> same opinion as Dick about the fact non copper layer names cannot be
> changed:
I agree in avoiding renaming tech layers which have a special function
(like mask and
Le 02/09/2013 13:47, Lorenzo Marcantonio a écrit :
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 ach
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 2 September 2013 10:39, Lorenzo Marcantonio
wrote:
> 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
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 differe
On Mon, 9/2/13, Brian Sidebotham wrote:
Subject: Re: [Kicad-developers] Experiments and considerations for more layer
To: "Kicad Developers"
Date: Monday, September 2, 2013, 5:30 PM
On 2 September 2013 10:02,
Lorenzo Marcantonio
wr
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 asse
On 2 September 2013 10:02, Lorenzo Marcantonio
wrote:
> 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.
>
>
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
48 matches
Mail list logo
