Hi Kai-Martin,
Kai-Martin Knaak writes:
[...]
However, a less severe wart remains: In case of multiple values for the
same attribute, the output still depends on the order the symbols were
added to the schematics.
This behaviour is intentional. But you can change it locally.
Regards,
This commit introduces 'gnetlist:get-all-package-attributes' to
retrieve every first attribute value for package consisting of
multiple symbol instances.
'gnetlist:get-package-attribute' gets redefined to use the above
procedure. To preserve backward compatibility, it returns the first
value
Slot attributes have different values across symbol instances of a same
package. But 'gnetlist:get-package-attribute' does not like that. So the
value has to get directly extracted from the list returned by
'gnetlist:get-all-package-attributes'.
---
gnetlist/scheme/gnet-drc2.scm |4 +++-
1
John Doty writes:
[...]
Then there's Patrick Bernaud. Bas Gjeltes and I tried to contribute a patch
for the attribute censorship bug, but Patrick grabbed it, unfactored my
Guile code, found a problem that broke drc2, and then dropped it.
Maybe you can elaborate on your last sentence
John Doty writes:
[...]
The work-around for the drc2 incompatibility. Where is it?
You remember that I am not the person proposing the initial patch,
only one reviewer?
Beside with the example I proposed, it is not an incompatibility,
but merely a (valid) warning triggered by the new code.
John Doty writes:
[...]
We agreed it has to be addressed, yes. But who should address it?
Since it was so kindly asked, I did: my full (and final as far as I am
concerned) patch set for this issue follows this message (so our
fellow readers will get a chance to understand what we are talking
---
gnetlist/src/g_netlist.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gnetlist/src/g_netlist.c b/gnetlist/src/g_netlist.c
index b3af8fa..14441cc 100644
--- a/gnetlist/src/g_netlist.c
+++ b/gnetlist/src/g_netlist.c
@@ -513,6 +513,7 @@ SCM
This commit introduces 'gnetlist:get-all-package-attributes' to
retrieve every first attribute value for package consisting of
multiple symbol instances.
'gnetlist:get-package-attribute' gets redefined to use the above
procedure. To preserve backward compatibility, it returns the first
value
---
tests/testcase.sch | 128
tests/testcase.scm | 41 +
2 files changed, 169 insertions(+), 0 deletions(-)
create mode 100644 tests/testcase.sch
create mode 100644 tests/testcase.scm
diff --git a/tests/testcase.sch
Hi all,
The patch from the parent message has to be replaced by the one
below. Sorry for the inconvenience.
Patrick
multi-part-attribute-search.patch
Description: Binary data
___
geda-user mailing list
geda-user@moria.seul.org
Hi,
Levente Kovacs writes:
[...]
So this is it. I have other hierarchical design, which works just fine. Any
help to track down the bug, or the error in the schematics would be
appreciated.
Could you please post the files of your project (directly to to the
list or in private to the
Levente Kovacs writes:
[...]
Ok, I solved the problem. The problem was that there was an empty value
attribute attached to one of my symbol. That is bad, but gnetlist should not
crash.
Have you built gnetlist from release sources (tarballs) or from a git
checkout? The issue with malformed
Hi John,
John Doty writes:
[...]
This is a coding error somewhere. There should be nothing wrong with an
empty string as an attribute: it's a perfectly good string.
No, actually, an attribute is required to have a value, see
documentation (and code) for o_attrib_string_get_name_value() in
Thomas Dean writes:
I have an application which causes a seg fault in gnetlist. I think
this can be fixed by changing the schematic. But, Segmentation fault
is NEVER the proper response.
Your issue is similar to bug #3032626 (a malformed attribute as
Kai-Martin explained). I have proposed
Hi Mike,
Mike Crowe writes:
[...]
The separator appears to be important even if it is disabled by
(hierarchy-uref-mangle disabled)
Indeed, the hierarchy-uref-separator is ignored when it comes to
separating base uref from full uref with hierarchy.
The patch below fixes that problem.
Hi Karl,
Karl Hammar writes:
gsch2pcb:
How can I tell gsch2pcb to search the current directory for footprints?
This
$ cat ~/.gEDA/gnetlistrc
(component-library .)
(component-library ${HOME}/git/openhw/share/gschem)
'component-library' is indeed a directive for gnetlist
Hello Gareth,
Gareth Edwards writes:
[...]
More data from the console:
Failed to read pcbfwd scm file
[/home/gareth/geda/share/gEDA/scheme/gnet-pcbfwd.scm]
[...]
I'm thinking my non-standard install location may have thrown the PCB
installer off-kilter - I'll have a dig.
Indeed
Hello Robert,
myken writes:
[...]
So I took a fresh sheet, removed the titleblock, added sum components
(include_component_as_individual_objects), added sum nets, then I did
a symbol translate (=0) and saved my new symbol (rommel.sym -
attached).
Then I took a new sheet, included
Hello,
Kovacs Levente writes:
[...]
hid/lesstif/menu.c: In function ?lesstif_call_action?:
hid/lesstif/menu.c:856: error: ?x? undeclared (first use in this function)
hid/lesstif/menu.c:856: error: (Each undeclared identifier is reported only
once
hid/lesstif/menu.c:856: error: for
Kai-Martin Knaak writes:
On Wed, 20 Jan 2010 12:33:34 -0700, John Doty wrote:
(component-library .)
Seems a simpler way. Would that work in Windows?
[...]
Minor side effect: Unlike the PWD environment variable, the dot is not
expanded in the library window of gschem. So
Hi gene and Johannes,
Johannes Bauer writes:
gene schrieb:
I'm using gschem 1.4.0 and get a consistent segmentation fault when
moving a group of parts.
I can confirm the bug with gEDA/gschem Version 1.5.0.20080706.
Thank you for the report and the confirmation.
Indeed there
guile. And this
is the case with default-titleblock.
If you are building from sources, change the last parameter of
o_complex_add() from FALSE to TRUE in gschem/src/g_add_component.c
(line 730).
Please confirm it does fix your problem and bug #1932474.
Regards,
Patrick Bernaud
Carlos Nieves Ónega writes:
[...]
So a better way to fix this problem would have been to use
g_slist_last() on the returned list and not to modify s_clib.c.
Here are the reasons:
- All the existing code asserts that the first node returned by
s_clib_search_basename is the first
23 matches
Mail list logo
