Hi,
I've been away from ABCL for some time, so I ask your indulgence in case I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo") "value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting environment variables, but there are known ways to jimmy it into doing so: https://stackoverflow.com/questions/318239/how-do-i-set-environment-variable...
Would a PR to add such a hack to ABCL be welcome, or should I just make it a local mod? Or is there another, recommended way of doing this?
-- Scott
Here's what I did: https://github.com/alanruttenberg/lsw2/blob/owlapiv4/util/setenv.lisp
You still can't set environment variables in the parent process, of course.
Alan
On Sat, Apr 29, 2023 at 2:25 AM Scott L. Burson Scott@sympoiesis.com wrote:
Hi,
I've been away from ABCL for some time, so I ask your indulgence in case I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo") "value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting environment variables, but there are known ways to jimmy it into doing so: https://stackoverflow.com/questions/318239/how-do-i-set-environment-variable...
Would a PR to add such a hack to ABCL be welcome, or should I just make it a local mod? Or is there another, recommended way of doing this?
-- Scott
Thanks!
On Sat, Apr 29, 2023 at 3:39 PM Alan Ruttenberg alanruttenberg@gmail.com wrote:
Here's what I did: https://github.com/alanruttenberg/lsw2/blob/owlapiv4/util/setenv.lisp
You still can't set environment variables in the parent process, of course.
Alan
On Sat, Apr 29, 2023 at 2:25 AM Scott L. Burson Scott@sympoiesis.com wrote:
Hi,
I've been away from ABCL for some time, so I ask your indulgence in case I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo") "value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting environment variables, but there are known ways to jimmy it into doing so: https://stackoverflow.com/questions/318239/how-do-i-set-environment-variable...
Would a PR to add such a hack to ABCL be welcome, or should I just make it a local mod? Or is there another, recommended way of doing this?
-- Scott
On Apr 30, 2023, at 00:38, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Here's what I did: https://github.com/alanruttenberg/lsw2/blob/owlapiv4/util/setenv.lisp
You still can't set environment variables in the parent process, of course.
Alan
On Sat, Apr 29, 2023 at 2:25 AM Scott L. Burson Scott@sympoiesis.com wrote: Hi,
I've been away from ABCL for some time, so I ask your indulgence in case I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo") "value") and got
Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV)
On investigation, I see that the JVM doesn't normally support setting environment variables, but there are known ways to jimmy it into doing so: https://stackoverflow.com/questions/318239/how-do-i-set-environment-variable...
Would a PR to add such a hack to ABCL be welcome, or should I just make it a local mod? Or is there another, recommended way of doing this?
A patch for ABCL to add this would be appreciated, but the implementation should somehow be changed to the “standard” load for JNA by the ABCL-ASDF contrib, namely something like
(require :abcl-contrib) (asdf:make :jna)
As I understand it, Alan’s implementation only works if ABCL-ASDF:RESOLVE is present, meaning it cannot be put “as is” in the base ABCL system. I believe this is possible because the OWL2 application uses the ABCL-AIO build of ABCL which merges abcl.jar which abcl-contrib.jar, but I could be wrong. Conceptually, we should somehow place the implementation of setting environment variables via the C syscall as a patch in the contrib system in a new contrib called (?) USE-POSIX-SYSCALLS (terrible name, please change). Such a new contrib would a) depend on JNA and b) have to be used via
(asdf:make :use-posix-syscalls)
On Tue, May 2, 2023 at 2:37 AM Mark Evenson evenson@panix.com wrote:
A patch for ABCL to add this would be appreciated, but the implementation should somehow be changed to the “standard” load for JNA by the ABCL-ASDF contrib, namely something like
(require :abcl-contrib) (asdf:make :jna)
As I understand it, Alan’s implementation only works if ABCL-ASDF:RESOLVE is present, meaning it cannot be put “as is” in the base ABCL system. I believe this is possible because the OWL2 application uses the ABCL-AIO build of ABCL which merges abcl.jar which abcl-contrib.jar, but I could be wrong.
It's true that I use aio. TBH I've never understood the point of separating the contribs from the base. File size isn't an issue any more. What's the upside of splitting them apart? A bit of extra time indexing the classes in the jar?
Conceptually, we should somehow place the implementation of setting
environment variables via the C syscall as a patch in the contrib system in a new contrib called (?) USE-POSIX-SYSCALLS (terrible name, please change). Such a new contrib would a) depend on JNA and b) have to be used via
(asdf:make :use-posix-syscalls)
I don't know what asdf:make does. I tried it in a situation (autoloading the java parser when #1 was used the first time) where I expected it to load a system and it didn't seem to.
Would it be sufficient to do something like:
(defun ensure-jna-loaded () (or *jna-loaded* (progn (when (not (ignore-errors (find-java-class 'jna.nativelibrary))) (require 'abcl-asdf) (add-to-classpath (funcall (intern "RESOLVE" 'abcl-asdf "net.java.dev.jna/jna/LATEST"))) (setq *jna-loaded* t)))))
This is assuming that abcl-contrib is available. Since I've never used contrib separately, I'm not sure what the standard pattern is for using something in contrib if it's not on the classpath. Mind you find-java-class is also part of jss, which is a contrib, which I always load...
Bottom line is that I don't know how to package this under whatever the assumptions are when not using abcl-aio
Alan
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
On May 2, 2023, at 21:16, Alan Ruttenberg alanruttenberg@gmail.com wrote:
[…]
It's true that I use aio. TBH I've never understood the point of separating the contribs from the base. File size isn't an issue any more. What's the upside of splitting them apart? A bit of extra time indexing the classes in the jar?
From https://github.com/armedbear/abcl/blob/master/doc/packaging-abcl.org:
We create two separate jar artifacts in order to: • To place an upper bound of size of abcl.jar regardless of what we package in abcl-contrib.jar. • Clearly mark which parts of the code-base are covered under GPLv2+classpath from those that may have other licensing terms. By making the loading of “contrib” a dynamic operation, we defer possible infringement to the User who redistributes the resulting jar artifact.
Conceptually, we should somehow place the implementation of setting environment variables via the C syscall as a patch in the contrib system in a new contrib called (?) USE-POSIX-SYSCALLS (terrible name, please change). Such a new contrib would a) depend on JNA and b) have to be used via
(asdf:make :use-posix-syscalls)
I don't know what asdf:make does. I tried it in a situation (autoloading the java parser when #1 was used the first time) where I expected it to load a system and it didn't seem to.
ASDF:MAKE is a shorter synonym for ASDF:LOAD-SYSTEM as far as I understand things.
Would it be sufficient to do something like:
(defun ensure-jna-loaded () (or *jna-loaded* (progn (when (not (ignore-errors (find-java-class 'jna.nativelibrary))) (require 'abcl-asdf) (add-to-classpath (funcall (intern "RESOLVE" 'abcl-asdf "net.java.dev.jna/jna/LATEST"))) (setq *jna-loaded* t)))))
Probably not: you really want to depend on the ASDF encapsulation of JNA in 'contrib/mvn/jna.asd’, not the presence of yet another special (“*jna-loaded*”). Since you are requiring ABCL-ASDF:RESOLVE to be present, you can make the assumption that both ASDF and ABCL-CONTRIB have been successfully REQUIREd.
[…]
Bottom line is that I don't know how to package this under whatever the assumptions are when not using abcl-aio
Alright. I will try to take a stab at this after I figure out the way forward with the Gray streams/SLIME imbroglio.
`ASDF:MAKE` is a wrapper function that can do `LOAD-SYSTEM` or other things through some complex configuration process. I think the intent is to let the user specify that the `MAKE` operation might actually involve building an executable, a library, or some other thing (particularly for the C-based implementations).
So you could require the `asdf:make` on `"use-posix-syscalls"` to do something like build a `.jar` file or some JNI whatchamacallit.
But if it's just going to do `load-system`, I'd encourage you to simply tailor the behavior of the `load-op`. `make` is a new layer of complexity, which you should avoid unless you need it.
Best, R
On 3 May 2023, at 10:30, Mark Evenson wrote:
On May 2, 2023, at 21:16, Alan Ruttenberg alanruttenberg@gmail.com wrote:
[…]
It's true that I use aio. TBH I've never understood the point of separating the contribs from the base. File size isn't an issue any more. What's the upside of splitting them apart? A bit of extra time indexing the classes in the jar?
From https://github.com/armedbear/abcl/blob/master/doc/packaging-abcl.org :
We create two separate jar artifacts in order to: • To place an upper bound of size of abcl.jar regardless of what we package in abcl-contrib.jar. • Clearly mark which parts of the code-base are covered under GPLv2+classpath from those that may have other licensing terms. By making the loading of “contrib” a dynamic operation, we defer possible infringement to the User who redistributes the resulting jar artifact.
Conceptually, we should somehow place the implementation of setting environment variables via the C syscall as a patch in the contrib system in a new contrib called (?) USE-POSIX-SYSCALLS (terrible name, please change). Such a new contrib would a) depend on JNA and b) have to be used via
(asdf:make :use-posix-syscalls)
I don't know what asdf:make does. I tried it in a situation (autoloading the java parser when #1 was used the first time) where I expected it to load a system and it didn't seem to.
ASDF:MAKE is a shorter synonym for ASDF:LOAD-SYSTEM as far as I understand things.
Would it be sufficient to do something like:
(defun ensure-jna-loaded () (or *jna-loaded* (progn (when (not (ignore-errors (find-java-class 'jna.nativelibrary))) (require 'abcl-asdf) (add-to-classpath (funcall (intern "RESOLVE" 'abcl-asdf "net.java.dev.jna/jna/LATEST"))) (setq *jna-loaded* t)))))
Probably not: you really want to depend on the ASDF encapsulation of JNA in 'contrib/mvn/jna.asd’, not the presence of yet another special (“*jna-loaded*”). Since you are requiring ABCL-ASDF:RESOLVE to be present, you can make the assumption that both ASDF and ABCL-CONTRIB have been successfully REQUIREd.
[…]
Bottom line is that I don't know how to package this under whatever the assumptions are when not using abcl-aio
Alright. I will try to take a stab at this after I figure out the way forward with the Gray streams/SLIME imbroglio.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
On May 3, 2023, at 17:30, Mark Evenson evenson@panix.com wrote:
On May 2, 2023, at 21:16, Alan Ruttenberg alanruttenberg@gmail.com wrote:
[…]
It's true that I use aio. TBH I've never understood the point of separating the contribs from the base. File size isn't an issue any more. What's the upside of splitting them apart? A bit of extra time indexing the classes in the jar?
Updated the rationale on
From https://github.com/armedbear/abcl/blob/master/doc/packaging-abcl.org:
to read:
The standard ABCL build process as described in the build.xml file and executed by the Ant build tool results in two artifacts: abcl.jar and abcl-contrib.jar. abcl.jar contains all the Java and Common Lisp code necessary that constitute the ANSI conforming implementation runtime, plus the latest stable ASDF. The abcl-contrib.jar (aka contrib) artifact contains additional Common Lisp-only code that extends the implementation in useful manners.
We create two separate jar artifacts in order to:
1. To place an upper bound of size and complexity of abcl.jar regardless of what we package in abcl-contrib.jar. Having a restricted core ANSI implementation plus ASDF enables us to:
1.1. More easily bootstrap ABCL when porting to JVM runtimes other than the OpenJDK (Dalvik, CLR, )
1.2. Subsequently use ASDF to package ABCL extension components.
2. Clearly mark which parts of the code-base are covered under GPLv2+classpath from those that may have other licensing terms. By making the loading of contrib a dynamic operation, we defer possible infringement to the User who redistributes the resulting jar artifact.
On May 2, 2023, at 21:16, Alan Ruttenberg alanruttenberg@gmail.com wrote:
[…]
Bottom line is that I don't know how to package this under whatever the assumptions are when not using abcl-aio
Since the [ABCL/CLOS/XP work for SLIME][abcl-clos-xp] is taking longer than expected, I’ve [provided an implementation based on Alan’s code][posix-syscalls] that satisfies my concerns about maintaining some amount of sanity on how ABCL is structured internally.
[abcl-clos-xp]: https://github.com/armedbear/abcl/pull/586
[posix-syscalls]: https://github.com/armedbear/abcl/pull/588
As always, I hope both Scott, Alan, and other users of the Bear find this useful and acceptable.
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Mark Evenson -
Robert Goldman -
Scott L. Burson