dear fellow MKCL hackers,
so, i became interested in playing with mkcl, and looking into porting it to android.
i suggest to set up a wiki where we can write up a highlevel roadmap, collect the issues, etc... IOW where we can keep a document that can coordinate the effort.
how about the github wiki?
https://github.com/jcbeaudoin/MKCL
FTR, i've heard that maxima got ported to android using ECL, so there should be some good resources around there:
http://maxima.sourceforge.net/
On Sun, Apr 27, 2014 at 4:43 AM, Attila Lendvai attila.lendvai@gmail.comwrote:
dear fellow MKCL hackers,
so, i became interested in playing with mkcl, and looking into porting it to android.
Great. But I think that I need to clarify this point first. The license of MKCL is GNU LGPL v3 as stated in the Copyright file of the MKCL source code base directory. There are a few exceptions to that in the MKCL source code but they are for historical reasons and every new piece of work is expected to be included under LGPL v3 terms. Therefore, you will have to acknowledge your understanding of and agreement with this condition in some formal way. (I think an email or a note with a pull request with a mention of it should be enough).
Managing contributions through Github is an excellent idea. I hope you will turn it into a frequent habit. ;-)
i suggest to set up a wiki where we can write up a highlevel roadmap, collect the issues, etc... IOW where we can keep a document that can coordinate the effort.
how about the github wiki?
Done. There is now a wiki page https://github.com/jcbeaudoin/MKCL/wiki/Port-to-Android for you to use. Please try to edit it a bit just to make sure there is no permission issues.
FTR, i've heard that maxima got ported to android using ECL, so there should be some good resources around there:
And that points to the github repository the ECL port of Ageneau.
Great. But I think that I need to clarify this point first. The license of MKCL is GNU LGPL v3 as stated in the Copyright file of the MKCL source code base directory. There are a few exceptions to that in the MKCL source code but they are for historical reasons and every new piece of work is expected to be included under LGPL v3 terms. Therefore, you will have to acknowledge your understanding of and agreement with this condition in some formal way. (I think an email or a note with a pull request with a mention of it should be enough).
i personally reject the whole notion of IP as merely a confused justification for the use of violence against peaceful people... but i can do the necessary steps:
hereby i acknowledge that any contribution i will provide to the MKCL project will fall under MKCL's LGPL v3 licence.
Done. There is now a wiki page https://github.com/jcbeaudoin/MKCL/wiki/Port-to-Android for you to use. Please try to edit it a bit just to make sure there is no permission issues.
i've edited it, it works. thanks!
Last, the FFI is the biggest problem. It involves writing code in assembler with a careful study of the Linux ARM ABI used by Android.
how about libffi? can that solve the problem?
On Tue, Apr 29, 2014 at 5:16 AM, Attila Lendvai attila.lendvai@gmail.comwrote:
Great. But I think that I need to clarify this point first. The license
of
MKCL is GNU LGPL v3 as stated in the Copyright file of the MKCL source
code
base directory. There are a few exceptions to that in the MKCL source
code
but they are for historical reasons and every new piece of work is
expected
to be included under LGPL v3 terms. Therefore, you will have to
acknowledge
your understanding of and agreement with this condition in some formal
way.
(I think an email or a note with a pull request with a mention of it
should
be enough).
i personally reject the whole notion of IP as merely a confused justification for the use of violence against peaceful people... but i can do the necessary steps:
hereby i acknowledge that any contribution i will provide to the MKCL project will fall under MKCL's LGPL v3 licence.
Properly recorded, thanks! Sorry for that, I don't make the laws, I merely live under their rule...
Done. There is now a wiki page https://github.com/jcbeaudoin/MKCL/wiki/Port-to-Android for you to use. Please try to edit it a bit just to make sure there is no permission
issues.
i've edited it, it works. thanks!
Good.
Last, the FFI is the biggest problem. It involves writing code in assembler with a careful study of the Linux ARM ABI used by Android.
how about libffi? can that solve the problem?
I have looked at it more than once along the years and I don't like the bloat it has come to be. So it is not much to my taste. And I expect it will be a major PITA when time comes to push the performance of the FFI as much as I want to do it. Also, I am currently reworking the FFI entirely anyway. I am not against learning from it though.
-- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The first panacea for a mismanaged nation is inflation of the currency; the second is war. Both bring a temporary prosperity; both bring a permanent ruin. But both are the refuge of political and economic opportunists.” ― Ernest Hemingway (1899–1961), 'Notes on the Next War' (1935)
On Tue, Apr 29, 2014 at 5:33 AM, Jean-Claude Beaudoin < jean.claude.beaudoin@gmail.com> wrote:
I have looked at it more than once along the years and I don't like the bloat it has come to be. So it is not much to my taste. And I expect it will be a major PITA when time comes to push the performance of the FFI as much as I want to do it. Also, I am currently reworking the FFI entirely anyway. I am not against learning from it though.
I forgot to mention two things. First, the FFI is needed in anything more than a stub form only if one intends to specifically use its very services. It used to be an optional part in ancient times under the name of "dynamic FFI" and MKCL can be still be a pretty useful piece without it. It just cannot then call foreign code from the bytecode interpreter, which is not much of a real drag in most situations.
Second, I am expecting the ARM to be the last architecture with assembler support in MKCL. I am of the opinion that nothing of interest will come up in that department for decades to come, but that is just my opinion. Although that opinion is not out of a lack of knowledge in that area since I have done significant coding in about 10 different assemblers along the years. And I am ready to bet pretty heavily on my position here.
-
Attila Lendvai -
Jean-Claude Beaudoin