X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=prochac.sk;
	s=default; t=1453068999;
	bh=NV/4Zlesm9Vm090G6ixILM9CJjyqJtdVdlCoCwQ7iBU=;
	h=Subject:To:References:From:Date:In-Reply-To;
	b=Dwtrwe9YGK2d4UkxkFf9xro3NfYetS+XggaF9LJYzSonQ+h4L/06cuQf+13tbH4yH
	GeVS0exF1ND31SN5QRQu7AYg+fDkomU70zPYDcwAXvr8DP1BGtEu5YeyWDBThTy7vD
	Gt7MI1v63tozIJXSykGoKWAEenhEd8DKUs2XeiO0=
X-Clacks-Overhead:	"GNU Terry Pratchett"
Subject:	Re: [geda-user] can we agree on a common start point for file format
	plugin stuff please
To:	geda-user AT delorie DOT com
References:	<CAC4O8c9eSvBVJ0oj17Tv+HFqSU3k3KAF2qjDi8S3B+ayqQx_6w AT mail DOT gmail DOT com>
	<201601170055 DOT u0H0to54024329 AT envy DOT delorie DOT com>
	<CAC4O8c8piNdZD2R=9BOu5Rw2u584jY4J1wAREZhu7rKu0h8xEg AT mail DOT gmail DOT com>
	<569AF06E DOT 1010902 AT prochac DOT sk>
	<CAC4O8c8kck08w9NuyhCoJC5pPK__Mt6KKUfZfcMdWM-q02tQ6g AT mail DOT gmail DOT com>
From:	"Milan Prochac (milan AT prochac DOT sk) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<569C130C.4090706@prochac.sk>
Date:	Sun, 17 Jan 2016 23:17:48 +0100
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.5.1
MIME-Version:	1.0
In-Reply-To:	<CAC4O8c8kck08w9NuyhCoJC5pPK__Mt6KKUfZfcMdWM-q02tQ6g@mail.gmail.com>
X-Spam-Status:	No, score=-101.0 required=5.0 tests=ALL_TRUSTED,
	USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0
X-Spam-Checker-Version:	SpamAssassin 3.4.0 (2014-02-07) on angua.bastl.sk
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 17. 1. 2016 22:12, Britton Kerin (britton DOT kerin AT gmail DOT com) [via 
geda-user AT delorie DOT com] wrote:
>
> I ran into a couple more small issues. You're probably already aware 
> but here they are:
>
> * The untrue (failure) result from SavePCBWithFormat() seems totally 
> ignored, it should really get an error popup or at the very least a 
> log message since this is the case where your work isn't actually 
> saved.  I'm not sure if it could be handled at the SavePCBWithFormat() 
> call points or if it would need to be further up.  This isn't a 
> problem with your branch, master has it too.  But it might be easier 
> to fix in your branch since it looks like you factored 
> SavePCBWithFormat() into backup.  We don' t want to fix it both places 
> as would just make merge pain later
>

We should address this as separate issue and/or improvement.  I do not 
want change more than necessary of the original code as part of the 
feature implementation. It makes review/testing/rollback easier.

> * It looks like SavePCB() and SavePCB2() are dead code now so should 
> be removed.  I like to put '// FIXME: I think I'm dead' by stuff like 
> this but maybe you just remember
>

They are used by built-in PCB format plugin. SavePCB is function in 
original PCB code and SavePCB2  is used to transform parameter list. 
Currently these are the only functions which really save the PCB layout.

> * There's some scope to reduce the number of points that need to be 
> edited in fftemplate.c.  For example with the below only the first 
> define value needs to change.
>
>      #include <stdio.h>
>      #define FORMAT_ID foo
>      // Stringify the argument.  Note that the argument isn't expanded.
>      #define STRINGIFY(arg) #arg
>      // First expand arg then STRINGIFY() it.
>      #define EXPAND_AND_STRINGIFY(arg) STRINGIFY (arg)
>      // Conctenate arg1 and arg2.  Note that the arguments aren't 
> expanded.
>      #define CONCAT(arg1, arg2) arg1 ## arg2
>      // First expand arg1 and arg2, then concatenate the results.
>      #define EXPAND_AND_CONCAT(arg1, arg2) CONCAT (arg1, arg2)
>      #define FORMAT_ID_STRING EXPAND_AND_STRINGIFY (FORMAT_ID)
>      #define FORMAT_FUNC(arg) EXPAND_AND_CONCAT (arg, FORMAT_ID)
>      int
>      FORMAT_FUNC (parse) (char *filename)
>      {
>        printf (
>            "I'm a " FORMAT_ID_STRING " parser parsing %s in %s!\n",
>            filename,
>            __func__
>            );
>        return 0;
>      }
>      int
>      main (void)
>      {
>        (FORMAT_FUNC (parse)) ("file.foo");
>        return 0;
>      }
>
> It's also a good idea to use use static functions for Parse Save etc. 
> provided everything external goes through the pointers in HID_Format, 
> in which case the function-name generating macro invocations are optional.
>

IMO the template is not the file which will be edited on daily basis, so 
it is not worth too much effort.

Static functions are good idea.

Milan

> Britton

- Raw text -