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-disposition:content-transfer-encoding
         :in-reply-to:user-agent;
        bh=ewU2ttvEHwJMY7s8mMfnmSXXaz071rPZChz5h6grh20=;
        b=tuJ5MnUtb4vSIXLXKRcLPxt+3YcsQ/Agvzvxvdm570MgjlLdacH7KzWR+5Go+Er/75
         D4lh+1ycsSpY+Zh+2KQ/qOK2tY5EDgLIaO3z2KEx1nUfgUaEH3QtIKWBqOQCcpKIDZgo
         8cHBLT0/8qly9V69N8f2xdMsTcr7ZCYBhMmd8JlwCS+kaPKKq2XL2jgtL44GHghsuyOq
         T+TQ+/OYuBe9k156aD6nH59HmxdCy/dcbTnVHmsNkXHA/HbMRRQX9Qgq7Eieg5ltbY2O
         JtviAu0r6IpqhJRtNNgk1K8isbYzrwP4uuIQ6dFqcBj6cT35RcYStX/AKLerSu3nknM8
         4MJw==
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-disposition
         :content-transfer-encoding:in-reply-to:user-agent;
        bh=ewU2ttvEHwJMY7s8mMfnmSXXaz071rPZChz5h6grh20=;
        b=LtYYkXjjcsqW1ibo2fMArc4X23Z8rzfaI7+dKpS/IAwcjNsZR3RjHp+h4G8hR+J0LS
         yYY2VkLqJLBOtPo6VJDJpQA13/GJO0ZANEpyH6sdRcj4XBaWyYi2AgAM2SrL13bSVsh1
         5AfBQb8rDRw21gsjKMXxUaI2S0l5vOYmcer9VlN9yai5BVZkY6e/YbZ2waPhQQ0pmGY5
         oZNgP4IuuYsgtdQVMjbX9RT7umO+vhhGfPMQE/IaxSvISA0lX+3rygwn/BjPY2MSrm0n
         FXttcdQHcrMjgLzrVWhk9gRXfvOkxMLtBVWKDEZvuDcSpnLeVAd75cBGL8rJCrHAfbz5
         PuZA==
X-Gm-Message-State: AE9vXwPJWV/80O1RCft0oGEF9FG4J8ttlYSy3cGb3LxApyr2C3k9AF9pi9I6RG5FImZ70w==
X-Received: by 10.25.34.65 with SMTP id i62mr8446990lfi.7.1472901233112;
        Sat, 03 Sep 2016 04:13:53 -0700 (PDT)
Date: Sat, 3 Sep 2016 14:13:51 +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] Oscopy
Message-ID: <20160903111351.GA32623@localhost.localdomain>
Mail-Followup-To: geda-user AT delorie DOT com
References: <CANqhZFwC48g07MUY411a20C5oipkmmkzUimhz8OgvL2Thi-yDg AT mail DOT gmail DOT com>
 <1471984429 DOT 18763 DOT 30 DOT camel AT oscopy DOT org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1471984429.18763.30.camel@oscopy.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Note-from-DJ: This may be spam
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

On Tue, Aug 23, 2016 at 10:33:49PM +0200, Arnaud Gardelein wrote:
...
> > Apart from what has been already said, there are other things to
> > improve:
> > - your keymap seems to conflict with gschem's default one,
> >   e.g. "l" is used for adding lines; I would suggest to use
> >   something like "<Shift>O L" where the prefix "<Shift>O" could
> >   mean Oscopy menu and would be easily to remember for users.
> > - your oscopy.scm is obsolete for gschem 1.9.x.
> >   I had to change your keymap to make it work in the recent
> >   version. The patch set is attached. It would be better, if you
> >   had a check of gschem version in Makefile.am to choose a proper
> >   version of oscopy.scm. The suggested changes include gettext
> >   support so your new menus are automatically translated if they
> >   have corresponding records in the geda-gaf *.po files.
> > - I have no $COLORTERM defined, and thus your oscopy:oscopy-cmd
> >   did not work for me. I've rewritten it to make it work using
> >   the function system*. Defining your preferred terminal using
> >   some variable in gschemrc before loading your script would be
> >   convenient. Anyway, you have to mention this variable (I mean
> >   COLORTERM) somewhere in your docs.
> > 
> The patchs are applied. It seems I misinterpreted the meaning of
> $COLORTERM several years ago. Now it shall help to select between xterm
> and gnome-terminal, would this way be suitable ? Or maybe it could be
> only gnome-terminal ?

I use `st' :-)

> To select which version of oscopy.scm to use, I was wondering whether
> it could be performed either at install time of at execution time.

You could use any one of the strategies.

> Would there be a way to get the gschem version ? It seems that gschem
> does not implement the command line option like '--version'. If needed
> I could submit a patch to implement this option.

$ gschem --version
gEDA 1.9.2 (gc48c185)
Copyright (C) 1998-2012 gEDA developers
Это свободное программное обеспечение, и его можно распространять при
определённых условиях. Подробности см. в файле COPYING
в дистрибутиве gEDA.
Нет НИКАКИХ ГАРАНТИЙ в рамках, допустимых имеющимся
законодательством.

Probably I don't understand what you are meaning here (?).

Moreover, there is the scheme procedure `gschem-version', which
though works not as I would expect. Comments in the sources say:
--------------------------------8<--------------------------------
/*! \brief Verify the version of the RC file under evaluation.
 *  \par Function Description
 *
 *  Implements the Scheme function "gschem-version". Tests the version
 *  string in the argument against the version of the application
 *  itself.
 *
 *  \param [in] scm_version Scheme object containing RC file version string
 *
 *  \returns #t if the version of the RC file matches the application,
 *           else #f.
 */
-------------------------------->8--------------------------------

I tried it against the version specified in my system-gschemrc and
it works as above:

scheme@(guile-user)> (gschem-version "20150930")
$8 = #t
scheme@(guile-user)> (gschem-version "xxx")
$9 = #f

The only thing you would need is to know actual release dates ;-)

> For the time being, the user has to modify manually the Makefile.am. I
> hope to find a better way before the release of oscopy.

You could also try to use one of autoconf GUILE_MODULE_*
(e.g. GUILE_MODULE_AVAILABLE) together with one of modules which
has been not available in 1.8.x, but is present in 1.9.x (I
suspect (gschem keymap) would be a candidate for this). 

> > Now, I'm on the stage when something is launched if I "launch
> > Oscopy" though I see the message as follows in the background
> > terminal gschem was launched from:
> > 
> > Error org.freedesktop.DBus.Error.ServiceUnknown: The name
> > org.freedesktop.Oscopy was not provided by any .service files
> > 
> > I tried to add "/usr/lib/python3/" and
> > "/usr/lib/python3/dist-packages/" to $PYTHONPATH with no success.
> > 
> > Any hints?
> > 
> Eventually I fixed the communication between gschem and oscopy. I took
> me some time to figure out how to activate actions from gschem, as
> dbus-send do not support complex datasets. I was not able to find
> suitable DBus bindings with Guile, although it seems that Chicken has
> [2]. Maybe someone here could point me to the right direction ?

The only non-ancient thing I found so far is [1] (found in the
discussion at [2]).

> In the meantime I implemented actions activation through a dedicated
> script, called from oscopy.scm. Therefore now it shall be possible to
> run the netlister and the simulator from gschem through oscopy.
> 
> Thanks a lot for your feedback. The experimental branch [3] is up to
> date with those changes, maybe you want to give it a try ?

I was going to play with it, and now I hope to find some time for
it. Thanks.

[1] http://git.savannah.gnu.org/cgit/ossaulib.git/tree/glib/dbus.scm
[2] https://lists.gnu.org/archive/html/guile-user/2014-04/msg00063.html 


-- 
  Vladimir