Re: gEDA-user: why some skip KiCAD and gEDA
On Sun, Sep 11, 2011 at 10:03:14AM +0530, Abhijit Kshirsagar wrote: On Sun, Sep 11, 2011 at 04:42, Markus Hitter m...@jump-ing.de wrote: Am 10.09.2011 um 13:35 schrieb Stefan Salewski: A lot of documentation can be bad. Ha! Now that's exactly the right answer to somebody offering writing documentation. :) I agree that too much documentation /can/ be bad - if its in a non-searchable, badly written form, etc. E.g. if one has to dig through volumes of massive stuff just to do simple tasks then it is a bad thing. But having lots of searchable (over the internet) docs is much better. For example, I imagine a beginner will run a [google] search for gEDA beginners guide or gSchem Tutorial whereas an advanced user will be searching for say PCB complete reference or the keywords pertaining to a particular issue. Searchable heap of random documentation is really good for those who already have an overview of the field and know what they want to achieve and what to search for. I remember when I started with PCB and gschem (originally with xcircuit), many years ago, without any EE or EDA background. I think for beginner hobbists this is not a rare case. And there are indeed a lot of things to consider... The hardest thing in such situation is that you don't see the extents, so you need to go (or at least you feel you are going) randomly until you gain enough knowledge and experience to be able to see at least the extents and main aspects of the whole topic. For such users, having a specific document that only enumerates everything that falls in the domain of the tools is most useful. This document wouldn't need to have a lot of text, but a lot of links and short explanation scratching only the surface of each topic. Key is not volume, but structure. This document would cover all the common workflows, all the common possibilities (i.e. for getting data from gschem to pcb or sims). It should also cover features or flows we don't have or don't support yet or at all. Starting from such a document is better than stating with a tutorial, as a specific tutorial will most probably cover only a small portion of the whole thing, and only a single flow/tool/possibility of all. It's easier to choose which tutorial to start with, if one sees the possibilities. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gedasymbols.org down?
On Wed, Aug 31, 2011 at 10:56:27AM -0400, DJ Delorie wrote: Just FYI, turns out the place that hosts my secondary DNS was *also* out for the hurricane. Not much I can do about that - my paranoia only goes so far ;-) I could host sec dns for the site in central Europe if that helps. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Linux Desktop f?r gEDA
On Fri, Aug 05, 2011 at 12:35:38PM -0700, yamazakir2 wrote:
Do you guys use your linux box for general desktop usage or only EDA?
I ask because I have tried many times to make the switch to linux for
general desktop usage but can't get over the inconvenience of it. I
have a linux box specifically for EDA (gschem, pcb, spice simulations,
etc), so I couldn't care less what the WM is. It could be motif for
all I care.
UNIX for desktop, EDA, programming, server. Mostly Linux, most often
Debian testing. As for the earlier question in this thread, my WM is a
PIDwm (a modified version of dwm), but i spend 95% of my time on 80x25
VGA console anyway.
Back a while I tried to really use windows once. It lasted for like 3
weeks. I was trying hard, and tried to convince myself that what I
experience is only the learning curve and it will get better by time,
but the more I learned, the worse it became, so after that brief period
I replaced it with my first Debian-for-desktop-use-attempt. I was
switching away from DOS ('90s), and before that period I believed
Linux distros were good for server use and if I wanted to do cad work
and web browsing and things like that, windows would be better.
Ever since, I sometimes peek over the shoulders of windows users around,
and I what I see is that things I hated in those 3 weeks got advanced
and more dominant and things I missed are still missing or
misimplemented. Meanwhile I also got used to actually modify software I
use for so many years that I never give a try to non-free software
anymore, because I hate to figure out after a few days that I can't fix
something in it, due to legal/technical restrictions.
Regards,
Tibor
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Wed, May 18, 2011 at 09:24:53PM +0100, Thomas Oldbury wrote: Is there a Python api for gEDA? I once made a GPMI plugin for PCB. Unfortunately it contains only a small set of interface libraries so what can be done was limited. I've written an SVG exporter prototype in tcl, an interactive extension to draw non-90-deg arcs in awk, and a HGPL exporter that I really use in 'production'. GPMI supports 10 script languages including both python and guile. Altough I totally agree with those who say guile keeps some people back from really making extensions or modifications to gEDA, my reasoning is probably totally different from the previous ones in this thread. I believe it is the wrong way to bind a tool to a specific scripting language and force the user to learn a new language for each new tool. It is not (only) about being lazy to learn: there are very different tasks out there and some tools are more suited for some tasks. Once one knows 2-3 different scripting languages, it may already cover a large area of possible tasks well enough that learning a new one has nearly zero benefit. Unfortunately in case of pcb-gpmi burdens are elsewhere. My current theory is that such project would work only if it was fully integrated in the tool, shipped with default installation. It takes some efforts to compile the plugin and naturally it has dependencies (like why would I try to rewrite the interpreters of all those languages when I could use their libs?). As far as I know, i am the only one who ever tried the pcb-gpmi. Probably those who dare to start compiling non-singe-c-file plugins and fetch external libraries are not that much interested in scripting PCB in python (or anything else) as they are already good enough in C. To work around this I provided .deb packages but it's probably the same story, those who really would use the stuff are not on debian. So all in all, all positive feedback but 0 efforts in even trying it out. I can imagine something similar would happen to a gschem/geda variant. Maybe the burden is slightly smaller if only python is hacked onto gschem/geda, but then, in my opinion, that's not much better than having only guile is. I think it starts to be good at like 3..4 very different languages. Python itself is not the solution to anything. Menawhile pcb-gpmi is bitrotten; I am still using it with an old version of PCB (even debs are still available) but since the low user count I started the big configuration system refactoring of gpmi in trunk which most probably makes it fail to configure on non-linux systems. 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: zview/ngscope
On Sun, Apr 17, 2011 at 04:15:16PM -0400, rickman wrote: On 4/4/2011 11:44 PM, Kai-Martin Knaak wrote: A.Burinskiy wrote: I did not saw satisfactory analog viewer for ngspice. Could you please send me a link or project name? Over the years several waveform projects have been tossed around on this list: gwavehttp://gwave.sourceforge.net/ gtkwave http://gtkwave.sourceforge.net/ KJWaves http://sourceforge.net/projects/kjwaves/ dataplot http://www.h-renrew.de/h/dataplot/dataplot.html When I had the need for an interactive waveform viewer that could also be driven by an application, I had good success with xmgrace http://plasma-gate.weizmann.ac.il/Grace/ It is fully scriptable and can produce publication quality plots, too. Would any of these be suitable for a real time update of an o'scope display? I'm just batting around some ideas and would like to find some software to base an o'scope UI on. I would also check out frtplot for that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Where is pcb-20100929 for Win32 ?
On Fri, Apr 15, 2011 at 12:35:28PM -0400, DJ Delorie wrote: Another note - when uploading the EXE, please be sure to upload ALL the sources used to build it - yes, all the .tar.gz for all the libraries built. Really. Kai and I can't make the binary available without also making all those sources available at the same time. Provided that, I can also offer a mirror in Hungary. Traffic is unlimited, bandwidth is relatively good in .hu (10 mbit guaranteed) and somewhat limited international bandwidth. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spam Email to This List
On Wed, Apr 13, 2011 at 01:02:40PM +0100, Andrew Seddon wrote: Yes I got this. OT: I'm new hear so please feel free to ignore this comment, but might it be worth switching to google groups or similar? The interface is nice and you can use it like a traditional mailing list if desired. Last year we tried that for challenge24 to remove some load from our servers during the contest. It works fine as long as you are using web and especially if you have google account, but for a plain, non-google user with email only it wasn't that good. I can not recall what exactly went wrong, but I remember we had to switch back to mailman running on our own server. I personally would be more happy to keep the mailing list private - of course I am not the one who contributes hosting, bandwidth or admin time. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spam Email to This List
On Wed, Apr 13, 2011 at 09:36:20AM -0400, rickman wrote: On 4/13/2011 8:56 AM, ge...@igor2.repo.hu wrote: On Wed, Apr 13, 2011 at 01:02:40PM +0100, Andrew Seddon wrote: Yes I got this. OT: I'm new hear so please feel free to ignore this comment, but might it be worth switching to google groups or similar? The interface is nice and you can use it like a traditional mailing list if desired. Last year we tried that for challenge24 to remove some load from our servers during the contest. It works fine as long as you are using web and especially if you have google account, but for a plain, non-google user with email only it wasn't that good. I can not recall what exactly went wrong, but I remember we had to switch back to mailman running on our own server. I personally would be more happy to keep the mailing list private - of course I am not the one who contributes hosting, bandwidth or admin time. I hope this thread doesn't go on too long. I had received email from this guy at another address so I wasn't sure if the problem had something to do with my security or if he had harvested from this group. I guess it was the latter. I think there is a lot of private email sent as a result of things discussed on this list. So making the list private might not be the best way to handle the spam. In fact, I've only gotten one spam email from this list that I can remember so clearly the problem isn't very bad. That isn't why I posted about this. Sorry, missunderstanding. By private I meant hosted privately instead of hosted by some 3rd company like google. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: default pcb stackup change?
On Mon, Apr 11, 2011 at 10:58:51AM +0530, Abhijit Kshirsagar wrote: 1. Agree! I'd find this much more intuitive and easy to work with. The layers option will be a big help... +1 I also like the ieda of dropping component/solder side, replacing it with whatever else that suggests one side and the other side. 2. What would go to the outline layer? The gerber files have outlines for each layer right? If your board is not rectangular, the outline layer would tell the fab house what shape to mill. It's sort of a hack as you draw something that looks copper but PCB supposed to handle it differently because the _name_ of the layer is outline. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Time tracking
On Sun, Jan 30, 2011 at 07:26:12PM -0500, Darryl Gibson wrote: Hello Group, I'm curious what folks are using for time tracking and/or billing? Spreadsheets, software? We have a custom software called wt (as working time). It is designed by programmers for programmers, to minimize administration overhead. I typically enter a single command line with only like ~10 extra characters beyond the description of the task I am starting or finishing. The result is very nice, with that small amount of overhead we have really minute-resolution working time entries for most folks at the company. Sometimes I have 15+ entries for a normal workday. Same CLI I use for querying statistics on my team. I often process the result with sed/grep/awk. The other interface, designed for the managers, is a shiny web2.0 UI accessing the same database. 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: .sch primitive ordering [was: Collaborative Development of Boards]
On Mon, Jan 17, 2011 at 10:26:58AM +, Peter TB Brett wrote: On Monday 17 Jan 2011 08:58:18 John Doty wrote: On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. No. The very shallow, wide nature of a .sch file's (at most, if symbols are embedded) two level structure means that it's much more meaningful to consider it as a list. At each level in this tree the order of the branches does not matter. No. It does matter; the ordering indicates the draw order of primitives in any viewer or graphics exporter. Arguably, it shouldn't, but if not, the file format needs to be amended to provide this information in another way. So, a canonical ordering of a .sch file just requires some sorting criterion. Correct. I suggested one in my previous e-mail. Peter Maybe I oversimplify it, but I still suggesting having UUIDs. Long random numbers, like 256 bits, stored in hex. Whenever a new object appears, generate a new one. Whenever an object is transformed, keep the UUID. When saving, order objects numerically by UUID (within each level, if the save file is not flat). Some corner cases: - UUID wouldn't be used for anything else than keep order, so in the extreme case someone deletes something and adds something else and the new object happens to get the same UUID, that only means it will really be at the same place in the file - if two persons editing the same file and there are only a small amount of objects, both adding a new object, the probability of having the new object in between the same existing object is higher, in this case some version control systems may handle it as a conflict. With large enough files the probability is lower, and in any case, it is probably better than not having anything. - if two developers add new objects independently and they happen to get the same UUID against all reasonable odds, well, then the file will contain the same UUID twice after merge. This is a real problem, as if they both change one UUID to random on load, that will be a new conflict the next time they exchange the file. Provided UUIDs are long enough this would probably happen less freuqently than having 2 usres adding new objects to the same file ending up modifying the same section with the current solutions, if I get it right. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Hello Markus, On Sun, Jan 16, 2011 at 10:11:31PM +0100, Markus Hitter wrote: Hi all, having run an open source electronics project with the intention of collaborative development for a few months now, the experience is less than inspiring. So I'm looking for opinions on how to do better. http://reprap.org/wiki/Generation_7_Electronics http://github.com/Traumflug/Generation_7_Electronics Looking at what happened in these few months, I think the essence can be described in 3 topics: Mech and programming bakground, I have the same, but I don't agree these things would work any better in programming. As others, I also think these problems are basically the same for free and for non-free jobs, as others on the list already expressed. Team work is hard to do right, and this is largely independent of the field you try to do it in engineering. 1. Files aren't mergeable. While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. One can store a design's files in a Git repository, of course, but always only in a linear fashion. As soon as one collaborator works on something, all others have to wait until he's done. The versioning system would actually need a locking mechanism, like good ol' CVS had. Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. Since I started to use PCB, I always stored everything in svn and I often had minor problems with the date lines. Subversion, and any other decent version control system offers means to generate last mod date, author info, etc by the VCS in a way this meta-info will look like being part of the file content to the end user while it won't interfere with versioning, especially won't cause diffs. I suggest we make this part of the file format optional, default turned off. (Feature request #1) The other problem is diff. Again, I don't think there is anessential difference between team work and VCS in software development and in using the same methods/tools on other fields; at least we have the same methods, but some tools are partially missing. How does it work with software? A. the source code is an ordered list of objects (not in the OOP sense). If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, but in my daytime job I often meet non-programming tasks where the editor doesn't and if you do a minimal change, fix a typo in a text or anything alike, things get reordered and you always get a full-file-diff. So whatever tool you use, you must make sure it does minimal change needed in the source file. B. diff. When you work on souce code, you make a diff to see what others changed, or what you are going to submit as your change. With programming, you have the same stages as with PCB. For programming: - real representation is when your program is running; this is the final form, as interpreted (not in the CS sense) by the machine, the goal of your efforts - the source code is something abstract you don't see working while editing; you look at your source code and interpret it, and imagine how it would work, but sure it won't translate 1:1, you use your brain a lot for that transformation while coding - diff is the second abstraction, a language describes changes between 2 such abstract source code. Experienced programmers have the skill to read an intrepret the change, reconstruct the source code in head, interpret those code and reconstruct the final behaviour. This requires jumping 2 levels of sbastraction in one step, transarently. Now for a PCB (assuming we are talking about the layout work only, as your mail suggested): - real representation is what the GUI shows, this is almost 1:1 what you will get in form of copper and plastic. - the source code is PCB file, this is what fed into the VCS system. Same abstraction as with program source code vs. running the program, and PCB users can even do the same trick interpreting the sources to different degree. Some of the most hardcore ones are even do modifications using text editor on regular basis, and it is often faster than ivoking PCB for a click-around session - you have the same diff tool, and the language is the same, so you jump the same 2 level of abstrsctions. So what's the big deal the two processes still differ so much seamingly? The middle one. Non-programming EEs usually won't do the middle step, which means they won't be able to do the 2nd abstraction either. Without diff, your VCS reduces to a shared file system with backups. In reality you probably won't ever get all your contributors to learn the file format and track changes on that level, so you'll need something else. Probably a graphical
Re: gEDA-user: Collaborative Development of Boards
On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Hmm, maybe I mix it with something then. I recall some efforts, maybe by Peter to get this fixed in PCB or in gschem. Or else my memory just fails. Yes, I agree it is not too bad for the diffs in practice, at least when I edit a file alone on multiple computers I rarely see actual problems - except diffs caused by storing the date. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Seeing pin numbers in PCB
On Wed, Dec 29, 2010 at 11:48:00PM -0800, Oliver King-Smith wrote: Being lazy I am importing footprints other folks kindly made for pcb. Unfortunately, I am not very trusting, so I want to check they are correct. I can measure the size of stuff using gerbv (there may be a better way to do this in pcb), but I can't tell if the right pin numbers have been assigned very easily. Is there a way to see this in PCB? Oliver Place footprint, then: - hover mouse cursor over the component (not over pin), press d: all pin numebrs will appear - hover over a pin, press d: pin number of the given pin appears - hover over a pin or component and press shift+d: pin number dialog opens The above work with the gtk hid, I don't know if bindings are the same for the lesstif hid. Recent versions of PCB with gtk hid also displays pin numbers in the preview window while selecting footprints. hope this helps, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: scripting for pcb
Hi Karl, On Thu, Dec 30, 2010 at 12:29:21PM +0100, Karl Hammar wrote: Tibor: On Wed, Dec 29, 2010 at 08:51:19PM +0100, Stephan Boettcher wrote: ... And when that's the case, a clean C-API that can be exported to Guile, Python, Ruby, C++, Fortran, ... just dreaming. [the above is about gschem, now switching to pcb] I once started to do that to PCB usign libgpmi, and got a plugin that exports a small portion of PCB internals through some sort of higher level APIs to any scripting language libgpmi supports (10 at the moment). I took a quick look at libgpmi and it seems to be scarce on documentation [1]. [2] have a note on gpmi. [2] also talks about a function library and a perl-callable parser. [3] does not mention any scripting language. There is some scripting possible through src/action.c. Libgpmi doesn't have much documentation, true. I've just found I even broke the website. Will fix it soon. Meanwhile, list of languages supported: - awk (using libmawk) - lua - scheme (guile) - stutter (a lisp dialect) - pascal (ghli - may be broken at the moment) - perl - php - python - ruby - tcl - of course you can write your module in C and load it as a shared object You can find a more detailed list at http://repo.hu/projects/pcb-gpmi/languages.txt Is there any plans or needs for a scripting language (like guile/perl/ ...) for pcb? On the above list you can find both of those languages. Anyway you won't find references of this in pcb sources. The whole thing is a plugin and a set of gpmi packages. The design is like this: [PCB] - [pcb-gpmi plugin] - [scripts] - [interface packages] ^ | | | +--+ Or in text: PCB loads a plugin called pcb-gpmi, which will load a config file and according to that, will load a set of scripts. Scripts will in turn load interface packages. Interface packages are tiny shared object files which provide an interface between PCB internals and scripting languages. The idea is to have some sort of higher level API which does not change much and is more convenient. How powerful the whole thing can get depends on how many languages it supports and how much of the PCB internals are exposed. I believe the list of languages is impressive. Unfortunately interface packages are only a few, and thin, only as much as I needed for proof-of-concept or to fulfill my daily needs on missing PCB features. Here is a short list of already working packages: - actions: scripts can create actions usign this package. - dialogs: create dialog boxes using the current hid; your script can pop up data entry windows, give warnings, etc. - hid: allows the script to regiester an exporter hid with dynamic attributes - layout: query or draw objects on the current layout There are a set of example scripts written in different languages to demonstrate ease of use of PCB internals with pcb-gpmi: - carc: custom angle arc support written in lua; registers an action that pops up a dialog where user can set angles and other properties of an arc that will be then placed on the layout using the current layer/style. - SVG exporter written in tcl; proof-of-concept but already can export a somewhat good looking SVG. - HPGL exporter written in awk; cares only about lines but can repeat lines by layer. I own an old pen plotter I drive with this hid. You can find the scripts at http://repo.hu/projects/pcb-gpmi/plugins/ pcb-gpmi is documented; you can read the on-line documentation at http://repo.hu/projects/pcb-gpmi/doc/ ; gpmi, as you mentioned, is largely undocumented. However, if you are interested in using pcb-gpmi for scripting your plugins, you don't need to know anything about gpmi, the same way as using PCB GTK hid for drawing your layouts doesn't imply you need to know how GTK works. Of course this is no good excuse for missing doc, I just wanted to point out that missing documentation of gpmi is not a show stopper. On the other hand, since user count of the project is exaclty 1 (that is me) for the past ~4 years, don't expect it to be user-friendly. For example current svn HEAD of gpmi probably won't work out-of-the-box with pcb-gpmi, and you will need to use the last release instead. If I had users I would have made a branch for the big cleanup I am doing on gpmi lately, but as I didn't have users I just started it on trunk. If you are still interested in the project, I can support compiling and installing. 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: scripting (was Resistor values???)
On Wed, Dec 29, 2010 at 08:51:19PM +0100, Stephan Boettcher wrote: John Doty j...@noqsi.com writes: On Dec 29, 2010, at 6:23 AM, Stephan Boettcher wrote: I can imagine that it's not a lot, since this is really a classical case for said design pattern. The real difficulty here is the complexity of the Guile-C interface. The functions and data on the C side are accessible to the midlayer only to the extent that somebody does the (difficult) work of exporting them. The C front end is very procedural, performing much semantic processing regardless of whether the back end ever requests the results. Not a good match to the factored, functional approach. Than that is the interface that needs to be morphed according to the prescribed pattern: the C-Guile interface. And when that's the case, a clean C-API that can be exported to Guile, Python, Ruby, C++, Fortran, ... just dreaming. I once started to do that to PCB usign libgpmi, and got a plugin that exports a small portion of PCB internals through some sort of higher level APIs to any scripting language libgpmi supports (10 at the moment). After scripting 1-2 plugins I really needed, development stalled, as I am the only user of the plugin. I think you'd get the same for a similar project around gschem, as gschem developers already speak guile so having other scripting languages will be interesting only as a theoretical possibility, not as a practical feature. At least, with my pcb-gpmi plugin feedback always was wow, very nice, very interesting, will try some day. Btw, I still use it weekly, since I have a nice (partial) HPGL exporter written in awk. Regards, Tibor ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values???
On Sat, Dec 25, 2010 at 09:23:17PM -0500, Mark wrote: snip So, because I use several methods, a single one-size-fits-all library is just not going to work for me. I *could* make use of a library of heavy symbols but I still need the lightweight symbols, too. If I was forced to choose one library then I would like to keep the lightweight stuff. Maybe we should extend existing library in a way that we clone existing symbols, prefix the names by use case and add/delete attributes. Since the currently available library wouldn't change at all, no existing schematics would be broken. We now have resistor-1.sym and resistor-2.sym; we woulg then have these cloned as _P_resistor-1.sym and _P_resistor-2.sym, _P_ meaning they are intended for use on PCB. Of course, this would increase the confusion of new users, but it should be no harder than getting the L/N/M suffix of some SMD footpritns in 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: Dev list [was: Random thoughts on the future interface of PCB]
On Thu, Dec 09, 2010 at 10:27:31AM +, Peter TB Brett wrote: snip If I remember correctly, a major factor in the closure of the gEDA-dev list was that the signal to noise ratio became very low. There were several people, few of whom *ever* submitted patches, loudly and rudely telling the people who *were* writing code and having ideas how their approach was wrong, the design was wrong, their ideas were wrong, how dare you change anything, you *must* do it *my* way, etc etc etc. It got to the point that it was actively *hindering* development, because it was very off-putting to the actual developers. Although the discussions on gEDA-dev are less frequent now, at least they are usually quite constructive. Perhaps the time has come to reconsider the role of and access to the gEDA-dev list? How can we ensure that it doesn't collapse into an unproductive bikeshedfest again? It may be rude to state, but there are about 3 or 4 persons at most, who cause this sort of frustration on the user mailing list and on irc. I would say if you can set up some sort of simple, short but clear policy about what topics are for the dev list, and ban only those 3-4 persons, opening the dev list would be possible. 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: very backward time step?
On Thu, Sep 23, 2010 at 08:52:26AM -0400, al davis wrote: On Tuesday 21 September 2010, Rub?n G?mez Antol? wrote: Gnucap 2009.12 is so stable, why not released? (In several days, I think even ask at debian maintainer to include snapshots, at least, in experimental branch of Debian.) The problem is with the build system. My offer for providing an alternative on that is still valid, I just need a tarball of the most recent version you have. 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: Functional blocks and PCB format changes
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote: On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote: XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal. I think that using a Lisp (or Lispy-looking) format would be extensible, easy to parse, and make the most people happy. Allow me to toss out JSON. It is about as light weight as using S-EXP, but politically it isn't tied down by references to Lisp. Plus, since it has become fairly popular, there are good readers/writers for most languages. The format is defined at: http://www.json.org/ Recently I had to implement multiple output formats for a project of mine, including xml, JSON and plist (property list). After that session, for simple trees, I'd prefer plist over JSON. Myabe it's just me but i found it more readable for the human eye (independent of the indentation). 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: Functional blocks and PCB format changes
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote: snip But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. There are always conversion programs to be written, no? Rick Please note: I am not saying this for or against XML. I just felt like the above sentences implied using a specific file format is an ultimate solution for compatibility. Please always read XML as any standard or widespread format, text or binary, for example json, plist, sql dumps, whatever. Using xml as file format for PCB (or any CAD program) will not automatically make it compatible with any other CAD program. I see two different things here. 1. Use a file format that is well documented and known (this can be a standard format like XML, json, plist, or a custom format with proper documentation). 2. How the content is actually represented. Point 1. is a basis, a must. Without that, we can not talk about making two programs compatible, since the data can not be read or written by the other program. However, just being able to read the file, but not understanding what they mean, won't make any compatibility. Thus point 2. is a must too. XML may or may not be a good solution for 1., but doesn't do _anything_ to 2. The current file format is plain text and documented enough (in worst case by the source code) that any developer has the chance to parse or generate it, this it also fulfills the reqiurements in 1. Switching (or not switching) to XML will not make a real difference in compatibility. Switching to any standard format may ease implementation as one doesn't need to write a custom parser. But don't overestimate this part either: using a parser generator helps a lot, and even going without that, I strongly believe that finally the real complex and big part of the work is 2., not 1. Making two CAD programs compatible is harder on the how we represent the design internally level than how do we convert the representation to an actual file format. 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: Ricks email client
On Mon, Aug 23, 2010 at 09:40:25PM -0600, John Doty wrote: On Aug 23, 2010, at 9:23 PM, kai-martin knaak wrote: If there still is no change, it must be gmane munging header and encoding. Still in base64. Raw text of your message reads: UmljayBDb2xsaW5zIHdyb3RlOgoKPj53aW5kb3dzL2Jyb3dzZV90aHJlYWQvdGhyZWFkLzdhNGU2 snip BTW, decoding that results in readable text split up with \n (0x0A) characters properly, so I think the problem is on the reader's side if everything goes in one long line. Regards, Tibor Palinkas ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: broken part
Hi all, sorry for the offtopic; we have a broken part which supposed to be a transducer in a board driving a tiny CRT. The sticker on the part says Lucius Baer TYP: VM 102-L (http://igor2.repo.hu/tmp/VM102.jpg). Has anyone met this part or does anyone have an idea for a substitute? 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: OT: Bike Alarms
On Thu, May 13, 2010 at 10:41:19AM -0500, John Griessen wrote: David SMITH wrote: John Griessen wrote: David C. Kerber wrote: If you've got a carbon frame, you could drop it into the seat tube, where it would never be seen, and therefore never removed by a thief... This really does sound like a product since bikes can cost these days. Not to put too much of a spanner in the works, but... Where does the power come from? What about this: you probably have a magnet on your wheel already to measure your speed so you can detect if the bike is in move. Add a hidden button or any other means that you can tell the device you locked or unlocked your bike. If it's locked and moving, turn on GPS and send SMS every 5 minutes until the battery goes out. Won't work if you lock your bike in a long tunnel and it gets stolen and the thief doesn't leave the tunnel with your bike before the battery dies, but... 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 programming
On Fri, Apr 23, 2010 at 01:00:20PM +0200, Miguel S?nchez de Le?n Peque wrote: Hi all, I'm a student interested in contributing to gEDA and learn some C ;-). The biggest problem I find any time I start coding is how should I write this?. You're always talking about deprecated code, libraries you're/you're not using, old style... Could you tell me any book/reference you'd find necessary to learn modern C programming? Or to learn how to use extended libraries as GTK and glibc? Or any other library widely used in C programming... Maybe there's no book for that, it's just programming experience... am I right? (I hope not! xD) Thanks in advance, A student who is a bit confused about which is good modern C programming style... :-) As you described above, programming takes much more than knowing the syntax of a programming language. I suggest reading The Art of Unix Porgramming. This book doesn't directly help you in library selection or modern C programming, but may help you develop a sense that would ease some of your decisions about how you approach the problems you listed. Regards, Tibor Palinkas P.S. a link to the online version: http://www.faqs.org/docs/artu/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: [ig...@igor2.repo.hu: Re: Net of Selected Common Pins Enroutes Shortest Path Through All Intervening Pins]
On Tue, Jan 05, 2010 at 10:08:15PM -0500, Stan Katz wrote: I use gEDA for small projects. One, and two sided boards only. It's been fine up until now. I now have a transceiver chip with some pins, a number of which I need to run to pin 1 on an IDE header. No matter how I draw the nets in gschem, the final rats nest runs produced in pcb is one trace, across all the pins on each side of the SOIC, as long as any of them are in the star end-run to the header pin. In other words, if I want to tie pins 1,3,5, of the transceiver, to pin 1 in the header, a rat route runs across pins 1,2,3,4,5, of the transceiver, shorting all of them together, and then routes to header pin 1. How can I separate these nets? Where do I do it? (gschem, gsch2pcb, just gnetlist, or pcb) My only solution, so far, has been to plant small terminals in each run in gschem, with a very small via footprint. This forces separate routes to pin 1 on the header in pcb. It's only the graphical representation that may seem to be like that. Take it as rat lines are arcs connecting 1-3-5 above 2 and 4, but as you are looking at them from the top, they look like lines. When I have a similar situation I usually press 'f' over the rat or over the header pin, so the whole net is highlighted - this would make the header pin, the rat lines and pins 1-3-5 highlighted green while leaving 2 and 4 alone. Regards, Tibor Palinkas - End forwarded message - ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
