>> Noobie alert <<
I have just installed from source geda-gaf-1.6.1 on Ubuntu Karmic (using
checkinstall). I am having a bit of difficulty getting auto-uref.scm to behave
as expected:
* When placing parts, refdes values start at 2 and go up by even numbers.
* The refdes for copy/pasted parts als
On Sep 5, 2010, at 6:29 PM, timecop wrote:
> On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote:
>> On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>>>
But when each parameter in the file has a name, than file size may
become really large, e.g. for files generated with
On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote:
> On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>>
>> > But when each parameter in the file has a name, than file size may
>> > become really large, e.g. for files generated with the topological
>> > router, with lot of arcs.
>>
On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>
> > But when each parameter in the file has a name, than file size may
> > become really large, e.g. for files generated with the topological
> > router, with lot of arcs.
>
> Compression. Either gzip the text file, or use an alternat
On Sun, Sep 5, 2010 at 2:19 PM, Peter Clifton <[1]pc...@cam.ac.uk>
wrote:
On Sun, 2010-09-05 at 00:18 +0200, Levente Kovacs wrote:
> On Sat, 4 Sep 2010 11:24:38 +
> Ineiev <[2]ine...@gmail.com> wrote:
>
> > Probably this patch may be used as a workaround.
>
> But when each parameter in the file has a name, than file size may
> become really large, e.g. for files generated with the topological
> router, with lot of arcs.
Compression. Either gzip the text file, or use an alternate binary
file (smaller *and* faster).
> > We are NOT going with another position-determines-meaning file format.
>
> Why?
Consider the parser for the PIN object:
Pin [rX rY Thickness Clearance Mask Drill "Name" "Number" SFlags]
Pin (rX rY Thickness Clearance Mask Drill "Name" "Number" NFlags)
Pin (aX aY Thickness Drill "Name" "Numbe
On Sat, Sep 04, 2010 at 12:17:15PM -0400, DJ Delorie wrote:
>
> > But suppose the user creates a rule like, "all traces on Layer 3 must
> > be at least 5mm apart", and then saves the file and reloads it. Now the
> > information about what traces are affected is lost, except that all the
> > traces
Peter Clifton wrote:
> What is useful is that the "outline" / "route" titled layers don't
> get pads flashed on them when exporting gerbers. All other (copper)
> layers get the pads on them, which would be a problem for an
> outline plot.
Apparently not for my preferred fab. When asked, they tol
On Sat, 2010-09-04 at 22:56 +0200, Pawel Kusmierski wrote:
> On Sat, Sep 4, 2010 at 1:11 PM, Peter Clifton wrote:
> > As a kludge, call your layer by one of the magic names "outline" or
> > "route" and it will be ignored by the DRC, and treated as non-copper.
> >
>
> Peter, thanks for the tip.
>
On Sun, 2010-09-05 at 00:18 +0200, Levente Kovacs wrote:
> On Sat, 4 Sep 2010 11:24:38 +
> Ineiev wrote:
>
> > Probably this patch may be used as a workaround.
>
> Why don't we just push this patch to HEAD? This works just great.
One minor nit..
I'd keep the "non-copper" / "skip-drc" ideas
On Sun, Sep 05, 2010 at 10:01:47PM +0200, Stefan Salewski wrote:
>
> But when each parameter in the file has a name, than file size may
> become really large, e.g. for files generated with the topological
> router, with lot of arcs.
>
If every parameter had a name like 'x', 'y', 'w', 'h', 'r', it
On Sun, 2010-09-05 at 21:56 +0200, kai-martin knaak wrote:
> Stefan Salewski wrote:
>
> > One disadvantage of that format may be:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers -- hand editing such lines may be difficult. Not a problem for
> > me, I do not intend
Stefan Salewski wrote:
> One disadvantage of that format may be:
> We have lines starting with a letter followed by up to 16 decimal
> numbers -- hand editing such lines may be difficult. Not a problem for
> me, I do not intend hand editing.
More precisely: Positional parameters are bad.
Mapping
On Sun, Sep 05, 2010 at 07:22:14PM +0200, Stefan Salewski wrote:
> On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > > We have lines starting with a letter followed by up to 16 decimal
> > > numbers
> >
> > We are NOT going with another position-determines-meaning file format.
> >
> >
>
On Sun, Sep 5, 2010 at 6:42 AM, Ineiev wrote:
> On 9/4/10, DJ Delorie wrote:
>>> Ineiev, thanks for the patch, it applied fine. However, I'm unable to find
>>> the
>>> (Edit->Edit attributes of->Current Layer). Is it placed somewhere else,
>>> or can I manually edit the .pcb file for the same res
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers
>
> We are NOT going with another position-determines-meaning file format.
>
>
Why?
Is manually editing the only reason?
I guess data in most files on our comp
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers
>
> We are NOT going with another position-determines-meaning file format.
May I suggest that while deciding on a file format and choosing how it
will work it wou
On Sat, Sep 04, 2010 at 07:49:06PM -0700, Steven Michalske wrote:
>
> This is why I use yaml to store data. It was designed to be human
> readable. It holds most high level data structures. And is very
> low bloat. You can tag the yam code to say that this is a particular
> data structure, like
> We have lines starting with a letter followed by up to 16 decimal
> numbers
We are NOT going with another position-determines-meaning file format.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-
Stefan Salewski writes:
> On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote:
>> All of this discussion of formats misses the shining example that's
>> already in gEDA: the schematic format.
>
> Yes. Recently I begun studying that format and started writing a parser
> in Ruby -- really easy.
>
>
On Sun, Sep 05, 2010 at 05:47:12PM +0200, Stefan Salewski wrote:
>
> One disadvantage of that format may be:
> We have lines starting with a letter followed by up to 16 decimal
> numbers -- hand editing such lines may be difficult. Not a problem for
> me, I do not intend hand editing.
>
Sounds li
Hi Bob,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Bob Paddock
> Sent: Sunday, September 05, 2010 1:24 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Functional blocks and PCB format changes
>
> I
On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote:
> All of this discussion of formats misses the shining example that's
> already in gEDA: the schematic format.
Yes. Recently I begun studying that format and started writing a parser
in Ruby -- really easy.
One disadvantage of that format may be
All of this discussion of formats misses the shining example that's already in
gEDA: the schematic format. Now *there's* a work of genius.
1. The format is based on a small, well-chosen set of elementary objects.
2. Elementary objects are represented by one-line tagged records of fixed
format (
Hi,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Ethan Swint
> Sent: Sunday, September 05, 2010 4:06 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: PCB format wishlist
>
> On 09/04/2010 10:19 PM, Andrew
On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
I have one more suggestion: the facility to create recursive PCBs.
What this will look like in the file format, I dunno. But we should
keep it in mind.
Recursive PCBs could work the same way as the footprint re-use: a node
could contain a refere
On 09/04/2010 10:04 PM, Andrew Poelstra wrote:
3) Connectivity information: include the connection information
between line segments, similar to (but not necessarily exactly!) SVG
format, where multiple points and arcs can be included in one line.
I'm not sure what you're getting at here.
IMHO, the "problem" with XML lies not in the bloat, even a factor
10 larger
would be acceptable, it's the <$TAGS> that have to be identical
across all
applications to have a "truly" exchangeable XML file.
[1]http://www.ibm.com/developerworks/xml/ XML can be easy or har
Hi,
There happens to be a newer version (1998) of the IDF specification:
http://www.simplifiedsolutionsinc.com/images/idf_v40_spec.pdf
Kind regards,
Bert Timmerman
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of B
Hi Rick,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins
> Sent: Sunday, September 05, 2010 12:38 AM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Functional blocks and PCB format changes
>
> At
On 9/4/10, Windell H. Oskay wrote:
>>
>> On Sep 4, 2010, at 4:30 AM, Ineiev wrote:
>>
>>> Hello, DJ;
>>>
>>> On 9/4/10, DJ Delorie wrote:
Our DRC engine could use a complete rewrite. It doesn't get arcs
right, for example.
>>>
>>> Could you elaborate on the arcs, please? what it doesn'
32 matches
Mail list logo
