GNU bug report logs - #56768
[PATCH] gnu: engineering: Add qucs-s.

Previous Next

To reply to this bug, email your comments to 56768 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: engineering: Add qucs-s.
Date: Mon, 25 Jul 2022 23:02:48 +0300

[Message part 1 (text/plain, inline)]

Hello,

this patch adds "Qucs-S", a GUI for different circuit simulation
kernels:
  https://github.com/ra3xdh/qucs_s

Currently the package supports only Ngspice simulation kernel, as it is
recommended by the authors and it is readily available in Guix; but in
the future other kernels can be added, namely Xyce (which is in the Guix
too.)

[0001-gnu-Add-qucs-s.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Thanks,

- Artyom

-- 
Artyom "avp" Poptsov <poptsov.artyom <at> gmail.com>
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>, 56768 <at> debbugs.gnu.org
Subject: Re: [bug#56768] [PATCH] gnu: engineering: Add qucs-s.
Date: Tue, 26 Jul 2022 20:07:46 +0200

[Message part 1 (text/plain, inline)]

> this patch adds "Qucs-S", a GUI for different circuit simulation
Often GUIs have problems with finding icons, could you check whether qucs-s works in a pure environment?

> +    (propagated-inputs (list ngspice))

Propagation is not very robust (e.g. if run directly from the store with 
$(guix build qucs-s)/bin/the-binary), would it be possible to not 
propagate this? E.g., if you are propagating it because of not finding a 
binary, you could use substitute* to insert an appropriate absolute file 
name.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #11 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 56768 <at> debbugs.gnu.org
Subject: Re: [bug#56768] [PATCH] gnu: engineering: Add qucs-s.
Date: Fri, 29 Jul 2022 18:26:53 +0300

[Message part 1 (text/plain, inline)]

Hello Maxime,

thanks you for the patch review!

> Often GUIs have problems with finding icons, could you check whether
> qucs-s works in a pure environment?

I tried to run Qucs-S installed through Guix, like the follows:

--8<---------------cut here---------------start------------->8---
guix shell -D guix
./pre-inst-env guix shell -D --pure qucs-s
qucs-s
--8<---------------cut here---------------end--------------->8---

And all the icons seem to be fine

Although it can be that I don't fully understand what you mean by "pure
environment" in that case.

> Propagation is not very robust (e.g. if run directly from the store with $(guix
> build qucs-s)/bin/the-binary), would it be possible to not propagate this? E.g.,
> if you are propagating it because of not finding a binary, you could use
> substitute* to insert an appropriate absolute file name.

Okay, that's a good point.  I checked the sources for the places where
Qucs-S uses executable paths and added substitutions for that.

I kept NGSpice in "propagated-inputs" because Qucs-S requires it to do
the simulations in runtime.

Also I've added GNU Octave to the "propagated-inputs" and substituted
the path to Octave too.

I tried to run simulations from the examples provided with the Qucs-S
and it seems to me that Qucs-S mostly works as it should.

I should note here that I'm not very good at electronics and such
simulations yet, so you should take what I said above with a grain of
salt indeed.  ;-)

Please check the updated patch.

[0001-gnu-Add-qucs-s.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Thanks,

- Artyom

-- 
Artyom "avp" Poptsov <poptsov.artyom <at> gmail.com>
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
Cc: 56768 <at> debbugs.gnu.org
Subject: Re: [bug#56768] [PATCH] gnu: engineering: Add qucs-s.
Date: Fri, 29 Jul 2022 18:17:30 +0200

[Message part 1 (text/plain, inline)]

On 29-07-2022 17:26, Artyom V. Poptsov wrote:
> Hello Maxime,
>
> thanks you for the patch review!
>
>> Often GUIs have problems with finding icons, could you check whether
>> qucs-s works in a pure environment?
> I tried to run Qucs-S installed through Guix, like the follows:
>
> --8<---------------cut here---------------start------------->8---
> guix shell -D guix
> ./pre-inst-env guix shell -D --pure qucs-s
> qucs-s
> --8<---------------cut here---------------end--------------->8---
>
> And all the icons seem to be fine
>
> Although it can be that I don't fully understand what you mean by "pure
> environment" in that case.


That's what I meant, thanks.  I guess the icons issue is GTK-specific 
and doesn't happen for Qt.

>> Propagation is not very robust (e.g. if run directly from the store with $(guix
>> build qucs-s)/bin/the-binary), would it be possible to not propagate this? E.g.,
>> if you are propagating it because of not finding a binary, you could use
>> substitute* to insert an appropriate absolute file name.
> Okay, that's a good point.  I checked the sources for the places where
> Qucs-S uses executable paths and added substitutions for that.
These substitutions look fine ...

> + (("QucsSettings.NgspiceExecutable = ngsp_exe")
> +                      (string-append "QucsSettings.NgspiceExecutable 
> = \""
> +                                     (assoc-ref inputs "ngspice")
> +                                     "/bin/ngspice"
> +                                     "\""))
> +                     (("QucsSettings.OctaveExecutable = \"octave\" + 
> QString(executableSuffix)")
> +                      (string-append "QucsSettings.OctaveExecutable = \""
> +                                     (assoc-ref inputs "octave")
> +                                     "/bin/octave"
> +                                     "\""))))))))
... but they can be improved, by replacing the assoc-ref with 
search-input-file: (search-input-file inputs "/bin/ngspice"). That way, 
it doesn't depend on the package name anymore, which is preferred by 
<https://guix.gnu.org/blog/2021/the-big-change/> (*) and makes in some 
cases --with-input more usable. That blog post also has en example.

(*) Don't follow the first 'hello' example though -- it showcases 
possibilities, not what should be done, and interferes with --with-input.

> I kept NGSpice in "propagated-inputs" because Qucs-S requires it to do
> the simulations in runtime.
>
> Also I've added GNU Octave to the "propagated-inputs" and substituted
> the path to Octave too.
By that logic, since qtbase and qtsvg are used at runtime too, they 
should be propagated as well, but ...
> I tried to run simulations from the examples provided with the Qucs-S
> and it seems to me that Qucs-S mostly works as it should.

... as you have observed, things work even when they aren't propagated 
(at least for qtbase etc., ngspice and octave have not yet been tested).

Less experimentally, the propagated- in propagated-inputs means only 
that: propagation -- the dependencies are still installed even if they 
aren't propagated, because the substitute* inserts a reference so the GC 
knows to not delete it, the only difference is that the dependency isn't 
automatically put in the profile when not propagating.

In theory, the propagation shouldn't be required because you added a 
'substitute*', so in principle qucs-s should know where to find it.

Also, I noticed these substitutions modify configuration, could you 
verify they aren't saved in wherever qucs-s' configuration file is 
located? Because if they are, then even after an update of octave etc. 
it would seem that qucs-s would still use the old octave.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #17 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
To: Maxime Devos <maximedevos <at> telenet.be>
Cc: 56768 <at> debbugs.gnu.org
Subject: Re: [bug#56768] [PATCH] gnu: engineering: Add qucs-s.
Date: Sat, 30 Jul 2022 09:59:21 +0300

[Message part 1 (text/plain, inline)]

Hello Maxime.

> That's what I meant, thanks.  I guess the icons issue is GTK-specific
> and doesn't happen for Qt.

Yes, Qt allows the application resources (like icons) to be put into the
application binary on the build time, and that's how it's done usually.

> These substitutions look fine ... ... ... but they can be improved, by
> replacing the assoc-ref with search-input-file: (search-input-file
> inputs "/bin/ngspice"). That way, it doesn't depend on the package
> name anymore, which is preferred by
> <https://guix.gnu.org/blog/2021/the-big-change/> (*) and makes in some
> cases --with-input more usable. That blog post also has en example.

Done.

> By that logic, since qtbase and qtsvg are used at runtime too, they
> should be propagated as well, but ...
> > I tried to run simulations from the examples provided with the
> > Qucs-S and it seems to me that Qucs-S mostly works as it should.

> ... as you have observed, things work even when they aren't propagated
> (at least for qtbase etc., ngspice and octave have not yet been
> tested).

I usually put into "propagated-inputs" packages that provide some binary
that the current package use in the runtime.

So do you mean that I should rely only on "inputs" package property, and
the inputs will be propagated anyway if they're in use by the package?

> In theory, the propagation shouldn't be required because you added a
> 'substitute*', so in principle qucs-s should know where to find it.

Following your logic I moved NGSpice and Octave from "propagated-inputs"
to "inputs" as they substituted in the sources.

> Also, I noticed these substitutions modify configuration, could you
> verify they aren't saved in wherever qucs-s' configuration file is
> located? Because if they are, then even after an update of octave etc.
> it would seem that qucs-s would still use the old octave.

Good catch.  In my previous patch I substituted NGSpice and Octave in the
part of code that is executed only when no configuration is provided, so
the current binary versions used by default.  However after the first run
Qucs-S stores the paths to the configuration file:

--8<---------------cut here---------------start------------->8---
$ cat ~/.config/qucs/qucs_s.conf [General] ...
NgspiceExecutable=/gnu/store/jl159ilvjzxd0i45xf2z8llbhvl10w54-ngspice-37/bin/ngspice
...
--8<---------------cut here---------------end--------------->8---

So the next time Qucs-S run it gets the paths from the configuration
file.

I changed the substitutions so Qucs-S will ignore the paths to Octave
and NGSpice from the configuration and will always use the paths
provided by Guix.  Also any custom paths to Octave and NGSpice will be
overwritten in the config when the application exits.

That is sub-optimal in my view as we're messing up with the application
configuration logic and if a user wants to change those paths he or she
will be able to remove the config and set the paths in the startup
configuration dialogue, but the settings will have no effect; that will
be a bit confusing.

Yet at least Qucs-S will always use the right Octave/NGSpice path from
GNU Guix.

What do you think?

Here's the patch.

[0001-gnu-Add-qucs-s.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Thanks,

- Artyom

-- 
Artyom "avp" Poptsov <poptsov.artyom <at> gmail.com> Home page:
https://memory-heap.org/~avp/ CADR Hackerspace co-founder:
https://cadrspace.ru/ GPG: D0C2 EAC1 3310 822D 98DE B57C E9C5 A2D9 0898
A02F

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: Jean Pierre De Jesus DIAZ <me <at> jeandudey.tech>
To: "56768 <at> debbugs.gnu.org" <56768 <at> debbugs.gnu.org>
Subject: [PATCH] gnu: engineering: Add qucs-s.
Date: Sat, 06 Aug 2022 10:15:02 +0000

Hello Artyom,

Just a nitpick:

>+    (description
>+     "@code{Qucs-S} provides a fancy graphical user interface for a number of

@code{Qucs-S} -> @acronym{Qucs-S, Quite universal circuit simulator with SPICE}

>Yet at least Qucs-S will always use the right Octave/NGSpice path from
>GNU Guix.

If the substitute of the binaries path is only done on the `else' block then
the settings would be respected.

For example, on:

https://github.com/ra3xdh/qucs_s/blob/master/qucs/main.cpp#L130-L136

>    if(settings.contains("NgspiceExecutable")) QucsSettings.NgspiceExecutable = settings.value("NgspiceExecutable").toString();
>    else {
>        QString ngsp_exe = QCoreApplication::applicationDirPath() +
>                QDir::separator() + "ngspice" + executableSuffix;
>        if (!QFile::exists(ngsp_exe)) ngsp_exe = QString("ngspice") + executableSuffix;
>        QucsSettings.NgspiceExecutable = ngsp_exe;
>    }

Can be substituted to:

    if(settings.contains("NgspiceExecutable")) QucsSettings.NgspiceExecutable = settings.value("NgspiceExecutable").toString();
    else {
        QString ngsp_exe = "/gnu/store/<substitute* used here>";
        if (!QFile::exists(ngsp_exe)) ngsp_exe = QString("ngspice") + executableSuffix;
        QucsSettings.NgspiceExecutable = ngsp_exe;
    }

Then if `NgspiceExecutable' is present on the configuration that value will be used, otherwise the default
one provided by GNU Guix. Same applies for the other executable files.

—
Jean-Pierre De Jesus DIAZ

Message #23 received at 56768 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
Cc: 56768 <at> debbugs.gnu.org
Subject: Re: [bug#56768] [PATCH] gnu: engineering: Add qucs-s.
Date: Sat, 6 Aug 2022 13:42:53 +0200

[Message part 1 (text/plain, inline)]

On 30-07-2022 08:59, Artyom V. Poptsov wrote:
>> ... as you have observed, things work even when they aren't propagated
>> (at least for qtbase etc., ngspice and octave have not yet been
>> tested).
> I usually put into "propagated-inputs" packages that provide some binary
> that the current package use in the runtime.
>
> So do you mean that I should rely only on "inputs" package property, and
> the inputs will be propagated anyway if they're in use by the package?
>
Yes to the first (at least in this case, propagation is sometimes hard 
to avoid), no to the second. Propagation happens only for 
propagated-inputs; however, if they are 'in use' by the package by 
ending up in the references, then the GC won't remove the store items. 
The GC and propagation are independent mechanisms.

> Less experimentally, the propagated- in propagated-inputs means only 
> that: propagation -- the dependencies are still installed even if they 
> aren't propagated, because the substitute* inserts a reference so the 
> GC knows to not delete it, the only difference is that the dependency 
> isn't automatically put in the profile when not propagating. 

Here, I meant with 'installed' = entry in /gnu/store is downloaded or 
built and kept, not 'added to ~/.guix-profile or equivalent' -- the 
latter is propagation.

> So the next time Qucs-S run it gets the paths from the configuration
> file.
>
> I changed the substitutions so Qucs-S will ignore the paths to Octave
> and NGSpice from the configuration and will always use the paths
> provided by Guix.  Also any custom paths to Octave and NGSpice will be
> overwritten in the config when the application exits.
>
> That is sub-optimal in my view as we're messing up with the application
> configuration logic and if a user wants to change those paths he or she
> will be able to remove the config and set the paths in the startup
> configuration dialogue, but the settings will have no effect; that will
> be a bit confusing.
>
> Yet at least Qucs-S will always use the right Octave/NGSpice path from
> GNU Guix.
>
> What do you think?
>
> Here's the patch.

It's not ideal that the ngspice cannot be overridden in the 
configuration, but OTOH we have --with-input. I think it's acceptable, 
though if there are any users that would like to override in the 
configuration, we might need to propagate it again and remove the 
substitute* -- or better, though more work: patch qucs-s to use the 
configuration when explicitly set by the user and don't write 
/gnu/store/... inside it automatically, with /gnu/store/... as a 
fallback when it is not set.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Artyom V. Poptsov" <poptsov.artyom <at> gmail.com>
To: guix-patches <at> gnu.org
Subject: Re: [PATCH] gnu: engineering: Add qucs-s.
Date: Sun, 04 Sep 2022 19:00:57 +0300

[Message part 1 (text/plain, inline)]

Hello,

I rebased my patch to the Guix "master" branch.

[0001-gnu-Add-qucs-s.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

- Artyom

-- 
Artyom "avp" Poptsov <poptsov.artyom <at> gmail.com>
Home page: https://memory-heap.org/~avp/
CADR Hackerspace co-founder: https://cadrspace.ru/
GPG: D0C2 EAC1 3310 822D 98DE  B57C E9C5 A2D9 0898 A02F

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.