On Mon, Jun 09, 2014 at 04:25:48PM -0500, Dick Hollenbeck wrote:
> That is attached, the #else now uses a *macro* LMSK() and I'm sure only
> results in one
> call to the static construction logic.
I fear that getting it to take an uint64_t would create an ambiguity,
since ATM LAYER_NUM is an enum
On Mon, Jun 09, 2014 at 03:50:57PM -0500, Dick Hollenbeck wrote:
> IOW, the compiler cannot pre-process even *inline functions* when they are
> part of a
> static constructor. It can however handle macros.
The static constructors are run only one time before main. I really don't
care if they are
On Mon, Jun 09, 2014 at 03:42:23PM -0500, Dick Hollenbeck wrote:
> You could also create a new constructor that actually takes an int64_t
> bitmap, and use
For the builtin layers could work, however in general there could be
more than 64.
> GetLayerMask() to build it.
>
> However I would rename
On 07/giu/2014, at 22:46, Jean-Paul Louis wrote:
Mac Keyboard has both HOME and END, you were probably referring to
compact/notebook one that requires the fn key.
Apple doesn’t hates no “button", just optimize the keyboard for common use and
documents how to use them.
I can assure as PC noteb
On 07/giu/2014, at 13:11, Nick Østergaard wrote:
Nick,
OSX has not menus icons by design, good hint.
wx-widgets ignores them too.
> Hello
>
> I am no an OSX user, but I know that OSX generally don't use these
> menu icons. It is also described in [1], see the section "Using Icons
> in Menus".
a revision of last one, prints in hex, simplifies.
something to play with.
#include
#include
//#define __STDC_FORMAT_MACROS
#include
#include
#include
enum LAYER_NUM
{
LAYER_CU_FRONT,
LAYER_CU_BACK,
};
#define LMSK( x ) (1ULL << (x))
#if 0
typedef std::bitset<64> LAYER_
On 06/09/2014 03:50 PM, Dick Hollenbeck wrote:
> On 06/09/2014 03:42 PM, Dick Hollenbeck wrote:
>>
>> Attached are two that work using the "set()" function.
>>
>>
>> As a third choice:
>>
>> You could also create a new constructor that actually takes an int64_t
>> bitmap, and use
>>
>> GetLayerMas
Attached are two that work using the "set()" function.
As a third choice:
You could also create a new constructor that actually takes an int64_t bitmap,
and use
GetLayerMask() to build it.
However I would rename GetLayerMask() to something more concise:
const LAYER_SET LAYER_SET::IMPORTANT
On 06/09/2014 03:42 PM, Dick Hollenbeck wrote:
>
> Attached are two that work using the "set()" function.
>
>
> As a third choice:
>
> You could also create a new constructor that actually takes an int64_t
> bitmap, and use
>
> GetLayerMask() to build it.
>
> However I would rename GetLayerM
On 6/9/2014 2:01 PM, jp charras wrote:
> Le 09/06/2014 19:23, Lorenzo Marcantonio a écrit :
>> On Mon, Jun 09, 2014 at 06:56:25PM +0200, jp charras wrote:
>>> For guys who are interested by theses extensions (I am thinking a change
>>> in Gerber Format should have a major interest for everybody), s
I just did a bit more digging and realized that you are correct. It is a
bug in xorg/gfx drivers. Darn!
I'll donate the $50 to the CERN group anyhow!
Thanks!
On Jun 9, 2014 12:18 PM, "Lorenzo Marcantonio"
wrote:
> On Mon, Jun 09, 2014 at 12:03:29PM -0400, Jon Neal wrote:
> > Anyone else want to
On Mon, Jun 09, 2014 at 08:01:47PM +0200, jp charras wrote:
> Gerber X2 fixes a *major issue*: the stack order.
> Therefore IMHO, accepting X2 gerbers is not a matter of years.
The stack order issue was solved from the start with stackup drawings.
However having a standard and internal labelling i
Le 09/06/2014 19:23, Lorenzo Marcantonio a écrit :
> On Mon, Jun 09, 2014 at 06:56:25PM +0200, jp charras wrote:
>> For guys who are interested by theses extensions (I am thinking a change
>> in Gerber Format should have a major interest for everybody), see:
>
> The extension in themselves are qui
On Mon, Jun 09, 2014 at 06:56:25PM +0200, jp charras wrote:
> For guys who are interested by theses extensions (I am thinking a change
> in Gerber Format should have a major interest for everybody), see:
The extension in themselves are quite interesting. If only to say 'this
is the top layer' insi
I just received a mail from Karel Tavernier (Managing Director at
Ucamco, the company which manages the Gerber format) about latest
changes in Gerber format (Gerber X2 format).
Using extensions (at least the "FileFunction" attribute, which defines
the purpose of each Gerber file, but some other at
I'm trying to rework the LAYER_MSK in a more flexible container,
whatever the decision about the structure will be. The idea is to remove
all the mask constants and only use the layer indices, together with
appropriate operator definition.
That part more or less works (using a bitset but that's no
On Mon, Jun 09, 2014 at 12:03:29PM -0400, Jon Neal wrote:
> Anyone else want to try and help with this? I would really like to see this
> get fixed!
Good luck with that... probably it's due to a bad driver interaction
with the way wx uses gtk (dummy example: calls from wx makes gtk flush
the pipel
On Mon, Jun 09, 2014 at 11:10:52AM -0500, Dick Hollenbeck wrote:
> We're in complete agreement then, let's switch to Cobol.
Sorry, that would be enough only if kicad did stock reports :D
(atleast probably the builtin reports would come out neatly formatted,
since wx still doesn't handle correctly
We're in complete agreement then, let's switch to Cobol.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launch
Anyone else want to try and help with this? I would really like to see this
get fixed!
Thank you,
Jon
On Jun 6, 2014 11:21 AM, "Jon Neal" wrote:
> Ian,
>
> I didn't want to try to use that as the solution since that makes
> everything in the OS use software rendering. Was really hoping for a bet
On Mon, Jun 09, 2014 at 08:55:57AM -0500, Dick Hollenbeck wrote:
> On that good day the switch() code generater will use a jump table with
> machine code which
> could also come from this type of construct:
>
> (*jump_table[switch_enum - switch_lowest_value])()
On other *very* good days the comp
On 06/06/2014 03:22 PM, Lorenzo Marcantonio wrote:
> On Fri, Jun 06, 2014 at 08:30:59PM +0200, Tomasz Wlostowski wrote:
>
>> Either use only C++ RTTI or a type ID field. Mixing both is ugly.
>
> Or better yet trust your interfaces:P if you need to know the kind of
> object you have, then there is
22 matches
Mail list logo