Re: gEDA-user: Progress with unified build
On Sat, 8 Aug 2009, Dan McMahill wrote: >Jason wrote: >> Kai-Martin Knaak wrote: >>> I use my own symbols only, anyway. >>> >> >> Having just made my first symbol for my first project (pic10f202), I >> have to ask, why? Does this include all the way down to rolling your >> own resistors? Is it for legal (IP) reasons, or technical (prefer >> everything in mm)? > >While I shouldn't speak for Kai-Martin, I can offer some reasons that I >and others have had for this. > >- others ? National or otherwise local standards. I know someone who would be really angry at me if I used the --/\/\/-- resistor symbol instead of the -[]- one, and of course no cad software can come with symbols for all possible components drawn for all possible standards. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gschem/Custom Symbol/Path
On Fri, 7 Aug 2009, Kai-Martin Knaak wrote:
>On Mon, 27 Jul 2009 07:37:12 +0100, Peter TB Brett wrote:
> There is a directory where you can put custom gafrc files which will
> automatically be loaded by system-gafrc (and won't be overwritten on the
> next update).
>
> ${prefix}/share/gEDA/gafrc.d/
>What would ${prefix} be on a debian system?
/usr; for more details about what should be installed where the policy may
help: http://www.debian.org/doc/debian-policy/ch-files.html; another
useful link may be FHS http://www.pathname.com/fhs/pub/fhs-2.3.html that
tells about /usr/local: "It needs to be safe from being overwritten when
the system software is updated. ... Locally installed software must be
placed within /usr/local rather than /usr unless it is being installed to
replace or upgrade software in /usr." For me, this suggests that .debs
need to install software under /usr and when you hand-compile from source
you may decide to install it in /usr/local or /usr. On debian I wouldn't
suggest using /usr for local compiled version, as it may interfere with
the package manager, instead, removing the package and installing local
compiled version to /usr/local sounds better.
Regards,
Tibor Palinkas
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA just hit SlashDotOrg (why live CD wouldn't work)
On Sat, 1 Aug 2009, evan foss wrote: >You know the mechanical people have a livecd or I think it is dvd now. >Perhaps we should have an electronics live disk of some kind? For a few semesters I was teaching gschem/pcb for undergrads. In the very first semester I tried with live cd (one I built myself) but it didn't work out as good as I expected. Reasons for this, in my opinion, are little issues: some seemingly unimportant convention of windows that windows users are so got used to that they do not want to switch to anything else, even if what they are currently using is the worst possible way of doing that thing. Some examples (and possible solutions): - window manager; there are ways to make the live cd run a very similar window manager that windows has, but it will never be the same. Any little difference will annoy windows users. - command line; most of windows users believe if you need to type commands or you see a prompt, that's the sign you are doing something wrong. On this, xgsch2pcb helped a lot but... - ... but "these are separate programs, tools are not integrated, omg, this will be very complicated how could i ever learn this?" Really, this was one of the big surprises for my students, that doing different tasks can be best achieved by using different tools. And this is not even about hjaving back annotation, it's purely about having everything in one big window. I am rather sure if anyone would come up with a tool that integrates xgsch2pcb, gschem and pcb into a single window with tabs, these users won't ever notice they are separate programs even if mouse commands are different in each window. - and if we are already here, the mouse. I remember I had hard time learning PCB and gschem; all the hotkeys and "strange" mouse controls. But when I started, I understood these all have a reason, and the controls are optimized for smooth workflow. After the learning curve, using these bindings are really fast. However, windows users do not care about being fast. Really, it's not gEDA-specific. I remember the old, DOS versions of autocad. The same story there with the command line. Those who really learned using acad back then had one hand on keyboard, one hand on mouse. Selecting objects and sometimes coordinates done with mouse, actions done using the keyboard. When I got to learn autocad at the university again, it was already a windows version: right click and a menu pops up. This way only one hand works, and selecting the line tool or the "perpendicular" menu item takes much longer then typing "l" or "perp". Of course there was a command line in the windows version as well, but noone bothered to use it, teachers didn't even teach the commands. I remember I tried to show some of my classmates how much faster using commands can be, but they were totally uninterested. For gEDA, I believe this is another blocker for windows users: it is optimized for speed (of use). Of course mouse bindings can be changed and I guess it's not a big deal to add context sensitive menus for the right click, but without these, windows users won't take it serious. Really, number of popups matter... - drive letters; they do want to name their hard disk "c:" and they find it more convenient to remember their usb pendrive as "f:" than to remember it as "/mnt/pendrive". Even if drive letters are assigned in an obscure way that when you insert a new hard disk as secondary master or primary slave, half of your drive letters would be shifted. Even if sometimes you want to have more mounts than alphabet would allow. This sounds ridiculous, but even in my fdaytime job, where we hire programmers and convert them to *NIX, this is one of the things that they say windows is better for the longest time. Of course this one can be really solved only with a native windows version. - this one is the first issue I can even understand: if you boot a live CD, you can not run the programs you normally run. This was not a real problem 15 years ago, but nowdays almost everyone is constantly online and they run their whatever network clients (chat clients, internet phone clients, rss readers with some sort of notifications). People get used to those little popups or blinking icons (or however they do it) and booting a live CD means going offline with those. For me, I have an ssh session so booting a live CD wouldn't hurt me as far as I have network and an ssh client - but if not, I can imagine not wanting to use the live CD for working with a CAD for a day. This could be solved if the live CD also offered running inside colinux or something similar (maybe even autostart a colinux or an emulator from the CD when the user inserts it). Conclusion: I think a pure live CD won't help much. Something that "integrates" better in the windows environment, and where integration is not possible, something that looks and acts exactly the same way (even if that's stupid and slow) is necessary to convience majority of windows users to even consider gE
Re: gEDA-user: connecting elements in PCB
On Fri, 24 Jul 2009, Oliver Lehmann wrote: >Hi, > >I'd like to start drawing a PCB but do not want to import any gschem >files... how do I connect the elemnts with circuit tracks? Are the lines >created by the "line" button circuit tracks? > Yes, lines, arcs and polygons. Also note the layers, most of them will result in copper, but some will not (silk for example). Btw, you never import the gschem file in pcb; you rather import the netlist that helps you connecting the right pins and avoid shorts. This feature is not mandantory (but for anything larger than a few pins it's very very useful). I remember doing my first few boards without netlist - it took a lot of time to make sure everything was connected correctly :) HTH, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: More robust support of multi-part symbols.
On Thu, 9 Jul 2009, Dave N6NZ wrote: >Ben Jackson wrote: >> On Wed, Jul 08, 2009 at 09:20:54PM -0700, Steve Meier wrote: >>> Let alone, how at the layout level we can do pin swapping and back >>> annotation. >> >> I've thought about working on that, because I've dealt with that problem >> in almost every project I've done with geda/pcb. I'd love to know how >> the big boys handle it. > >Often poorly. > >> Obviously you can't draw wires in gschem and >> then swap pins in pcb and expect the wires to be asthetically re-drawn >> in gschem. So do you only do it with busrippers and netname attributes? > >The first thing to realize is that for large projects, hand placed line >corners don't scale. The in-house CAD systems I've used on large >(30-300 engineer) projects had auto-routed drawings. In some ways, >auto-routing a drawing is more of a challenge than auto-routing a PCB, >since aesthetics matters as well as connectivity. An in no case were >the drawings "perfect" -- that is to say what a good draftsman would do. >But all the systems produced readable drawings, and nobody hand to spend >much time making them readable. gpsim (Free PIC microcontroller simulator) tries to do something similaron the breadboard feature. The breadboard looks like a schematics, you see there the PIC being simulated, and if you have external modules (LCD, rs232 terminal, LED, etc), you see them as well. The netlist is visualized by drawing black lines between the pins. The lines consist of horizontal and vertical segments and gpsim tries its best to add as many segments as required to avoid crossing components or other lines. Of course it works well only if you have 2..3 boxes and max 6-8 lines :) I agree that this may be a bit overkill. However, swapping pin numbers may work for the big box symbols. Maybe we could mark groups of pins in a symbol, let's say GPIO1, 8 pins is a group, if any two of these are swapped, just swap the pin number on the schematics. If you swap a GND with a GPIO1 pin, it won't work, because they are not in the same pin group. I think something similar may be applied on slots. Another option is defining net lines with different color in gschem. If two pins are swapped, gschem deletes the two net segments connceted to the pins and draws two new segments simply crossing eachothers with this different color. This means the user can swap whatever he wants on the PCB and his schematics becomea haystack with red lines, then he can go and clean it up when he finished swapping pins on the PCB. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Breadboard drawings with pcb?
On Wed, 27 May 2009, Kai-Martin Knaak wrote: >On Tue, 26 May 2009 14:12:16 -0600, Miles Gazic wrote: >> I have this same problem, because I automate my build with makefiles, >> and I'd like to have a build machine (that doesn't run X) be able to >> build everything >Ack. Scripting is a weak point of pcb and in particular gschem. IMHO an >expert-friendly app should allow for non-interactive use. This would make >the suite much more powerful. FYI, pcb-gpmi allows non-interactive use. You can create actions and call them from pcb command line directly. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb library and hid build modification
On Tue, 26 May 2009, Jason Childs wrote: >On Tue, May 26, 2009 at 8:38 PM, John Griessen wrote: >> To control drawing tools via a plugin in any language >> Igor/Tibor's GPMI interface allows would be fabulous! Think of all the >> extra efforts >> that people would make in all their different favorite scripting languages? >> Just like SWIG, and we already have it. > >Do you have a working link to the GPMI hid? I can't seem to find any that work. > http://repo.hu/projects/pcb-gpmi/ Current state: the infrastructure is ready and some things are already accessible trough the bindings (can pop up custom dialogs, can modify the drawing in memory, add new exporter). Still a lot to do on improving bindings so more of PCB internals are exposed. If you want to write an exporter to xml, you already can write it (there's an example SVG exporter). Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB scripting plugin: exporters, drawing, gui gadgets in python, perl and more
On Sat, 16 May 2009, Chitlesh GOORAH wrote: >On Fri, May 15, 2009 at 8:57 PM, igor2 wrote: >> As usual, comments, questions, bugreports are welcome. > >From a packager point of view, can this plugin be merged to the pcb >upstream trunk ? > >Chitlesh Could be, but shouldn't be. For example this plugin has a lot of (optional) dependencies that we shouldn't force on people who are not going to use it. On debian side, it is currently: apt-get install pcb apt-get install pcb-gpmi apt-get install libgpmi-mod- last line when the user installs those language modules he needs. I think this process is not a big hassle and could be reproduced in other packaging systems that can handle dependencies as well. For those who prefer to install from source, we could write a shell script that can fetch all the sources, that would have a similar effect as having the project in upstream trunk, right? Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB scripting plugin: exporters, drawing, gui gadgets in python, perl and more
Hi all, I'm proud to present pcb-gpmi (http://repo.hu/projects/pcb-gpmi), which is a PCB plugin that allows integrated scripting on 10 different languages. Example scripts accessible from the above page demonstrates a minimal SVG exporter (171 lines of tcl), a custom angle arc drawing dialog (32 lines in lua). Make sure to check out the screenshots :) For i386 debian/ubuntu users, debian packages can be downloaded (or apt-get intalled with a sources.list modification). For users of other systems different source packages are available. The plugin is in beta state. Only a limited subset of PCB internals are exposed yet, but I plan to improve the amount, especially on user demand. As usual, comments, questions, bugreports are welcome. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: pcb deb (and or other OS) dev package
Hi all, still working on the pcb-gpmi plugin, I was wondering... Currently the plugin requires the user to have PCB sources somewhere around because it uses the header files. I think this is bad for the user of binary distributions, who may decide to (or need to) install the plugin from source while having PCB installed from binary. I believe this problem doesn't affect only this plugin but any PCB plugin. Therefore I suggest having a pcb-dev package that installs all the .h files under /usr/include/pcb. Regards, Tibor Palinkas -- .O. ..O OOO ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] action context patch - lesstif
Oops, forgot to attach the file :)
--
.O.
..O
OOO
On Wed, 25 Mar 2009, igor2 wrote:
>Hi,
>
>I still believe that lesstif should call hid_actionv() from common
>instead of having a copy of it, but I can't make it so. Instead, this
>little patch updates lesstif's version.
>
>Regards,
>
>Tibor Palinkas
>
>
diff -uri pcb.orig/src/hid/lesstif/menu.c pcb.lesstif/src/hid/lesstif/menu.c
--- pcb.orig/src/hid/lesstif/menu.c 2009-03-25 05:57:56.0 +0100
+++ pcb.lesstif/src/hid/lesstif/menu.c 2009-03-25 06:49:17.0 +0100
@@ -813,12 +813,13 @@
int
lesstif_call_action (const char *aname, int argc, char **argv)
{
- int px, py;
+ int px, py, ret;
HID_Action *a;
+ void *context, *old_context;
if (!aname)
return 1;
- a = hid_find_action (aname, NULL);
+ a = hid_find_action (aname, &context);
if (!a)
{
int i;
@@ -848,7 +849,11 @@
printf ("%s%s", i ? "," : "", argv[i]);
printf (")\033[0m\n");
}
- return a->trigger_cb (argc, argv, px, py);
+ old_context = hid_action_context;
+ hid_action_context = context;
+ ret = a->trigger_cb (argc, argv, px, py);
+ hid_action_context = old_context;
+ return ret;
}
static void
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PCB] action context patch - lesstif
Hi, I still believe that lesstif should call hid_actionv() from common instead of having a copy of it, but I can't make it so. Instead, this little patch updates lesstif's version. Regards, Tibor Palinkas -- .O. ..O OOO ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] action context patch
Hi,
this version fixes the mistake in hid.h about void return value and
contains the internals for registering/deregistering single actions.
Regards,
Tibor Palinkas
--
.O.
..O
OOO
diff -uri pcb.orig/src/hid/common/actions.c pcb/src/hid/common/actions.c
--- pcb.orig/src/hid/common/actions.c 2008-01-05 06:37:08.0 +0100
+++ pcb/src/hid/common/actions.c 2009-03-24 05:31:29.0 +0100
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "global.h"
#include "data.h"
@@ -26,14 +27,27 @@
struct HID_ActionNode *next;
HID_Action *actions;
int n;
+ /* The registrar the callback function may use this pointer to remember
+ context; the action infrastructure will just pass it along. */
+ void *context;
+ /* is this ActionNode registered runtime? (can be deregistered) */
+ int dynamic;
} HID_ActionNode;
-HID_ActionNode *hid_action_nodes = 0;
+/* The master list of all actions registered */
+typedef struct HID_ActionContext {
+ HID_Action action;
+ void *context;
+} HID_ActionContext;
static int n_actions = 0;
-static HID_Action *all_actions = 0;
+static HID_ActionContext *all_actions = NULL;
-void
-hid_register_actions (HID_Action * a, int n)
+HID_ActionNode *hid_action_nodes = NULL;
+
+void *hid_action_context = NULL;
+
+static void
+hid_register_actions_context (HID_Action * a, int n, void *context, int dynamic)
{
HID_ActionNode *ha;
@@ -41,26 +55,87 @@
ha = (HID_ActionNode *) malloc (sizeof (HID_ActionNode));
ha->next = hid_action_nodes;
hid_action_nodes = ha;
- ha->actions = a;
+ if (dynamic) {
+ assert(n == 1); /* we register dynamic actions one by one */
+ ha->actions = malloc(sizeof(HID_Action));
+ memcpy(ha->actions, a, sizeof(HID_Action));
+ }
+ else
+ ha->actions = a;
+
ha->n = n;
+ ha->context = context;
+ ha->dynamic = dynamic;
n_actions += n;
if (all_actions)
{
free (all_actions);
- all_actions = 0;
+ all_actions = NULL;
}
}
+void
+hid_register_actions (HID_Action * a, int n)
+{
+ hid_register_actions_context (a, n, NULL, 0);
+}
+
+void
+hid_register_action (const HID_Action * a, void *context)
+{
+ hid_register_actions_context (a, 1, context, 1);
+}
+
+void
+hid_deregister_action (const char *name, void **context)
+{
+ HID_ActionNode *prev, *ha;
+
+ if (context != NULL)
+ *context = NULL;
+
+ /* find the action in hid_action_nodes */
+ for(prev = NULL, ha = hid_action_nodes; ha != NULL; prev = ha, ha = ha->next) {
+ if (ha->dynamic) {
+ if (strcmp(ha->actions->name, name) == 0) {
+/* found the action in the tree, save context */
+if (context != NULL)
+ *context = ha->context;
+
+/* remove ha */
+if (prev == NULL)
+ hid_action_nodes = ha->next;
+else
+ prev->next = ha->next;
+
+free(ha->actions);
+free(ha);
+
+/* to make sure the rebuild of the sorted list next time */
+if (all_actions != NULL) {
+ free (all_actions);
+ all_actions = NULL;
+}
+
+n_actions--;
+return;
+ }
+ }
+ }
+
+ /* action not found - nothing to do */
+}
+
static int
action_sort (const void *va, const void *vb)
{
- HID_Action *a = (HID_Action *) va;
- HID_Action *b = (HID_Action *) vb;
- return strcmp (a->name, b->name);
+ HID_ActionContext *a = (HID_ActionContext *) va;
+ HID_ActionContext *b = (HID_ActionContext *) vb;
+ return strcmp (a->action.name, b->action.name);
}
HID_Action *
-hid_find_action (const char *name)
+hid_find_action (const char *name, void **context)
{
HID_ActionNode *ha;
int i, n, lower, upper;
@@ -68,14 +143,17 @@
if (name == NULL)
return 0;
- if (all_actions == 0)
+ if (all_actions == NULL)
{
n = 0;
- all_actions = malloc (n_actions * sizeof (HID_Action));
+ all_actions = malloc (n_actions * sizeof (HID_ActionContext));
for (ha = hid_action_nodes; ha; ha = ha->next)
- for (i = 0; i < ha->n; i++)
- all_actions[n++] = ha->actions[i];
- qsort (all_actions, n_actions, sizeof (HID_Action), action_sort);
+ for (i = 0; i < ha->n; i++) {
+ all_actions[n].action = ha->actions[i];
+ all_actions[n].context = ha->context;
+ n++;
+ }
+ qsort (all_actions, n_actions, sizeof (HID_ActionContext), action_sort);
}
@@ -85,10 +163,13 @@
while (lower < upper - 1)
{
i = (lower + upper) / 2;
- n = strcmp (all_actions[i].name, name);
+ n = strcmp (all_actions[i].action.name, name);
/*printf("try [%d].%s, cmp %d\n", i, all_actions[i].name, n); */
- if (n == 0)
- return all_actions + i;
+ if (n == 0) {
+ if (context != NULL)
+ *context = all_actions[i].context;
+ return &(all_actions[i].action);
+ }
if (n > 0)
upper = i;
else
@@ -96,8 +177,11 @@
}
for (i = 0; i < n_actions; i++)
-if (strcasecmp (all_actions[i].name, name) == 0)
- return all_actions + i;
+if (strcasecmp (all_actions[i].action.name, name) == 0) {
+ if (*context != NULL)
+*context = all_actions[i].c
Re: gEDA-user: [PCB] action context patch
On Mon, 23 Mar 2009, Gabriel Paubert wrote:
>On Mon, Mar 23, 2009 at 06:36:39AM +0100, igor2 wrote:
>> fixed typo and added more comments (about intention of the new calls)
>>
>> --
>> .O.
>> ..O
>> OOO
>>
>
>> --- pcb.orig/src/hid.h 2009-02-21 18:51:54.0 +0100
>> +++ pcb/src/hid.h2009-03-23 06:34:54.0 +0100
>> @@ -86,7 +86,25 @@
>> const char *syntax;
>>} HID_Action;
>>
>> + /* This global variable is always set to the action context,
>> + before an action callback is called. Action context can
>> + be specified when registering an action with
>> hid_register_action()
>> + Intended for plugins with hub action callbacks. */
>> + extern void *hid_action_context;
>> +
>> + /* Register a singe action associated with an action context
>> + Intended for plugins to register actions with a hub callback. */
>> +extern void hid_register_action(HID_Action *, void *);
>> +
>> +/* Deregister an action; returns 0 on success. Action context pointer
>> is copied
> ^
>> + in the 2nd argument if it's not NULL.
>> + Intended for plugins to deregister actions registered earlier
>> + with hid_register_action() */
>> +extern void hid_deregister_action(const char *, void **);
>
>Hmmm, how can a void returning function return 0 on success?
>
>Maybe I'm just nitpicking, but...
>
>> +
>> + /* Register a list of actions without action context */
>>extern void hid_register_actions (HID_Action *, int);
>> +
>> #define REGISTER_ACTIONS(a) HIDCONCAT(void register_,a) ()\
>> { hid_register_actions(a, sizeof(a)/sizeof(a[0])); }
>>
>
> Regards,
> Gabriel
>
>
Ooops :) Thanx for the warning, probably it won't return anything and if
the user tries to delete a non-existing action, it will be silently
dismissed.
Regards,
Tibor Palinkas
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] action context patch
fixed typo and added more comments (about intention of the new calls)
--
.O.
..O
OOO
--- pcb.orig/src/hid.h 2009-02-21 18:51:54.0 +0100
+++ pcb/src/hid.h 2009-03-23 06:34:54.0 +0100
@@ -86,7 +86,25 @@
const char *syntax;
} HID_Action;
+ /* This global variable is always set to the action context,
+ before an action callback is called. Action context can
+ be specified when registering an action with hid_register_action()
+ Intended for plugins with hub action callbacks. */
+ extern void *hid_action_context;
+
+ /* Register a singe action associated with an action context
+ Intended for plugins to register actions with a hub callback. */
+ extern void hid_register_action(HID_Action *, void *);
+
+ /* Deregister an action; returns 0 on success. Action context pointer is copied
+ in the 2nd argument if it's not NULL.
+ Intended for plugins to deregister actions registered earlier
+ with hid_register_action() */
+ extern void hid_deregister_action(const char *, void **);
+
+ /* Register a list of actions without action context */
extern void hid_register_actions (HID_Action *, int);
+
#define REGISTER_ACTIONS(a) HIDCONCAT(void register_,a) ()\
{ hid_register_actions(a, sizeof(a)/sizeof(a[0])); }
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] action context patch
On Mon, 23 Mar 2009, DJ Delorie wrote:
>
>> This was the simpler and more general change.
>
>Simpler and more general does not always mean better. To me, the more
>general solution is to be able to add/remove single actions, with
>their own context. Other functions can build on that. If the
>internals of that code need to be changed to support that, it's a
>change we need to now to avoid more work later.
>
>Creating a new API that will never be used in its full functionality
>seems wrong to me.
>
>> I don't say the GUI should know about context, but that, as the GTK
>> hid does, the GUI hid should not do this directly but call
>> hid_actionv() from hid/common/actions.c.
>
>Perhaps hid_find_action could set the global context pointer?
>
>> I have one more layer, which is not part of this patch but the
>> plugin, where I do this. My approach is doing the smallest but more
>> general patch to the core and do everything else in plugins.
>
>My approach is to create the best API in the core so that the least
>amount of code need be duplicated in plugins.
>
After polishing the API on irc, the final(?) version of the proposed API
is attached.
--- pcb.orig/src/hid.h 2009-02-21 18:51:54.0 +0100
+++ pcb/src/hid.h 2009-03-23 06:25:44.0 +0100
@@ -86,7 +86,21 @@
const char *syntax;
} HID_Action;
+ /* This global variable is always set to the action context,
+ before an action callback is called. Action context can
+ be specified when registering an action with hid_register_action() */
+ extern void *hid_action_context;
+
+ /* Register a singe action associated with an action context */
+ extern void hid_register_actions(HID_Action *, void *);
+
+ /* Deregister an action; returns 0 on success. Action context pointer is copied
+ in the 2nd argument if it's not NULL */
+ extern void hid_deregister_action(const char *, void **);
+
+ /* Register a list of actions without action context */
extern void hid_register_actions (HID_Action *, int);
+
#define REGISTER_ACTIONS(a) HIDCONCAT(void register_,a) ()\
{ hid_register_actions(a, sizeof(a)/sizeof(a[0])); }
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] action context patch
On Sun, 22 Mar 2009, DJ Delorie wrote: > >Are you sure this is the functionality you want? It sounded like you >need one context pointer per action, not one context pointer per list >of actions. This was the simpler and more general change. Currently I use the call with list of 1 action, but I can imagine a situation when I want to do the same for different actions, so I thought why restrcit that? >And there's no reason why the GUIs would need to even know that the >contexts exist. The HID registering the action gives the context for >the action to the common action code, and the common action code tells >the action's handler what the context is. Nobody *invoking* actions >needs to know. Maybe I misunderstand the code, but lesstif_call_action() in hid/lesstif/menu.c calls hid_find_action and then the trigger_cb of the action and this is not a GUI-local. I suspect this can happen to any of my context-registered actions and then I would have context NULL. I don't say the GUI should know about context, but that, as the GTK hid does, the GUI hid should not do this directly but call hid_actionv() from hid/common/actions.c. >Something like: > >hid_register_action (const char *name, ..., void *context); >hid_deregister_action (const char *name); > >The remaining functions need not change. > I have one more layer, which is not part of this patch but the plugin, where I do this. My approach is doing the smallest but more general patch to the core and do everything else in plugins. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PCB] action context patch
Hi all,
lately I started to work again on my gpmi plugin for PCB. This plugin
would be able to load and run scripts written in different languages
and expose PCB internals to the script. In other words, the user could use
lua, python, perl, etc., to write a PCB plugin, being able to display
dialog boxes on the current HID and manipulate the drawing.
As part of this effort, I probably need to extend different parts of the
current PCB code. For example, when the user script wants to register
actions, it's not (easily) possible to pass on unique callback function
for each action that directly calls a script function; instead the plugin
needs to install a "hub" action callback function that catches any and all
script-registered action delivers them in a way that scripts can find out
which action triggered the callback.
This is not possible with the current codebase as action callbacks do not
get any argument that tells the action name. After consulting dj on IRC, I
made up the attached patch. It adds a new hidden layer in the
hid/common/actions.c, called HID_ActionContext; this layer is used to
store every action with a context coming from the action register
function. A new function is provided where the user can set a context to
the list of actions being registered, while keeping the original
hid_register_actions() call for backward compatibility (it sets context
to NULL). When an action callback is triggered by hid_actionv(), a global
variable called hid_action_context will be set to the context given during
the registration. A side effect of the changes is that a mostly internal
function, hid_find_action() has a new optional argument in which it can
return the context for the action found.
I tested the patch with the gtk hid and it worked as expected. I made the
necessary modification in the lesstif hid so that it should also compile
but will not set hid_action_context. The reason is that lesstif seems to
implement it's own action dispatcher instead of calling hid_actionv(). Of
course it's not very hard to add the required context-handling code there
as well, but I suspect not using the common code is simply a bug that
should be fixed.
Please test my patch on lesstif and if it doesn't break anything, please
commit the patch.
TIA,
Tibor Palinkas
--
.O.
..O
OOO
diff -ur pcb.orig/src/hid/common/actions.c pcb/src/hid/common/actions.c
--- pcb.orig/src/hid/common/actions.c 2008-01-05 06:37:08.0 +0100
+++ pcb/src/hid/common/actions.c 2009-03-19 19:46:30.0 +0100
@@ -26,14 +26,25 @@
struct HID_ActionNode *next;
HID_Action *actions;
int n;
+ /* The registrar the callback function may use this pointer to remember
+ context; the action infrastructure will just pass it along. */
+ void *context;
} HID_ActionNode;
-HID_ActionNode *hid_action_nodes = 0;
+/* The master list of all actions registered */
+typedef struct HID_ActionContext {
+ HID_Action action;
+ void *context;
+} HID_ActionContext;
static int n_actions = 0;
-static HID_Action *all_actions = 0;
+static HID_ActionContext *all_actions = 0;
+
+HID_ActionNode *hid_action_nodes = 0;
+
+void *hid_action_context = NULL;
void
-hid_register_actions (HID_Action * a, int n)
+hid_register_actions_context (HID_Action * a, int n, void *context)
{
HID_ActionNode *ha;
@@ -43,6 +54,7 @@
hid_action_nodes = ha;
ha->actions = a;
ha->n = n;
+ ha->context = context;
n_actions += n;
if (all_actions)
{
@@ -51,16 +63,22 @@
}
}
+void
+hid_register_actions (HID_Action * a, int n)
+{
+ hid_register_actions_context (a, n, NULL);
+}
+
static int
action_sort (const void *va, const void *vb)
{
- HID_Action *a = (HID_Action *) va;
- HID_Action *b = (HID_Action *) vb;
- return strcmp (a->name, b->name);
+ HID_ActionContext *a = (HID_ActionContext *) va;
+ HID_ActionContext *b = (HID_ActionContext *) vb;
+ return strcmp (a->action.name, b->action.name);
}
HID_Action *
-hid_find_action (const char *name)
+hid_find_action (const char *name, void **context)
{
HID_ActionNode *ha;
int i, n, lower, upper;
@@ -71,11 +89,14 @@
if (all_actions == 0)
{
n = 0;
- all_actions = malloc (n_actions * sizeof (HID_Action));
+ all_actions = malloc (n_actions * sizeof (HID_ActionContext));
for (ha = hid_action_nodes; ha; ha = ha->next)
- for (i = 0; i < ha->n; i++)
- all_actions[n++] = ha->actions[i];
- qsort (all_actions, n_actions, sizeof (HID_Action), action_sort);
+ for (i = 0; i < ha->n; i++) {
+ all_actions[n].action = ha->actions[i];
+ all_actions[n].context = ha->context;
+ n++;
+ }
+ qsort (all_actions, n_actions, sizeof (HID_ActionContext), action_sort);
}
@@ -85,10 +106,13 @@
while (lower < upper - 1)
{
i = (lower + upper) / 2;
- n = strcmp (all_actions[i].name, name);
+ n = strcmp (all_actions[i].action.name, name);
/*printf("try [%d].%s, cmp %d\n", i, all_actions[i].name, n); */
- if (n == 0)
- return a
Re: gEDA-user: footprint request: mini-fit 4P
On Sat, 23 Aug 2008, Darrell Harmon wrote: >I am not sure your request is specific enough. I have attached the >footprint for a Molex Mini Fit Jr 2x2 pin straight header which I >assume may be what you are looking for. This is the same connector as >the PC motherboard 12V power connector. > >Darrell Harmon Yes, I meant exactly this footprint, thank you. Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: footprint request: mini-fit 4P
Hi, does anyone have PCB footprint for mini-fit 4P connector? TIA Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: poll: How do you geda?
On Wed, 4 Jun 2008, Kai-Martin Knaak wrote: >I am curious, just how heterogeneous the group of geda users and >developers is. So I thought, I'd start this little non-random sample poll >in the mailing list: > >* What OS do you run geda applications on? Debian GNU/Linux (testing and unstable); 6 PCs + the laboratory at the univesity (12+6 PCs) >* How did you install your copy of geda apps? Debian repositories; I also have cvs version of PCB and i build .deb from that and install from my private repository. > >* Which apps do you use. What is your typical workflow? gschem -> gsch2pcb (using custom Makefiles) -> PCB -> gv/gs for printing -> toner transfer >* Did you (have to) modify portions of geda to suit your needs? not yet (thanx for the great community and support) but I plan to develop my own PCB plugin so that can run scripts which can manipulate PCB internals on the fly. >* What is the general flavor of your projects? (analog, digital, HF) very simple digital circuits, usually with microcontrollers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [pcb] merging layers and pasting
On Sat, 12 Apr 2008, DJ Delorie wrote: >In the case where we can't figure out what to do, I think a pop-up >dialog would be appropriate (the HID has a way to do this already). Could you give a pointer to some documentation or location in the sources? I have been waiting for this feature for some time... :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: random project idea
On Thu, 27 Mar 2008, Larry Doolittle wrote: >On Thu, Mar 27, 2008 at 09:28:23PM -0500, John Griessen wrote: >> Larry Doolittle wrote: >> > Self-reconfigurable FPGAs have been promised for years, but aren't >> > ready, and probably never will be. >> I guess that's because the fpga makers seem to not want to let out their >> programming details -- probably because they let Mentor and Synplicity >> and the like do all their tools and THEY don't want it let out. > >Tools are certainly part of the story. But it also strikes me as >a chicken-and-egg problem. The user's don't demand or exercise the >tools because of the conceptual problems and the silicon limitations. > If we are at tools, I wonder... Is there an FPGA family that I could use without using non-free software at all? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB windows on a small screen
On Sat, 23 Feb 2008, Peter Clifton wrote: >(Deliberately on geda-user list to solicit a wider opinion on this) > >Hi, > >I'm just linking an Ubuntu bug report here in case it is of interest: > >https://bugs.edge.launchpad.net/ubuntu/+source/pcb/+bug/111405 > >PCB struggles on a small screen (1024x768 is still relatively common), >and the OP wonders if we should be shipping with the default layout >being a more compact one. I often use even smaller desktops :) >Its a difficult question to answer though, as the layout is such a >matter of personal preference. I don't think there is any obviously >correct way to figure out a default at run-time either. > >We "could" query the size of the screen, and make the default layout >options respond to that, however I'm not immediately convinced this is a >good idea. Should be done install time or first run. It would be annoying if the user set up something, then quit and restart and pcb says "hah, I know it better what you need" and decide instead of loading the previous user settings. If an ultimate default is needed, I vote for the compact layout, because having it on large screen hurts less than having the non-compact layout on the small screen. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Couple pics from my new PCB
On Sat, 22 Dec 2007, DJ Delorie wrote: > >> http://ad7gd.net/geda/panelusb-sm.jpg > >Am I the only one who tries to make the absolutely smallest board I >can still fit my parts on? My latest board would fit in the blank >spots between your chips. I do that too - saves cost but it's bad when I have to debug or replace or add parts. Btw, how do you guys solder those big SM chips with so many pins? I've just bought a chip with TQFP64_10, managed to iron and etch a board for it but I am still not sure how I would solder the chip. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb 20070912 and GTK trouble + another bug?
On Mon, 10 Dec 2007, DJ Delorie wrote: > >> btw now i can't see the red wireframe helpers while i'm drawing a >> line (latest CVS). > >If you mean you can't see them when you're autoscrolling because the >mouse has left the window, that might be my patch. Yes, _while_ I am autoscrolling, but that's ok. But it seems once I autoscrolled while drawing a line, it turns out the wireframe lines permanently and I don't see them even when drawing without autoscrolling. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb 20070912 and GTK trouble + another bug?
On Mon, 10 Dec 2007, Peter Clifton wrote: > >On Mon, 2007-12-10 at 07:13 +0100, Igor2 wrote: > >I hope this bug-reporting and testing is all against the latest CVS >version.. as many of the bugs with GTK hid + 20070912 have been fixed >there. yup, latest CVS by the time of the patch creation; btw now i can't see the red wireframe helpers while i'm drawing a line (latest CVS). I am not yet sure whether it's related to my local changes but i will test. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb 20070912 and GTK trouble
On Sun, 9 Dec 2007, Ben Jackson wrote: >On Mon, Dec 10, 2007 at 05:53:38AM +0100, Igor2 wrote: >> >> I've spent a "few" hours debugging this. I've submitted a bugreport on sf >> (http://sourceforge.net/tracker/index.php?func=detail&aid=1840422&group_id=73743&atid=538811) >> I've found that the bug is related to grid and grid snapping code and >> also depends on what's the grid offset compared to the drawing area >> is. Please see the comments in the bugreport. > >If you mean 'pcb-gtk-pan.patch' I just applied that and I can still >reproduce the jumping. It might even be worse. I set the grid to 100mil >and zoomed way in and it jumps every time I mouse out of the work area, >basically. It's almost like an auto-scroll? Yes, it still jumps away - it just won't jump back. Jumping away is caused by one bug, jumping back is caused by another, the patch fixes the latter. I am not sure the patch does the proper thing, since I am no gtk expert (actually I hate to code any kind of GUI) - but at least here it fixed half of the problem. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb 20070912 and GTK trouble
On Sun, 9 Dec 2007, DJ Delorie wrote: > >Is this similar to the lesstif bug I fixed a while ago, where grid >snapping causes the crosshair to leave the window? I don't know the fixed lestiff bug, but this gtk seems to be what you described. The other half of the bug was that after scrolling away, it forgot to update some GTK scroll states while it updated others, this why it jumped back on the next action that tried to scroll. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb 20070912 and GTK trouble
On Sun, 9 Dec 2007, Stefan Salewski wrote: >Stefan Salewski wrote: > >>Now we should try to find the reason for the jumping window content. > >I will try to describe this bug more detailed: > >The jump of the inner display occurs, when the mouse pointer touches the >border of the inner drawing area. It is not related to the sliders (at >right and bottom of the window, for panning.) Jump occurs also when I >move the mousepointer to the top window limit, beside the pulldown menu, >where no action element is located. The displayed area changed, and the >coordinates displayed in the upper window border reflect this position >change. > >If I press the right mouse button and do a minimal mouse movement >(minimal panning) the window content and the position display jumps back >to the correct value. > >If I use the middle mouse wheel to change zoom, display will not jump >back to correct position. > >The jump occurs if the pcb window is maximized or smaller. I've spent a "few" hours debugging this. I've submitted a bugreport on sf (http://sourceforge.net/tracker/index.php?func=detail&aid=1840422&group_id=73743&atid=538811) I've found that the bug is related to grid and grid snapping code and also depends on what's the grid offset compared to the drawing area is. Please see the comments in the bugreport. I've also submitted a patch there (and a notify about this on de geda-dev list) that partially fixes this bug and probably a number of other bugs that may happen when PCB wants to scroll somwhere to show something to the user (DRC?). The patch won't stop PCB to jump away, but once it has jumped away, at least it stays there so next time you pan/scroll/zoom/click it won't jump back to the previous position. This is not a workaround - the patch replaces a FIXME in the code. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: opinions on move-line-to-layer via removal?
On Sun, 2 Dec 2007, Kai-Martin Knaak wrote: >On Sat, 01 Dec 2007 20:57:08 -0800, Ben Jackson wrote: > >> 3) As in (2), but the via-creation code is changed to set AUTOFLAG (so >> the via is "created by the autorouter") and only vias that were auto- >> created in this was are removed (other rules same as (2)). > >No. This would lead to an unexpected loss of vias on "rip up all >autorouted tracks". What about introducing a new flag so it doesn't collide with the autorouter? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda project manager
On Mon, 17 Sep 2007, Dennis Veatch wrote: >On Monday 17 September 2007 09:53:48 am Peter Clifton wrote: >> On Mon, 2007-09-17 at 09:10 -0400, Dennis Veatch wrote: >> > Ok, at the risk of sounding like a moron. Where would be the download >> > link for the project manager, version 1.2.0.20070902 ? The last version I >> > was able to download was from (that was a while back); >> > >> > ftp://ftp.geda.seul.org/pub/geda/devel/20060123 >> > >> > I don't see it anywhere on the sources download page. >> > >> > Thanks. >> >> The project manager has been deprecated for some time now, and was >> removed from releases as it is no longer developed or maintained. I'm >> not totally familiar with the problems it had, however I'm assured it >> did have some issues. >> >> If you're looking for a GUI tool for the gschem -> PCB workflow, the new >> (and not yet officially released) xgsch2pcb tool might be of interest. >> At the moment, only development versions exist in the git repository: >> >> http://git.gpleda.org/?p=xgsch2pcb.git;a=summary >> >> NB: You must also use a relatively recent version of PCB, and >> specifically compile it with DBus support. (This allows xgsch2pcb to >> push changes from the schematic into a live, open copy of your layout. >> It doesn't work without this support). >> >> Regards, >> >> Peter Clifton >> > >Ah thank you, that is some good information. Btw, if you plan to sue a deb based system on i386, I have some .debs recently packaged with CVS version of PCB compiled with DBUS and latest version of xgsch2pcb. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Marketing gEDA - was - Re: Professional PCB help using geda?
On Thu, 6 Sep 2007, DJ Delorie wrote: > >> I have only one pending feature request which keeps me back from >> finishing my scripting plugin for PCB :) > >Which one is that? gadgets or wizard or whatever dialogs (you had an idea for the proper name). They would be dynamic like the output dialogs, so a plugin could present its settings. Unlike output-related plugins, a "wizard" plugin would modify the current PCB. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Marketing gEDA - was - Re: Professional PCB help using geda?
On Wed, 5 Sep 2007, DJ Delorie wrote: > >> DJ, so a slowly growing base is more preferable to a rapidly growing >> user base and I should not try encourage people to give gEDA a try >> on a wholesale level ? > >It depends. For example, getting a school, classroom, or other >organization to try it as a group is different than getting the same >number of people to try it individually. As a group, they can work >together to solve many of their individual problems and share >solutions, feeding only the worst problems to us. I did exactly this a year ago and will do it again this semester. My "input" is mechanical engineer students who choose to take an exotic tour in electronics (very basic, blinking leds, a PIC hooked on serial line of the PC doing something simple, etc). I use gschem, xgsch2pcb and pcb on Debian/GNU Linux for these. My experience is that for average students the UI itself is less problematic than a non-windows system. I'm lucky because these guys haven't used other EDA tools before so it's not like they expect some sort of UI "standards", however they usually have experience with 2 or more mechanical engineering CAD software. My experience about the developers and gEDA community in general is positive. Whenever I asked for a feature or submitted a patch, sooner or later it was done in the repository. I have only one pending feature request which keeps me back from finishing my scripting plugin for PCB :) Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [pcb] drill helper
-- .O. ..O OOO On Tue, 15 May 2007, DJ Delorie wrote: > >Having made a number of boards at home now, I'm thinking the drill >helper could be better. My local copy does this instead: If you check >"drill helper", all pins are drawn with a much smaller drill hole. >I.e. it doesn't draw the normal-sized hole at all, so if the drill is >off-center, you won't have a gap between the hole and the copper. >Instead, it only etches a small amount of copper at the center, to >help you center the drill. > >Comments? Good idea, what would be the "much smaller drill hole"? If it's too small, it can disappear with toner transfer, if it's too big it doesn't center the drill. I would suggest ~0.4 mm. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: VMWare image of Ubuntu distribution of Linux with gEDA installed.
On Tue, 3 Apr 2007, John Griessen wrote: >Steve Morss's VMWare image with gEDA is available on my server until people >use up too much >bandwidth. That will happen after 50 downloads > >See http://foseda.com/ the link gEDA-on-Linux-on-VMWare > >John Griessen > >PS I have not tested it yet. Do you have a checksum for it Steve? > I've downloaded it and put it online at http://user.peticio.hu/geda as this host doesn't have traffic limit. However don't expect too high download speeds from outside of Hungary. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: Looking for a project
On Sat, 31 Mar 2007, Kai-Martin Knaak wrote: >There is a project called comedi which aims to provide a common linux >interface to all the A/D converter cards on the market. > ---> http://www.comedi.org/ >This is a long lived project with roots back in the early nineties. The >list of supported cards is quite impressive. I successfully used comedi to >read from an National Instruments card PCI-6071E. NI was a let down. They >promised a linux driver but delivered a proof of concept piece of >software that could not access the features I needed... I can comfirm, had to use an advantech PCL 817 for a project and comedi had support for the card (however i couldn't get the dma to work). >Open source A/D hardware should come with a comedi driver. I agree. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Looking for a project
On Sat, 31 Mar 2007, DJ Delorie wrote: > >> That clock advances one *day* at a time. > >"I am going to a commune in Vermont, and will deal with no unit of >time shorter than a season." That book is the best. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: File corrupted after segmentation fault in pcb
On Sun, 18 Mar 2007, Andy Peters wrote: >On Mar 18, 2007, at 8:06 PM, Igor2 wrote: > >> On Sun, 18 Mar 2007, Mikael W. Bertelsen wrote: >> >>> If I take a look at the bright side, this incident did convinced >>> me to >>> finish my backup script which takes an hourly snapshot. Backup is not >>> so bad after all. >> >> Why don't you use some sort of version control instead? :) > >What if the crash occurred before he was ready to commit a change? He was talking about hourly snapshots; normally with a version control, you prefer to commit changes in small sets, and I assume creating such a small changeset takes less time than an hour :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: File corrupted after segmentation fault in pcb
On Sun, 18 Mar 2007, Mikael W. Bertelsen wrote: >If I take a look at the bright side, this incident did convinced me to >finish my backup script which takes an hourly snapshot. Backup is not >so bad after all. Why don't you use some sort of version control instead? :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Sun, 18 Mar 2007, al davis wrote: >> * Finally, how should PCB behave with a hierarchical >> schematic? > >Right click on a symbol, select "go inside", and another drawing >opens up showing what's inside. gschem also should act this >way. I like this idea very much. In case of PCB it also would make sense to add a way to display in place what's inside. With an "expand all" functionality this would allow one to see the whole pcb with all inner structures at once, without needing to export to ps. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design Flow Roadmap starting point
On Fri, 16 Mar 2007, John Griessen wrote: >John Griessen wrote: >> So, "What do you want? > Please add this to the list: [PCB] an interface for presenting dynamic dialog boxes for importers and wizards similar to the exporters. This would help some plugins to integrate better in the GUI. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: Re: gEDA-user: TOP-3 package
Thank you Wojciech Kazubski and John Luciani, I have drawn a footprint for a stnading and a laying TOP-3 which then i compared with TO247. As soon as i get the actual devices, i will see how much they match :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: TOP-3 package
Hi, Local electronics store sells BD249 and BD250 with TOP-3 packages. The datasheets I found on the web say BD249 is SOT-93. I can't find footprints for either pkg in PCB or gedasymbols.org; does anyone know an equivalent footprint I could use? If there is none, is there a standard source to acquire information about those standard packages to draw my own footprint or do I need to trust a random manufacturer's datasheet? (Unfrotunately the store's web catalog doesn't tell anything about the manufacturer) TIA Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [pcb] long list of minor fixes
On Sat, 3 Mar 2007, Ben Jackson wrote: >On Sat, Mar 03, 2007 at 10:25:36PM -0500, DJ Delorie wrote: >> >> While on a trip to visit relatives, I got some time to tinker with >> PCB. I found time to fix/tweak/add many things... > >Sounds like what happens when *I* "go on vacation". Nice job. > > >> Added "lock names" setting: >> Added "only names" setting: > >I had noticed that the 'move' tool seemed to make it easier to move >names. Was that just my imagination? > >This reminds me that PCB needs a "Did you know?" style "tips" system. >I had considered writing a plugin to do it, but those most in need of >tips won't know about plugins. I think it still would be a good idea to keep it in a plugin because there are people who would not like such system (including me). Yeah, I know that today computers have gigabytes of ram so it's ok to have features you will never use compiled in, but I have an older computer and I dislike bloat even on new ones and we have a nice plugin system :) Anyway nice fixes DJ! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: scons
On Thu, 1 Mar 2007, Dan McMahill wrote: >Igor2 wrote: >> On Wed, 28 Feb 2007, al davis wrote: >bash is not always there by default but /bin/sh _is_. And it's not that >hard to write shell scripts which are portable. As far as make is >concerned, you can usually count on having some make implementation >around. The trouble is that there are lots of make extensions which are >all non-compatible. My take here is if you have to rely on some extra >feature it should be in GNU make just because many users have already >had to install GNU make for other packages. Yes, and this is the drawback: gpmi depends on bash and gnu make. >I've seen plenty of packages that use autotools that try to store >pointers in ints. Not portable but worked on x86-linux. Of course it >fails on an alpha or x86_64. I've seen plenty of packages that for one >reason or another cared about byte order. Those tended to fall into 2 >categories, the ones that had a broken homebrew detection and those >which used the autoconf test and got it right. Yup, you can't totally ignore portability. On the other hand, casting pointers to ints is a bad habbit, even if you don't plan to port the stuff. What I learned and what I wanted to suggest: keep the code clean in general (no ptr->int casts, do not depend on sizeof(int), do not depend on undocumented "features") _and_ move all #ifdef chunsk in named high level procedures. >> The configure script is a shell script (unfortunately depends on bash, >> not sh). It's modular: there's a huge (20k) central script that > >well, so there is problem #1. bash is only there by default on linux. >So step #1 on solaris would be "figure out why the configure script >won't run, install bash". Unfortunately I run into this all the time >and often times it is simple stuff like using "==" instead of "=" in >lines like > >if test "$x" == "$y"; then ... > >Of course I see people put non-portable stuff like that in configure.ac >as well. Yes, again, we do depend on bash and the script starts with #!/bin/bash not with #!/bin/sh. This is a dependency, as if the script was in python or m4. >> way). General settings (like prefix or whether an option is enabled or >> not) are simple shell variables during the configuration and some of them >> end up in an includable Makefile and in an includable shell file so later >> other Makefiles or scripts can use settings without running the whole >> configure process again. There's a shell file that has the default >> settings for all these variables with rich comments; the comments are >> structured in a way that a small script (<7k) can present a menuconfig >> using dialog(1) - it looks like menuconfig of the Linux kernel, with >> nested submenus. The user can use --with arguments for the configure >> script or use a local.conf file where he can modify any of the >> variables (note that this file is a shell script so he can build some >> basic logic here). > >which means that 3rd party packaging systems which might build things >automatically have to have their own custom ways of configuring the >tool. Granted it is probably not hard, but it just adds up for those >trying to maintain a large number of packages. Sorry, I can't get this one. Configure script runs without assuming on what system you are on - it rather tries to discover the system. Autodetecting script libs is part of this. When you are packaging, you expect the software can be easily installed so you can copy/move the installed files into the package. We can build .deb, .msi and .rpm currently and we didn't have hard time doing them because the lack of autotools. For example debian/rules runs configure make and make install, and it doesn't need to have any custom ways. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Why use gEDA?
On Thu, 1 Mar 2007, Ales Hvezda wrote: >[snip] >> We need a plugin list at the gEDA home page -- which will change sometime >> before >> summer...and maybe get some updating. >> > >The physical server might change, but "home page ... will change sometime >before summer ...", nothing definite has been decided. > >I've been seriously toying with moving the whole or maybe just parts of >the project to sourceforge. Yes yes, everybody who hates SF has already >spoken up, so no need to reiterate your views... :-) > >-Ales I can offer space on my server (will be up in a month or two, hopefully) for the project. It will be hosted in a server hotel, 100 MBit towards the Hungarian backbone but much smaller international line. I think it could be a backup mirror or something like that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: scons
gpmi we decided to separate these issues into os_dep.c/os_dep.h; I'm so happy with this scheme that I tend to follow it in other projects as well. The idea is to create a compatibility layer which has all the ifdefs. For example we have gpmi_path_init() call there, which sets up some basic paths: on windows using the registry and using backlashes, on UNIX using the prefix info got from Makefile (and indirectly configure) and slashes. We need to do foobar but that is done differently in BSD and in windows? We just add a foobar() in os_dep. Sometimes it's just a wrapper to call the same functions with different names for different systems or to rearrange the call arguments, sometimes the whole logic differs. Yes, this is definetly reinventing the wheel. For example Apache has a nice compatibility lib or actually even automake offers solving the porting problem. I am sure automake knows more systems than I do, and I am also sure Apache devs know more about porting than me. Still, if one of my aims is to keep things small and simple, I simply shouldn't reuse their work. Sometimes reusing existing work/code saves time, sometimes it wastes time :) -- Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: VMPlayer Image
On Sun, 18 Feb 2007, John Griessen wrote: >Igor2 wrote: >> About debian, i had such a project some time ago > > The only part >> that actually needed some thinking was how to get it work in a chroot with >> the already running X server. > >[jg]Is that a working thing, now? Yes, as it's totally independent of the host linux, as long as the host has an X server and mount --bind and chroot, it should work. > A nice example on using >> squashfs is iSteve's Olive, which is a live cd featuring abiword, mozilla, >> irc clients and other common apps and takes only about 70 megs > >[jg]That sounds good for putting on a USB flash drive...which might seem even >more convenient to some than turning on VMware -- only for customers with a >linux box of course, and we were talking windows... You would need to replace the booting process i think (it boots with isolinux which is for CDs, i am not sure what's needed for usb). For windows, if i get it right vmware would run a linux from an image, and i wanted to point out that we already have a relatively small tarball which could be used as a base for such an image. > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: VMPlayer Image
On Sun, 18 Feb 2007, John Griessen wrote: >Mike Hansen wrote: >> >> That would be perfect, question is will the gEDA suite run on it? > >It takes a little work to get one of those set up. It's possible. >Debian is easier to set up a distro with minimal anything beyond what gEDA >needs. Fedora is already done. How much different would the VMware image be >from Fedora to damnsmalllinux? The VMware binary still is a large chunk of >that >500MB Fedora image I bet. > About debian, i had such a project some time ago (you may remember it John, you have tested it for me). It is a big tar.gz (~60 megs) and it unpacks a debian with all the libs and binaries needed to run (an old version of) geda and pcb. It was not too hard to create it. The only part that actually needed some thinking was how to get it work in a chroot with the already running X server. The tarball was intended to solve the problem of non-debian linux users who didn't want to install dependencies (but had an X server and chroot installed, both considered a common thing imo). To make it standalone, one would need to add an X server and a kernel and maybe some basic programs to communicate with the host system (depending on what emulator is targeted). I think a compressed tarball or image still could be below 128 megs, which should be acceptable for the target audience. For compression I would recommend squashfs in the long run. A nice example on using squashfs is iSteve's Olive, which is a live cd featuring abiword, mozilla, irc clients and other common apps and takes only about 70 megs to download. In case anyone wants to try the chroot geda out or experiment with the idea, the url is http://inno.bme.hu/~igor2/geda-test ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: dxf?
On Thu, 8 Feb 2007 [EMAIL PROTECTED] wrote: >Igor2 wrote: >I'll need to find some way in the >> HID API to provide interface for the user to run scripts (like tiling >> scripts). For exporting it's easy, the export dialog is extensible. I >> think there should be a similar Import interfce and a 3rd one, which I >> can't find a good name for, to run plugin functions that would not >> import/export but would change the PCB itself. > >Of course. I tested some of the first efforts you made. Yeah, I remember (thanx again), that was the pre-plugin ages. Now we have a proper way doing all this. >You have a hook in the source code now so you can use >the GPMI library, right? To me it seems the import interface >is just the idea of the outward acting HID API functions. Once we get the >inward acting ones done, they would not have to be just one way... We could >call >it the external in out interface or some such language. You are wanting >a no compile way to hook in -- that's great! Perhaps a c coded plugin could >do >the interfacing to GPMI? It would not be a very specific plugin, just a >presenting of the internal function names so external scripts could use them >by >name and parameter list as in a subroutine call. Yes, but actually it can be written more in a more elegant way. The plugin needs to be only a thin wrapper that loads GPMI and the specific module for the language you have your script in, then the script itself could load small packges to access internal functions. I planned to have about 6-8 such packages, like one for manipulating the drawing, another related to hid-registering and so on. This means a script doesn't need to load tons of bloat it will never use. >Does GPMI convert all the many ways in scripts to define a subroutine call to >one form? If so, that one form could be what the "scriptio" plugin transforms >into a HID API function call. GPMI has an unified interface towards the scripts which covers calling package functions from the script (which then can directly call pcb internals) and delivering events to the script(s) (which actually may result in function calls in the script, depending on hwo the script bound the events). All this doesn't need any modification in the host app, if we have the plugin support which we already have. The only thing that needs modifications in PCB itself is the GUI: currently I see no proper solution for displaying simple dialog boxes similar to the exporter. Of course when I write a script for tiling I could pretend that it's an exporter, register an exporting hid but then instead of writing a file just call PCB interlans trough the interfacing packages to modify the layout data, but it would just be an ugly hack :) >I will help some more with testing. I gave DJ's plugin code examples a look, >( >* RenumberBlock * Teardrops ), and they are maybe obvious to him, but > the >c language without comments was opaque to me... I will welcome a script >interface. > Ok, if we can meet on irc this weekend, and we could work out some way to share the tasks. I think togehter we could make it all work in less time. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Re: dxf?
On Wed, 7 Feb 2007 [EMAIL PROTECTED] wrote: > >> As I recall a pcb "importer" is a concept not yet implemented in the HID way >> of doing things, for it is not a printer and is not an exporter. >. >> Bert Timmerman. > >There's the plugin way of implementing. It lets your code use the PCB API. >DJ has examples of c coded plugins. > >I wonder if we could make a plugin with python somehow -- with or without >a SWIG or other c wrapper? > >John Griessen I'm working on one, but with a lib (so no direct python). Currently I don't have any time on that project but I hope I can start working on it again in a few months. It'll support all scripting languages GPMI supports (tcl, php, python, ruby, lua, ghli (pascal), stutter (lisp)). It's a plugin. Before I can get it all work, I'll need to find some way in the HID API to provide interface for the user to run scripts (like tiling scripts). For exporting it's easy, the export dialog is extensible. I think there should be a similar Import interfce and a 3rd one, which I can't find a good name for, to run plugin functions that would not import/export but would change the PCB itself. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: hidden gui "state" in PCB (gtk-hid)?
On Wed, 7 Feb 2007, Matt Ettus wrote: >When using the gtk-hid for PCB, I see some strange behaviors every now >and then. For example, usually when I press "z", it usually zooms. >However, sometimes it gives me the message "click on focus for zoom" >or something like that, forcing me to either click, or to press "z" >for a second time. It will be in this alternate mode for a while, and >then will go back without warning. I can confirm this. When the mosue cursor is on the drawing and I press "z", it works fine. When the cursor is over menus or buttons, pressing "z" disables all controls (layer selection, menus, everything) then pressing "z" again enables them and zooms. I get the same with "Z" as well. However, I've never seen the "click on focus for zoom" message. >Any ideas? I am using CVS as of 2 days ago. I'm using an older CVS, but I remember having this issue for long; it's easy to get used to it once you find out where you shouldn't press "z" :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GPL and BSD (was: strange build failure)
On Wed, 13 Dec 2006, DJ Delorie wrote: >Also, consider a cell phone with GPL'd software in it. Does copyright >cover the cell phone? It's hardware, but it includes copyrighted >works within it. Can we say the same about the layout of a circuit >board? I don't know. Fair use might come into play, the "works" >might not be sufficiently unique, etc. This is, IMHO, similar to the >issue of copyrighting fonts used for print. Interpreting a license is always a problem. It's a problem for programmers since they are not lawyers to understand all the legal parts to infinite depths and it's a problem for lawyers because they don't understand every little thecnical part. There are always gray zones depending on common sense and intentions. A good rule of thumb about GPL may be to check what GNU or FSF says, recommends or suggests or even how they interpret their own licenses. For this case, they have a point in thier faq (http://www.gnu.org/licenses/gpl-faq.html#GPLOutput): "Is there some way that I can GPL the output people get from use of my program? For example, if my program is used to develop hardware designs, can I require that these designs must be free? In general this is legally impossible; copyright law does not give you any say in the use of the output people make from their data using your program." This clearly applies to PCB but still it's a question how a schematic symbol is related to the final hardware product. Maybe it is worth to ask FSF (in case the symbol and/or footprint is under the GPL). Igor2 P.S. DJ, I tried to send you a mail in private about the challenge boards but your mail server seems to drop my mail considering it a spam. I use the same email address and host as for this mail. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcb exporing problem
On Sun, 10 Dec 2006, DJ Delorie wrote: > >Your board is 30 inches across. It doesn't fit on a page. > >It prints just fine if I change the board size to 5 inches. Thanx, resizing helped :) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: strange build failure
On Tue, 5 Dec 2006, Michael Sokolov wrote: >Andy Peters <[EMAIL PROTECTED]> wrote: > >> a) (Most) Hardware guys want to design and implement hardware. Tools >> are the means to that end, not the end in itself, and we'd rather do >> our work than deal with tool build failures. > >I just feel like adding one different data point. > >I come into the world of hardware design from a software background. >And not just any software background, but specifically a religiously >zealous free software background, and specifically UNIX, all command >line and non-visual. It's just like if you were describing me, especially the text-oriented part, 80x25 (or 80x24 on a vt terminal) forever ;) However, I admit I need to use visual tools when the task itself is visual, which is the case for laying out a PCB. As long as I find the interface comfortable (for example I can use the keyboard for giving commands to save time on clicking and use the mouse mostly for entering coordinates), I'm happy to work with an GUI on the visual part. Fortunately both gschem and pcb provides an interface I like. Btw, about the windows users, I think it's important to make the intended audience very clear. Reading back the rich mailing of the previous days, yhis mostly happened. As I think this issue would raise from time to time, it might worth to write a short summary on a webpage or a wiki or whatever is fashionable nowdays. On the other hand, it seems there's need for a windows port while there's noone has the energy and time to do it, unless paid. Maybe it would make sense to set up a sourceforge project for a native windows port and ask for donations. For example get someone who has the skills to do the port, ask him how much it would cost and then tell: "dear windows user, we collect money to pay this developer, as soon as X amount comes together, he starts working on the port." Then if there are really so many windows users, I guess they could put together the money, if not, they should go and invest even more money in buying a commercial CAD. Finally, about a live cd. Some devs may remember that I made some minor efforts in creating a working chroot environment for gEDA a few months ago. It was promoted only on the geda-dev list. Meanwhile I had to put together a live cd for my students as they have windows at home. I've spent much time on getting the CD working well, but still it has many problems. Majority of the problems are not related to gEDA or chroot, but: - as mentioned above, I'm a text console oriented guy so I don't know much about GUIs thus I have no idea what a real GUI user needs; mount is so simple that first I didn't provide a GUI tool to make my students able to mount their USB pendrives. - I use old hardware from the pentium I era, so I have no idea what to do when my kernel fails on one of the user's computer because it's the latest 64 bit processor with n+1 cores and whatever APIC/ACPI/APM/SATA totally unknown to me :) If anyone is interested I can share the chroot which can be put on any live CD or just run from HDD (it's not small, I didn't have to optimize for size as I had a whole CD). At least if there's user feedback and enough contributors, I think there's more chance to produce an usable live CD than a windows port. Windows users also should consider trying colinux with the live cd or the chroot environment, whichever is possible. The chroot stuff and/or the live CD offers "you don't need to install, there's no dependency you need to care about" thing, which is what some users want, if I got it right. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: smd challenge boards
On Sat, 11 Nov 2006, DJ Delorie wrote: > >15 left... If nobody else here wants one, I'll post a message to >usenet to sell off the rest. If you want me to hold one for you, let >me know. I would like 2 of them; is there any european redistribution set up already? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [pcb-gpmi] scriptable exporter
Hi! Today I've finished the first working version of the scriptable HIDs. The external hid feature and related patches recently added by DJ enables the scriptable exporter to load in a clean way. Currently it is capable to register exporters written in any script language supported by GPMI (ghli(pascal), lua, perl, php, python, ruby, stutter(lisp) and tcl). It generates enough events so the script can produce the desired output. For now only a very simple test script is provided which simply prints the names of the layers and lines on stdout. Software requirements: - the CVS version of PCB - the lib for the script language(s) you plan to use (tcl8.4 for the test script) - the svn version of GPMI (svn://svn.libpgmi.org/trunk) - pcb-gpmi (http://inno.bme.hu/~igor2/tmp/pcb-gpmi-1.0.2.tar.gz or svn://igor2.peticio.hu/pcb-gpmi/trunk) There's a Readme file in doc/ which describes the installation process step by step. Test results, suggestions, feedbacks are welcome. Regards, Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design changs required to mill PCBs?
On Wed, 4 Oct 2006, Robert Fitzsimons wrote: >> Do you still have the code? would you share? I have an old plotter and >> learned some HPGL years ago, even wrote some simple plotting tools. Now I >> would use HPGL as an example exporter with the scriptable PCB project. > >I didn't see a response from Dave, but I've attached the code wrote to >work with my plotter last year. It is able to convert a DXF file to >HPGL format. > >Hope it helps. Thanx, it's extremly useful, I will be able to reuse many functions :) Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Design changs required to mill PCBs?
On Mon, 2 Oct 2006, Dave McGuire wrote: >On Oct 2, 2006, at 8:19 PM, Bob Paddock wrote: >> What I always wonder about with these tools, or similar X/Y >> machines is why >> no one ever optimizes the travel to save time. Seems like it >> should be simple >> mater of sorting the vectors? Instead the machine goes at random from >> place to place. > > Years ago, I wrote a bunch of code which generated HPGL to drive a >plotter. I sorted the vectors for exactly this reason. It made a >BIG difference in plot time. Do you still have the code? would you share? I have an old plotter and learned some HPGL years ago, even wrote some simple plotting tools. Now I would use HPGL as an example exporter with the scriptable PCB project. > > -Dave > > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB a bad name ?
On Thu, 21 Sep 2006, Samuel A. Falvo II wrote: >Here's a possible suggestion for compromise:- > >Retain the current, keyboard-centric user interface. There is no need >to change it, and on top of that, you'd P-off a whole lot of currently >happy users. But for those who are new to the product, enable a mode >of operation whereby when the mouse hovers over an item for, say, 2 >seconds, a semi-transparent balloon would pop-up listing the keyboard >commands that are valid and applicable to that object. As soon as the >mouse moves off that object, the balloon disappears and the process >repeated. > >To retain the old-style user interface, just go into your settings and >turn off "balloon help." > I would hate having an extra function I wouldn't ever use (the extra bloat, compile time and whatever). What about forking the gtk hid, so we would have a gtk hid that works as now and another that has balloon or even some extra clicky-clicky feature? Of course, it would make more sense if HIDs could be loaded runtime :) Before that, there could be 2 binaries and on download and/or install and/or ./configure the user could choose. I'm not sure how comfortable to manage 2 branches of the mostly same HID with cvs, it's more or less ok with SVN (but means extra work of course). Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PCB] external hid bugfix
Hi, As John Griessen pointed out, the Makefile of host_lib wanted to run gpmi-config. Actually the host_lib doesn't really need GPMI so I've removed all references from there. New version can be downloaded from: svn://igor2.peticio.hu/pcb-gpmi/trunk http://inno.bme.hu/~igor2/tmp/pcb-gpmi-1.0.1 This time following the process written in the Readme should really produce usable binaries. Regards, Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [PCB] external (dynamic loadable) hids
On Thu, 14 Sep 2006, John Griessen wrote: >Igor, > >I followed the Readme instructions and put link to pcb source inside your >directory pcb-gpmi/trunk/src >ran commands and got this: > >[EMAIL PROTECTED]:/moredata/src-pcb-unique-geda/pcb-gpmi/trunk/src$ >./configure >--prefix=/opt/pcb-gpmi >Found pcb source dir: pcb >[EMAIL PROTECTED]:/moredata/src-pcb-unique-geda/pcb-gpmi/trunk/src$ make >cd host_lib; make >make[1]: gpmi-config: Command not found >make[1]: Entering directory >`/moredata/src-pcb-unique-geda/pcb-gpmi/trunk/src/host_lib' >Makefile:9: /Makefile.config: No such file or directory >make[1]: *** No rule to make target `/Makefile.config'. Stop. > >Have I misunderstood the instructions? > >John G Ooops, sorry, my fault, forgot to mention in the readme that you need GPMI installed (svn://svn.libgpmi.org/gpmi/trunk). Anyway this version doesn't really use GPMI yet so I think I should fix the cofigure script so it could go without GPMI as well. Regards, Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [PCB] external (dynamic loadable) hids
Hi! The first version of pcb-gpmi is finished. It contains a host lib, which can be loaded in pcb without recompiling pcb and an example guest lib. The host lib is able to load any amount of guest libs. Each guest lib then can register itself as a HID. The example guest lib is a board summary exporter which generates a text file with some info that may help calculating the price of manufacturing. Currently only number of holes are printed (the code was copied from report.c), later board extents and number of layers should be in the file as well. The next step is to develope a real guest library, a plugin system that can load scripts using GPMI. This project aims to provide scriptable tools for pcb as a separate project. This means pcb itself won't have new dependencies and the user should be able to use this project without recompiling pcb (or even without having to install the source of pcb). This release is a pilot release to see how pcb users/developers like it. URLs: svn://igor2.peticio.hu/pcb-gpmi http://inno.bme.hu/~igor2/tmp/pcb-gpmi-1.0.0 Regards, Igor2 P.S. yes, the host lib does ugly tricks and generates a few error messages. With the current version of pcb this was the only way I could make it load without having to patch pcb. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-dev: Re: gEDA-user: New features in gattrib
Sorry, missed from the last mail: about portability, for I meant windows for the other protocols (TCP, UDP); They all use the same network.h in that lib. I think unix sockets are not supported on windows (but changing the code to use TCP instead is not a big deal). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-dev: Re: gEDA-user: New features in gattrib
On Mon, 14 Aug 2006, al davis wrote: >On Monday 14 August 2006 12:59, Stuart Brorson wrote: >> However, doing any sort of >> IPC between gattrib and gschem is not on my radar screen. >> Therefore, any discussion of pipes vs. TCP/IP, 802.11g, or >> OC-192 is pointless. Unless somebody wants to implement it >> themselves and send me the patches. > >That's an invitation for someone else. Igor? I think I wouldn't go further than contributing the demo programs, mainly because I have a nice socket lib in gpmi which I would like to use but I couldn't (dependencies). I would end up rewriting or ripping that code instead of using the lib which is pretty much against my taste :) >Igor: >How about a pair of little demo programs. Make one send, the >other receive, just to demonstrate the concept. http://inno.bme.hu/~igor2/tmp/socketing.tar.gz I've ripped existing code from gpmi_extension which is under the LGPL, so the demo programs are LGPL too. The server listens using a local socket /tmp/gEDA.sock which it first unlinks (so you can restart the server and it will be able to bind the socket again). The server accepts the first connection then dumps anything it reads prefixing with "> ". The client tries to connect then sends the current time every second. On it's stdout it echoes it so it's easy to check whether the server really received the same data (prefix is ">> " here.) I've cut off most of the portability layer (network.h) so it compiles only on UNIX now but gpmi_extensions version compiles fine on bsd, solaris, windows (both with cygwin and crosscompiling from Linux using mingw). >My reason for suggesting a pipe is that it looks like a file, so >it is trivial to implement. Besides the listen/accept and the connect parts, actual reading and writing is the same. This why we like UNIX: everything is a file :) Setting to nonblocking, using select(2) or poll(2) are all possible using only a few extra lines. Regards Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New features in gattrib
On Mon, 14 Aug 2006, al davis wrote: >One feature I would like to see is the ability to immediately >pass updates to a running gschem. > >This would involve opening a pipe between the two programs, and >passing the update as a message. With a pair of pipes it could >go both ways. > I would suggest using sockets instead of pipes if you want two-way communication between the two processes. There's no much difference between using UNIX domain sockets (AF_LOCAL) and TCP/IP on code level, but UNIX domain sockets are usually as fast as pipes. This means once you implement sockets instead of pipes, it will become much easier to change it from local sockets to TCP/IP which opens up possibilites like clustering, remote simulation, etc. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: footprints -- novice`s problems
>I use underlayer from adhesive sheets for this purpose >but there is another problem I won't warn you before >when I try to do this frist time I let the iron on the borard for a long >time >and the printing gets pour out Yes, too hight temperature, too long heating are sources of problems. The other problem is usually that it's hard to heat a big board in a way that all parts get exactly what it needs so often it gets pour near edges and it doesn't even melt in the middle. Cheap non-FR4 boards can't stand the heat and they blend. Even the best boards I did with this method has worse contours than the ones others draw by hand. If the toner is not very new, big planes may have contiunity problems and that's visible on the final board. Well, many problems, and probably it won't work for the first try, but once you learn the settings of the printer, the temperature of the iron, the quality of the paper, it's a nice method for hobby projects :) Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: footprints -- novice`s problems
>> So far for all my home made boards I used PCB's ps output printed on >> laserjet on special paper which then I put on the board and use an >> iron to transfer the paint from the paper to the board. I used 2 >> different laser printers, an Infotec and a HP and with both I had 1:1. Of >> course this doesn't mean that PostScript is always 1:1 and I guess it >> depends on the printer and other things, but I think you should >> give it a try :) > > Can you share info on this special paper? I would like to try this. > >-Dave > Someone sells special film for this purpose, and that costs much. I am not an expert, so I may be wrong on the mechanism, but I think the idea is that the laser printer doesn't use ink but some sort of polimer that is melted on the media. If the media is paper, some of the polimer paint works off in the paper. If you try your good old non-ball-point pen with normal paper, it 'drinks' the ink. However, if you use the special film, it has a shiny surface which won't 'drink' the ink or paint. The trick is not to buy that special film, but use some shiny paper with similar surface. This kind of paper is used for magazines and printed spam. It's usually thicker than normal paper. (I can't translate the name of the paper, my dictionary lacks this word.) I could buy some in a local decoration shop, in my experience most printers can handle ones between 100 and 130 gram/m^2. The critical part is when the printer tries to feed the paper and it slips. Someone reported that he was too lazy to buy such paper and used some spam or magazine. I haven't tested this, it may be an urban legend. I hope this helps; if my description was not useful enough, I could snail mail you a sample. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: footprints -- novice`s problems
>I'd do it with PostScript output straight from PCB, but I understand >that PostScript's 1:1 doesn't really mean 1:1 exactly. Or am I wrong? So far for all my home made boards I used PCB's ps output printed on laserjet on special paper which then I put on the board and use an iron to transfer the paint from the paper to the board. I used 2 different laser printers, an Infotec and a HP and with both I had 1:1. Of course this doesn't mean that PostScript is always 1:1 and I guess it depends on the printer and other things, but I think you should give it a try :) For testing maybe you should draw some big box, print it from ps and measure it. If it's 1:1, I think it's enough to print the footprints on paper and try the parts on it to catch most problems. Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: one-file ps
Hi! A very old version of PCB had a ps output with multiple files (named like "xxx_frontsilk.ps", "xxx_back.ps"), while the new versions produce a single ps with multiple pages. I like both approach, for some task the one big file is better, for others the many small files is better. In case there are other PCB users who would like to have one file per page sometimes, I attach a short shell script that can split up the multipage ps. Tested with the CVS version. If there's a more proper solution to get the same result without scripts, please tell me :) bye Igor2 ps_split.sh Description: Bourne shell script ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB Paneling
On Wed, 26 Jul 2006, DJ Delorie wrote: > >> Is there a way to determine the board size using an action script? > >"Action" scripts are like really dumb shell scripts - all they do is >run commands, there's no flow control or other common scripting >capabilities. What you really want to do is use a perl script to do >the logic, and have it "drive" pcb with an action script. > >We've blue-skied about adding a real scripting language as a HID, but >the problem is we'd need to add something to the core to extract board >information in a generic script-api way. Before I started to read the mailing list, I thought I would add GPMI support in PCB (had the same problem with panelizing and other, mostly printing related tasks). GPMI is a library that allows a software to have scripts trough an unified interface. Currently 8 languages are supported: ghli (pascal), lua, perl, python, ruby, stutter (a lisp dialect), tcl. That something that can drive PCB wouldn't be added in core, but rather in separate dynamic loadable libraries. But this would bring in some external dependencies which is generally not preferred, if I got it right :) bye Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: a note from a novice user
> >Also, the folks who say "use emerge foo.bar" or "apt-get baz.woof" to >install don't understand that the real problem is the complexity and >lack of coherence of the components in gEDA. Yes, you can do "emerge >geda", but what about PCB? How is the totally ignorant user to know >that he also needs PCB? And ngspice? and gerbv? This is our problem >to fix. I really don't want to generate flame, I write this in hope it would be constructive. For the above question: when I type apt-get install geda, besides the libs, it would install: geda-doc geda-gnetlist geda-gschem geda-symbols It also gives suggestions and recommendations. Without copying the full list: geda-utils geda-gsymcheck geda-examples geda-gattrib gerbv So long story short, in some modern distros, the user has the chance to get tips/suggestions about what he would need. And I think the problem should be split at this point: at such a system, it should be assumed that the user knows what he is doing, probably this why he choosed that system and not something more 'user friendly'. We should assume that he knows how to use emerge or apt-get and that he reads what packages apt-get suggests. I know these kind of user is the minoroty. For the majority, it's a good idea to have an install. I agree that it would be hard to write one that works for all distros and is up to date while distros are changing. Exactly this why i suggest to split users and write the install program for only those who use a system that lacks a package system that can handle the situation. This would limit the number of distros a bit, like you could say "this install cd supports readhat, suse and windows" (picked a few systems randomly). I also think that for these kind of users binaries are very important so such a cd should contain binaries for some common platforms, like 64bit x86. Another interesting approach would be to provide a live cd. There are many live linux distros out there, so it would be possible to add gEDA to one of them. This way the 'lazy' user could try out the system without needing to understand parts of it, reading manuals, installing or anything like that. If he likes it, probably he will invest some more time in the installation process. It would be like a trial period so the user could decide to invest time or not after experiencing a working version. In case of *NIX, a special hack would allow to have something similar, a live environment but one that could embed in the users own system. The idea is to build up a directory with all the needed binaries and libs and m4 and everything then use chroot to start the software from there. This way one can ship all the binaries and libs needed, the exact versions, one big collection that just works. However this method also assumes distributing binary files so once the user has a non-supported architecture, this wouldn't work. Unlike with a live cd, the user uses his own system and can run his other software, however communication between chrooted gEDA and the rest of the system would be somewhat difficult. >The OP wanted to use the software for free, but was disappointed that >he couldn't make it work for him. That is too bad, but he does have >the possibility of asking for help on the user group, or -- better -- >paying somebody to help him set it up. That is, I do have sympathy >for his plight, but OTOH, my sympathy is limited since gEDA is a >freebie and the OP didn't want the software enough to consider paying >for support. This is a good example where a live version could help: if he sees first the bright side and not the bug-bug-bug part, he probably would spend more time and/or money to get it working :) bye Igor2 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
