Mail Archives: geda-user/2015/10/07/00:23:37
On Tue, 6 Oct 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Tue, Oct 6, 2015 at 2:44 PM, Britton Kerin
> (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]
> <geda-user AT delorie DOT com> wrote:
>>
>>
>> On Mon, Oct 5, 2015 at 9:41 PM, Dave McGuire (mcguire AT neurotica DOT com) [via
>> geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>>
>>> On 10/05/2015 11:34 PM, gedau AT igor2 DOT repo DOT hu wrote:
>>>>> Well, considering the fact that I use gEDA and PCB nearly every day,
>>>>> *I* am the user base. And to watch the traffic around here, I'm the
>>>>> only guy busy actually USING this stuff!
>>>>
>>>> I am an user too in that sense. Britton too. We both say scripting is
>>>> good, so you are losing this by rate 2:1.
>>>
>>> Oh hey, no, I never said scripting wasn't good. I like scripting. I
>>> just don't like people getting their panties in a bunch when it isn't
>>> done in their favorite language so they insist it be changed to suit them.
>>
>>
>> There's no real reason not to support multiple scripting languages, as Igor
>> has shown with his fork.
>
> I agree but other people did not. The limitation is in the longer term
> with packaging when distros think that it means they need to build
> against all of them so that every possible 3rd party script works. It
> is also a concern for support/maintenance reasons over having a
> polyglot developer base/contribution.
I do not think it works like that. At least, not with gpmi. In the below
wall of text I will try to show how having multiple languages won't casue
more trouble to the developer or the user than having a modern desktop
system up and running.
To overcome the problem, there are 2 different set of glue layers. One
layer glues pcb-rnd to gpmi and the other glues gpmi to a specific
scripting language. This way gpmi is language-neutral, pcb-rnd is
language-neutral too. When you need a new language, you just need to
install (or compile) the language glue for that one language. By default
it all loads dynamically, so you don't recompile gpmi, you don't
recompile pcb-rnd. No recompilation even if you are installing the glue
for a new scripting language that did not even exist by the time you
compiled pcb-rnd and/or gpmi.
This means a distro can support as many language glues as it wants. This
also means an application that supports one language already supports al
language for which anyone ever made the glue. (All binary API language
glue layers to the currently supported langages are between 150 and 300
sloc in volume so it is not very hard to support a new language.) There's
nothing that forces it to support language foo if foo is incompatible
with the distro for whatever reason. It also means the user doesn't need
to install all languages, just because of the potential need for an user
script in the future. He can install the glues just when he needs them.
The analogy is like if you get to edit a file, for example svg. If you
have a base system, you probably don't have a graphical svg editor
installed. You figure your task now requires editing the svg; you just
install the tool that does it, and do the job. Same with the scripts: you
can install pcb-rnd and gpmi with 0 script languages, then another day you
download an advanced panelizing script written in ruby and figure you need
a ruby glue for that and install the ruby glue. Installing inkscape to
deal with svg doesn't look very different to me than installing a ruby
and the gpmi ruby glue lib to be able to deal with the ruby script.
... in other words:
Everyone writes everything in different languages one level up. If you
want to run peted, you need ruby. If you want to run gimp, on Debian it
brings python. If you install a lot of programs, sooner or later you will
have a lot of different languages on your system. The only ways to avoid
this are either using a single application (e.g. some people use emacs
and try to edit everything with emacs) or carefully selecting your
applications that they all use the same language. I don't think these
happen too often. In my exeprience most users just install the
software they think they need and it rarely keeps them back if the
package brings in another scripting language. Even, when I need to decide
which application to install from two that do the same job, and I say "one
of my reasons for application A is that it is written in languages I
prefer [because then I have more chance to debug it or fix bugs]", I am
considered to be an alien.
So all in all I don't think it is bad or any more risky to have the same
thing on application level (rather than on system level). Because of the
double glue layer, it doesn't require more effort from the application's
side. With proper dependencies, it doesn't require more effort from the
user's side than installing any other software.
Regards,
Igor2
- Raw text -