X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 7 Oct 2015 07:46:25 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] GTK3, Glade interface designer (how to support
 multiple scripting languages without n^2 effort)
In-Reply-To: <201510070458.t974wZu9022589@envy.delorie.com>
Message-ID: <alpine.DEB.2.00.1510070712400.7137@igor2priv>
References: <20151003210701 DOT de392b925f54dadb0a5fedd8 AT gmail DOT com> <CAC4O8c_g7e562Gaotrbi6gLfjP6cJU1ys=MtEkDE7bSh4F9dfg AT mail DOT gmail DOT com> <1443975731 DOT 671 DOT 52 DOT camel AT ssalewski DOT de> <20151004191717 DOT bf8223417541a9306bfbd9ea AT gmail DOT com>
 <CAC4O8c9Bi5HJfcW6wUgm_+4O2gs4vDdBMbS2hF_0dCqnBuJahQ AT mail DOT gmail DOT com> <1443997480 DOT 2068 DOT 32 DOT camel AT ssalewski DOT de> <CAC4O8c-bnGky=Nab59-pOTJkB8Q9Tc5t5hqE+dnEF-777hUjMg AT mail DOT gmail DOT com> <1444070851 DOT 1014 DOT 20 DOT camel AT ssalewski DOT de> <muv4ua$hat$1 AT ger DOT gmane DOT org>
 <alpine DOT DEB DOT 2 DOT 00 DOT 1510060356440 DOT 7137 AT igor2priv> <56133047 DOT 7030402 AT neurotica DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1510060433080 DOT 7137 AT igor2priv> <56133CC4 DOT 7000306 AT neurotica DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1510060523170 DOT 7137 AT igor2priv> <56135F05 DOT 9000203 AT neurotica DOT com>
 <CAC4O8c-OZHX2PLEKEW9X1N4BV0xXf_WfH=JkfiEjAXS6eypLsw AT mail DOT gmail DOT com> <CAM2RGhQFe5C+Z4Ko0zLt02xNDEyZUFQBosq6m7b34zwVV-V4Lg AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1510070555020 DOT 7137 AT igor2priv> <201510070458 DOT t974wZu9022589 AT envy DOT delorie DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 Wed, 7 Oct 2015, DJ Delorie wrote:

>
> Seeing this from the distro side, I agree with Evan.  A distro will
> default to building all the glue up front, partly to ensure the user
> can do whatever they want, and partially "because they can".  Even
> though the glue is dynamically loaded, the distro will still pre-build
> them all.  The only options you get are whether the resulting binaries

Yup. I agree, and never said the opposite. There may be exceptions, tho, 
if a specific language is not in the distro, the glue wouldn't be there 
either.

> are packaged in one big package (likely) or split into one per glue
> layer (unlikely, as they'd be conservative and want to make sure the
> user isn't confused by a partial install).

I disagree on this. I see no reason why a distro would package glues of 
different languages into a single big package. In debian the typical 
approach is to have such independent things in independent packages and 
sometime provide an optional metapackage that depends on all.

If the user wants to install a specific package, he can, but installing 
all at once is easy too by installing the meta.

>
> Sometimes this can lead to problems, but this is how the distros do
> it.  Given the size of a standard desktop install, I don't think this
> is a "big" problem (heh) but that's how it works.

I disagree that "that's how it works". I agree that the packager can 
decide either way, but I do see tons of good examples of the "set of 
small packages" approach in Debian, like:

  - tons of python3-* packages instead of "install everything python 
related from a single package"

  - cantor-backend-* - an example of different language backends end up in 
separate packages

  - geany-plugin-* - same story with plugins from which a few are about 
scripting languages

  - a lot of other examples which are about backends and plugins (pdns, 
akondi, cl-sql, libopendbx1, phonon, lcmaps, munin, shinken, just to name 
a few)

I really see no reason why the same could't or wouldn't happen with gpmi.

> The case where support is added "on the fly" is a rarely used one -
> I've seen it for codecs and that's about it, and even then all the
> codes are pre-built and pre-packaged.

I disagree, I see this mechanism in action pretty often.

Codecs are good examples: as you said, they are pre-built and 
pre-packaged, just like gpmi language glues are (yes, I do have debian 
packages for gpmi). You can install a codec later, without recompiling the 
media player.

Many of the scriptable/modular software I know of are able to load new 
scripts or plugins after startup. Irc clients (ircII, irssi, bitchx, even 
mirc), irc bots (eggdrop), map editor josm. Scripts written in modern 
scripting languages also dynamically load code and other scripts on the 
run. The Linux kernel can load and unload modules on the fly; modules 
that are sometimes not even compiled locally (debian even packages some 
modules like that). Many popular GUI web browser can load and unload 
plugins without restart.

I think loading things on the fly is normal these days. I do use this 
feature in random software from time to time and I am very happy that I 
don't need to restart them for loading a plugin or a script.


Beside arguing on the statistics whether similar mechanisms are 
rare or not, do you have anything against it?


Regards,

Igor2