Greetings. In the org file below, the first babel block will evaluate just fine, while the second will signal "End of file during parsing". The difference is the opening bracket "[" in output. I think am running the most recent stable version: Org mode version 9.3.7 (release_9.3.7-4-gba6ca7) Thanks for any ideas. Jarmo # --------------------------------------------------------------------------- * This will parse just fine #+name: OK #+begin_src java :exports results :classname OK :results output class OK { public static void main (String[] args) { System.out.println ("foo"); } } #+end_src #+RESULTS: OK : foo * This will generate a parse error when evaluated #+name: BAD #+begin_src java :exports results :classname BAD :results output class BAD { public static void main (String[] args) { System.out.println ("[foo"); } } #+end_src
[-- Attachment #1: Type: text/plain, Size: 1236 bytes --] I've written an alternative org-java.el that doesn't have that problem. I wanted to add it to contrib/ but haven't been able to get access. if you want to try it I can post it somewhere. On Thu, Jun 25, 2020 at 7:29 AM Jarmo Hurri <jarmo.hurri@iki.fi> wrote: > > Greetings. > > In the org file below, the first babel block will evaluate just fine, > while the second will signal "End of file during parsing". The > difference is the opening bracket "[" in output. > > I think am running the most recent stable version: > Org mode version 9.3.7 (release_9.3.7-4-gba6ca7) > > Thanks for any ideas. > > Jarmo > > # > --------------------------------------------------------------------------- > * This will parse just fine > #+name: OK > #+begin_src java :exports results :classname OK :results output > class OK > { > public static void main (String[] args) { System.out.println > ("foo"); } > } > #+end_src > > #+RESULTS: OK > : foo > > * This will generate a parse error when evaluated > #+name: BAD > #+begin_src java :exports results :classname BAD :results output > class BAD > { > public static void main (String[] args) { System.out.println > ("[foo"); } > } > #+end_src > > > [-- Attachment #2: Type: text/html, Size: 1709 bytes --]
ian martins <ianxm@jhu.edu> writes:
Hello.
> I've written an alternative org-java.el that doesn't have that
> problem. I wanted to add it to contrib/ but haven't been able to get
> access. if you want to try it I can post it somewhere.
Sounds excellent.
Would it be possible for us to fix the current version without
introducing a new one? Can you identify the parts of your code that fix
the issue?
I am already a contributor, so if you can post your solution here I can
create a patch and give you the credit.
How does that sound?
Jarmo
[-- Attachment #1: Type: text/plain, Size: 1640 bytes --] On Sat, Jun 27, 2020 at 1:25 AM Jarmo Hurri <jarmo.hurri@iki.fi> wrote: > ian martins <ianxm@jhu.edu> writes: > > Hello. > > > I've written an alternative org-java.el that doesn't have that > > problem. I wanted to add it to contrib/ but haven't been able to get > > access. if you want to try it I can post it somewhere. > > Sounds excellent. > > Would it be possible for us to fix the current version without > introducing a new one? Can you identify the parts of your code that fix > the issue? > The existing code creates the java program and runs it correctly, but it uses `org-babel-import-elisp-from-file' to interpret the results, and that sees the bracket and tries to make the response into a list, and errors when it can't. I don't see a quick fix for it. If you allow unbalanced brackets but that would be a change in ob-core and would probably cause unwanted results in other places. If you don't try to convert the output into a list, you can't present java results as lists or tables. Really the problem is that ob-java doesn't support functional mode, so it tries to guess if scripting mode output should be a table or list. The version I wrote supports functional and scripting modes and doesn't use `org-babel-import-elisp-from-file'. > > I am already a contributor, so if you can post your solution here I can > create a patch and give you the credit. > I would really appreciate that if you are willing, but it's a significant change (code is 400 lines, 600 lines of tests and test data) and there might be iterations so you might be signing up for more than you realize. > > How does that sound? > > Jarmo > > > [-- Attachment #2: Type: text/html, Size: 2416 bytes --]
>> ian martins <ianxm@jhu.edu> writes: >> >> Would it be possible for us to fix the current version without >> introducing a new one? Can you identify the parts of your code that fix >> the issue? >> > The existing code creates the java program and runs it correctly, but > it uses `org-babel-import-elisp-from-file' to interpret the results, > and that sees the bracket and tries to make the response into a list, > and errors when it can't. I don't see a quick fix for it. If you allow > unbalanced brackets but that would be a change in ob-core and would > probably cause unwanted results in other places. If you don't try to > convert the output into a list, you can't present java results as > lists or tables. Really the problem is that ob-java doesn't support > functional mode, so it tries to guess if scripting mode output should > be a table or list. The version I wrote supports functional and > scripting modes and doesn't use `org-babel-import-elisp-from-file'. Ok. >> I am already a contributor, so if you can post your solution here I >> can create a patch and give you the credit. >> > I would really appreciate that if you are willing, but it's a > significant change (code is 400 lines, 600 lines of tests and test > data) and there might be iterations so you might be signing up for > more than you realize. Fair enough. 1. Have you considered writing a patch yourself? 2. If not, I think you lose nothing by posting your code here and patiently waiting if I can create something out of it. All the best, Jarmo
[-- Attachment #1: Type: text/plain, Size: 2287 bytes --] A little while back I submitted a patch to add org-babel integration for haxe and mentioned that the same could be done for java to expand the features of the java integration. There was no response which I took to mean no interest in haxe or java, so I didn't think submitting a patch for java would be fruitful. Then I thought I could just add them to the contrib directory but was mistaken since that goes through the same ML patch workflow. Since you recommend it, I will try submitting a patch for java. I still want to share the haxe integration. What is the best way to do that? -Ian On Sun, Jun 28, 2020 at 1:55 AM Jarmo Hurri <jarmo.hurri@iki.fi> wrote: > > >> ian martins <ianxm@jhu.edu> writes: > >> > >> Would it be possible for us to fix the current version without > >> introducing a new one? Can you identify the parts of your code that fix > >> the issue? > >> > > The existing code creates the java program and runs it correctly, but > > it uses `org-babel-import-elisp-from-file' to interpret the results, > > and that sees the bracket and tries to make the response into a list, > > and errors when it can't. I don't see a quick fix for it. If you allow > > unbalanced brackets but that would be a change in ob-core and would > > probably cause unwanted results in other places. If you don't try to > > convert the output into a list, you can't present java results as > > lists or tables. Really the problem is that ob-java doesn't support > > functional mode, so it tries to guess if scripting mode output should > > be a table or list. The version I wrote supports functional and > > scripting modes and doesn't use `org-babel-import-elisp-from-file'. > > Ok. > > >> I am already a contributor, so if you can post your solution here I > >> can create a patch and give you the credit. > >> > > I would really appreciate that if you are willing, but it's a > > significant change (code is 400 lines, 600 lines of tests and test > > data) and there might be iterations so you might be signing up for > > more than you realize. > > Fair enough. > > 1. Have you considered writing a patch yourself? > > 2. If not, I think you lose nothing by posting your code here and > patiently waiting if I can create something out of it. > > All the best, > > Jarmo > > > [-- Attachment #2: Type: text/html, Size: 2989 bytes --]
ian martins <ianxm@jhu.edu> writes: > Since you recommend it, I will try submitting a patch for java. Excellent. > I still want to share the haxe integration. What is the best way to do > that? What does "haxe integration" mean here? All the best, Jarmo
[-- Attachment #1: Type: text/plain, Size: 632 bytes --] On Tue, Jun 30, 2020 at 12:13 AM Jarmo Hurri <jarmo.hurri@iki.fi> wrote: > ian martins <ianxm@jhu.edu> writes: > > > Since you recommend it, I will try submitting a patch for java. > > Excellent. > I posted the patch <https://orgmode.org/list/CAC=rjb7AhmnRQ9Nc4Ao07qK3QZF4LVaTmU_R1fWqr+97NpnRJQ@mail.gmail.com/T/#u> for java. Let me know if you have feedback. > > > I still want to share the haxe integration. What is the best way to do > > that? > > What does "haxe integration" mean here? > haxe <https://haxe.org/> is a language. By haxe integration I meant that I wrote an ob-haxe.el to use haxe code blocks in org. -Ian [-- Attachment #2: Type: text/html, Size: 1296 bytes --]
Hi Jarmo,
Jarmo Hurri <jarmo.hurri@iki.fi> writes:
> In the org file below, the first babel block will evaluate just fine,
> while the second will signal "End of file during parsing". The
> difference is the opening bracket "[" in output.
Fixed in maint, thanks.
--
Bastien
Hi Ian,
ian martins <ianxm@jhu.edu> writes:
> I've written an alternative org-java.el that doesn't have that
> problem.
I hope you don't mind the fix I just integrated -- it's simple
enough for being in 9.3.8, the next stable release. Obviously
your updates ob-java.el will probably make it obsolete once
we can move on after 9.4.
Thanks,
--
Bastien
[-- Attachment #1: Type: text/plain, Size: 558 bytes --] Of course there's never a problem in fixing things. I'm curious how you did it. Will look when I have a chance. On Sun, Sep 6, 2020, 5:57 AM Bastien <bzg@gnu.org> wrote: > Hi Ian, > > ian martins <ianxm@jhu.edu> writes: > > > I've written an alternative org-java.el that doesn't have that > > problem. > > I hope you don't mind the fix I just integrated -- it's simple > enough for being in 9.3.8, the next stable release. Obviously > your updates ob-java.el will probably make it obsolete once > we can move on after 9.4. > > Thanks, > > -- > Bastien > [-- Attachment #2: Type: text/html, Size: 971 bytes --]
Hi Ian, ian martins <ianxm@jhu.edu> writes: > Of course there's never a problem in fixing things. I'm curious how > you did it. Will look when I have a chance. Here it is: https://code.orgmode.org/bzg/org-mode/commit/989f50a53 Sorry I forgot to mention the commit in the ack message. PS: As I said, it was quite simple ;) -- Bastien