X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Mailer: exmh version 2.8.0 04/21/2012 (debian 1:2.8.0~rc1-2) with nmh-1.5
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
From: karl AT aspodata DOT se
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] should we broaden scope of libgeda
In-reply-to: <CAMvDHVCi5wR78jybhOEG0EmKyqWVpeaoYFuyWkWSrtkxF7kXQw@mail.gmail.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>
Comments: In-reply-to "Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
   message dated "Thu, 21 Jan 2016 16:21:47 +0300."
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Message-Id: <20160121144142.2703D81053E4@turkos.aspodata.se>
Date: Thu, 21 Jan 2016 15:41:42 +0100 (CET)
X-Virus-Scanned: ClamAV using ClamSMTP
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
Precedence: bulk

Vladimir:
> On 1/2/16, karl AT aspodata DOT se <karl AT aspodata DOT se> wrote:
> ...
> > So currently, if I want to write an "get all syms that this sch file
> > referencs"-program I have to do it in c or don't use libgeda at all.
> >
> > I thought that kind of program could be a nice way to learn a
> > little scheme, but the infrastructure wasn't there.
> 
> You were wrong ;)

I don't mind being wrong. Sometimes you wish wery hard that you are 
wrong, because if you are right you'll get great troubles.

> The attached script will do just what you want.
> 
> You can extend it, if you want, say, by adding menu entry for it, or
> probably add a hook to run it automatically at exit, or make the cache
> dir name configurable and so on.

I changed the dir to "sym_cache", maybe the script and the cache dir
should have the same or similar name.

> Installation:
>   - place the file into your ~/.gEDA;
>   - add somewhere in your ~/.gEDA/gschemrc the line:
>     (load "cache-symbols.scm")
> 
> Usage:
>   - make the "sym" directory in the current directory
>   - open gschem
>   - hit ":" to open command line
>   - type (cache-symbols)
>   - hit Enter
> 
> That's all.

Hmm, didn't work. See log below.

$ grep cache ~/.gEDA/gschemrc 
(load "cache-symbols.scm")
$ ls -l ~/.gEDA/`grep cache ~/.gEDA/gschemrc  | cut -f2 -d\"`
-rw-r--r-- 1 karl users 1894 Jan 21 14:51 /home/karl/.gEDA/cache-symbols.scm
$ grep  sym_cache ~/.gEDA/cache-symbols.scm
(define cache-dir-name "sym_cache")
$ md5sum ~/.gEDA/cache-symbols.scm
45fb7f8d3b9e996123cb7ae13497f527  /home/karl/.gEDA/cache-symbols.scm
$ dir=`grep  sym_cache ~/.gEDA/cache-symbols.scm | cut -f2 -d\"`
$ ls -l $dir ~/$dir
/home/karl/sym_cache:
total 0

sym_cache:
total 0
$

Tried FT (i.e. via menus) also.

...
> 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

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.

///

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
#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.

///


Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57