Emacs ffi

Emacs ffi

[laynor]

I've seen SXEmacs has a foreign function interface, any chance it will
also be in mainstream FSF Emacs?

Re: Emacs ffi

[Pascal J. Bourguignon]

"laynor@gmail.com" <laynor@gmail.com> writes:

> I've seen SXEmacs has a foreign function interface, any chance it will
> also be in mainstream FSF Emacs?

Yes. 

P(FFI in FSF Emacs) = P(somebody ports FFI to FSF Emacs) * P(FFI patch is accepted by FSF Emacs maintainers).

Since you seems interested, and only a programmer would be interested
in FFI, we could evaluate P(somebody ports FFI to FSF Emacs)  to be
about 0.7 (you'll tell us).


On the other hand, AFAIK, FSF (ie. RMS) is not to keen to integrate
FFI to Emacs, so I would evaluate: P(FFI patch is accepted by FSF
Emacs maintainers) = 0.1 in the near future.

Total: P(FFI in FSF Emacs) = 0.7 * 0.1 = 0.07

Which is not null.

Moreover, you might not care about RMS's opinion, and be happy with
your port of FFI to GNU emacs.  There will probably be other users
happy with your patch too, and some interesting stuff will be
developed with it.  Which should increase P(FFI patch is accepted by
FSF Emacs maintainers) eventually.

-- 
__Pascal Bourguignon__

Re: Emacs ffi

[Anselm Helbig]

At Tue, 14 Jul 2009 16:28:49 -0700 (PDT),
"laynor@gmail.com" <laynor@gmail.com> wrote:
> 
> I've seen SXEmacs has a foreign function interface, any chance it will
> also be in mainstream FSF Emacs?

RMS doesn't like it because it would allow to link emacs with non-free
binary code. This leads to many possible licensing problems with
regard to the GPL that RMS wants to avoid. We already have a similar
situation with the Linux kernel. Search the emacs-devel archives for
some discussions about this, e.g.

  http://lists.gnu.org/archive/html/emacs-devel/2003-07/msg00398.html

The pragmatic me would also very much like to see a FFI in GNU Emacs,
but it's also a political issue, unfortunately.

HTH, 

Anselm


-- 
Anselm Helbig 
mailto:anselm.helbig+news2009@googlemail.com

Re: Emacs ffi

[Maurizio Vitale]

>>>>> "Anselm" == Anselm Helbig <anselm.helbig+news2009@googlemail.com> writes:

    Anselm> RMS doesn't like it because it would allow to link emacs
    Anselm> with non-free binary code. This leads to many possible
    Anselm> licensing problems with regard to the GPL that RMS wants to
    Anselm> avoid. We already have a similar situation with the Linux
    Anselm> kernel. Search the emacs-devel archives for some discussions
    Anselm> about this, e.g.

It is worth nothing that the same reasoning applies to GCC plugins,
which have now been accepted into the main thunk with license changes so
that one cannot develop proprietary plugins.

So maybe the same will happen with Emacs as well.

Best regards,

     Maurizio

-- 

Re: as for Calc and the math library

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

> > If Emacs is to have a math library, the library must use high-quality
> > mathematical and numerical algorithms that are well-known and
> > described in many textbooks on this subject matter...
>
> I agree with this point, but I suspect that writing such a library from
> scratch might be a bit difficult.
>
> May I suggest an alternative: abstract out GNU Calc math routines to be
> available from Elisp without having to read Calc sources.
> Such a task would require:
> 1. Documenting some Calc data structures
> 2. Possibly refactoring some Calc functions to use simpler API.
>
> It would be a much easier task and can improve the existing
> functionality.

Even better, given people proper FFI so they can import and use any of the tens
or hundreds of quality math libraries available.

That would also help to keep C core smaller, and relieve the dependency on core
devs to add bindings to future libraries when users want or need them.

A third of Emacs C core could have easily been implemented by users if they had
proper FFI exposed to Lisp instead of C modules which very few people use.

[-- Attachment #2: Type: text/html, Size: 3943 bytes --]

Re: as for Calc and the math library

[Eli Zaretskii]

> From: arthur miller <arthur.miller@live.com>
> Date: Mon, 12 Aug 2024 05:30:08 +0000
> 
> Even better, given people proper FFI so they can import and use any of the tens
> or hundreds of quality math libraries available.

Not going to happen, and you know it.

Re: as for Calc and the math library

[Nicolas Martyanoff]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: arthur miller <arthur.miller@live.com>
>> Date: Mon, 12 Aug 2024 05:30:08 +0000
>> 
>> Even better, given people proper FFI so they can import and use any of the tens
>> or hundreds of quality math libraries available.
>
> Not going to happen, and you know it.

Naïve question, why? I had this problem not so long ago because I wanted
to bind libpq, and I had to abandon the whole idea because dealing with
dynamic modules was way too inconvenient.

Having something similar to Common Lisp FFIs would make it trivial.

Best,

-- 
Nicolas Martyanoff
https://n16f.net
nicolas@n16f.net

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Nicolas Martyanoff <nicolas@n16f.net>
> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
> Date: Mon, 12 Aug 2024 13:23:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: arthur miller <arthur.miller@live.com>
> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
> >> 
> >> Even better, given people proper FFI so they can import and use any of the tens
> >> or hundreds of quality math libraries available.
> >
> > Not going to happen, and you know it.
> 
> Naïve question, why?

Because providing FFI would allow using non-free libraries in Emacs.

We made the effort to allow loading dynamic modules precisely for this
reason: to allow free libraries to be used, but not non-free ones.

Re: as for Calc and the math library

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Martyanoff <nicolas@n16f.net>
>> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
>> Date: Mon, 12 Aug 2024 13:23:27 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: arthur miller <arthur.miller@live.com>
>> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
>> >> 
>> >> Even better, given people proper FFI so they can import and use any of the tens
>> >> or hundreds of quality math libraries available.
>> >
>> > Not going to happen, and you know it.
>> 
>> Naïve question, why?
>
> Because providing FFI would allow using non-free libraries in Emacs.
>
> We made the effort to allow loading dynamic modules precisely for this
> reason: to allow free libraries to be used, but not non-free ones.

There is an item in etc/TODO about adding FFI, as an important feature:

  ** FFI (foreign function interface)
  See e.g. https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html

  One way of doing this is to start with fx's dynamic loading, and use it
  to implement things like auto-loaded buffer parsers and database
  access in cases which need more than Lisp.

Now I'm confused.

Re: as for Calc and the math library

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Nicolas Martyanoff <nicolas@n16f.net>
>>> Cc: arthur miller <arthur.miller@live.com>,  emacs-devel@gnu.org
>>> Date: Mon, 12 Aug 2024 13:23:27 +0200
>>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> 
>>> >> From: arthur miller <arthur.miller@live.com>
>>> >> Date: Mon, 12 Aug 2024 05:30:08 +0000
>>> >> 
>>> >> Even better, given people proper FFI so they can import and use any of the tens
>>> >> or hundreds of quality math libraries available.
>>> >
>>> > Not going to happen, and you know it.
>>> 
>>> Naïve question, why?
>>
>> Because providing FFI would allow using non-free libraries in Emacs.
>>
>> We made the effort to allow loading dynamic modules precisely for this
>> reason: to allow free libraries to be used, but not non-free ones.
>
> There is an item in etc/TODO about adding FFI, as an important feature:
>
>   ** FFI (foreign function interface)
>   See e.g. https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html
>
>   One way of doing this is to start with fx's dynamic loading, and use it
>   to implement things like auto-loaded buffer parsers and database
>   access in cases which need more than Lisp.
>
> Now I'm confused.

I guess an FFI is already there? Or was there because it looks kind of
dead:

  https://github.com/tromey/emacs-ffi

Tom Tromey says in one of the issues

  https://github.com/tromey/emacs-ffi/issues/20

that John Wigley asked him on IRC to submit it for inclusion. Can't find
anything on emacs-devel though.

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Nicolas Martyanoff <nicolas@n16f.net>,  arthur.miller@live.com,
>   emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 06:11:00 +0200
> 
> I guess an FFI is already there? Or was there because it looks kind of
> dead:
> 
>   https://github.com/tromey/emacs-ffi
> 
> Tom Tromey says in one of the issues
> 
>   https://github.com/tromey/emacs-ffi/issues/20
> 
> that John Wigley asked him on IRC to submit it for inclusion. Can't find
> anything on emacs-devel though.

It doesn't ensure GPL-compliance, AFAICT, so in its current form it
cannot be accepted, sorry.  And I'm not sure I understand how can one
technically enforce GPL compliance in FFI-style loading of arbitrary
shared libraries.  The only idea that comes to mind is allow-list of
known libraries, the way we do in sqlite.c, but I'm not sure that
method is scalable to the basically infinite world of arbitrary
libraries.

Re: as for Calc and the math library

[Suhail Singh]

Eli Zaretskii <eliz@gnu.org> writes:

>> I guess an FFI is already there? Or was there because it looks kind of
>> dead:
>> 
>>   https://github.com/tromey/emacs-ffi
>> 
>> Tom Tromey says in one of the issues
>> 
>>   https://github.com/tromey/emacs-ffi/issues/20
>> 
>> that John Wigley asked him on IRC to submit it for inclusion. Can't find
>> anything on emacs-devel though.
>
> It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> cannot be accepted, sorry. And I'm not sure I understand how can one
> technically enforce GPL compliance in FFI-style loading of arbitrary
> shared libraries.  The only idea that comes to mind is allow-list of
> known libraries, the way we do in sqlite.c, but I'm not sure that
> method is scalable to the basically infinite world of arbitrary
> libraries.

On the topic of what would be acceptable for an FFI, wouldn't something
akin to what's done for modules be sufficient ?  I.e., have the users of
the interface explicitly state that they are compliant.

It would scale better than an allow-list.  IIUC, Arthur mentioned this
in another thread.  If this wouldn't be sufficient for an FFI, could you
please elaborate on why that's the case ?

The question here isn't about what does or does not constitute GPL
compliance, but what Emacs, as a project, is trying to ensure when it
comes to such compliance.  In the case of modules, at least, a claim of
compliance is sufficient (without any additional verification).

-- 
Suhail

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   nicolas@n16f.net,
>   arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 10:00:18 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It doesn't ensure GPL-compliance, AFAICT, so in its current form it
> > cannot be accepted, sorry. And I'm not sure I understand how can one
> > technically enforce GPL compliance in FFI-style loading of arbitrary
> > shared libraries.  The only idea that comes to mind is allow-list of
> > known libraries, the way we do in sqlite.c, but I'm not sure that
> > method is scalable to the basically infinite world of arbitrary
> > libraries.
> 
> On the topic of what would be acceptable for an FFI, wouldn't something
> akin to what's done for modules be sufficient ?  I.e., have the users of
> the interface explicitly state that they are compliant.
> 
> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> in another thread.  If this wouldn't be sufficient for an FFI, could you
> please elaborate on why that's the case ?

What exactly are you suggesting?  IOW, please describe what you have
in mind in more detail, because I don't think I understand it.

> The question here isn't about what does or does not constitute GPL
> compliance, but what Emacs, as a project, is trying to ensure when it
> comes to such compliance.

It tries to ensure that Emacs is not used as front-end for non-free
software.

Re: as for Calc and the math library

[Suhail Singh]

Eli Zaretskii <eliz@gnu.org> writes:

>> On the topic of what would be acceptable for an FFI, wouldn't something
>> akin to what's done for modules be sufficient ?  I.e., have the users of
>> the interface explicitly state that they are compliant.
>> 
>> It would scale better than an allow-list.  IIUC, Arthur mentioned this
>> in another thread.  If this wouldn't be sufficient for an FFI, could you
>> please elaborate on why that's the case ?
>
> What exactly are you suggesting?  IOW, please describe what you have
> in mind in more detail, because I don't think I understand it.

Specifically, modify the `define-ffi-library' macro that emacs-ffi
provides.

Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
that it be updated to take three arguments: a SYMBOL, a NAME and a
GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
a reference to the library.

If the value of `t' would be insufficient for Emacs' standards for
encouraging GPL compliance (in case it's considered "not explicit
enough"), the third argument could instead be something like
GPL-COMPATIBILITY where the value of 'library-is-GPL-compatible would be
necessary to be able to create a reference to the library.

A further variant/extension of the above proposal is also possible.
This extension modifies both `define-ffi-library' as well as
`define-ffi-function'.  When `define-ffi-library' gets an acceptable
claim of GPL compatibility, it attaches a property (which acts as a
witness for observing the claim of GPL compatibility) to the library
symbol.  The presence of said property is then checked by
`define-ffi-function'.  If the property is missing,
`define-ffi-function' complains.

-- 
Suhail

Re: as for Calc and the math library

[Eli Zaretskii]

> From: Suhail Singh <suhailsingh247@gmail.com>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>  nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Wed, 14 Aug 2024 11:08:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> On the topic of what would be acceptable for an FFI, wouldn't something
> >> akin to what's done for modules be sufficient ?  I.e., have the users of
> >> the interface explicitly state that they are compliant.
> >> 
> >> It would scale better than an allow-list.  IIUC, Arthur mentioned this
> >> in another thread.  If this wouldn't be sufficient for an FFI, could you
> >> please elaborate on why that's the case ?
> >
> > What exactly are you suggesting?  IOW, please describe what you have
> > in mind in more detail, because I don't think I understand it.
> 
> Specifically, modify the `define-ffi-library' macro that emacs-ffi
> provides.
> 
> Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
> that it be updated to take three arguments: a SYMBOL, a NAME and a
> GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
> a reference to the library.

And if the value is not t, then the load will fail?  If so, then this
additional argument makes very little sense: you could instead say
that just by loading the library, the Lisp program which uses
emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
are back where we began.

The way we do it when loading modules requires the _loaded_ library to
declare itself compatible, by exporting a symbol of a certain name.
That is an action by the library we load, not by the Lisp program
which loads it.

Emacs ffi (was: Re: as for Calc and the math library)

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Suhail Singh <suhailsingh247@gmail.com>
>> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>>  nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> Date: Wed, 14 Aug 2024 11:08:02 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> On the topic of what would be acceptable for an FFI, wouldn't something
>> >> akin to what's done for modules be sufficient ?  I.e., have the users of
>> >> the interface explicitly state that they are compliant.
>> >> 
>> >> It would scale better than an allow-list.  IIUC, Arthur mentioned this
>> >> in another thread.  If this wouldn't be sufficient for an FFI, could you
>> >> please elaborate on why that's the case ?
>> >
>> > What exactly are you suggesting?  IOW, please describe what you have
>> > in mind in more detail, because I don't think I understand it.
>> 
>> Specifically, modify the `define-ffi-library' macro that emacs-ffi
>> provides.
>> 
>> Presently, it takes two arguments: a SYMBOL and a NAME.  I am proposing
>> that it be updated to take three arguments: a SYMBOL, a NAME and a
>> GPL-COMPATIBLE-P token.  A value of `t' would be necessary for creating
>> a reference to the library.
>
> And if the value is not t, then the load will fail?  If so, then this
> additional argument makes very little sense: you could instead say
> that just by loading the library, the Lisp program which uses
> emacs-ffi "declares" the loaded library to be GPL-compatible.  And we
> are back where we began.

Agree

> The way we do it when loading modules requires the _loaded_ library to
> declare itself compatible, by exporting a symbol of a certain name.
> That is an action by the library we load, not by the Lisp program
> which loads it.

But we could do the same for our hypothetical ffi machinery, that is:
`define-ffi-library' could fail if the shared library is not exporting
the predetermined symbol we expect no?

  Andrea

Re: Emacs ffi (was: Re: as for Calc and the math library)

[Eli Zaretskii]

> From: Andrea Corallo <acorallo@gnu.org>
> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> Date: Thu, 15 Aug 2024 05:31:49 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The way we do it when loading modules requires the _loaded_ library to
> > declare itself compatible, by exporting a symbol of a certain name.
> > That is an action by the library we load, not by the Lisp program
> > which loads it.
> 
> But we could do the same for our hypothetical ffi machinery, that is:
> `define-ffi-library' could fail if the shared library is not exporting
> the predetermined symbol we expect no?

Of course.  But how many such libraries do that?  You are in effect
talking about libraries specifically written or adapted for this
hypothetical FFI machinery that is Emacs- or at least GNU-specific.
Whereas the main motivation behind the request is to allow loading
arbitrary libraries out there that already exist and definitely don't
export any such symbols.  At the very least, the interested individual
will have to fork the library, verify it has a GPL-compatible license,
modify its code to export such a symbol, and then rebuild it.

So, while this arrangement is definitely possible and okay for Emacs,
I very much doubt that it will be practical enough to be of use.
Nevertheless, if someone submits such an implementation of such FFI
machinery, I see no obstacles to accepting it (except the usual: clean
code, good documentation, etc.).

Re: Emacs ffi

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <acorallo@gnu.org>
>> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The way we do it when loading modules requires the _loaded_ library to
>> > declare itself compatible, by exporting a symbol of a certain name.
>> > That is an action by the library we load, not by the Lisp program
>> > which loads it.
>> 
>> But we could do the same for our hypothetical ffi machinery, that is:
>> `define-ffi-library' could fail if the shared library is not exporting
>> the predetermined symbol we expect no?
>
> Of course.  But how many such libraries do that?

Dunno, ATM very few if not zero I guess.

> You are in effect
> talking about libraries specifically written or adapted for this
> hypothetical FFI machinery that is Emacs- or at least GNU-specific.
> Whereas the main motivation behind the request is to allow loading
> arbitrary libraries out there that already exist and definitely don't
> export any such symbols.  At the very least, the interested individual
> will have to fork the library, verify it has a GPL-compatible license,
> modify its code to export such a symbol, and then rebuild it.

Maybe over time libraries interested to e used by Emacs could accept the
simple patch necessary to define end export the symbol?

> So, while this arrangement is definitely possible and okay for Emacs,
> I very much doubt that it will be practical enough to be of use.
> Nevertheless, if someone submits such an implementation of such FFI
> machinery, I see no obstacles to accepting it (except the usual: clean
> code, good documentation, etc.).


Okay thanks, we are on the same page on this.


  Andrea

Re: Emacs ffi

[Andrea Corallo]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Friday, August 16, 2024 at 8:32 AM
>> From: "Andrea Corallo" <acorallo@gnu.org>
>> To: "Eli Zaretskii" <eliz@gnu.org>
>> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
>> Subject: Re: Emacs ffi
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>> >>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> >> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> > The way we do it when loading modules requires the _loaded_ library to
>> >> > declare itself compatible, by exporting a symbol of a certain name.
>> >> > That is an action by the library we load, not by the Lisp program
>> >> > which loads it.
>> >>
>> >> But we could do the same for our hypothetical ffi machinery, that is:
>> >> `define-ffi-library' could fail if the shared library is not exporting
>> >> the predetermined symbol we expect no?
>> >
>> > Of course.  But how many such libraries do that?
>>
>> Dunno, ATM very few if not zero I guess.
>
> If there are no existing libraries that export the required symbol, it
> raises legitimate concerns about the feasibility and utility of the
> approach. Essentially, if the mechanism put in place is not supported by
> any available libraries, then the mechanism is ineffective and overly
> idealistic.
>
> There exists a large disconnect between theoretical compliance and
> practical usability. If the requirements for compliance are so stringent
> or specific that no existing libraries can meet them, then it could be
> argued that the approach is not grounded in the reality of software
> development.

I disagree, this is normal evolution for software ex: every time a new
programming language is created (or a new feature is added to it)
compilers implement the related support, even if no programs are using
that language or that new extension at present.  Is this a large
disconnect between theoretical compliance and practical usability?  No,
is just that users will come later.

If Emacs requires the symbol maybe compatible libraries will just export
it afterwards (given the cost is close to zero).

  Andrea

Re: Emacs ffi

[Christopher Dimech]

> Sent: Saturday, August 17, 2024 at 8:07 AM
> From: "Andrea Corallo" <acorallo@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, "Eli Zaretskii" <eliz@gnu.org>
> Subject: Re: Emacs ffi
>
> Christopher Dimech <dimech@gmx.com> writes:
> 
> >> Sent: Friday, August 16, 2024 at 8:32 AM
> >> From: "Andrea Corallo" <acorallo@gnu.org>
> >> To: "Eli Zaretskii" <eliz@gnu.org>
> >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> >> Subject: Re: Emacs ffi
> >>
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> >> From: Andrea Corallo <acorallo@gnu.org>
> >> >> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
> >> >>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
> >> >> Date: Thu, 15 Aug 2024 05:31:49 -0400
> >> >>
> >> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >>
> >> >> > The way we do it when loading modules requires the _loaded_ library to
> >> >> > declare itself compatible, by exporting a symbol of a certain name.
> >> >> > That is an action by the library we load, not by the Lisp program
> >> >> > which loads it.
> >> >>
> >> >> But we could do the same for our hypothetical ffi machinery, that is:
> >> >> `define-ffi-library' could fail if the shared library is not exporting
> >> >> the predetermined symbol we expect no?
> >> >
> >> > Of course.  But how many such libraries do that?
> >>
> >> Dunno, ATM very few if not zero I guess.
> >
> > If there are no existing libraries that export the required symbol, it
> > raises legitimate concerns about the feasibility and utility of the
> > approach. Essentially, if the mechanism put in place is not supported by
> > any available libraries, then the mechanism is ineffective and overly
> > idealistic.
> >
> > There exists a large disconnect between theoretical compliance and
> > practical usability. If the requirements for compliance are so stringent
> > or specific that no existing libraries can meet them, then it could be
> > argued that the approach is not grounded in the reality of software
> > development.
> 
> I disagree, this is normal evolution for software ex: every time a new
> programming language is created (or a new feature is added to it)
> compilers implement the related support, even if no programs are using
> that language or that new extension at present.  Is this a large
> disconnect between theoretical compliance and practical usability?  No,
> is just that users will come later.
> 
> If Emacs requires the symbol maybe compatible libraries will just export
> it afterwards (given the cost is close to zero). - Andrea

It is imposing an additional requirement that isn't typically necessary 
in most other environments.

Typically, mathematical libraries are designed to be widely applicable
and used across various platforms and applications. Requiring these
libraries to export a specific symbol or be designed with editor
compatibility in mind is an unnecessary hurdle. Developers of libraries
do not prioritize compatibility with editors like Emacs.

To overcome the hurdle that Emacs is bringing upon itself, of requiring
GPL compliance for mathematical libraries, it should provide its own
built-in library as suggested by E. Berg. It is the pragmatic way to do
it.  I disagreed with Berg initially, but I can now understand his
frustrations with the whole emacs design.

Some free software simply cannot be used with GPL-licensed software like 
Emacs without violating the terms of one or both licenses.  Requiring GPL 
compliance for integration is banal.  Particularly when Emacs is not the 
one providing the library.  It will be the user who will be using.  One 
simply cannot accuse a user to breaking any license if the library is not
GPL compliant.  The landscape of free software licenses is diverse, with 
many different licenses with many not compatible with each other. You’d 
have to put every teenager in the world in jail, and you can’t do that ! 

But this message does not resonate within the minds of the core emacs maintainers, 
with the trend continuing for many years to come.  Some believe that everybody 
in the world doesn’t get it about free software, and even that everybody in the 
world is a crook and that everybody in the world is trying to steal free software 
and make bad use of it.  I do not approve of such ideas.  Many think they know
everything about copyright infringement, but never been thrown out of court on 
a motion to dismiss.  

It's always the same, you'll get prima donna maintainers who are at the same 
level of priests, who preach a lot about licensing scenarios.  But have never 
been there, never done it, but preaching a lot about what others can do and what 
they cannot do.  Too much coercion was surely not what we wanted to apply.

As customary I get "Your message was deemed inappropriate by the moderator."
from emacs-devel-owner@gnu.org.  I wonder who it is.  Actually I wonder why
I wonder.

We need to understand how that working together purposively brings us to the 
point where everyone is not afraid of free software anymore and we are not 
worried about their complying anymore.  We are just all engaging and leading 
the task of making free software.

Re: Emacs ffi

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net,
>  arthur.miller@live.com, emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 16 Aug 2024 23:21:48 +0200
> 
> 
> But this message does not resonate within the minds of the core emacs maintainers, 
> with the trend continuing for many years to come.  Some believe that everybody 
> in the world doesn’t get it about free software, and even that everybody in the 
> world is a crook and that everybody in the world is trying to steal free software 
> and make bad use of it.  I do not approve of such ideas.  Many think they know
> everything about copyright infringement, but never been thrown out of court on 
> a motion to dismiss.  
> 
> It's always the same, you'll get prima donna maintainers who are at the same 
> level of priests, who preach a lot about licensing scenarios.  But have never 
> been there, never done it, but preaching a lot about what others can do and what 
> they cannot do.  Too much coercion was surely not what we wanted to apply.

For the umpteenth time: the maintainers are not at liberty to change
the policies they promised to uphold when they were appointed.  If you
want to discuss these policies, please take this to the proper place.

> As customary I get "Your message was deemed inappropriate by the moderator."
> from emacs-devel-owner@gnu.org.  I wonder who it is.  Actually I wonder why
> I wonder.

You were asked, several times, to take this subject off this list.
What did you expect to happen when you keep ignoring those requests,
time and again?

Re: Emacs ffi

[Christopher Dimech]

> Sent: Saturday, August 17, 2024 at 6:06 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: acorallo@gnu.org, suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> Subject: Re: Emacs ffi
>
> > From: Christopher Dimech <dimech@gmx.com>
> > Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net,
> >  arthur.miller@live.com, emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> > Date: Fri, 16 Aug 2024 23:21:48 +0200
> > 
> > 
> > But this message does not resonate within the minds of the core emacs maintainers, 
> > with the trend continuing for many years to come.  Some believe that everybody 
> > in the world doesn’t get it about free software, and even that everybody in the 
> > world is a crook and that everybody in the world is trying to steal free software 
> > and make bad use of it.  I do not approve of such ideas.  Many think they know
> > everything about copyright infringement, but never been thrown out of court on 
> > a motion to dismiss.  
> > 
> > It's always the same, you'll get prima donna maintainers who are at the same 
> > level of priests, who preach a lot about licensing scenarios.  But have never 
> > been there, never done it, but preaching a lot about what others can do and what 
> > they cannot do.  Too much coercion was surely not what we wanted to apply.
> 
> For the umpteenth time: the maintainers are not at liberty to change
> the policies they promised to uphold when they were appointed.  If you
> want to discuss these policies, please take this to the proper place.
> 
> > As customary I get "Your message was deemed inappropriate by the moderator."
> > from emacs-devel-owner@gnu.org.  I wonder who it is.  Actually I wonder why
> > I wonder.
> 
> You were asked, several times, to take this subject off this list.
> What did you expect to happen when you keep ignoring those requests,
> time and again?
 
I have no illusions about the outcome. Decisions will be made regardless, 
but it's important to present the contrarian perspective. While I typically 
refrain from commenting, I do speak on the rare occasions when licensing 
is at issue.  It's about enhancing functionality, not complicating it with 
licensing hurdles that don't really apply.  

Incorporating a mathematical library into Emacs, based on Calc, is not
just feasible but highly beneficial.  Without all the perceived worries
you described.  You do a great job on the technical aspects, but when
you step outside your field and level of specialty, sometimes it is like
stepping off a cliff.

Emacs is a great idea.  In order to make it appeal to a younger generation 
of people who write programs for sharing, we need to make it simpler to use, 
quicker to understand, and better at doing all the jobs it’s supposed to do. 
And we need to refrain from going unnecessarily to war.

Re: Emacs ffi

[Eli Zaretskii]

> From: Christopher Dimech <dimech@gmx.com>
> Cc: acorallo@gnu.org, suhailsingh247@gmail.com, gerd.moellmann@gmail.com,
>  nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> Date: Sat, 17 Aug 2024 11:05:43 +0200
> 
> > > As customary I get "Your message was deemed inappropriate by the moderator."
> > > from emacs-devel-owner@gnu.org.  I wonder who it is.  Actually I wonder why
> > > I wonder.
> > 
> > You were asked, several times, to take this subject off this list.
> > What did you expect to happen when you keep ignoring those requests,
> > time and again?
>  
> I have no illusions about the outcome. Decisions will be made regardless, 
> but it's important to present the contrarian perspective. While I typically 
> refrain from commenting, I do speak on the rare occasions when licensing 
> is at issue.  It's about enhancing functionality, not complicating it with 
> licensing hurdles that don't really apply.  

You are welcome to comment on this, just not here.  Discussing the
policies of the GNU Project is off-topic on this list.  So please
stop.

Re: Emacs ffi

[Stefan Kangas]

Christopher Dimech <dimech@gmx.com> writes:

> Incorporating a mathematical library into Emacs, based on Calc, is not
> just feasible but highly beneficial.

I think we all agree that a general purpose mathematical library would
be interesting.  The point is that the specifics of how it is
implemented matters.  If you think basing it on Calc is the best way
forward, then I invite you to get started.  I mean this sincerely.

Unfortunately, this discussion currently seems to be going in circles.
Since nothing helps ground a discussion more than working code, I
propose that we revisit this topic when we have something more concrete
to consider.

Re: Emacs ffi

[Joel Reicher]

Stefan Kangas <stefankangas@gmail.com> writes:

> Christopher Dimech <dimech@gmx.com> writes:
>
>> Incorporating a mathematical library into Emacs, based on Calc, 
>> is not just feasible but highly beneficial.
>
> I think we all agree that a general purpose mathematical library 
> would be interesting.  The point is that the specifics of how it 
> is implemented matters.

"Interesting" is different to "useful", and I think this is why 
the implementation is unclear, because the requirements of a 
library can only be made clear by a multiplicity of consumers.

What packages, other than Calc, would make use of such a library? 
(That's not rhetorical; I don't pretend to have an overview of all 
such packages.)

> If you think basing it on Calc is the best way forward, then I 
> invite you to get started.

It needs to be based on potential consumers. If Calc is the only 
consumer, then a library does not make sense yet. 

But that's not to say an FFI wouldn't improve Calc's 
implementation. If that's the issue, then it's a discussion that 
differs from one about library.

Regards,

        - Joel

Re: Emacs ffi

[Christopher Dimech]

> Sent: Sunday, August 18, 2024 at 2:30 AM
> From: "Joel Reicher" <joel.reicher@gmail.com>
> To: "Stefan Kangas" <stefankangas@gmail.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "Eli Zaretskii" <eliz@gnu.org>, acorallo@gnu.org, suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> Subject: Re: Emacs ffi
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
> > Christopher Dimech <dimech@gmx.com> writes:
> >
> >> Incorporating a mathematical library into Emacs, based on Calc,
> >> is not just feasible but highly beneficial.
> >
> > I think we all agree that a general purpose mathematical library
> > would be interesting.  The point is that the specifics of how it
> > is implemented matters.
>
> "Interesting" is different to "useful", and I think this is why
> the implementation is unclear, because the requirements of a
> library can only be made clear by a multiplicity of consumers.
>
> What packages, other than Calc, would make use of such a library?
> (That's not rhetorical; I don't pretend to have an overview of all
> such packages.)
>
> > If you think basing it on Calc is the best way forward, then I
> > invite you to get started.
>
> It needs to be based on potential consumers. If Calc is the only
> consumer, then a library does not make sense yet.

Agreed.  I cannot see an Emacs package that would make extensive use
of the library.

> But that's not to say an FFI wouldn't improve Calc's
> implementation. If that's the issue, then it's a discussion that
> differs from one about library. - Joel

Calc is not bad, and outside libraries would not improve it much.
The mathematical tools of calc could be redesigned as an emacs
built-in library that Calc would then use.  Calc would then become
just a normal package.  Direct work on Calc has stopped.

My comments were directed at not enforcing licensing checks on external
libraries, but rather to maintain only our own internal licensing compliance
and provide guidance to users.  Users should make their own decisions about
integrating libraries.  Individuals who primarily write code have no serious
experience on licensing matters and legal implications.

Licensing issues require specialized knowledge beyond coding skills, including
an understanding of legal frameworks, compliance requirements, and the nuances
of different software licenses. Therefore, it's crucial to involve those with
a solid background in licensing to ensure proper handling and adherence to legal
standards.

Re: Emacs ffi

[Emanuel Berg]

Joel Reicher wrote:

> What packages, other than Calc, would make use of such
> a library? (That's not rhetorical; I don't pretend to have
> an overview of all such packages.)

All packages that do math, science, stats, scientific
computing, and so on; and all users who do any of that with
and from Emacs.

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs ffi

[Christopher Dimech]

> Sent: Sunday, August 18, 2024 at 1:21 AM
> From: "Stefan Kangas" <stefankangas@gmail.com>
> To: "Christopher Dimech" <dimech@gmx.com>, "Eli Zaretskii" <eliz@gnu.org>
> Cc: acorallo@gnu.org, suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
> Subject: Re: Emacs ffi
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> > Incorporating a mathematical library into Emacs, based on Calc, is not
> > just feasible but highly beneficial.
>
> I think we all agree that a general purpose mathematical library would
> be interesting.  The point is that the specifics of how it is
> implemented matters.  If you think basing it on Calc is the best way
> forward, then I invite you to get started.  I mean this sincerely.

Others thought that basing it on Calc is a good way forward.  It does
make for a good library having looked into its mathematical capabilities.

E. Berg's initial inclination to create a mathematical library for Emacs
was a commendable idea to expand the capabilities within the editor.
However, he did not want to delve into Calc, but on his own
implementations.

The disappointment to some was grounded in a strong argument from the
core Emacs developers, who emphasized the importance of having a robust,
well-integrated library that could match or exceed the functionality of
the existing Calc package.  The high bar set for quality and integration
within the Emacs ecosystem means that such a project would be a major
undertaking, likely contributing to the reluctance to pursue it.

> Unfortunately, this discussion currently seems to be going in circles.
> Since nothing helps ground a discussion more than working code, I
> propose that we revisit this topic when we have something more concrete
> to consider.

It is for the core emacs groups leading the development to establish the
principal design that is user-friendly and flexible to allow for easy
extension, without imposing overly stringent requirements beyond what is
typically expected for standard Emacs packages. My role is not to
overstep but to provide occasional input.

At this moment, it's unclear whether the decision will lean toward
implementing an FFI (Foreign Function Interface) or pursuing a different
approach. However, having Emacs provide a built-in solution seems more
conducive to seamless integration, allowing for a more cohesive
experience.

I could contribute concrete mathematical operations and assist in
refining the library as it evolves. While it doesn't need to be a
comprehensive solution, it should be robust enough to meet current needs
and provide a foundation for further development as required in a
collaborative approach.  Ultimately, I adhere to established design,
working within the framework set by the core Emacs team to create a
valuable tool.

Re: Emacs ffi

[Emanuel Berg]

Stefan Kangas wrote:

> Unfortunately, this discussion currently seems to be going
> in circles. Since nothing helps ground a discussion more
> than working code, I propose that we revisit this topic when
> we have something more concrete to consider.

Well, what is it that the code should do?

Provide a simpler interface to Calc?

What kind of interface?

-- 
underground experts united
https://dataswamp.org/~incal

Re: Emacs ffi

[Andrea Corallo]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Saturday, August 17, 2024 at 8:07 AM
>> From: "Andrea Corallo" <acorallo@gnu.org>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, "Eli Zaretskii" <eliz@gnu.org>
>> Subject: Re: Emacs ffi
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>> 
>> >> Sent: Friday, August 16, 2024 at 8:32 AM
>> >> From: "Andrea Corallo" <acorallo@gnu.org>
>> >> To: "Eli Zaretskii" <eliz@gnu.org>
>> >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
>> >> Subject: Re: Emacs ffi
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> >> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>> >> >>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> >> >> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> >> >>
>> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >>
>> >> >> > The way we do it when loading modules requires the _loaded_ library to
>> >> >> > declare itself compatible, by exporting a symbol of a certain name.
>> >> >> > That is an action by the library we load, not by the Lisp program
>> >> >> > which loads it.
>> >> >>
>> >> >> But we could do the same for our hypothetical ffi machinery, that is:
>> >> >> `define-ffi-library' could fail if the shared library is not exporting
>> >> >> the predetermined symbol we expect no?
>> >> >
>> >> > Of course.  But how many such libraries do that?
>> >>
>> >> Dunno, ATM very few if not zero I guess.
>> >
>> > If there are no existing libraries that export the required symbol, it
>> > raises legitimate concerns about the feasibility and utility of the
>> > approach. Essentially, if the mechanism put in place is not supported by
>> > any available libraries, then the mechanism is ineffective and overly
>> > idealistic.
>> >
>> > There exists a large disconnect between theoretical compliance and
>> > practical usability. If the requirements for compliance are so stringent
>> > or specific that no existing libraries can meet them, then it could be
>> > argued that the approach is not grounded in the reality of software
>> > development.
>> 
>> I disagree, this is normal evolution for software ex: every time a new
>> programming language is created (or a new feature is added to it)
>> compilers implement the related support, even if no programs are using
>> that language or that new extension at present.  Is this a large
>> disconnect between theoretical compliance and practical usability?  No,
>> is just that users will come later.
>> 
>> If Emacs requires the symbol maybe compatible libraries will just export
>> it afterwards (given the cost is close to zero). - Andrea
>
> It is imposing an additional requirement that isn't typically necessary 
> in most other environments.
>
> Typically, mathematical libraries are designed to be widely applicable
> and used across various platforms and applications. Requiring these
> libraries to export a specific symbol or be designed with editor
> compatibility in mind is an unnecessary hurdle. Developers of libraries
> do not prioritize compatibility with editors like Emacs.
>
> To overcome the hurdle that Emacs is bringing upon itself, of requiring
> GPL compliance for mathematical libraries, it should provide its own
> built-in library as suggested by E. Berg. It is the pragmatic way to do
> it.  I disagreed with Berg initially, but I can now understand his
> frustrations with the whole emacs design.
>
> Some free software simply cannot be used with GPL-licensed software like 
> Emacs without violating the terms of one or both licenses.  Requiring GPL 
> compliance for integration is banal.  Particularly when Emacs is not the 
> one providing the library.  It will be the user who will be using.  One 
> simply cannot accuse a user to breaking any license if the library is not
> GPL compliant.  The landscape of free software licenses is diverse, with 
> many different licenses with many not compatible with each other. You’d 
> have to put every teenager in the world in jail, and you can’t do that ! 
>
> But this message does not resonate within the minds of the core emacs maintainers, 
> with the trend continuing for many years to come.  Some believe that everybody 
> in the world doesn’t get it about free software, and even that everybody in the 
> world is a crook and that everybody in the world is trying to steal free software 
> and make bad use of it.  I do not approve of such ideas.  Many think they know
> everything about copyright infringement, but never been thrown out of court on 
> a motion to dismiss.  
>
> It's always the same, you'll get prima donna maintainers who are at the same 
> level of priests, who preach a lot about licensing scenarios.  But have never 
> been there, never done it, but preaching a lot about what others can do and what 
> they cannot do.  Too much coercion was surely not what we wanted to apply.

Looking at your Emacs contribution track I guess we have "been there"
and "did it" more than you, so I'm sorry but I don't understand where
*your* preaching is coming from.

This is my last (of very few) replies to you on this subject 👋

Re: Emacs ffi

[Björn Bidar]

Christopher Dimech <dimech@gmx.com> writes:

>> Sent: Saturday, August 17, 2024 at 8:07 AM
>> From: "Andrea Corallo" <acorallo@gnu.org>
>> To: "Christopher Dimech" <dimech@gmx.com>
>> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org, "Eli Zaretskii" <eliz@gnu.org>
>> Subject: Re: Emacs ffi
>>
>> Christopher Dimech <dimech@gmx.com> writes:
>> 
>> >> Sent: Friday, August 16, 2024 at 8:32 AM
>> >> From: "Andrea Corallo" <acorallo@gnu.org>
>> >> To: "Eli Zaretskii" <eliz@gnu.org>
>> >> Cc: suhailsingh247@gmail.com, gerd.moellmann@gmail.com, nicolas@n16f.net, arthur.miller@live.com, emacs-devel@gnu.org
>> >> Subject: Re: Emacs ffi
>> >>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >> From: Andrea Corallo <acorallo@gnu.org>
>> >> >> Cc: Suhail Singh <suhailsingh247@gmail.com>,  gerd.moellmann@gmail.com,
>> >> >>   nicolas@n16f.net,  arthur.miller@live.com,  emacs-devel@gnu.org
>> >> >> Date: Thu, 15 Aug 2024 05:31:49 -0400
>> >> >>
>> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >>
>> >> >> > The way we do it when loading modules requires the _loaded_ library to
>> >> >> > declare itself compatible, by exporting a symbol of a certain name.
>> >> >> > That is an action by the library we load, not by the Lisp program
>> >> >> > which loads it.
>> >> >>
>> >> >> But we could do the same for our hypothetical ffi machinery, that is:
>> >> >> `define-ffi-library' could fail if the shared library is not exporting
>> >> >> the predetermined symbol we expect no?
>> >> >
>> >> > Of course.  But how many such libraries do that?
>> >>
>> >> Dunno, ATM very few if not zero I guess.
>> >
>> > If there are no existing libraries that export the required symbol, it
>> > raises legitimate concerns about the feasibility and utility of the
>> > approach. Essentially, if the mechanism put in place is not supported by
>> > any available libraries, then the mechanism is ineffective and overly
>> > idealistic.
>> >
>> > There exists a large disconnect between theoretical compliance and
>> > practical usability. If the requirements for compliance are so stringent
>> > or specific that no existing libraries can meet them, then it could be
>> > argued that the approach is not grounded in the reality of software
>> > development.
>> 
>> I disagree, this is normal evolution for software ex: every time a new
>> programming language is created (or a new feature is added to it)
>> compilers implement the related support, even if no programs are using
>> that language or that new extension at present.  Is this a large
>> disconnect between theoretical compliance and practical usability?  No,
>> is just that users will come later.
>> 
>> If Emacs requires the symbol maybe compatible libraries will just export
>> it afterwards (given the cost is close to zero). - Andrea
>
> It is imposing an additional requirement that isn't typically necessary 
> in most other environments.
>
> Typically, mathematical libraries are designed to be widely applicable
> and used across various platforms and applications. Requiring these
> libraries to export a specific symbol or be designed with editor
> compatibility in mind is an unnecessary hurdle. Developers of libraries
> do not prioritize compatibility with editors like Emacs.

> To overcome the hurdle that Emacs is bringing upon itself, of requiring
> GPL compliance for mathematical libraries, it should provide its own
> built-in library as suggested by E. Berg. It is the pragmatic way to do
> it.  I disagreed with Berg initially, but I can now understand his
> frustrations with the whole emacs design.

> Some free software simply cannot be used with GPL-licensed software like 
> Emacs without violating the terms of one or both licenses.  Requiring GPL 
> compliance for integration is banal.  Particularly when Emacs is not the 
> one providing the library.  It will be the user who will be using.  One 
> simply cannot accuse a user to breaking any license if the library is not
> GPL compliant.  The landscape of free software licenses is diverse, with 
> many different licenses with many not compatible with each other. You’d 
> have to put every teenager in the world in jail, and you can’t do that ! 


I think GPL compliance could be checked but I agree we can't require
external libraries where Emacs is the minority to impose such
requirements. Well technically we can but who will honor them? Does the
FFI interface have a system for such things?
I think a warning or a "do you really want this" would be the least
intrusive way.
Similarly to spoiler warnings in media when there's graphic depections
of violence: Do you really want to enable this, the libraries could
restrict your freedom or similar. 

I think the XEmacs implementation of FFI would be a good start to look
how such an interface could be added.


> But this message does not resonate within the minds of the core emacs maintainers, 
> with the trend continuing for many years to come.  Some believe that everybody 
> in the world doesn’t get it about free software, and even that everybody in the 
> world is a crook and that everybody in the world is trying to steal free software 
> and make bad use of it.  I do not approve of such ideas.  Many think they know
> everything about copyright infringement, but never been thrown out of court on 
> a motion to dismiss.  

I don't really want to go into the politics besides that I have seen
worse on this list from user or maintainer such as to tell user to not
use gender neutral pronouns if they so chose to do so.

> It's always the same, you'll get prima donna maintainers who are at the same 
> level of priests, who preach a lot about licensing scenarios.  But have never 
> been there, never done it, but preaching a lot about what others can do and what 
> they cannot do.  Too much coercion was surely not what we wanted to apply.
>
> As customary I get "Your message was deemed inappropriate by the moderator."
> from emacs-devel-owner@gnu.org.  I wonder who it is.  Actually I wonder why
> I wonder.
>
> We need to understand how that working together purposively brings us to the 
> point where everyone is not afraid of free software anymore and we are not 
> worried about their complying anymore.  We are just all engaging and leading 
> the task of making free software.

I had this experience in the past too where some judge first and then
read. I.e. the recent discussion about OAuth2 where there was a
compliant that we shouldn't implement support for non-free platforms
even thou that wasn't really the point.

Sometimes it would be better if the more experienced contributors would
try to be more welcoming or helping when it comes to new contributors.

Re: Emacs ffi

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think GPL compliance could be checked but I agree we can't require
  > external libraries where Emacs is the minority to impose such
  > requirements. Well technically we can but who will honor them? Does the
  > FFI interface have a system for such things?

Instead of thinking of this question as an abstract one, it will be
more productive to look at exanples.  I think we will find that most
things people might want in the area of mathematical libraries are
available as GPL-compatible free software, and that most of the rest
come with an operating system's major components and would qualify for
the "system library" exception.

So maybe in practice the problematical case only rarely occurs.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Emacs ffi

[Christopher Dimech]

> Sent: Tuesday, August 20, 2024 at 4:57 AM
> From: "Richard Stallman" <rms@gnu.org>
> To: "Björn Bidar" <bjorn.bidar@thaodan.de>
> Cc: emacs-devel@gnu.org, eliz@gnu.org
> Subject: Re: Emacs ffi
>
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > I think GPL compliance could be checked but I agree we can't require
>   > external libraries where Emacs is the minority to impose such
>   > requirements. Well technically we can but who will honor them? Does the
>   > FFI interface have a system for such things?
> 
> Instead of thinking of this question as an abstract one, it will be
> more productive to look at exanples.  I think we will find that most
> things people might want in the area of mathematical libraries are
> available as GPL-compatible free software, and that most of the rest
> come with an operating system's major components and would qualify for
> the "system library" exception.
> 
> So maybe in practice the problematical case only rarely occurs.

Why are we moving away from the built-in mathematical implementations in 
Emacs' Calc package ?  Calc is a powerful tool and deeply integrated within 
Emacs, offering a wide range of mathematical functionalities that cater to 
many common and advanced needs.  It supports arithmetic, algebra, calculus, 
and even symbolic mathematics, making it very versatile.  

Is its interface daunting for users ?  Would we need dedicated people to focus
on it again ? 

Still, the discussion has been shifting towards a General FFI Interface, beyond
mathematical libraries.

Re: Emacs ffi

[Emanuel Berg]

Emacs is not the only free software out there, how does
everyone else do this?

In Debian we opt-in with non-free in /etc/apt/sources.list
e.g. with a line like this:

  deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware

Using this command, you can see that they give the user access
to software repositories of a size that is mindboggling.

Do they have another policy than Emacs?

Also, are there no free or FOSS libraries we can start with,
and possibly upgrade later if the others really are superior?

IME when people say the proprietary version is much better,
like for CAD and such specific applications, where the
free/FOSS world is supposedly behind - I dont know who can
tell, but what we have is good enough.

Is the situation not the same for libraries?

Here is the shell command. Yes

$ apt-cache pkgnames | wc -l
64 986

- that is amazing digit to behold.

-- 
underground experts united
https://dataswamp.org/~incal