Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Max Nikulin writes: > To wrap up, I suggest (and I do not insist) to drop > "-Djava.awt.headless=true" since "-headless" is anyway added in jar > mode. Those who desperately need namely "-Djava.awt.headless=true" (for > some unknown to me reason) may customize :java header argument. I do not > see any real problem with the change, just a minor improvement. After further consideration, I decided to follow your suggestion. If we insist of -Djava.awt.headless=true in org-plantuml-exec-mode='jar but not in 'plantuml, we may run into inconsistency between users using the two alternatives. Applied onto main as b5f0efc04. Best, Ihor
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
On 21/01/2022 19:48, Ihor Radchenko wrote:
Max Nikulin writes:
I have reordered some parts of your message
I do not see much point customising this particular argument. We _do
not_ want plantuml in gui mode. Ever. Otherwise, babel behaviour will be
unpredictable. If we make it customizeable, the only "benefit" would be
allowing users to shoot their own leg.
I have tried plantuml and it does not start in GUI mode unless -gui
option is specified. I admit it might be not so kind in the past. If you
mean the following thread
Sun Lin. Subject: [PATCH] Fix DISPLAY error on exporting org with
plantuml to html. Sat, 16 Oct 2021 03:25:40 + (UTC)
https://list.orgmode.org/388850760.3644614.1634354740...@mail.yahoo.com/
than it is some strange use case. A lot of applications behave
incorrectly when DISPLAY environment variable has invalid value. So it
is responsibility of the user to reset it. On the other hand I believe
that nobody is still using e.g. remote font server and headless mode
might be a bit more reproducible (e.g. screen dpi can not affect result).
Actually you patch makes headless mode customizable and I do not
consider it as shooting somebody's foot:
+(defcustom org-plantuml-args (list "-headless")
So in my opinion dropping "-Djava.awt.headless=true" is just a step to
more consistent behavior for jar/wrapper modes.
if (argsArray.length > 0 && argsArray[0].equalsIgnoreCase("-headless")) {
System.setProperty("java.awt.headless", "true");
}
Thank you it makes thing more clear. By the way, latest wrapper in
ubuntu has the following code
>8
HEADLESS=
[ -z "$DISPLAY" ] && HEADLESS=-Djava.awt.headless=true
$JAVA -Djava.net.useSystemProxies=true $HEADLESS -jar
/usr/share/plantuml/plantuml.jar "$@"
8<
I realise that the current situation is kind of awkward. Maybe we should
encourage ob-* libraries to use special header args instead of
defcustoms and modify built-in libraries in this spirit. Would you be
interested to write a feature request?
I do not have clear vision how it should work yet. I am afraid that even
if I were dump current state of ideas, they would be lost and nobody
would remind about them when the question would be risen next time.
I do not object concerning common `org-plantuml-args' variable. Earlier
I had in mind that user might have incompatible versions of plantuml
installed as executable wrapper and available as another jar. Separate
args variable might make it easier to switch between wrapper/jar modes.
I do not think it is a case that must be supported, anyway it is
currently impossible to switch mode through header arguments, e.g. to
demonstrate version difference.
On 15/01/2022 13:20, Ihor Radchenko wrote:
Dejan Josifović writes:
Using PlantUML from jar (org-plantuml-jar-path variable) and latest
org-mode, I wanted to render a diagram containing some Unicode
characters (such as '⊥' and '∀'), but the end image had some gibberish
instead.
#+BEGIN_SRC plantuml :file ./test.png
A -> B: ∀ characters display correctly is ⊥
#+END_SRC
FYI, I am unable to reproduce it on my system.
Default charset depends on locale:
LANG=C plantuml -h | grep charset
-charset xxxTo use a specific charset (default is US-ASCII)
plantuml -h | grep charset
-charset xxxTo use a specific charset (default is UTF-8)
echo $LANG
en_US.UTF-8
To wrap up, I suggest (and I do not insist) to drop
"-Djava.awt.headless=true" since "-headless" is anyway added in jar
mode. Those who desperately need namely "-Djava.awt.headless=true" (for
some unknown to me reason) may customize :java header argument. I do not
see any real problem with the change, just a minor improvement.
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
On 19-Jan-22 17:54, Max Nikulin wrote: FYI, you can customise any header arg globally. See manual page 16.3 Using Header Arguments. info "(org) Using Header Arguments" https://orgmode.org/manual/Using-Header-Arguments.html Thanks for the info. I'm still not fully proficient in org-mode so this (and the discussion) is very helpful. On 18-Jan-22 14:30, Ihor Radchenko wrote: I am not sure about this specific case. The PlantUML executable is literally a wrapper around java call to jar. Below is the contents of plantuml file in my system: #!/bin/bash gjl_package=plantuml gjl_jar="plantuml.jar" source /usr/share/java-config-2/launcher/launcher.bash Unless it is any different on your side, the arguments for jar and executable should be literally the same. I see your point here - no need for redundant custom variables. I realise that the current situation is kind of awkward. Maybe we should encourage ob-* libraries to use special header args instead of defcustoms and modify built-in libraries in this spirit. Would you be interested to write a feature request? This is very interesting, I will keep an eye on this discussion to follow up on everything. :-) Thanks. Regards, -- Dejan Josifović | Дејан Јосифовић Software engineer | Софтверски инжењер https://theparanoidtimes.org () ascii ribbon campaign /\ www.asciiribbon.org
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Max Nikulin writes:
>> #!/bin/bash
>> gjl_package=plantuml
>> gjl_jar="plantuml.jar"
>> source /usr/share/java-config-2/launcher/launcher.bash
>
> It seems with with the suggested patch both -Djava.awt.headless=true and
> -headless are passed to jar. I suspect it is either redundant or
> launcher.bash converts "-headless" to "-Djava.awt.headless=true". In
> ubuntu there is no room for special treatment of "-headless" option by
> the shell wrapper:
It is redundant, but should not cause any harm. plantuml source code has:
if (argsArray.length > 0 && argsArray[0].equalsIgnoreCase("-headless")) {
System.setProperty("java.awt.headless", "true");
}
I can of course add a condition to not add -headless if we are running
jar, but I do not see much benefit except purity argument.
>> I feel that running headless mode in the ob-plantuml is deliberate.
>
> https://plantuml.com/faq
> "Basically, this is because PlantUML needs to have access to some
> graphical resources"
>
> I have no idea what is actually affected.
It mostly looks like otherwise there are some harmless warnings in the
output.
> Which peace of code (java or plantuml.jar) handles "-headless" option?
> This question affects decision if jar and executable wrapper modes may
> share same list of arguments. Plantuml site recommends namely
> -Djava.awt.headless=true. Anyway with or without the patch,
> "-Djava.awt.headless=true" is added unconditionally in the jar mode. I
> would revert that patch and either add it to java header argument or to
> a new defcustom.
I do not see much point customising this particular argument. We _do
not_ want plantuml in gui mode. Ever. Otherwise, babel behaviour will be
unpredictable. If we make it customizeable, the only "benefit" would be
allowing users to shoot their own leg.
> Are there cases when :cmdline header argument is not enough and extra
> custom variable org-plantuml-args (org-plantump-executable-args) should
> be used?
> Actually I have realized that I do not understand why babel code uses
> mix of defcustom and header arguments. The latter are more flexible and
> may be adjusted per source block. On the other hand they may be set in
> init file. Even java executable and path to jar file may be obtained
> from header arguments.
Good questions. I think that the main reason is that most of header args
are not merged - only the last value is used. If you define :cmdline in
source block, it will override system-wide settings. Having an
additional defcustom allows to provide a "permanent" set of parameters -
to be used no matter what.
I realise that the current situation is kind of awkward. Maybe we should
encourage ob-* libraries to use special header args instead of
defcustoms and modify built-in libraries in this spirit. Would you be
interested to write a feature request?
Best,
Ihor
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
On 18/01/2022 20:30, Ihor Radchenko wrote:
Dejan Josifović writes:
But, since ob-plantuml already had variable for arguments for executable
it fells natural to me to have customizable variables for when using
jar. These headers are of course easier, but the user would have to
write them on each source block to achieve something that should be
globally customizable (like charset).
FYI, you can customise any header arg globally. See manual page 16.3
Using Header Arguments.
info "(org) Using Header Arguments"
https://orgmode.org/manual/Using-Header-Arguments.html
#!/bin/bash
gjl_package=plantuml
gjl_jar="plantuml.jar"
source /usr/share/java-config-2/launcher/launcher.bash
It seems with with the suggested patch both -Djava.awt.headless=true and
-headless are passed to jar. I suspect it is either redundant or
launcher.bash converts "-headless" to "-Djava.awt.headless=true". In
ubuntu there is no room for special treatment of "-headless" option by
the shell wrapper:
--- >8
if [ -n "${JAVA_HOME}" ] && [ -x "${JAVA_HOME}/bin/java" ] ; then
JAVA="${JAVA_HOME}/bin/java"
elif [ -x /usr/bin/java ] ; then
JAVA=/usr/bin/java
else
echo Cannot find JVM
exit 1
fi
$JAVA -jar -Djava.net.useSystemProxies=true
/usr/share/plantuml/plantuml.jar ${@}
8< ---
I feel that running headless mode in the ob-plantuml is deliberate.
https://plantuml.com/faq
"Basically, this is because PlantUML needs to have access to some
graphical resources"
I have no idea what is actually affected.
Which peace of code (java or plantuml.jar) handles "-headless" option?
This question affects decision if jar and executable wrapper modes may
share same list of arguments. Plantuml site recommends namely
-Djava.awt.headless=true. Anyway with or without the patch,
"-Djava.awt.headless=true" is added unconditionally in the jar mode. I
would revert that patch and either add it to java header argument or to
a new defcustom.
Are there cases when :cmdline header argument is not enough and extra
custom variable org-plantuml-args (org-plantump-executable-args) should
be used?
Actually I have realized that I do not understand why babel code uses
mix of defcustom and header arguments. The latter are more flexible and
may be adjusted per source block. On the other hand they may be set in
init file. Even java executable and path to jar file may be obtained
from header arguments.
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Dejan Josifović writes: > But, since ob-plantuml already had variable for arguments for executable > it fells natural to me to have customizable variables for when using > jar. These headers are of course easier, but the user would have to > write them on each source block to achieve something that should be > globally customizable (like charset). FYI, you can customise any header arg globally. See manual page 16.3 Using Header Arguments. > I second the concern that Max stated: >> Is there a case when some arguments are suitable for dedicated binary but >> should be avoided for jar (when a user has both executable from system >> package and manually downloaded jar having newer version)? It may be a >> reason to have separate variables (or header arguments). > I believe it is better design decision to separate arguments for > executable and jar. I am not sure about this specific case. The PlantUML executable is literally a wrapper around java call to jar. Below is the contents of plantuml file in my system: #!/bin/bash gjl_package=plantuml gjl_jar="plantuml.jar" source /usr/share/java-config-2/launcher/launcher.bash Unless it is any different on your side, the arguments for jar and executable should be literally the same. > Since we are making jar arguments customizable, we should think about > adding java arguments customizable (also mentioned by Max!). This line > in patch: > + "-Djava.awt.headless=true" > can be also added to a separate variable. I feel that running headless mode in the ob-plantuml is deliberate. We may not want users to change it. Otherwise, you are free to customize java arguments in org-babel-default-header-args:plantuml > Lastly, there is a typo in the patch: > +** Removed or renamed functions and variables > +*** =org-plantump-executable-args= is renamed and applies to jar as well > + > +The new variable name is =org-plantump-args=. It now applies to both > +jar PlantUML file and executable. > Word plantump should be plantuml I guess. :-) Thanks! Will fix. Best, Ihor
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
On 16-Jan-22 08:53, Max Nikulin wrote: Dejan, have you tried :java or :cmdline header arguments? Hi Max! Yes, I have tried with those header arguments and they naturally work. Maybe I should've mentioned that. But, since ob-plantuml already had variable for arguments for executable it fells natural to me to have customizable variables for when using jar. These headers are of course easier, but the user would have to write them on each source block to achieve something that should be globally customizable (like charset). On 15-Jan-22 07:20, Ihor Radchenko wrote: See the attached patch. It appears that we can simply carry over the executable args to jar (but please test it on other systems!) I have tested the patch on my machine and it works fine. I have set the new/renamed variable like this: (setq org-plantuml-args (list "-headless" "-charset" "UTF-8")) and tried the same example: #+BEGIN_SRC plantuml :file ./test.png A -> B: Hello ∧ #+END_SRC and it renders correctly. However, I have a couple of concerns. I second the concern that Max stated: Is there a case when some arguments are suitable for dedicated binary but should be avoided for jar (when a user has both executable from system package and manually downloaded jar having newer version)? It may be a reason to have separate variables (or header arguments). I believe it is better design decision to separate arguments for executable and jar. Since we are making jar arguments customizable, we should think about adding java arguments customizable (also mentioned by Max!). This line in patch: + "-Djava.awt.headless=true" can be also added to a separate variable. Lastly, there is a typo in the patch: +** Removed or renamed functions and variables +*** =org-plantump-executable-args= is renamed and applies to jar as well + +The new variable name is =org-plantump-args=. It now applies to both +jar PlantUML file and executable. Word plantump should be plantuml I guess. :-) Thanks all, -- Dejan Josifović | Дејан Јосифовић Software engineer | Софтверски инжењер https://theparanoidtimes.org () ascii ribbon campaign /\ www.asciiribbon.org OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] ob-plantuml: Allow setting PlantUML args for jar file
Hi. Disclaimer: I am neither plantuml nor ditaa user, so my comments may have no sense. On 15/01/2022 13:20, Ihor Radchenko wrote: Dejan Josifović writes: Comparing ob-plantuml.el and plantuml-mode.el files I found what is the problem. plantuml-mode has a customizable variable for specifying arguments when using PlantUML from jar (plantuml-jar-args (list "-charset" "UTF-8" ). The charset arguments is what is needed for the images to render correctly (I confirmed it by implementing it locally). I was wondering why such variable doesn't exist in ob-plantuml. Dejan, have you tried :java or :cmdline header arguments? Even though I was unable to reproduce your problem (most likely because my system is different), it sounds like a good idea to allow users to customise jar args as well. I agree that arguments should be customizable when the application is launched from jar, but there are already :java argument that is inserted before jar file and :cmdline argument that is appended after it. Another consideration is that ob-ditaa and ob-plantuml should use similar set of header arguments for additional parameters. They (and third-party packages) may even share some parameters related to java executable location and arguments for tuning of java VM (memory limits, etc.). See the attached patch. It appears that we can simply carry over the executable args to jar (but please test it on other systems!) - (t (list java -"-Djava.awt.headless=true" (unrelated to this patch) The line above is a recent change, and I do not see a reason why it is not added in a customizable way through appending (:java "-Djava.awt.headless=true") to `org-babel-default-header-args:plantuml'. Maybe I just missed something stupid since I have not tried it. -"-jar" -(shell-quote-argument (expand-file-name org-plantuml-jar-path)) + (t `(,java +"-Djava.awt.headless=true" +"-jar" +,(shell-quote-argument (expand-file-name org-plantuml-jar-path)) + ,@org-plantuml-args Is there a case when some arguments are suitable for dedicated binary but should be avoided for jar (when a user has both executable from system package and manually downloaded jar having newer version)? It may be a reason to have separate variables (or header arguments). I suppose, a part of problem that there are no plantuml and ditaa users and subscribers of this list who are ready to discuss code of related babel packages.
