Re: gEDA-user: cvs.gedasymbols.org and gschem
Peter:
k...@aspodata.se (Karl Hammar) writes:
[about code that enables recursion in component-library-search]
Nack, for a number of reasons.
*
1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are
targetting GLib 2.12 or later.
Regular expression is actually overkill for this. It would suffice to
check (is it required that .sym is lowercase?) if the last 4 chars
is .sym or not for the files tested.
Corrected in attached recursive.diff.
*
2) This is an absolutely *textbook* example of the sort of thing that's
more cleanly done using Scheme (Guile has all of the necessary
functionality in the standard library).
a, Can you provide some pointers to which scheme functions to use?
Is there something like find path -name \*.sym ?
If I still have to use opendir et al., I don't see the gain of doing
the c to scheme conversion.
b, One could possible initialize the gafrc with a shell script.
It would be a static configuration which would be awkward to update.
Maybe someone finds it helpful.
See attached gedasymbols.sh.
*
3) I strongly recommend *not* using component-library-search because it
gives you no control over the precedence ordering of libraries when
searching for a symbol name match --
What do you mean by precedence ordering of libraries?
a, Is it the ordering in the library browser?
There is 71 duplicate and 6 triplicate symbols names in the cvs.
One of the triplicate is triac-1.sym, and searching for triac in
the browser gives me five alternatives:
dj_delorie/symbols/nvsemis
triac-1.sym
dj_delorie/symbols
triac-1.sym
levente_kovacs/symbols
triac-1.sym
werner_hoch/symbols/sf
triac-2.sym
Basic devices
triac-1.sym
Why should I ever care in what order thoose five are displayed?
b, or do you mean ..., if I have the file:
v 20110116 2
C 4 4 0 0 0 title-B.sym
C 53500 46700 1 0 0 triac-1.sym
{
T 54600 47500 5 10 1 1 0 0 1
refdes=TR?
T 53500 46700 5 10 0 1 0 0 1
footprint=TO220
}
how does gschem find the sym file?
Well, that has actually nothing to do with ...-search.
In gaf/docs/wiki/geda-file_format_spec.html, under component,
it calls the last field of the C line for basename.
Using the basename of a file to find it opens up for ambiguity.
Consider a schematic containg components a.sym and b.sym,
and two libraries with
path1/ a.sym b.sym
path2/ a.sym b.sym
and suppose we want path1/a.sym and path2/b.sym.
This cannot ever be handled with a precedence ordering of libraries
unless you can specify precedence for each and every component.
But then you could just as well allow some part of the path or entry
name to the field basename.
*
you're entirely at the mercy of the
order in which the filesystem decides to give the directories to
you. Even when that happens to be in alphabetical order, it's rarely
what you actually want.
a, To add a sorter should not be a big deal.
An experimental one is attached (includes the recursive ...-search)
in component-library-sort.diff
Using the diff, and (component-library-sort asc) added to my gafrc
I get the browser listing sorted :)
b, And BTW, entries are listed in the reverse order in the library
browser compared to how they are listed in the gafrc file with
component-library. That is rarely what I actually want:)
In libgeda/src/s_slib.c, lines 846-876:
const CLibSource *s_clib_add_directory (const gchar *directory,
const gchar *name)
{
...
/* Sources added later get scanned earlier */
clib_sources = g_list_prepend (clib_sources, source);
...
}
why do we use _prepend instead of _append here, there should not be
any performance problems with _append here ?
*
Having it implemented in C as a core part of
libgeda functionality seems to me to send the incorrect message that
using it is a good idea.
I don't understand the reasoning in this. Regardless if ...-search or
something like it is implemented in c or scheme, I think it is a good
idea to use it, why shouldn't it.
Compare maintaining one line of
(component-library-search-recursive root_directory prefix)
to 109 lines of
(component-library
/var/home/karl/Net/cvs/cvs.gedasymbols.org/www/user/wojtek_zabolotny/symbols
cvs/wojtek_zabolotny/symbols)
(component-library
/var/home/karl/Net/cvs/cvs.gedasymbols.org/www/user/werner_hoch/symbols/sf
cvs/werner_hoch/symbols/sf)
...
(component-library
/var/home/karl/Net/cvs/cvs.gedasymbols.org/www/user/ales_hvezda/symbols
cvs/ales_hvezda/symbols)
in your gafrc file.
My idea is to have the whole of cvs.gedasymbols.org's sym files
accessible via the library browser.
In what way is that not a good idea ?
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
diff --git a/libgeda/include/libgeda/prototype.h
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Tue, 24 May 2011 01:34:04 -0400 DJ Delorie d...@delorie.com wrote: but I avoid name conflicts in project libraries. If we find ourselves gaining popularity and a plethora of libraries comes into being, we may no longer have the luxury of avoiding name conflict. name scoping came up a few times in the library discussion, I think keeping the issue in mind, even at time, is important. It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Of course, there would be backward-compatibility for symbols without a UUID attribute, but if a schematic made use of a symbol with a UUID, then the schematic is future-proofed against any future name collisions for that symbol. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Do you mean a UUID for a symbol template in a library, or a UUID for a specific instance of a symbol in a schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On May 24, 2011, at 2:34 PM, DJ Delorie wrote: but I avoid name conflicts in project libraries. If we find ourselves gaining popularity and a plethora of libraries comes into being, we may no longer have the luxury of avoiding name conflict. name scoping came up a few times in the library discussion, I think keeping the issue in mind, even at time, is important. I agree. I was objecting to the notion that we should kill an existing function that works well in simple cases just because it could have problems in more complex cases. gEDA has a huge dynamic range in application scale, so there are going to be things that work well in some contexts but not in others. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Tue, 24 May 2011 07:57:28 -0400 DJ Delorie d...@delorie.com wrote: It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Do you mean a UUID for a symbol template in a library, or a UUID for a specific instance of a symbol in a schematic? My initial thought was for an abstract symbol (i.e., a .sym file). This way Diode.sym from my personal library is treated as a unique symbol from Diode.sym from another library. But now that you mention it, a UUID for a symbol instance in a schematic is important too, particularly when slots come into play. Proper design of the slotting system would fix the footprint for a slotted symbol is taken only from the first instance with that refdes problem... Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
k...@aspodata.se (Karl Hammar) writes: The code that executes the ...-search command is in libgeda/src/g_rc.c (relative the top of the git repo.), in the function: SCM g_rc_component_library_search(SCM path); I have changed that function to a wrapper around int C_g_rc_component_library_search(gchar *string, gchar *name, GRegex *regex); which can be more easily called recursively within c. That function contains the main body of the former function. Its added parameters are name and regex. regex is simply a precompiled regular expression matching file names ending in .sym (since we don't want to have entries that doesn't contain any symbol files). Name's function is described below under the code snippet. Nack, for a number of reasons. 1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are targetting GLib 2.12 or later. 2) This is an absolutely *textbook* example of the sort of thing that's more cleanly done using Scheme (Guile has all of the necessary functionality in the standard library). 3) I strongly recommend *not* using component-library-search because it gives you no control over the precedence ordering of libraries when searching for a symbol name match -- you're entirely at the mercy of the order in which the filesystem decides to give the directories to you. Even when that happens to be in alphabetical order, it's rarely what you actually want. Having it implemented in C as a core part of libgeda functionality seems to me to send the incorrect message that using it is a good idea. I've been thinking of nuking g_rc_component_library_search() and reimplementing it as a Scheme extension, and I would gladly accept a patch that does this. Regards, Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
Peter: k...@aspodata.se (Karl Hammar) writes: [about code that enables recursion in component-library-search] Nack, for a number of reasons. 1) GRegex was introduced in GLib 2.14, and during the 1.7.x cycle we are targetting GLib 2.12 or later. 2) This is an absolutely *textbook* example of the sort of thing that's more cleanly done using Scheme (Guile has all of the necessary functionality in the standard library). 3) I strongly recommend *not* using component-library-search because it gives you no control over the precedence ordering of libraries when searching for a symbol name match -- you're entirely at the mercy of the order in which the filesystem decides to give the directories to you. Even when that happens to be in alphabetical order, it's rarely what you actually want. Having it implemented in C as a core part of libgeda functionality seems to me to send the incorrect message that using it is a good idea. I've been thinking of nuking g_rc_component_library_search() and reimplementing it as a Scheme extension, and I would gladly accept a patch that does this. Ok. I'm not fluent in scheme and I'm rather busy this week. Perhaps someone else will beat me to it. /// Now, I did this as a test case of what can be done a relatively little effort and in the same time somehow integrate gedasymbols with gschem. Do you have any comment on the functionality which the screen dump hints you at? Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Mon, 23 May 2011 17:13:01 +0200 (CEST)
k...@aspodata.se (Karl Hammar) wrote:
There are a lot of symbols available at cvs.gedasymbols.org.
To make them all available to gschem I have added:
(component-library-search
${HOME}/Net/cvs/cvs.gedasymbols.org/www/user)
to my ~/.gEDA/gafrc, and changed component-library-search to descend
into subdirectories (see diff).
The result is as seen in attachment (dump.jpg).
Very nice!
However, for this to be usable wouldn't it be important to have a good
way to import the symbol into the project, either (1) storing the symbol
file in the same directory as the schematic, or (2) embedding the symbol
in the schematic?
(Otherwise your schematic will be broken if you copy it to another
machine, share it with others, restore it from a backup after hard
drive crash, or maybe the user on gedasymbols deletes it and it no
longer exists in your cvs checkout? Or worse, maybe the owner of the
symbol on gedasymbols makes an incompatible modification to the symbol
and doesn't bump the symversion... you might have big problems that you
don't catch until your board is assembled...)
Regards,
Colin
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Mon, 23 May 2011 17:13:01 +0200 (CEST) k...@aspodata.se (Karl Hammar) wrote: The result is as seen in attachment (dump.jpg). Very nice! Thank you. However, for this to be usable wouldn't it be important to have a good I think it usable as is (though not finished). way to import the symbol into the project, either (1) storing the symbol file in the same directory as the schematic (2) embedding the symbol in the schematic? In the library browser you have the choise to embed the component in the .sch file. I think that might be the solutions for your scenarios. (Otherwise your schematic will be broken if you copy it to another machine, share it with others, restore it from a backup after hard drive crash, or maybe the user on gedasymbols deletes it and it no longer exists in your cvs checkout? Or worse, maybe the owner of the symbol on gedasymbols makes an incompatible modification to the symbol and doesn't bump the symversion... you might have big problems that you don't catch until your board is assembled...) Yes, there are a lot of things that can happen, you might even delete your own file by mistake. But I consider that to be another set of problem than I did intend to solve. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Mon, 23 May 2011 22:18:54 +0200 (CEST) k...@aspodata.se (Karl Hammar) wrote: In the library browser you have the choise to embed the component in the .sch file. I think that might be the solutions for your scenarios. That would be a reasonable solution. I guess I've always overlooked that option. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Mon, 2011-05-23 at 13:31 -0700, Colin D Bennett wrote: On Mon, 23 May 2011 22:18:54 +0200 (CEST) k...@aspodata.se (Karl Hammar) wrote: In the library browser you have the choise to embed the component in the .sch file. I think that might be the solutions for your scenarios. That would be a reasonable solution. I guess I've always overlooked that option. I was thinking that when I next got some free time to do a bit of coding, I would take a break from the PCB+GL merge work and attack the long outstanding make symbol libraries writeable problem. Aims: Make back-ends which can support it allow writing to the library (if the library is configured to accept this).. e.g. local project library, or per-user library. Teach libgeda (and gschem etc..) to allow symbols to be backed by, and written to the symbol library APIs (like a VFS layer), rather than insist on an on-disk representation. Consider treating schematic embedded symbols as a special library source. (I'm not completely decided on this though). They should certainly be writeable of course, however we do it. Details might not be exposed in the symbol browser of course. I'm hoping that eventually back-ends could include such exciting things as fetch from and push to gedasymbols.org. I would like to see some options added to the symbol library dialogue: 1. Create a new (e.g. local) library 2. Copy an existing symbol to another (e.g. local) library 3. Create a completely new symbol (perhaps using a wizard interface) When editing symbols, the save options should be amongst: * Replace existing library symbol * Save with new name (optionally updating the instance, or instances on the schematic which was descended into from). * Update embedded symbol Sensible error handling for read-only (system installed) libraries might be to prompt the user for another location to save into - including the option to create a new local library for the purpose. Hopefully these extra features will solve some of the problems I have explaining simple footprint creation to new users ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On 05/23/2011 10:13 AM, Karl Hammar wrote: changed component-library-search to descend into subdirectories (see diff). The result is as seen in attachment (dump.jpg). Dang, that was quick Karl! John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On 05/23/2011 11:44 AM, Karl Hammar wrote: comment on the functionality which the screen dump hints you at? Like it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On May 24, 2011, at 12:29 AM, Peter Brett wrote: 3) I strongly recommend *not* using component-library-search because it gives you no control over the precedence ordering of libraries when searching for a symbol name match -- you're entirely at the mercy of the order in which the filesystem decides to give the directories to you. Even when that happens to be in alphabetical order, it's rarely what you actually want. Actually, I've been using it for years without any trouble. It seems that it's always what I want, but I avoid name conflicts in project libraries. I don't think removing useful functionality because it could theoretically produce confusion is a good thing. Having it implemented in C as a core part of libgeda functionality seems to me to send the incorrect message that using it is a good idea. I'm all for moving everything possible out of the core. The scripter doesn't want to be blocked by unnecessary barriers. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
I would like to see some options added to the symbol library dialogue: 1. Create a new (e.g. local) library 2. Copy an existing symbol to another (e.g. local) library 3. Create a completely new symbol (perhaps using a wizard interface) Incorporating DJboxsym (or similar) into the wizard would be nice. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On May 24, 2011, at 5:18 AM, Karl Hammar wrote: In the library browser you have the choise to embed the component in the .sch file. I think that might be the solutions for your scenarios. There are a couple of problems with embedded symbols: 1. You can't edit them. 2. Once embedded, they aren't instances of a common symbol any more. Common (heavy) symbols are useful as containers for common project-specific attributes. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
Colin D Bennett wrote: In the library browser you have the choise to embed the component in the .sch file. I think that might be the solutions for your scenarios. That would be a reasonable solution. I guess I've always overlooked that option. There is a catch: Unembed works only for symbols that are available in the current library search path. This means, you can't extract a symbol from a schematic. At best, unembed replaces the embedded symbol with the same symbol from the local lib. Worst case strikes, if the local symbol with the same name has its pins placed at different coordinates. It might even be a completely different symbol that bears the same name by coincidence. IMHO, an action that extracts embedded symbols would be a major step forward in usability. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
but I avoid name conflicts in project libraries. If we find ourselves gaining popularity and a plethora of libraries comes into being, we may no longer have the luxury of avoiding name conflict. name scoping came up a few times in the library discussion, I think keeping the issue in mind, even at time, is important. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
