gerbv-devel — Gerbv tech discussions

[Gerbv-devel] Rendering improvements (I hope...)

[Julian L. <jul...@gm...>]

I've committed a few changes to the rendering code.  Stuart, the GDK
memory leak (and crashes I've encountered) you found seems to be tied to
the idle function, so I've disabled that in CVS temporarily.  Hopefully
it fixes your problem.

On the cairo side, I've tried a couple recommendations from Peter and
tried switching to using Xlib surfaces instead of patterns.  I think it
helped a tiny bit...nothing substantial though.  I changed the rendering
logic around to make panning feel just as snappy as the GDK code before
it has to redraw.  Also, I've cleaned up the code to help with the cairo
analyzing...Peter, it should be a lot easier to look at now that the
cairo code is much simpler.

Finally, I'll mention I happened to boot up recently without my
proprietary Nvidia drivers loaded (yeah, hate me for using something
closed source... :) and noticed gerbv w cairo was slow as MOLASSES for
me.  I'm wondering if it is just a bug in the open source "nv" drivers,
or if it was actually offloading some of the image composition to the
video card before and potentially that slow for others.  I'm curious to
see how fast the cairo stuff is on everyone else's system now.  I'm
hoping to get all the rendering stuff setup to allow export-to-xxx from
the command line very soon.  Once that is done, we can potentially run
some standard tests like rendering a suite of files to PNG from the
command line, and using something like "time gerbv
--export-to-PNG=output.png input.gbr" to see how much time it takes on
different systems.  Thoughts anyone?

Oh, and I changed the background to black, by popular consensus.

Cheers,
Julian Lamb

Re: [Gerbv-devel] First draft of rewritten drill parser

[Peter C. <pc...@ca...>]

On Fri, 2007-12-14 at 11:57 -0500, Julian wrote:
> > Unfortunately, I'm not really good at all that GUI stuff.  I never
> > worked much with GTK so far.  I've been able to add a "Preferences"
> > menu item to the "File" menu, and make it create a popup dialog, but
> > hacking together a real preferences dialog is somewhat over my head.
> > Are there any takers for this, Julian maybe?  If there were some stub
> > preferences dialog code where the individual parts of the program
> > could fill something in (I think layer colors, default measurement
> > units etc. are also good candidates), I'm willing to try adding the
> > stuff I see fit in the area of the drill parser.
> > 
> Sure, I can work on a preferences dialog in a few weeks if you want.
> I guess ideally we would want the settings to be maintained between
> sessions...do we want to set up a ~/.gerbv directory and try to code
> some preferences saving/parsing code too?  Maybe we could rob some
> code from PCB?

Or look at the g_key_file API, which we use in gEDA for saving dialog
positions etc.. in gschem.

As gerbv is part of the gEDA project (according to the about dialog
anyway), please stick any config files in ~/.gEDA to avoid an explosion
of hidden config dirs in the home directory.

If you want to duplicate that feature, you'll see that all custom
dialogs in gschem derive from GschemDialog (not GtkDialog). This
GtkDialog subclass has hooks to save / restore state like position etc.
This avoids us needing to modify every dialog we implement, all we need
to provide is a name to store the dialog's settings under.

I'm not sure whether extending its usage to remembering settings / state
is clean or not, but I've made it hookable. For example, the default
code saves position and size, but I can hook it for dialogs with HPaned
(e.g. the component preview) and save the pane position. I also save the
current tab in the GtkNotebook of the component selector.

Eg. a snippet from my ~/.gEDA/gschem-dialog-geometry:

[compselect]
x=152
y=132
width=850
height=651
hpaned=377
source-tab=1

Code re-use is very much encouraged if it seems suitable.

Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)

Re: [Gerbv-devel] First draft of rewritten drill parser

[Julian <the...@gm...>]

> Unfortunately, I'm not really good at all that GUI stuff.  I never
> worked much with GTK so far.  I've been able to add a "Preferences"
> menu item to the "File" menu, and make it create a popup dialog, but
> hacking together a real preferences dialog is somewhat over my head.
> Are there any takers for this, Julian maybe?  If there were some stub
> preferences dialog code where the individual parts of the program
> could fill something in (I think layer colors, default measurement
> units etc. are also good candidates), I'm willing to try adding the
> stuff I see fit in the area of the drill parser.
> 

Sure, I can work on a preferences dialog in a few weeks if you want.  I
guess ideally we would want the settings to be maintained between
sessions...do we want to set up a ~/.gerbv directory and try to code
some preferences saving/parsing code too?  Maybe we could rob some code
from PCB?

Cheers,
Julian

[Gerbv-devel] Running gerbv under valgrind

[Stuart B. <sd...@cl...>]

Guys,

As I continue fiddling with my statistics gathering stuff, I tried
running gerbv under valgrind to find memory leaks.  It shows a
boatload of the usual complaints from X, which are probably harmless.
It also shows a "jump on uninitialized value" error when drawing an
arc.  A random snippet from the valgrind report:

==16345== Conditional jump or move depends on uninitialised value(s)
==16345==    at 0x437AC47: gdk_draw_arc (in /opt/gnome/lib/libgdk-x11-2.0.so.0.600.4)
==16345==    by 0x804DF46: gerbv_gdk_draw_circle (draw-gdk.c:720)
==16345==    by 0x8050411: image2pixmap (draw-gdk.c:1049)
==16345==    by 0x8065C18: redraw_pixmap (render.c:657)
==16345==    by 0x8065DEA: idle_redraw_pixmap (render.c:386)
==16345==    by 0x44B8050: (within /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44B9966: g_main_context_dispatch (in /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44BBCE1: (within /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44BCCF6: g_main_loop_run (in /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x41B4BE2: gtk_main (in /opt/gnome/lib/libgtk-x11-2.0.so.0.600.4)
==16345==    by 0x80562F9: main (gerbv.c:727)
==16345==
==16345== Conditional jump or move depends on uninitialised value(s)
==16345==    at 0x437ABA6: gdk_draw_arc (in /opt/gnome/lib/libgdk-x11-2.0.so.0.600.4)
==16345==    by 0x438503B: (within /opt/gnome/lib/libgdk-x11-2.0.so.0.600.4)
==16345==    by 0x437ABE8: gdk_draw_arc (in /opt/gnome/lib/libgdk-x11-2.0.so.0.600.4)
==16345==    by 0x804DF46: gerbv_gdk_draw_circle (draw-gdk.c:720)
==16345==    by 0x8050411: image2pixmap (draw-gdk.c:1049)
==16345==    by 0x8065C18: redraw_pixmap (render.c:657)
==16345==    by 0x8065DEA: idle_redraw_pixmap (render.c:386)
==16345==    by 0x44B8050: (within /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44B9966: g_main_context_dispatch (in /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44BBCE1: (within /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x44BCCF6: g_main_loop_run (in /opt/gnome/lib/libglib-2.0.so.0.600.3)
==16345==    by 0x41B4BE2: gtk_main (in /opt/gnome/lib/libgtk-x11-2.0.so.0.600.4)

BTW:  I am compiling and running using the GDK stuff.

I don't know if this is serious, or if it is benign, but I thought I'd
offer this to you to chew on for a while.

Cheers,

Stuart

Re: [Gerbv-devel] gEDA-user: gerbv (fwd)

[Peter C. <pc...@ca...>]

On Thu, 2007-12-13 at 21:34 +0100, Joerg Wunsch wrote:
> As Stuart Brorson wrote:
> 
> > I am reposing this e-mail here since it is directly apropos to some
> > of the drill work going on.  Anybody have any comments?
> 
> [forwarded message from Ian Chapman]
> 
> > I have noticed a minor difference between gerbv under Linux and
> > Viewmate 9.8 under XP.  The unplated-drill.cnc loads and displays
> > under Linux but under XP gives ---Warning - syntax error
> > M4BINC?H,TZT12C0.170%*.  I have pasted the unplated drill file on
> > the tail of this post.
> 
> That file parses correctly with the rewritten drill parser.  However,
> I can only test under Linux and FreeBSD, I don't have a Win32
> environment.
> 
> What's strange is that I cannot find any occurence of "syntax error"
> in the code even before (neither the drill parser nor the Gerber
> parser), except within the scheme language parser.  Did you perhaps
> accidentally attempt to load that file as a project file rather than a
> layer file, Ian?

It was Viewmate 9.8 software being used in WinXP, not Gerbv.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)

Re: [Gerbv-devel] Announcing gerbv-build! [was: Re: autobuild]

[Dan M. <da...@mc...>]

Stuart Brorson wrote:
> Hi again --
> 
>> I'm mostly set up to automatically to a cvs update and if anything
>> changed, do both cairo and gdk builds and have an email generated.  Is
>> that something people would find useful?  Should it go to this list?  Or
>> would that just be considered spam?
> 
> Per Dan's comment, I have just set up a mailing list called
> gerbv-build.  You can subscribe here:
> 
> https://lists.sourceforge.net/lists/listinfo/gerbv-build
> 
> The purpose of gerbv-build is to receive and reflect
> autogenerated build messages emitted by Dan's compile farm and send
> them to whomever wants to monitor the nightly build process.
> 
> Moving forward, I'd envision that gerbv-build could also be used to
> reflect any messages which a nightly test suite generates.  (Of
> course, the nightly test suite is yet to-be-done.)  Also, any other
> autogenerated messages of interest to developers and relevant to
> building gerbv can go here.  If others want to create compile farms,
> please feel free to send your compiler farm messages to this list.
> 
> Just to be clear, this list is *not* intended for human generated
> traffic.  It probably won't be read by many people, so if you have
> something important to say, gerbv-build is *not* the place to say it.


Hopefully we'll start seeing stuff there tomorrow.  I have an old 
version of NetBSD on my alpha with gcc3.  Also one of our users over on 
the geda lists has been kind enough to give me access to a nice sun 
server running solaris 10 with the sunpro compilers.  So we should be 
getting builds from both.  I have it set to build both gdk and cairo 
versions with 'distcheck' as the target.

If the source tree hasn't changed since the last build, no building is done.

I plan on making a minor modification to the scripts to only send the 
build admin (me) an email if no build took place or there were no 
warnings and send the list email otherwise.  That should help with traffic.

-Dan

Re: [Gerbv-devel] First draft of rewritten drill parser

[Stefan P. <sp...@st...>]

Joerg Wunsch wrote:
> I think most of the stuff remaining is about the assumptions at
> startup.  Right now, the parser assumes the virtual milling machine to
> be in the pristine state as specified by Excellon.  But of course, it
> could as well be that the machine operator already performed some
> initial settings on the machine's keyboard.  IMHO, the best match we
> could find for that is to allow a pre-setup of the virtual milling
> machine implied by implementing user preferences that could be set at
> run-time.  (Maybe they should also be saved along with the project
> file then?)  Similar user preferences could be applied to the virtual
> photoplotter that is used to draw the Gerbers, if that's needed.

Maybe a good idea?


> I'm not really happy with the way that parser is written so far, but I
> don't have any useful reimplementation proposal either.

What do you think is wrong? The design or implementation? If the parser
is to be rewritten, now is probably the best time.

I looked at the code and it seems that METRIC and INCH should be happier
if they got split out into separate functions.

And instead of the syntax:
if (a) {
  if (b) {
    if (c) {

I recommend the syntax:
if (a && b && c) {

In C you always evalute && and || from left to right, and when some
operation make the complete operation false it will stop evaluate the
expressions (K&R 2nd Ed. pp.207-208).

Don't always look at the code around. Pitch and me don't always write
perfect code too. :)


> That would again fit into my user preference setup suggestion.  That
> way, we can at least parse all the files that adhere to the Excellon
> specs correctly, and the users would only need to interoperate with
> the program for lousy files.  Compared to the old parser, it often did
> not parse files correctly that adhere to the standard, in an attempt
> to guess things that are hard to guess at all (as we noticed) so it
> would be better to refer these to the user anyway instead of guessing.

User preferences is good, but at the same time makes it harder to the
user (soooo many options). And also, as you point out, hides errors the
PCB houses might not even notice. And it's not only valid for Excellons,
the same goes for the Gerbers.

I have heard from users that gerbv is simple to use compared to other
viewers.

I am kind of divided here. But the more I think about it user
preferences is good. But first a good parser that parses as much as
possible without intervention. Then user preferences.


> Unfortunately, I'm not really good at all that GUI stuff.  I never
> worked much with GTK so far.

Who is? Not me at least. gerbv started out as an example scratch pad
application from a book... Then I stole loads of ideas from Ales and
gschem. And for the hard parts of the drawing engine (like the strange
things Julian asked about, idle something) my very good friend Anders wrote.

Jokes aside, the drill parser really needs some TLC I think. If you can
provide it I'm happy.

Best regards,
/Stefan

Re: [Gerbv-devel] First draft of rewritten drill parser

[Dan M. <da...@mc...>]

Stefan Petersen wrote:
> Joerg Wunsch wrote:
>> As Stuart Brorson wrote:
>>
>>> Since others have approved it, I have backed out my stuff from my
>>> local repo, applied Joerg's patch, and then committed Joerg's stuff
>>> to CVS.  Please give it a try!
>> Thanks, that's been really fast!
>>
>>> 1.  Please check the latest out of cvs and take it for a test drive.
>>> Verify that everything is in order.
>> Running a "cvs diff" didn't show me any more local changes after the
>> update, so yes, everything arrived in CVS the way I sent the patch.
>>
>> I also verified a number of the existing Excellon files again.
> 
> Hi!
> 
> I tested against numpres in the example directory. It is a design with
> gerbers generated from an old version of pcb. The drill file comes up in
> the left lower corner. Is it an error from an old pcb version or is it a
> drill parser error? Looking at the code gives no obvious errors.
> 
> Regards,
> /spe


Also I have an example of 2.5 inches formatted drill files from pads. 
When you generate the drill file, you can specify how many digits you 
want and evidentally produce a broken output.

I think that GC-preview (freeware, closed source, windows tool) read it 
correctly.

Personally I think the way to go is to do our best to guess the format 
and then provide a way for the user to override if the guess is wrong.


-Dan

Re: [Gerbv-devel] First draft of rewritten drill parser

[Stefan P. <sp...@st...>]

Joerg Wunsch wrote:
> As Stuart Brorson wrote:
> 
>> Since others have approved it, I have backed out my stuff from my
>> local repo, applied Joerg's patch, and then committed Joerg's stuff
>> to CVS.  Please give it a try!
> 
> Thanks, that's been really fast!
> 
>> 1.  Please check the latest out of cvs and take it for a test drive.
>> Verify that everything is in order.
> 
> Running a "cvs diff" didn't show me any more local changes after the
> update, so yes, everything arrived in CVS the way I sent the patch.
> 
> I also verified a number of the existing Excellon files again.

Hi!

I tested against numpres in the example directory. It is a design with
gerbers generated from an old version of pcb. The drill file comes up in
the left lower corner. Is it an error from an old pcb version or is it a
drill parser error? Looking at the code gives no obvious errors.

Regards,
/spe

Re: [Gerbv-devel] First draft of rewritten drill parser

[Joerg W. <j...@ur...>]

As Stefan Petersen wrote:

> There was one issue I thought of, but in my tired mind I didn't want
> to bring it up then. But it seemed like the background was white
> again.  Probably some cvs update missing. It's hard to keep up these
> days.

I noticed one drawing artefact at home on my FreeBSD system which I
cannot see at work on Linux: occasionally, the layer color selected
for the drill layer fills the entire displayed area.  When zooming a
bit around, this effect eventually vanishes, and the display is as it
ought to be.  This appears to never happen to other layers, and only
in cairo.  I cannot see it on the Linux machine I've also been using
for testing, so I guess it's a bug in that FreeBSD's version of cairo.

OTOH, I think the default background has not been changed to black in
CVS so far, if that's what you're referring to.

> The reference the Excellon parser was designed to parse was the
> Veribest files in nollezappare. They are apparently quite bad and
> Joerg had problems with it too.

Yes, I think they're violating the spec by specifying tool sizes in
millimeters without indicating so.  According to Excellon, the machine
defaults to inch measures.

> I think that starting from a standard and then fixing buggy files is
> probably the best way to do it. I have found consistent "bugs" in
> gerber files from different vendors.

I think most of the stuff remaining is about the assumptions at
startup.  Right now, the parser assumes the virtual milling machine to
be in the pristine state as specified by Excellon.  But of course, it
could as well be that the machine operator already performed some
initial settings on the machine's keyboard.  IMHO, the best match we
could find for that is to allow a pre-setup of the virtual milling
machine implied by implementing user preferences that could be set at
run-time.  (Maybe they should also be saved along with the project
file then?)  Similar user preferences could be applied to the virtual
photoplotter that is used to draw the Gerbers, if that's needed.


As Julian wrote:

> Also, does this address Patch #1626449 in Sourceforge?

I think so, the file that is attached to the patch tracker looks OK to
me.  It would have been good to have one Gerber layer of that same
design for reference.

> Also, speaking of Sourceforge, do you still get the Integer warnings
> with CVS Joerg?

Yes, I replied to your question in the bug tracker.  Essentially, the
parser is looking at the string "*\r\n%" at that point.  It just
parsed the "*", and resets primitive to 0, so the next iteration
starts to hunt for a primitive number again.  Obviously, "%" does not
form a valid integer then.

I'm not really happy with the way that parser is written so far, but I
don't have any useful reimplementation proposal either.



As Dan McMahill wrote:

[About the Excellon specs]

> I don't have access to pads right now, but I pretty certain it lets
> you specify the number format and have more than the 2.4 for inches.
> Maybe 2.5.  The unfortunate reality is that there probably are CAD
> tools out there capable of producing stuff outside the Excellon
> spec.

The big question would IMHO not be whether there's software producing
broken Excellon files but whether the next PCB house would even be
willing to accept the broken files...  gerbv is probably the first
instance to verify the resulting files before people are sending them
off to a PCB manufacturer, so we should be as liberal as the milling
machines itself but probably not more.

> In fact, I'm looking at an old file created by pads and see that it
> sure looks like 2.5.  The board is 5.5 inches by 4.5 inches.  See if
> this looks right with the new code.

No, that one is indeed 2.5, so it doesn't display correctly.

> I actually wonder if there needs to be the ability to explicitly set
> the format for problem files.

That would again fit into my user preference setup suggestion.  That
way, we can at least parse all the files that adhere to the Excellon
specs correctly, and the users would only need to interoperate with
the program for lousy files.  Compared to the old parser, it often did
not parse files correctly that adhere to the standard, in an attempt
to guess things that are hard to guess at all (as we noticed) so it
would be better to refer these to the user anyway instead of guessing.


Unfortunately, I'm not really good at all that GUI stuff.  I never
worked much with GTK so far.  I've been able to add a "Preferences"
menu item to the "File" menu, and make it create a popup dialog, but
hacking together a real preferences dialog is somewhat over my head.
Are there any takers for this, Julian maybe?  If there were some stub
preferences dialog code where the individual parts of the program
could fill something in (I think layer colors, default measurement
units etc. are also good candidates), I'm willing to try adding the
stuff I see fit in the area of the drill parser.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: [Gerbv-devel] gEDA-user: gerbv (fwd)

[Joerg W. <j...@ur...>]

As Stuart Brorson wrote:

> I am reposing this e-mail here since it is directly apropos to some
> of the drill work going on.  Anybody have any comments?

[forwarded message from Ian Chapman]

> I have noticed a minor difference between gerbv under Linux and
> Viewmate 9.8 under XP.  The unplated-drill.cnc loads and displays
> under Linux but under XP gives ---Warning - syntax error
> M4BINC?H,TZT12C0.170%*.  I have pasted the unplated drill file on
> the tail of this post.

That file parses correctly with the rewritten drill parser.  However,
I can only test under Linux and FreeBSD, I don't have a Win32
environment.

What's strange is that I cannot find any occurence of "syntax error"
in the code even before (neither the drill parser nor the Gerber
parser), except within the scheme language parser.  Did you perhaps
accidentally attempt to load that file as a project file rather than a
layer file, Ian?

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: [Gerbv-devel] First draft of rewritten drill parser

[Joerg W. <j...@ur...>]

As Stuart Brorson wrote:

> Since others have approved it, I have backed out my stuff from my
> local repo, applied Joerg's patch, and then committed Joerg's stuff
> to CVS.  Please give it a try!

Thanks, that's been really fast!

> 1.  Please check the latest out of cvs and take it for a test drive.
> Verify that everything is in order.

Running a "cvs diff" didn't show me any more local changes after the
update, so yes, everything arrived in CVS the way I sent the patch.

I also verified a number of the existing Excellon files again.

> 2.  Please write up an entry for the ChangeLog and send me a patch
> for it.

Here we go:

============================================================
2007-12-13 Joerg Wunsch

	Rewrite a large part of the drill parser.
	* src/drill.c: Rewrite the parser to do a lot less of
	guesswork, and be more in line with the way Excellon specifies
	the file format.  drill_guess_format() has been removed.
	METRIC and INCH statements in the header are now correctly
	parsed, and if they are followed by TZ or LZ statements
	(trailing/leading zeros), these are taken as a definitive
	reference for zero handling throughout the file.  In the
	METRIC case, the number format (3.3, 3.2, or 4.2) will also be
	parsed.  In INCH mode, only 2.4 is specified by Excellon.
	When parsing a double number, missing trailing zeros are
	correctly filled in before applying the scaling according to
	the number format.
	* src/gerb_image.h: add UNIT_UNSPECIFIED to unit_t, and
	ZEROS_UNSPECIFIED to omit_zeros_t, respectively.  They are used
	initially in the drill parser, until a specification has been
	seen.
	* src/gerb_stats.c: Remove the handling for METR, METI, and METC
	statistics because a METRIC specification is not a genuine M code.
	* src/gerb_stats.h: (Ditto.)
	* src/callbacks.c: (Ditto.)
============================================================

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: [Gerbv-devel] First draft of rewritten drill parser

[Peter C. <pc...@ca...>]

On Thu, 2007-12-13 at 10:06 -0500, Dan McMahill wrote:
> Stuart Brorson wrote:
> 
> > 2.  Please write up an entry for the ChangeLog and send me a patch for
> > it.
> 
> I can defer to Stefan, but I really believe that manually updating 
> ChangeLog is a waste of time.  With pcb, I just update ChangeLog right 
> before snapshot with cvs2cl.pl which automatically generates ChangeLog 
> from all the cvs commits.  It's one less step to manually mess up.


gEDA now auto-generates the ChangeLog from the git log. It forces people
to write decent commit messages, which is always a plus. (No criticism
of gerbv commit messages here, just a general comment)

The old (manually updated) ChangeLog was moved (cvs admin?) to a
different file-name, and we started auto-generating with a script
written by Peter B.

The MAJOR benefit of the auto-generation turned out to be avoiding a
terrible mess when merging changelogs from different branches. They
_always_ conflict otherwise.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)

[Gerbv-devel] gEDA-user: gerbv (fwd)

[Stuart B. <sd...@cl...>]

I am reposing this e-mail here since it is directly apropos to some of
the drill work going on.  Anybody have any comments?

Cheers,

Stuart


---------- Forwarded message ----------
Date: Thu, 13 Dec 2007 10:20:12 -0500
From: Ian Chapman <ian...@al...>
To: ged...@mo...
Subject: gEDA-user: gerbv

I have noticed a minor difference between gerbv under Linux and Viewmate 9.8
under XP.  The unplated-drill.cnc loads and displays under Linux but under
XP gives ---Warning - syntax error M4BINC?H,TZT12C0.170%*.  I have pasted
the unplated drill file on the tail of this post.

 	Gerbv does not print.  Is there a version that is able to print?
Regards Ian.
=======================================================
M48
INCH,TZ
T11C0.150
T12C0.170
%
T11
X023765Y016935
X023765Y013435
X032855Y032685
X014675Y032685
X035885Y034435
X011645Y034435
T12
X023765Y008035
X040565Y037135
X006965Y037135
M30



_______________________________________________
geda-user mailing list
ged...@mo...
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: [Gerbv-devel] First draft of rewritten drill parser

[Dan M. <da...@mc...>]

Stuart Brorson wrote:

> 2.  Please write up an entry for the ChangeLog and send me a patch for
> it.

I can defer to Stefan, but I really believe that manually updating 
ChangeLog is a waste of time.  With pcb, I just update ChangeLog right 
before snapshot with cvs2cl.pl which automatically generates ChangeLog 
from all the cvs commits.  It's one less step to manually mess up.

-Dan

[Gerbv-devel] Announcing gerbv-build! [was: Re: autobuild]

[Stuart B. <sd...@cl...>]

Hi again --

> I'm mostly set up to automatically to a cvs update and if anything
> changed, do both cairo and gdk builds and have an email generated.  Is
> that something people would find useful?  Should it go to this list?  Or
> would that just be considered spam?

Per Dan's comment, I have just set up a mailing list called
gerbv-build.  You can subscribe here:

https://lists.sourceforge.net/lists/listinfo/gerbv-build

The purpose of gerbv-build is to receive and reflect
autogenerated build messages emitted by Dan's compile farm and send
them to whomever wants to monitor the nightly build process.

Moving forward, I'd envision that gerbv-build could also be used to
reflect any messages which a nightly test suite generates.  (Of
course, the nightly test suite is yet to-be-done.)  Also, any other
autogenerated messages of interest to developers and relevant to
building gerbv can go here.  If others want to create compile farms,
please feel free to send your compiler farm messages to this list.

Just to be clear, this list is *not* intended for human generated
traffic.  It probably won't be read by many people, so if you have
something important to say, gerbv-build is *not* the place to say it.

Cheers,

Stuart

Re: [Gerbv-devel] First draft of rewritten drill parser

[Stuart B. <sd...@cl...>]

Hi guys,

> I tested the patch Joerg sent and it seems to work excellent. The Protel
> files in the examples directory seems to parse correct compared to previous.

Since others have approved it, I have backed out my stuff from my
local repo, applied Joerg's patch, and then committed Joerg's stuff to
CVS.  Please give it a try!

Joerg, can you please do me two favors:

1.  Please check the latest out of cvs and take it for a test drive.
Verify that everything is in order.

2.  Please write up an entry for the ChangeLog and send me a patch for
it.

Thanks for the patch!  Keep 'em coming!

Cheers,

Stuart

Re: [Gerbv-devel] First draft of rewritten drill parser

[Stefan P. <sp...@st...>]

Hi!

I tested the patch Joerg sent and it seems to work excellent. The Protel 
files in the examples directory seems to parse correct compared to previous.

There was one issue I thought of, but in my tired mind I didn't want to 
bring it up then. But it seemed like the background was white again. 
Probably some cvs update missing. It's hard to keep up these days.

I prefer Joergs patch to go in before Stuarts patch. I think it is 
better to have a correct parser to start from and then add the extra. I 
also found Stuarts patch buggy. After my test I reported about I also 
got a true and blue segfault.

The reference the Excellon parser was designed to parse was the Veribest 
files in nollezappare. They are apparently quite bad and Joerg had 
problems with it too.

I think that starting from a standard and then fixing buggy files is 
probably the best way to do it. I have found consistent "bugs" in gerber 
files from different vendors. I added warnings in the gerber parser to 
say "Hey, this file is probably made by this vendor". It has apparently 
made the vendor to fix their gerber generator when too many customers 
started to complain. :)

So I vote for Joergs patch going in ASAP and then updating it as 
problems are found. But I think parsing peoples buggy Gerbers and 
Excellon files without signalling an error, or at least a warning, is 
bad. They should have a slap on their wrist for doing stupid things.

Regards,
/spe

Julian wrote:
> Excellent work, Joerg!  I'm curious to get Stefan's thoughts on the 
> patch when he has time...he probably knows of some of the reasons behind 
> the old drill parsing guessing, so I'm curious if he knows of many 
> "gotchas" from bad drill files he's seen.  But, I can't wait to see it 
> in CVS (Stuart, are you going to merge this in?).  Also, does this 
> address Patch #1626449 in Sourceforge?  If so, remind me so I can close 
> it out.
> 
> Also, speaking of Sourceforge, do you still get the Integer warnings 
> with CVS Joerg?  I applied the part of your patch I referred to in an 
> earlier email and wanted to know if that was indeed enough to stop the 
> warnings.  If not, we can add the other half of your patch back in.
> 
> Thanks--
> 
> On Wed, 2007-12-12 at 22:46 +0100, Joerg Wunsch wrote:
>> As promised, I rewrote a large part of the drill parser.  Sorry
>> Stuart, this work might partially collide with your drill statistics
>> work.  If you eventually accept the patch, I volunteer to manually
>> resolve the conflicts (or just commit the statistics patch to CVS
>> before, and I'll resolve it after a cvs update).
>>
>> I read the Excellon manuals up and down.  I think we can do with much
>> less guesswork than we used to.  Excellon says that the only allowable
>> number format for INCH coordinates is 2.4, while METRIC coordinates
>> default to 3.3 but could also be 3.2 or 4.2.  The latter case needs to
>> be explicitly specified.
>>
>> The only real discrepancy I encountered is that Excellon says the
>> default zero format is to use leading zeros (i.e., omit the trailing
>> zeros) while all Excellon files floating around that don't have an
>> explicit LZ or TZ in the header seem to contradict to that.  So I went
>> with all these examples, and made the code default to trailing zeros
>> being specified.
>>
>> The new implementation works on all the Excellon files that are in the
>> example directory, plus on all Excellon files I've got around here
>> (which are from either BAE or Protel).  Note that the code as it is in
>> CVS failed on my own files before.  There is one semi-guess built in:
>> the file example/nollezappare/ThruHolePlated.ncd does not have a
>> METRIC specification in the header but only a M71 code in the data
>> part of the file, yet they obviously give the tool definitions in the
>> header in millimeters rather than inches.  IMHO that violates the
>> Excellon spec.  To get it working, I'm now keeping track of whether
>> INCH or METRIC had been seen before in the header, and if not, I
>> recalculate the tool size upon encountering the M71 code.
>>
>> As for guessing, I still think the ultimately best route would be to
>> have some User Preferences dialog which provides the defaults to
>> assume for drill files.  This will be essentially the same as a manual
>> operator setup on the CNC machine preceding the part programming file.
>> It could be used to pre-define the following things:
>>
>> . trailing or leading zeros
>> . metric or inch measures, 3.3, 3.2, or 4.2 number formats for the
>>   metric case (maybe even non-standard cases?)
>> . even default tools could be supplied so an Excellon files that
>>   just uses the tools but does not define them could be parsed
>>
>> The patch also removes the METR/METI/METC drill code statistics.  They
>> should never have been three separate items in the first place,
>> because the code previously parsed the word METRIC rather than three
>> different words METR, METI, and METC.  This was done in a rather
>> horrible nested (or rather chained) if statement that could obviously
>> be parsed correctly by a compiler but not by a human. ;-)  Second, the
>> keyword METRIC is not a genuine M code so collecting statistics on it
>> IMHO does not make sense.  It is (now) only allowed inside the header.
>> The code to parse the METRIC keyword is only in drill_parse_M_code()
>> since it starts with M, and other M codes are allowable within the
>> header as well.
>>
>> Please give that a try.  If you encounter Excellon files that aren't
>> parsed correctly, I'd like to get them in order to see what the
>> problem is.  In particular, I'd like to ask people with Eagle files to
>> test it because there apparently aren't any of them in the examples
>> directory.
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________ Gerbv-devel mailing list Ger...@li... <mailto:Ger...@li...> https://lists.sourceforge.net/lists/listinfo/gerbv-devel
> Julian
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Gerbv-devel mailing list
> Ger...@li...
> https://lists.sourceforge.net/lists/listinfo/gerbv-devel

Re: [Gerbv-devel] autobuild

[Dan M. <da...@mc...>]

Julian wrote:
> Dan,
>     What kind of information would it send out...just the stdout 
> messages from cvs update and both builds?  My gut instinct says the (new 
> information gained divided by the work of reading through the logs) 
> quotient may not be very high.  Have you done this before?  On PCB?

Stuart set up a gerbv-build list so we don't spam the devloper list. 
Basically if everything works all you get is a couple line summary plus 
the result of

grep warn make.log

(make.log was the output of make)

If something  fails to build or fails to configure, you get the full result.

What I might do at some point is set it up so if there are no warnings 
or failures that the mail doesn't go or maybe just goes to me (so I know 
my cron job is alive).

-Dan

Re: [Gerbv-devel] autobuild

[Julian <the...@gm...>]

Dan,
    What kind of information would it send out...just the stdout
messages from cvs update and both builds?  My gut instinct says the (new
information gained divided by the work of reading through the logs)
quotient may not be very high.  Have you done this before?  On PCB?


On Wed, 2007-12-12 at 09:09 -0500, Dan McMahill wrote:

> I'm mostly set up to automatically to a cvs update and if anything 
> changed, do both cairo and gdk builds and have an email generated.  Is 
> that something people would find useful?  Should it go to this list?  Or 
> would that just be considered spam?
> 
> It's not set up to do it yet, but I could probably teach the build 
> script to only spam the list if there are build failures or compiler 
> warnings generated.
> 
> -Dan
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Gerbv-devel mailing list
> Ger...@li...
> https://lists.sourceforge.net/lists/listinfo/gerbv-devel

Julian

Re: [Gerbv-devel] First draft of rewritten drill parser

[Julian <the...@gm...>]

Excellent work, Joerg!  I'm curious to get Stefan's thoughts on the
patch when he has time...he probably knows of some of the reasons behind
the old drill parsing guessing, so I'm curious if he knows of many
"gotchas" from bad drill files he's seen.  But, I can't wait to see it
in CVS (Stuart, are you going to merge this in?).  Also, does this
address Patch #1626449 in Sourceforge?  If so, remind me so I can close
it out.

Also, speaking of Sourceforge, do you still get the Integer warnings
with CVS Joerg?  I applied the part of your patch I referred to in an
earlier email and wanted to know if that was indeed enough to stop the
warnings.  If not, we can add the other half of your patch back in.

Thanks--

On Wed, 2007-12-12 at 22:46 +0100, Joerg Wunsch wrote:

> As promised, I rewrote a large part of the drill parser.  Sorry
> Stuart, this work might partially collide with your drill statistics
> work.  If you eventually accept the patch, I volunteer to manually
> resolve the conflicts (or just commit the statistics patch to CVS
> before, and I'll resolve it after a cvs update).
> 
> I read the Excellon manuals up and down.  I think we can do with much
> less guesswork than we used to.  Excellon says that the only allowable
> number format for INCH coordinates is 2.4, while METRIC coordinates
> default to 3.3 but could also be 3.2 or 4.2.  The latter case needs to
> be explicitly specified.
> 
> The only real discrepancy I encountered is that Excellon says the
> default zero format is to use leading zeros (i.e., omit the trailing
> zeros) while all Excellon files floating around that don't have an
> explicit LZ or TZ in the header seem to contradict to that.  So I went
> with all these examples, and made the code default to trailing zeros
> being specified.
> 
> The new implementation works on all the Excellon files that are in the
> example directory, plus on all Excellon files I've got around here
> (which are from either BAE or Protel).  Note that the code as it is in
> CVS failed on my own files before.  There is one semi-guess built in:
> the file example/nollezappare/ThruHolePlated.ncd does not have a
> METRIC specification in the header but only a M71 code in the data
> part of the file, yet they obviously give the tool definitions in the
> header in millimeters rather than inches.  IMHO that violates the
> Excellon spec.  To get it working, I'm now keeping track of whether
> INCH or METRIC had been seen before in the header, and if not, I
> recalculate the tool size upon encountering the M71 code.
> 
> As for guessing, I still think the ultimately best route would be to
> have some User Preferences dialog which provides the defaults to
> assume for drill files.  This will be essentially the same as a manual
> operator setup on the CNC machine preceding the part programming file.
> It could be used to pre-define the following things:
> 
> . trailing or leading zeros
> . metric or inch measures, 3.3, 3.2, or 4.2 number formats for the
>   metric case (maybe even non-standard cases?)
> . even default tools could be supplied so an Excellon files that
>   just uses the tools but does not define them could be parsed
> 
> The patch also removes the METR/METI/METC drill code statistics.  They
> should never have been three separate items in the first place,
> because the code previously parsed the word METRIC rather than three
> different words METR, METI, and METC.  This was done in a rather
> horrible nested (or rather chained) if statement that could obviously
> be parsed correctly by a compiler but not by a human. ;-)  Second, the
> keyword METRIC is not a genuine M code so collecting statistics on it
> IMHO does not make sense.  It is (now) only allowed inside the header.
> The code to parse the METRIC keyword is only in drill_parse_M_code()
> since it starts with M, and other M codes are allowable within the
> header as well.
> 
> Please give that a try.  If you encounter Excellon files that aren't
> parsed correctly, I'd like to get them in order to see what the
> problem is.  In particular, I'd like to ask people with Eagle files to
> test it because there apparently aren't any of them in the examples
> directory.
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ Gerbv-devel mailing list Ger...@li... https://lists.sourceforge.net/lists/listinfo/gerbv-devel

Julian

Re: [Gerbv-devel] First draft of rewritten drill parser

[Dan M. <da...@mc...>]

Joerg Wunsch wrote:
> As promised, I rewrote a large part of the drill parser.  Sorry
> Stuart, this work might partially collide with your drill statistics
> work.  If you eventually accept the patch, I volunteer to manually
> resolve the conflicts (or just commit the statistics patch to CVS
> before, and I'll resolve it after a cvs update).
> 
> I read the Excellon manuals up and down.  I think we can do with much
> less guesswork than we used to.  Excellon says that the only allowable
> number format for INCH coordinates is 2.4, while METRIC coordinates
> default to 3.3 but could also be 3.2 or 4.2.  The latter case needs to
> be explicitly specified.

I don't have access to pads right now, but I pretty certain it lets you 
specify the number format and have more than the 2.4 for inches.  Maybe 
2.5.  The unfortunate reality is that there probably are CAD tools out 
there capable of producing stuff outside the Excellon spec.

In fact, I'm looking at an old file created by pads and see that it sure 
looks like 2.5.  The board is 5.5 inches by 4.5 inches.  See if this 
looks right with the new code.

I actually wonder if there needs to be the ability to explicitly set the 
format for problem files.


%
T1F95S300C0.01
X318800Y524350
X318800Y539150
X369500Y656950
X369500Y639000
X548500Y626600

T2F95S300C0.015
X93750Y371300
X58300Y422500
X91550Y431650

T11F35S794C0.125
X60200Y368100
X60200Y778100
X570200Y778100
X570200Y368100

M30

[Gerbv-devel] First draft of rewritten drill parser

[Joerg W. <j...@ur...>]

As promised, I rewrote a large part of the drill parser.  Sorry
Stuart, this work might partially collide with your drill statistics
work.  If you eventually accept the patch, I volunteer to manually
resolve the conflicts (or just commit the statistics patch to CVS
before, and I'll resolve it after a cvs update).

I read the Excellon manuals up and down.  I think we can do with much
less guesswork than we used to.  Excellon says that the only allowable
number format for INCH coordinates is 2.4, while METRIC coordinates
default to 3.3 but could also be 3.2 or 4.2.  The latter case needs to
be explicitly specified.

The only real discrepancy I encountered is that Excellon says the
default zero format is to use leading zeros (i.e., omit the trailing
zeros) while all Excellon files floating around that don't have an
explicit LZ or TZ in the header seem to contradict to that.  So I went
with all these examples, and made the code default to trailing zeros
being specified.

The new implementation works on all the Excellon files that are in the
example directory, plus on all Excellon files I've got around here
(which are from either BAE or Protel).  Note that the code as it is in
CVS failed on my own files before.  There is one semi-guess built in:
the file example/nollezappare/ThruHolePlated.ncd does not have a
METRIC specification in the header but only a M71 code in the data
part of the file, yet they obviously give the tool definitions in the
header in millimeters rather than inches.  IMHO that violates the
Excellon spec.  To get it working, I'm now keeping track of whether
INCH or METRIC had been seen before in the header, and if not, I
recalculate the tool size upon encountering the M71 code.

As for guessing, I still think the ultimately best route would be to
have some User Preferences dialog which provides the defaults to
assume for drill files.  This will be essentially the same as a manual
operator setup on the CNC machine preceding the part programming file.
It could be used to pre-define the following things:

. trailing or leading zeros
. metric or inch measures, 3.3, 3.2, or 4.2 number formats for the
  metric case (maybe even non-standard cases?)
. even default tools could be supplied so an Excellon files that
  just uses the tools but does not define them could be parsed

The patch also removes the METR/METI/METC drill code statistics.  They
should never have been three separate items in the first place,
because the code previously parsed the word METRIC rather than three
different words METR, METI, and METC.  This was done in a rather
horrible nested (or rather chained) if statement that could obviously
be parsed correctly by a compiler but not by a human. ;-)  Second, the
keyword METRIC is not a genuine M code so collecting statistics on it
IMHO does not make sense.  It is (now) only allowed inside the header.
The code to parse the METRIC keyword is only in drill_parse_M_code()
since it starts with M, and other M codes are allowable within the
header as well.

Please give that a try.  If you encounter Excellon files that aren't
parsed correctly, I'd like to get them in order to see what the
problem is.  In particular, I'd like to ask people with Eagle files to
test it because there apparently aren't any of them in the examples
directory.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: [Gerbv-devel] Attempt to dereference a generic pointe

[Stefan P. <sp...@st...>]

Who's got the long nose now? I spoke too soon...

In file included from draw.c:38:
draw.h:113: warning: 'struct gerb_image' declared inside parameter list
draw.h:113: warning: its scope is only this definition or declaration,
which is probably not what you want
draw.c:348: warning: 'struct gerb_image' declared inside parameter list
draw.c:349: error: conflicting types for 'draw_image_to_cairo_target'
draw.h:113: error: previous declaration of 'draw_image_to_cairo_target'
was here
draw.c: In function 'draw_image_to_cairo_target':
draw.c:355: error: dereferencing pointer to incomplete type
draw.c:434: error: dereferencing pointer to incomplete type
draw.c:446: error: dereferencing pointer to incomplete type
draw.c:449: error: dereferencing pointer to incomplete type
draw.c:455: error: dereferencing pointer to incomplete type
draw.c:456: error: dereferencing pointer to incomplete type
draw.c:462: error: dereferencing pointer to incomplete type
draw.c:475: error: dereferencing pointer to incomplete type
draw.c:491: error: dereferencing pointer to incomplete type
draw.c:515: error: dereferencing pointer to incomplete type
draw.c:516: error: dereferencing pointer to incomplete type
draw.c:517: error: dereferencing pointer to incomplete type
draw.c:518: error: dereferencing pointer to incomplete type
draw.c:519: error: dereferencing pointer to incomplete type
draw.c:524: error: dereferencing pointer to incomplete type
draw.c:543: error: dereferencing pointer to incomplete type
draw.c:544: error: dereferencing pointer to incomplete type
draw.c:545: error: dereferencing pointer to incomplete type
make[2]: *** [draw.o] Error 1

But this is files you have not modified. The hunt goes on...

/spe

Re: [Gerbv-devel] Attempt to dereference a generic pointe

[Stefan P. <sp...@st...>]

Here we go third time. Here is your culprit (from the patch):
-typedef struct gerb_image {
+typedef struct {

You remove the definition of "struct gerb_image" which is sent as a
parameter to "draw_image_to_cairo_target" which is defined in draw.h.

Hopefully this is it.

/spe