Re: gEDA-user: Bugtracker-cleanup
Thanks a lot for reviewing and committing! Kind regards, Felix Am 23.05.2011 00:49, schrieb Krzysztof Kościuszkiewicz: Thanks for taking the time to report the list - status update below. On Sun, May 22, 2011 at 06:01:49PM +0200, Felix Ruoff wrote: Here is the list: a) Patches for documentation - 699306 elements color in manual Committed. - 699391 refcard updates Committed. - 699476 G-CODE export GUI Commented on the tracker - we need eps files updated Makefile.am aa) Patches for the Webside - 704086 download page links to sourceforge Commented - Peter wanted to run some tests with robot on this bug b) Patches for GTK-gui - 769815 Fix warnings 'gray50 ignored' for gtk menu Committed. - 699496 Detect case-different accelerators as unique - 699510 Cleanup conditional code because GTK 2.12 is required now Committed. - 699493 Add plus and minus to possible keyboard-shortcuts c) New features/modifications - 699508 Use GTK dialog for confirming file-overwrite (replaces pcb-dialog-implementation with a dialog given by gtk+) d) Patches to the core - 699478 refdes labels in new layout can't be moved without restart Cheers, ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
Kai-Martin:
Stephen Trier wrote:
Kai, try (component-library-search/home/..snip../symbols
Unfortunately, it works only for the first layer. Symbols in
../symbols/analog/diode are still ignored. In other words: gschem
does not descend recursively into sub dirs.
If you are brave, you can try the attached patch.
Regards,
/Karl Hammar
---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
diff --git a/libgeda/src/g_rc.c b/libgeda/src/g_rc.c
index e287da7..588a582 100644
--- a/libgeda/src/g_rc.c
+++ b/libgeda/src/g_rc.c
@@ -541,13 +541,14 @@ SCM g_rc_component_library_funcs (SCM listfunc, SCM
getfunc, SCM name)
* \param [in] path
* \return SCM_BOOL_T on success, SCM_BOOL_F otherwise.
*/
-SCM g_rc_component_library_search(SCM path)
-{
+int C_g_rc_component_library_search(gchar *string, gchar *name, GRegex *regex);
+SCM g_rc_component_library_search(SCM path) {
gchar *string;
char *temp;
- GDir *dir;
- const gchar *entry;
-
+ int ix;
+ const char pattern[] = \\.sym$;
+ GRegex *regex;
+
SCM_ASSERT (scm_is_string (path), path,
SCM_ARG1, component-library-search);
@@ -556,13 +557,29 @@ SCM g_rc_component_library_search(SCM path)
string = s_expand_env_variables (temp);
free (temp);
+ regex = g_regex_new (pattern, G_REGEX_CASELESS | G_REGEX_OPTIMIZE, 0, NULL);
+ ix = C_g_rc_component_library_search(string, NULL, regex);
+ g_regex_unref (regex);
+
+ g_free(string);
+
+ if (ix 0) return SCM_BOOL_F;
+ else return SCM_BOOL_T;
+}
+
+int C_g_rc_component_library_search(gchar *string, gchar *name, GRegex *regex)
+{
+ GDir *dir;
+ const gchar *entry;
+ int have_sym = 0;
+
/* invalid path? */
if (!g_file_test (string, G_FILE_TEST_IS_DIR)) {
fprintf (stderr,
Invalid path [%s] passed to component-library-search\n,
string);
-g_free(string);
-return SCM_BOOL_F;
+//g_free(string);
+return -1;
}
dir = g_dir_open (string, 0, NULL);
@@ -570,37 +587,48 @@ SCM g_rc_component_library_search(SCM path)
fprintf (stderr,
Invalid path [%s] passed to component-library-search\n,
string);
-g_free(string);
-return SCM_BOOL_F;
+//g_free(string);
+return -1;
}
while ((entry = g_dir_read_name (dir))) {
/* don't do . and .. and special case font */
-if ((g_strcasecmp (entry, .)!= 0)
-(g_strcasecmp (entry, ..) != 0)
-(g_strcasecmp (entry, font) != 0))
-{
+if ((g_strcasecmp (entry, .)== 0)
+(g_strcasecmp (entry, ..) == 0)
+(g_strcasecmp (entry, CVS) == 0)
+(g_strcasecmp (entry, font) == 0)) continue;
+
+if ( g_regex_match (regex, entry, 0, NULL) == TRUE ) {
+ have_sym++;
+} else {
gchar *fullpath = g_build_filename (string, entry, NULL);
+ gchar *entry_name;
+
+ if (name == NULL) entry_name = g_strconcat(cvs_, entry, NULL);
+ else entry_name = g_strconcat(name, _, entry, NULL);
if (g_file_test (fullpath, G_FILE_TEST_IS_DIR)) {
if (g_path_is_absolute (fullpath)) {
- s_clib_add_directory (fullpath, NULL);
+ if (C_g_rc_component_library_search(fullpath, entry_name, regex) 0)
+ s_clib_add_directory (fullpath, entry_name);
} else {
gchar *cwd = g_get_current_dir ();
gchar *temp;
temp = g_build_filename (cwd, fullpath, NULL);
- s_clib_add_directory (temp, NULL);
+ if (C_g_rc_component_library_search(temp, entry_name, regex) 0)
+ s_clib_add_directory (temp, entry_name);
g_free(temp);
g_free(cwd);
}
}
g_free(fullpath);
+ g_free(entry_name);
}
}
- g_free(string);
+ //g_free(string);
- return SCM_BOOL_T;
+ return have_sym;
}
/*! \todo Finish function description!!!
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: This morning's treat
On Mon, 23 May 2011, John Doty wrote: Well, here I am in Osaka. It's Monday morning, and I just saw the prototype Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the electronics, a large, complex circuit board and some mixed-signal ASICs, is of my design, using gEDA. I've been working on this for six years, now, and it's wonderful to see it all built and plugged together. So, thank you to all who made this possible. It's a beautiful morning. Sweet! gEDA in Space! -- David Griffith dgri...@cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: This morning's treat
Well done that man. Cheers, Andy. On 23 May 2011 05:18, Steven Michalske smichal...@gmail.com wrote: Cool, Got photos? Steve On May 22, 2011, at 6:57 PM, John Doty j...@noqsi.com wrote: Well, here I am in Osaka. It's Monday morning, and I just saw the prototype Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the electronics, a large, complex circuit board and some mixed-signal ASICs, is of my design, using gEDA. I've been working on this for six years, now, and it's wonderful to see it all built and plugged together. So, thank you to all who made this possible. It's a beautiful morning. 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA wiki in read-only mode
[snip] I'm doing some maintenance on the gEDA wiki this weekend, so it is currently in read-only mode. ... The gEDA wiki is back to read-write mode. -Ales ___ 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: This morning's treat
On 5/23/11 2:18 AM, John Doty wrote: CCD driver/temperature controller board. This is a gEDA design, published at https://github.com/noqsi/SXI. Mitsubishi did the layout. They didn't tell me until very late in the game that they wanted a PADS netlist, but that was no problem for gEDA. Video filter/digitizer ASIC chips. I designed these with gEDA, simulated them with ngspice. Digian Technology did the layout. Nice work!! -Dave -- Dave McGuire Port Charlotte, FL ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gerber magic numbers
On Sun, May 22, 2011 at 03:00:35PM -0700, Andrew Poelstra wrote: I am cleaning up the unit handling for the gerber exporter, using the guide at http://www.linux-cae.net/PCB/rs274xrevd_e.pdf Things are mostly straightforward, but I am lost as to the /10 factors in /* These are for drills */ #define gerberDrX(pcb, x) ((long) ((x)/10)) #define gerberDrY(pcb, y) ((long) (((pcb)-MaxHeight - (y)))/10) Why are the drill numbers divided by 10, and why are they output with leading zeroes?... The reason for this seems to be that drill layers are output in their own format in .cnc files, which use different units than the .gbr (and do not terminate their lines with *). What is the format of these files? -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: This morning's treat
Great! Well done! And pictures would be nice. Robert. On 23/05/11 03:57, John Doty wrote: Well, here I am in Osaka. It's Monday morning, and I just saw the prototype Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the electronics, a large, complex circuit board and some mixed-signal ASICs, is of my design, using gEDA. I've been working on this for six years, now, and it's wonderful to see it all built and plugged together. So, thank you to all who made this possible. It's a beautiful morning. 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gerber magic numbers
On Mon, 23 May 2011 11:09:23 -0700 Andrew Poelstra as...@sfu.ca wrote: On Sun, May 22, 2011 at 03:00:35PM -0700, Andrew Poelstra wrote: I am cleaning up the unit handling for the gerber exporter, using the guide at http://www.linux-cae.net/PCB/rs274xrevd_e.pdf Things are mostly straightforward, but I am lost as to the /10 factors in /* These are for drills */ #define gerberDrX(pcb, x) ((long) ((x)/10)) #define gerberDrY(pcb, y) ((long) (((pcb)-MaxHeight - (y)))/10) Why are the drill numbers divided by 10, and why are they output with leading zeroes?... The reason for this seems to be that drill layers are output in their own format in .cnc files, which use different units than the .gbr (and do not terminate their lines with *). What is the format of these files? The drill files output by pcb's gerber export are NC drill files, commonly called Excellon format. See: http://www.apcircuits.com/resources/information/nc_introduction.html http://en.wikipedia.org/wiki/Excellon_Format Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gerber magic numbers
On Sun, 22 May 2011 15:00:35 -0700 Andrew Poelstra as...@sfu.ca wrote: Why are the drill numbers divided by 10, and why are they output with leading zeroes? For the Excellon (NC drill) format: “Maximum m.n format supported is 2.4” [1]. That means that the units are 1/10 mil rather than the pcb-internal 1/100 mil unit. That explains the 1/10 factor. Regards, Colin [1] http://www.apcircuits.com/resources/information/nc_codes.html. ___ 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: Solving the light/heavy symbol problem
I'd like to note that we have a serious power tool in gnetlist, and it's not too hard to get it to translate attributes. Here's an example: gnetplug-metadata.scm Description: Binary data project_metadata.scm Description: Binary data metademo.sch Description: Binary data Usage: gnetlist -l project_metadata.scm -g your_favorite_back_end metademo.sch project_metadata is a project-specific file, while gnetplug-metadata.scm defines the simple machinery that makes this work. A next step might be to have a parser for a rule format that's more tabular and spreadsheet-friendly than S-expressions, although cargo cult construction of rules from the example here shouldn't be too hard. This could be a fine mechanism for manipulating invisible attributes like footprints. It can't do annotation because gnetlist hides much of the schematic data from the back-end script. There is an annotation tool that's conceptually like gnetlist at https://github.com/xcthulhu/lambda-geda. It converts schematic format to/from S-expressions for processing with a back end, but it's written in Haskell, which I guess would be even more of a barrier than Scheme. It is, however, in production use at Noqsi and Osaka, creating flattened schematics for documentation. Consider it proof of concept for an annotation tool. 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 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: This morning's treat
Thanks to all for the compliments. But I'm standing on the shoulders of giants, even though said giants: 1. Aren't too happy with me at the moment. 2. Don't seem to understand how tall they are. Note the excessively modest description at http://www.geda.seul.org/wiki/start. This work demonstrates that gEDA is much more capable than the impression you'd get there. 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 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: Solving the light/heavy symbol problem
On May 23, 2011, at 1:40 PM, DJ Delorie wrote: In a heirarchy, only the higher level schematics know what the heirarchy is, the sub-schematics don't, so the higher ones need to retain the instance-specific data. Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. 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: gEDA wiki in read-only mode
Ales Hvezda wrote: The gEDA wiki is back to read-write mode. Fine. So I can go ahead and add the component-search tip. ---)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: Solving the light/heavy symbol problem
I'd like to note that we have a serious power tool in gnetlist, Yup. I had hoped to move some of the heavyifying data into a database or the layout (or whatever), and have gnetlist gather all the attribute data from the schematic, the database, and the layout. It can then combine the data in order to update the layout. For example, to do pin swapping - you could set the pin numbers in the schematic, or leave them unspecified. If unspecified, gnetlist would see unassigned pins and allocate them based on some pin map database, then give that to the layout. On the next iteration, the pin numbers would be provided by the layout so gnetlist would know not to change them. Either way, gnetlist gathers the pin information from wherever it is available, and doles it out to whoever needs it. On a simpler scale, I expected gnetlist to read my partdb that maps light symbols and design rules to heavy symbols. At least, for those attributes not already specified in the schematic. No need to have hundreds of symbols, when you could have hundreds of rows in a database instead. Thus, schematics need only concern themselves with schematics - the symbolic connections of the design. Design-specific component attributes would be managed by gnetlist and gattrib. Physical layout, simulation, or other final target information would be managed by their respective tools. But yes, this means gnetlist would have to take on much more responsibility for managing the project. With your workflow, for example, your heavy symbols might be heavy only by having a manufacturer's part number in them, or some keyword that says that it is (purpose=bypass-cap for example), with all the other information added by gnetlist. ___ 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
Re: gEDA-user: Solving the light/heavy symbol problem
Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
