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=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:mail-followup-to:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=aQf9+JD00IDVJWHyovw9SMT/4N27qke+Nh/7+H0b8IU=;
	b=0oYcU8ohuYBQ4MjNAwFQhfcuA82P0euEm9sBbO3CReq2s30XXmgZjlCvKlM5UW4Bk9
	MGl4T4MTiFb0AV512dqX9Yf5pJW8wkKe+XSiZoF5BZhfeRvbG6G1Pgv4xGUv8NRj5Xgi
	OGDDyD/arbVIRnLp6N/0gMctc+V01nwmtsQvtrzbMpbwEWvyenUqoU69F8ywevvmgdYp
	ac83fUmvknNnKw+mBIf6s8zRVR/0K6zqzF7ev8bh4yHchZzJDgBoxxg+gWUpeG8PJReJ
	nxeC4H89HZaB54XzoRB6NlOSvN7ShCjDLiG90ca6t0m/GvbzrBzH0/gpY4cGMJzAXKlh
	GaPQ==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to
	:references:mime-version:content-type:content-disposition
	:in-reply-to:user-agent;
	bh=aQf9+JD00IDVJWHyovw9SMT/4N27qke+Nh/7+H0b8IU=;
	b=ZHNdgjIXAMoGe9zHsEFS3OtwlL0jq0b+CQMEWoceadQI8+nUJZdjYHP4J8XCESp9Qr
	8CqUpkTfPKI0yHLDJ3+HP5OzgAxNKO/YFMkqD5AaX+8Wux5hTVKzr+u5IuKlrAFsCkSv
	z88U+jf3MalyFWw9souvuWHgTk2Uvnvwc8y9Fyn/SV6VsN55LCCZtPkhtguPVAMJ5EOk
	2RTHsyuhiHr0JusxwvcyUmeZLVRIpGi/CxA3dzcEERYuAzFEYi5YUqAF1UoN0jy601er
	bNrY3U0ltWQQI+g5rgMXQ0zIYMDSfgVH7bQztCFdERPtKdey8xjWIN7mRR30BCUQJFEz
	pqeQ==
X-Gm-Message-State:	ALoCoQlbCZM8eYmiFQdxS4QsQ4ypVwX3tZn0QbKD+yOL0oHihFSp9CniLy5nrZZ4zNSaQ5rEcPXVegqe8oAm6mzcIQ6HDM2bMA==
X-Received:	by 10.112.139.164 with SMTP id qz4mr15265584lbb.41.1453393201124;
	Thu, 21 Jan 2016 08:20:01 -0800 (PST)
Date:	Thu, 21 Jan 2016 19:19:58 +0300
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] should we broaden scope of libgeda
Message-ID:	<20160121161958.GB4788@localhost.localdomain>
Mail-Followup-To:	geda-user AT delorie DOT com
References:	<20160102091556 DOT BBC6D809D79B AT turkos DOT aspodata DOT se>
	<CAJXU7q_Zwyfpcb4g00QCFNTjQ9Le2Tm8WjKz3CKMnNXb7gMceg AT mail DOT gmail DOT com>
	<20160102131252 DOT F383A809D79A AT turkos DOT aspodata DOT se>
	<CAMvDHVCi5wR78jybhOEG0EmKyqWVpeaoYFuyWkWSrtkxF7kXQw AT mail DOT gmail DOT com>
	<20160121144142 DOT 2703D81053E4 AT turkos DOT aspodata DOT se>
MIME-Version:	1.0
In-Reply-To:	<20160121144142.2703D81053E4@turkos.aspodata.se>
User-Agent:	Mutt/1.5.23 (2014-03-12)
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 Thu, Jan 21, 2016 at 03:41:42PM +0100, karl AT aspodata DOT se wrote:
...
> > Obviously, the script mistakenly assumes that the cache dir already
> > exist.
> ...
> 
> I don't mind that.
> 
> > If anybody want to do the same things in C, please do, it is doable,
> > and we'll compare results ;)
> 
> I published a patch
> 
>  http://archives.seul.org/geda/user/May-2011/msg00556.html
> 
> in c to allow the equiv. of 
> 
>  (component-library-search "/Net/cvs/cvs.gedasymbols.org/www/user" "cvs")
> 
> a few years ago. That patch was NAK'ed by P.Brett. Later someone
> else implemented the same thing in scheme, see link below and followups:
> 
>  http://www.delorie.com/archives/browse.cgi?p=geda-user/2011/11/29/10:18:18

Karl, please, no. Don't compare static C string "CVS" compiled in the
code of the program, which you've proposed, with the hi-level Scheme
function taking any argument. Peter Brett, IIUC, has apparently meant
this.

> 
> So to make this script in c I'll have to go through scheme anyhow,
> putting c at a disadvantage.
> 
> So my point is that c is treated like the "cousin from the country" as 
> we say here in Sweden. And the ability to do things in c is affected by 
> that, and any comparison wouldn't be fair.

No, I don't think so. Look, I like C very much, and most of my
contributions so far have been done in C. However, we will never
compare Scheme and C, as we wouldn't compare C and inline assembler. C
is a great language which nevertheless is not a silver bullet. It has
its own limitations.

> ///
> 
> Log window:
> 
> ==============
> Backtrace:
> In unknown file:
>    ?:  0* [invoke-macro "(cache-symbols)"]
> In /usr/local/share/gEDA/system-gschemrc:
>  707:  1  [gschem-log ...
>  707:  2* [simple-format #f "~s
> " ...
>  707:  3* [eval-string-protected "(cache-symbols)"]
> In unknown file:
>    ?:  4* [eval-string "(cache-symbols)"]
>    1:  5* [cache-symbols]
> In /home/karl/.gEDA/cache-symbols.scm:
>   60:  6  [for-each #<procedure cache-page-symbols (page)> (#<geda-page 0x8ba3000>)]
> In unknown file:
>    ?:  7* [cache-page-symbols #<geda-page 0x8ba3000>]
> In /home/karl/.gEDA/cache-symbols.scm:
>   54:  8* [for-each #<procedure cache-symbol #> #]
> In unknown file:
>    ?:  9* [cache-symbol "78xx.sym"]
> In /home/karl/.gEDA/cache-symbols.scm:
>   36: 10* (let ((page #) (component #)) (close-page! (page->file # #)))
>   38: 11  [%close-page! ...
>   39: 12* [page->file #<geda-page 0x8e8ba80> ...
>   44: 13* [get-cache-name "78xx.sym"]
>   22: 14  [string-append "sym_cache" ...
> 
> /home/karl/.gEDA/cache-symbols.scm:22:3: While evaluating arguments to string-append in expression (string-append cache-dir-name file-name-separator-string ...):
> /home/karl/.gEDA/cache-symbols.scm:22:3: Unbound variable:
> file-name-separator-string

Here.

You see, the function 'file-name-separator-string' doesn't work. It's
a stock guile 2.0 function. What's your version of guile? And what's
your version of geda-gaf?

> #f
> More than one component found with name [78xx.sym]
> ==============
> 
> Yes, mult. symbols with the same name is a problem. Just have a
> look at cvs.gedasymbols.org.

It's another question.

Cheers,
  Vladimir

- Raw text -