Hi Peter and all,
On Sat, 2009-01-17 at 07:37 +, Peter TB Brett wrote:
On Saturday 17 January 2009 02:43:44 Steve Meier wrote:
hmmm, isn't problem info being logged. I would agree if during the
current run the logfile only included warnings.
99+% of the time, the log doesn't contain
On Fri, Jan 16, 2009 at 10:44:54PM +, Peter TB Brett wrote:
My proposal is to use a Scheme-like syntax for the configuration
files,
but to parse rather than execute them.
Personally, I really like the ability of gaf to use arbitrary scripts
for configuration. While I don't use it in gaf
On Fri, Jan 16, 2009 at 10:44:57PM +, Peter TB Brett wrote:
1. In their configuration files, users specify plugins to load using a
string of the form:
plugin-type:type-specific-part
For instance, to load a plugin written in Scheme, the plugin-type
might be scheme and
On Fri, Jan 16, 2009 at 11:54 PM, Peter TB Brett wrote:
I needed a Gantt chart for a project report, so I drew one in gschem.
Oh, the strange things one can achieve with gEDA! (BTW, Cairo gschem
looks feels amazing, and Peter C. deserves donations towards his
secret evil mastermind
I was thinking that the question was should the log file be deleted at
the completion of the program execution. If a new user is required to go
back and re run the code but change a setting you might be forever
telling new users to do so. By having a no error delete of the log file
a good run
On Fri, 16 Jan 2009 22:29:42 +0100, Stefan Salewski wrote:
for Gnome this command inside of gschem:
lp -d pdf-printer
You need cups-pdf, I think Kai-Martin has written some notes about this
in the gEDA wiki.
http://geda.seul.org/wiki/geda:faq-gschem#how_can_i_produce_pdf_output
Peter Clifton quite rightly pointed out that my specification for the
'E' object syntax neglected the fact that while the gEDA file format
requires LF characters to be used, the MIME spec. requires CRLF line
endings.
So this is an alternative specification for the embedded object syntax
which
[snip]
My proposal is to use a Scheme-like syntax for the configuration files,
but to parse rather than execute them. Naturally, it would be necessary
to design the system carefully to ensure that all configuration
parameters can be specified in the reduced syntax.
No objections as long
[snip]
Currently, Scheme is the only available extension language for
gEDA. However, in future it may be desirable to extend gEDA apps in
other languages, including possibly as native code loaded from .so
files.
No objections with the following constraints:
- All plugins should
[snip]
gEDA currently allows symbols or pictures to be embedded in a
schematic. However, the current embedding system requires the full
data to be embedded for each instance of an embedded item.
This has a number of shortcomings:
1. It bloats filesize by requiring multiple redundant copies of
The New window functiona in gschem is getting in my way (for a variety
of rather technical reasons that I can go into if someone really wants
me to). [*]
Neutral, leaning towards leaving it in. Especially with an undefined /
dangling [*].
[snip]
Currently, if you 'copy' in gschem and 'paste' in another program,
nothing useful happens. We should ideally try and use the X
clipboard.
No objections to any of the options.
-Ales
___
Currently, running any gEDA suite program leaves behind a log file in
the current working directory. I would like to change the default to not
generating log files, so that I (and other users who use the default
configuration) don't end up with gschem.log and gnetlist.log files
scattered over
On Saturday 17 January 2009 15:56:19 Ales Hvezda wrote:
Currently, running any gEDA suite program leaves behind a log file in
the current working directory. I would like to change the default to not
generating log files, so that I (and other users who use the default
configuration) don't end
On Fri, 16 Jan 2009 16:11:18 -0700, John Doty wrote:
Will anyone miss it enormously if it is removed?
Well, I sometimes use it when doing cut/paste between pages.
I too use the new window function for cut'n paste. However, this is just
workaround for a non functional clipboard.
[snip]
The general consensus so far seems to be to carry on generating log files b=
y=20
default, but to put them in some central location. What to call them and=20
where exactly that location should be ($HOME/.gEDA/logs? $TMPDIR/gEDA?=20
Somewhere else?) seems to be up for debate.
On Sat, Jan 17, 2009 at 9:56 AM, Ales Hvezda ahve...@moria.seul.org wrote:
[snip]
gEDA currently allows symbols or pictures to be embedded in a
schematic. However, the current embedding system requires the full
data to be embedded for each instance of an embedded item.
This has a number of
On Saturday 17 January 2009 16:05:31 Ales Hvezda wrote:
[snip]
The general consensus so far seems to be to carry on generating log files
b= y=20
default, but to put them in some central location. What to call them
and=20 where exactly that location should be ($HOME/.gEDA/logs?
[snip]
I'm actually okay with leaving the backup undo files where they are. No-o=
ne=20
seems to complain about Emacs keeping its backup/undo files in the same=20
directory as the file being edited. Doing this has the added advantage that=
=20
if gschem crashes, and then someone tries to open
On Sat, Jan 17, 2009 at 9:55 AM, Ales Hvezda ahve...@moria.seul.org wrote:
[snip]
Currently, Scheme is the only available extension language for
gEDA. However, in future it may be desirable to extend gEDA apps in
other languages, including possibly as native code loaded from .so
files.
On Saturday 17 January 2009 16:17:07 Ales Hvezda wrote:
[snip]
I'm actually okay with leaving the backup undo files where they are.
No-o= ne=20
seems to complain about Emacs keeping its backup/undo files in the same=20
directory as the file being edited. Doing this has the added advantage
[snip]
Can someone define plug-in for me?
What is the advantage, given that the whole project is open-source?
This is a good page which describes plugins:
http://en.wikipedia.org/wiki/Plugin
-Ales
On Sat, 2009-01-17 at 16:10 +, Peter TB Brett wrote:
On Saturday 17 January 2009 16:05:31 Ales Hvezda wrote:
[snip]
The general consensus so far seems to be to carry on generating log files
b= y=20
default, but to put them in some central location. What to call them
and=20 where
[snip]
We need to fix the security implications of making known named files in
$TMPDIR, and with that I'd suggest that we used a subdir (per process
perhaps?). I can't find anything in my /tmp for gschem undo files after
I've been working with gschem for a while.
If you exit gschem, the
On Sat, 2009-01-17 at 10:18 -0600, Mark Rages wrote:
Can someone define plug-in for me?
What is the advantage, given that the whole project is open-source?
It means we can push the policy further out of the core, whilst still
providing options for all those crazy 99% use-case work-flows
On Sat, 2009-01-17 at 11:22 -0500, Ales Hvezda wrote:
[snip]
We need to fix the security implications of making known named files in
$TMPDIR, and with that I'd suggest that we used a subdir (per process
perhaps?). I can't find anything in my /tmp for gschem undo files after
I've been working
Amen
On Sat, 2009-01-17 at 10:56 -0500, Ales Hvezda wrote:
Currently, running any gEDA suite program leaves behind a log file in
the current working directory. I would like to change the default to not
generating log files, so that I (and other users who use the default
configuration) don't
Peter TB Brett wrote:
I needed a Gantt chart for a project report, so I drew one in gschem.
Hey! The mime types for .sch are updated on debian now and Ijust
clickety-opened the gantt chart!
Good work!
___
geda-user mailing list
On Saturday 17 January 2009 15:56:03 Ales Hvezda wrote:
[snip]
gEDA currently allows symbols or pictures to be embedded in a
schematic. However, the current embedding system requires the full
data to be embedded for each instance of an embedded item.
This has a number of shortcomings:
John Doty wrote:
On Jan 16, 2009, at 3:54 PM, Peter TB Brett wrote:
Oh, the strange things one can achieve with gEDA!
Yep. The difference between user software and consumer software.
So... Peter B, Are you thinking to write some scheme to generate
some of that Gantt chart so it can become
On Saturday 17 January 2009 15:56:03 Ales Hvezda wrote:
[*] Note that we may also consider making gEDA files officially use CRLF
line-endings, for better compatibility with 'quoted-printable'
encoding Windows users.
Really _not_ sold on this one. I think you will get
On Saturday 17 January 2009 16:30:12 John Griessen wrote:
Peter TB Brett wrote:
I needed a Gantt chart for a project report, so I drew one in gschem.
Hey! The mime types for .sch are updated on debian now and Ijust
clickety-opened the gantt chart!
Yet more reasons for sending Peter C.
DJ Delorie wrote:
It would be really cool if you could cut/copy in gschem, and paste in
*pcb*, and have the right footprint show up.
So you mean that cut gets text that contains a reference and pcb could resolve
the data, (footprint), it refers to?
Sounds fab.
John G
--
Ecosensory Austin
On Sat, 2009-01-17 at 16:35 +, Peter TB Brett wrote:
On Saturday 17 January 2009 15:56:03 Ales Hvezda wrote:
[*] Note that we may also consider making gEDA files officially use CRLF
line-endings, for better compatibility with 'quoted-printable'
encoding Windows users.
DJ Delorie wrote:
Having been stung by this in the past, I would prefer the majority
of plugins to be opt-in than opt-out (i.e. loaded only when the
current project needs to use them).
The counter-sting is trying to automatically install N plugins, each
of which has to be listed in a single
On Saturday 17 January 2009 16:41:13 Peter Clifton wrote:
...but I don't think it's unreasonable to specify one line ending in
particular for the nuts and bolts of the gEDA file format. :) Hence my
amended spec.
Personally, I'd favour emitting \n, and tolerating \r\n.
Sounds good. The
Hi!
Sorry if I will be too long, but this is an important question.
Short version: Don't Do That!
Long version:
Once upon a time we did a firewall software development project, which
had horribly failed. When we analyzed the causes, we identified
numerous management problems, and some technical
On Saturday 17 January 2009, John Griessen wrote:
How about when you create a new project, all plugins
available pop up a dialog so you can enable them for the
project or not, then that configuration is added to the
project dir gafrc file.
To put that in perspective ...
In gnucap, which
On Sat, 2009-01-17 at 17:53 +0100, Árpád Magosányi wrote:
Hi!
Sorry if I will be too long, but this is an important question.
Short version: Don't Do That!
Rebuttal:
Least important reason: Turing complete may present security
implications.
(BTW: Just saying sandbox the interpreter is very
On Sat, 17 Jan 2009 10:56:03 -0500, Ales Hvezda wrote:
Also, keep
in mind that the default of gschem is not to embed symbols/pictures, so
how many users will really take advantage of this?
Currently, embedded symbols are the only reliable way to share a self
contained schematic. Final
al davis wrote:
On Saturday 17 January 2009, John Griessen wrote:
How about when you create a new project, all plugins
available pop up a dialog so you can enable them for the
project or not, then that configuration is added to the
project dir gafrc file.
To put that in perspective ...
Let's assume that, for now, we're just going to implement copying
and pasting of schematic data.
It would be up to the receiving application (pcb in this case) to
interpret the incoming data, anyway. gschem would only need to
publish its data format and the magic cookie it uses to say it's a
Peter TB Brett wrote:
On Saturday 17 January 2009 15:56:03 Ales Hvezda wrote:
[snip]
However, what happens if a
user does want N different versions of the same symbol embedded?
I can't seea good enough reason for that... it's not an automatable workflow.
Quite a lot of people have
On Saturday 17 January 2009 17:41:01 John Griessen wrote:
Another thing this enables: because we now have an easy-to-get-at list of
embedded files, we can catch attempts to insert a library component
with the same name as an embedded component, and offer the user some
options for
On Sat, 2009-01-17 at 12:39 -0500, DJ Delorie wrote:
Let's assume that, for now, we're just going to implement copying
and pasting of schematic data.
It would be up to the receiving application (pcb in this case) to
interpret the incoming data, anyway. gschem would only need to
publish
On Sat, 2009-01-17 at 11:21 -0600, John Griessen wrote:
al davis wrote:
On Saturday 17 January 2009, John Griessen wrote:
How about when you create a new project, all plugins
available pop up a dialog so you can enable them for the
project or not, then that configuration is added to the
On Sat, 17 Jan 2009 18:24:31 +, Peter Clifton wrote:
Realistically, I don't expect to see copy-paste between schematic and
board layout any time soon. It's getting to the edge of what fits the
physical copy+paste UI metaphor. Drag/drop would also be a stretch.
Transfer of selection
Hi all,
Here's a semi-controversial suggestion I'm considering for the 1.8
series.
I want to wipe out almost the entire list of automatically promoted
attributes. Currently, we have:
(always-promote-attributes '(footprint device value model-name))
I want to reduce that to to nothing.
On Sat, 2009-01-17 at 18:39 +, Peter Clifton wrote:
We are rising to the challenge, and would very much appreciate if people
could refrain from objecting when there is a real example of a problem,
rather than as a knee-jerk reaction to a proposal.
That reads better (and as intended) if
On Sat, 2009-01-17 at 18:46 +, Kai-Martin Knaak wrote:
On Sat, 17 Jan 2009 18:24:31 +, Peter Clifton wrote:
Realistically, I don't expect to see copy-paste between schematic and
board layout any time soon. It's getting to the edge of what fits the
physical copy+paste UI metaphor.
On Saturday 17 January 2009 18:46:14 Kai-Martin Knaak wrote:
On Sat, 17 Jan 2009 18:24:31 +, Peter Clifton wrote:
Realistically, I don't expect to see copy-paste between schematic and
board layout any time soon. It's getting to the edge of what fits the
physical copy+paste UI metaphor.
On Saturday 17 January 2009 18:48:34 Peter Clifton wrote:
To mitigate the change in behaviour, I'd like to see all of a symbol's
attributes kept in memory behind the scenes. I propose to teach the
multi-attribute editor to display (perhaps greyed, or in a separate
group), those attributes
On Sat, 17 Jan 2009 18:54:17 +, Peter Clifton wrote:
Transfer of selection between schematics and layout seems an easier
task and would be very helpful. I used this a lot with protel95.
Did you mean cross-probing by transfer of selection?
Yes, cross-probing of whole groups of symbols.
Hi,
I just thought about a way to have defaults for footprint assignments
and such, while keeping it easy to change them project-wide, and at
the same time keeping local customizations.
How about having a text file, with rules like:
match device=RESISTOR
assign footprint=1206
Then, any
Hi All,
[snip]
1. Non-Turing-complete configuration files.
2. Plugin system.
3. Embedding system revamp.
4. New window functionality.
5. Use of X server clipboard.
6. Generation of log files.
I am glad some experienced gEDA/EDA/user/EE-designers, such
as John Doty, r, Árpád Magosányi
2009/1/17 Peter Clifton pc...@cam.ac.uk:
On Sat, 2009-01-17 at 17:53 +0100, Árpád Magosányi wrote:
Hi!
Sorry if I will be too long, but this is an important question.
Short version: Don't Do That!
Rebuttal:
Least important reason: Turing complete may present security
implications.
On Sat, 2009-01-17 at 21:31 +0100, Árpád Magosányi wrote:
Real crux of the matter: If you accept free-form input, it becomes
inordinately more difficult to write any sane GUI, or write-back of
changed config options. (Since the config file might be arbitrarily
complex).
Reading
Currently, if you 'copy' in gschem and 'paste' in another program,
nothing useful happens. We should ideally try and use the X
clipboard.
I would actually recommend you use PRIMARY, not CLIPBOARD (though I
also recognize that you may not have meant clipboard to be the
technical term here).
On Jan 17, 2009, at 6:04 AM, Bob Paddock wrote:
We need a way to import symbols from the library to the *project*,
not just to the schematic. The schematic may ultimately be shared by
many projects, with different parts requirements.
2. Institutions often have preferred parts lists,
The current implementation of slotting in gEDA is confusing and
inflexible.
It overloads the pinseq= attribute, which is also used to order pins
for SPICE netlisting.
It does not work when the slots are heterogeneous. This, in turn,
either requires hidden power pins or redundant power pins
On Jan 17, 2009, at 1:59 PM, Peter TB Brett wrote:
On Saturday 17 January 2009 18:48:34 Peter Clifton wrote:
To mitigate the change in behaviour, I'd like to see all of a
symbol's
attributes kept in memory behind the scenes. I propose to teach the
multi-attribute editor to display
On Jan 17, 2009, at 12:16 PM, Kai-Martin Knaak wrote:
On Sat, 17 Jan 2009 10:56:03 -0500, Ales Hvezda wrote:
Also, keep
in mind that the default of gschem is not to embed symbols/
pictures, so
how many users will really take advantage of this?
Currently, embedded symbols are the only
On Sat, 2009-01-17 at 16:58 -0500, der Mouse wrote:
Currently, if you 'copy' in gschem and 'paste' in another program,
nothing useful happens. We should ideally try and use the X
clipboard.
I would actually recommend you use PRIMARY, not CLIPBOARD (though I
also recognize that you may
On Sat, 2009-01-17 at 17:11 -0500, John Doty wrote:
The old mechanism could be left in place. Many, including me, would
scream if it changed. If the slot is defined by slotdef=, it's old
style, by slotfile=, it's new style.
I'd quite like to see the current slot handling C code ripped
On Fri, 2009-01-16 at 13:37 -0500, DJ Delorie wrote:
Ah, switching to loading the new scheme file works.
However, the print doesn't match the schematics...
http://www.delorie.com/electronics/powermeter/
Compare powermeter.pdf to channel.sch... (channel.ps in my build dir
matches the
The idea I had a while back was to use symbolic pin names in the
symbols, and map symbolic pin names to physical pin numbers as part of
the heavyification of the symbol. The physical pin numbers are
added to the symbol at that point. The syntax for slots would be
expanded, to allow for multiple
Here is a suggested patch. Portability is still dubious, but I've done
my best to make sure that we create new logfiles in a secure manner.
The format of the log filenames is intended so as to make it easy for a
user to find the most recent log file when troubleshooting.
I'd appreciate comments
DJ Delorie d...@delorie.com wrote:
The idea I had a while back was to use symbolic pin names in the
symbols, and map symbolic pin names to physical pin numbers as part of
the heavyification of the symbol. The physical pin numbers are
added to the symbol at that point.
That's exactly how my
On Jan 17, 2009, at 5:44 PM, Peter Clifton wrote:
I don't
like the fact that libgeda's core code understands the slot=
attribute
in so many places (and does lots of kludgy in-schematic
manipulation of
pinnumbers).
Very good point.
John Doty Noqsi Aerospace, Ltd.
Yes. But let's distinguish between the design data (the source
files for the design) and the BOM, which is a report generated from
these files.
The BOM can contain much more than just the gEDA/PCB based
files. It may mounting hardware, enclosures, notes, warnings (see below) etc.
Also in a
On Jan 16, 2009, at 5:24 PM, Peter TB Brett wrote:
Here is a suggested patch.
Why not use the syslog() machinery? gEDA is not the only application
with a knotty thread of issues involving logging. syslog() is
intended as a systematic answer here. Why not stand on the shoulders
of giants
Updated with some suggestions from Peter C.
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
From cabf7399d5f7d24559f8c36571e8bdf65fc673fa Mon Sep 17 00:00:00 2001
From: Peter TB Brett pe...@peter-b.co.uk
Date: Fri, 16 Jan 2009 22:20:29
On Jan 17, 2009, at 6:16 PM, DJ Delorie wrote:
The idea I had a while back was to use symbolic pin names in the
symbols, and map symbolic pin names to physical pin numbers as part of
the heavyification of the symbol. The physical pin numbers are
added to the symbol at that point. The
On Sat, Jan 17, 2009 at 5:11 PM, John Doty j...@noqsi.com wrote:
On Jan 17, 2009, at 6:04 AM, Bob Paddock wrote:
The schematic may ultimately be shared by
many projects, with different parts requirements.
The BOM by definition has to contain the correct parts for the
variation
of the
On Jan 17, 2009, at 6:27 PM, Bob Paddock wrote:
It's a one-liner in AWK to hide all value= attributes.
For you or I or most everyone here, yes. However there may
very well be people that simply want to use the tool to get
a task done, and have zero interest in figuring out what
a
Check again now. I think I've fixed it.
Yup, much better. Thanks!
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Jan 17, 2009, at 6:27 PM, Bob Paddock wrote:
That's another reason why, in the gEDA architecture, it makes great
sense to maintain the information that will generate the BOM in
project-specific heavy symbols.
To a degree. Say you have a Second-Source alternative that fulfills
form,
On Sat, Jan 17, 2009 at 5:08 PM, Peter Clifton pc...@cam.ac.uk wrote:
Sorry if I will be too long, but this is an important question.
Short version: Don't Do That!
Rebuttal:
Least important reason: Turing complete may present security
implications.
(BTW: Just saying sandbox the
On Sun, 2009-01-18 at 00:10 +, r wrote:
On Sat, Jan 17, 2009 at 5:08 PM, Peter Clifton pc...@cam.ac.uk wrote:
Fair enough. I'm not particularly attached to the current
configuration mechanism (although setting callbacks without this could
be difficult). I just don't think it is broken or
You don't need to change the schematic. One way to do this is to keep
a directory of second source symbols.
That presupposes that you know the second source when you are working
on the project. Part might be obsoleted years from now.
New second source symbol would have to be created when
a
I'd appreciate comments as to whether this will work (or even compile)
on Windows!
+ dir_path = g_build_filename (g_getenv (HOME),
+ .gEDA, logs, NULL);
Should test to see if HOME really exists on Windows,
it usually doesn't by default. You don't want to report
On Sunday 18 January 2009 01:07:13 Bob Paddock wrote:
I'd appreciate comments as to whether this will work (or even compile)
on Windows!
+ dir_path = g_build_filename (g_getenv (HOME),
+ .gEDA, logs, NULL);
Should test to see if HOME really exists on
On Sat, Jan 17, 2009 at 8:10 PM, Peter TB Brett pe...@peter-b.co.uk wrote:
On Sunday 18 January 2009 01:07:13 Bob Paddock wrote:
I'd appreciate comments as to whether this will work (or even compile)
on Windows!
+ dir_path = g_build_filename (g_getenv (HOME),
+
Hi Chitlesh, (cc gEDA-user)
After comments from distros about not over-linking gEDA apps, Peter Clifton
has recently done some work to minimise the CFLAGS we pass through our
libgeda.pc file.
Although Peter has followed the pkgconfig specification, the build currently
breaks on Fedora due to
On Sun, 2009-01-18 at 01:10 +, Peter TB Brett wrote:
On Sunday 18 January 2009 01:07:13 Bob Paddock wrote:
I'd appreciate comments as to whether this will work (or even compile)
on Windows!
+ dir_path = g_build_filename (g_getenv (HOME),
+ .gEDA,
On Sun, 2009-01-18 at 01:49 +, Peter Clifton wrote:
On Sun, 2009-01-18 at 01:10 +, Peter TB Brett wrote:
On Sunday 18 January 2009 01:07:13 Bob Paddock wrote:
I'd appreciate comments as to whether this will work (or even compile)
on Windows!
+ dir_path = g_build_filename
This is better, but its still not quite the right place to put things
on Win32 if you were aiming for a more native place.
APPDATA may always be set, I'm not sure.
Shows some examples of the native places:
http://docs.wxwidgets.org/trunk/classwx_standard_paths.html
My own program says this:
DJ Delorie wrote:
or will pcb support ASIC layouts in the future?
I don't expect so, but I don't see how that relates to what gschem is.
I can see using pcb really soon on organic semiconductor materials similarly to
how I amusing it on conductive ink mask patterns.
Exit? Not necessary.
Peter TB Brett wrote:
On Saturday 17 January 2009 01:24:52 r wrote:
Extending gEDA with native code plugins makes IMHO little sense. There
are no particular performance requirements in gEDA, and even if are,
it's usually easier and better to patch the source code.
The main issue is that
Peter TB Brett wrote:
Oh, right. I personally think that /tmp is the Right Place for undo files,
in that case, since they're (presumably) of very limited utility once the
session they belong to exits?
I can see playing them forward to recover from a crash after doing some fine
placement
On Sunday 18 January 2009 02:20:19 Bob Paddock wrote:
This is better, but its still not quite the right place to put things
on Win32 if you were aiming for a more native place.
APPDATA may always be set, I'm not sure.
Hmm, yes, it sounds like $APPDATA/gEDA/ is where we should keep things
91 matches
Mail list logo
