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=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=8YpYVB6yaLHTirN9xM/xVgQBka5i3STtw4JECvHCAwc=;
        b=l5ecCpO99YD7zZvy+hgbcxF1UfJePyQXvZ5TWLg73tFCJNgLrCPAFpROqzWpYYr40K
         Ikqr4Uipr9oLHTGA9UfwFn6Va0TCcg9XIjmPj7zWB67s09+348zaO1Bibszj3gKxWY4C
         Imm8lJzaoRymb0WCx8Bi3e0Ck0nwUU8qoX9DNYtZNli5f0dRckR0Fp3NUeuRj20rO2pq
         OTZxh0HNnYhUpBB55lS2H65K/LQWMwDmb49s8ClJVgNNOdCzGoVd39bjo5aGVIua6rBq
         jgyZSRN55HH5Yuj79O1h7tYaOBxQiK4CnpEgE9mLaHD34eKGCtwHLcds/pgTaQakjxJW
         0Kkg==
MIME-Version: 1.0
X-Received: by 10.112.64.72 with SMTP id m8mr700006lbs.41.1444227467314; Wed,
 07 Oct 2015 07:17:47 -0700 (PDT)
In-Reply-To: <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>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1510070712400 DOT 7137 AT igor2priv>
Date: Wed, 7 Oct 2015 10:17:47 -0400
Message-ID: <CAM2RGhS=ymV3zzqFEO9gFsDpxMzjD1RC=39Rp6dOvNZv14hE7w@mail.gmail.com>
Subject: Re: [geda-user] GTK3, Glade interface designer (how to support
 multiple scripting languages without n^2 effort)
From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: gEDA users mailing list <geda-user AT delorie DOT com>
Content-Type: text/plain; charset=UTF-8
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, Oct 7, 2015 at 1:46 AM,  <gedau AT igor2 DOT repo DOT hu> wrote:
>
>
> 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.

That is a point. I mean the interpriters like python and tcl are not
built into GPMI so it is just a question of having a lot of
dependencies not a single large package.

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

+1

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

+1

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

+1
(although in codecs it makes me worry about security)

> 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



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/