Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: >> Yes, ideally, we need to know which exact test case fails. But please >> open a new thread as it will be unrelated to java discussed herein. > > Now you lost me. :) > > The linked mail has all the information already has its own thread. You are right.

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: >> In the linked mail, I discuss the problem starting from this test, >> tracking it down to the problematic line of code. Do you want me to >> look into something further? > > Yes, ideally, we need to know which exact test case fails. But please > open a new thread as it

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > Ihor Radchenko writes: > >> Could you narrow down the particular test condition which is failing? >> Is it similar to previously discussed cases where MacOS sorting is not >> consistent with Linux? > > In the linked mail, I discuss the problem starting from this test,

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: > Could you narrow down the particular test condition which is failing? > Is it similar to previously discussed cases where MacOS sorting is not > consistent with Linux? In the linked mail, I discuss the problem starting from this test, tracking it down to the problematic

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: > Then, it sounds like local.mk does not enable java tests. > > I fixed such scenario on main. > Now, java tests will be skipped when ob-java testing is not requested. That works for me now, with or without java in local.mk. Thanks for the patch and the explanation!

Re: [PATCH] ob-java: Define the list of all supported header arguments

Bruno Barbier writes: > I'm seeing these 3 failures too, running the tests from the command > line. The failure looks like this: > > FAILED ob-java/lint-header-args-block ((should-not (org-lint > '(wrong-header-argument))) :form (org-lint (wrong-header-argument)) > :value ((1 ["8"

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: > Rudolf Adamkovič writes: > >> Overall, I now see the following failures on the main branch: >> >>FAILED ob-java/lint-header-args-block >>FAILED ob-java/lint-header-args-buffer >>FAILED ob-java/lint-header-args-heading > > AFAIK, Max is using Linux.

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > The second one (`test-org-table') still fails on macOS. > > Overall, I now see the following failures on the main branch: > >FAILED ob-java/lint-header-args-block >FAILED ob-java/lint-header-args-buffer >FAILED ob-java/lint-header-args-heading AFAIK,

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: >> ... The remaining tests (`test-org-num' and `test-org-table') fail >> in both scenarios. That said, I run macOS, which has some issues with >> sorting [*]. > > This is not because of macOS. Emacs 29 broke some assumptions about > return value of `overlays-in'. See >

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > On `main' with Emacs 29 (5b9b393c61), I get: > > 8 unexpected results: > ... >FAILED test-org-num/max-level [...] >FAILED test-org-num/skip-numbering [...] >FAILED test-org-num/update [...] >FAILED test-org-table/sort-lines [...] >FAILED

Re: [PATCH] ob-java: Define the list of all supported header arguments

Max Nikulin writes: > Am I the only person who gets > > 3 unexpected results: > FAILED ob-java/lint-header-args-block > FAILED ob-java/lint-header-args-buffer > FAILED ob-java/lint-header-args-heading On `main' with Emacs 29 (5b9b393c61), I get: 8 unexpected results: FAILED

Re: [PATCH] ob-java: Define the list of all supported header arguments

Max Nikulin writes: > Am I the only person who gets > > 3 unexpected results: > FAILED ob-java/lint-header-args-block > FAILED ob-java/lint-header-args-buffer > FAILED ob-java/lint-header-args-heading > > Emacs-27.1. Example of failure: Tests are passing on my side. -- Ihor

Re: [PATCH] ob-java: Define the list of all supported header arguments

Am I the only person who gets 3 unexpected results: FAILED ob-java/lint-header-args-block FAILED ob-java/lint-header-args-buffer FAILED ob-java/lint-header-args-heading Emacs-27.1. Example of failure: Test ob-java/lint-header-args-block backtrace: signal(ert-test-failed

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > Rudolf Adamkovič writes: > >> Please see the attached patch with updated tests. > > Oops, I had a typo (a wrong tense) in the commit message. > > Please see the patch attached to this message that has it fixed. Thanks! Applied onto main.

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > Please see the attached patch with updated tests. Oops, I had a typo (a wrong tense) in the commit message. Please see the patch attached to this message that has it fixed. Rudy >From 37bd1716a652751e6941781464d47c283be3b4b9 Mon Sep 17 00:00:00 2001 From:

Re: [PATCH] ob-java: Define the list of all supported header arguments

Ihor Radchenko writes: > Thanks! > Applied onto main. Fantastic! > Fixed. Thanks. Please see the attached patch with updated tests. Rudy >From 5405d0419295bb1a0314cb2b3ce07713fc77e792 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Fri, 21 Oct 2022 14:48:56 +0200

Re: [PATCH] ob-java: Define the list of all supported header arguments

Rudolf Adamkovič writes: > Hello smart folks! > > The Org linter warns about *correct* Java source block arguments. The > attached patch fixes that. Thanks! Applied onto main. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ee3dbb0fdb6e119207f13a165e90b878b741cf49 > P.S. I

[PATCH] ob-java: Define the list of all supported header arguments

rejects these as unknown header arguments. From what I understand, that look like a separate issue. Rudy >From 54f008cdfcf4680b3d3bc7107aa640596d5a91bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= Date: Thu, 20 Oct 2022 21:31:37 +0200 Subject: [PATCH] ob-java: Define the l

Re: [PATCH] ob-java: Allow import to end with asterisk

Hi Ian, ian martins writes: > Thanks for fixing this. I re-read the woof documentation and realized > I needed to put "Applied" at the beginning of the line. Yes - and also add a "X-Woof-Patch: applied" header in your reply.

Re: [PATCH] ob-java: Allow import to end with asterisk

On Sat, Apr 24, 2021 at 11:44 PM Timothy wrote: > > This was not marked as applied on updates.orgmode.org. > Doing so with the X-Woof-Patch header. > > ian martins writes: > > > Thanks. And thanks for taking the time to fix issues that you find. It > > continues to improve because of your

Re: [PATCH] ob-java: Allow import to end with asterisk

This was not marked as applied on updates.orgmode.org. Doing so with the X-Woof-Patch header. ian martins writes: > Thanks. And thanks for taking the time to fix issues that you find. It > continues to improve because of your contributions. > The patch looks good. Applied.

Re: [PATCH] ob-java, a proposal on import improvement

This was not marked as applied on updates.orgmode.org. Doing so with the X-Woof-Patch header. ian martins writes: > It's no problem. Didn't mean to rush you. Thanks again for the patch. Applied.

Re: [PATCH] ob-java: Allow import to end with asterisk

Thanks. And thanks for taking the time to fix issues that you find. It continues to improve because of your contributions. The patch looks good. Applied. On Thu, Jan 28, 2021 at 3:04 PM John Herrlin wrote: > > > ian martins writes: > > >> I found this case: > >> And it seems to me that the

Re: [PATCH] ob-java: Allow import to end with asterisk

Stay safe! >From 92c72792fb18a73572ee35d34a5e1d5ce56d8b6a Mon Sep 17 00:00:00 2001 From: John Herrlin Date: Tue, 26 Jan 2021 08:19:19 +0100 Subject: [PATCH] ob-java: Allow import to end with asterisk * lisp/ob-java.el (org-babel-java--imports-re, org-babel-java--import-maybe): Allow import to e

Re: [PATCH] ob-java: Allow import to end with asterisk

Thank you for the guidence! I will try to figure it out and sending a updated patch soon. ian martins writes: >> I found this case: >> And it seems to me that the import regex dont see the asterisk. >> >> I attached a possible patch. > > Thanks again, John. You're right the regex is missing

Re: [PATCH] ob-java: Allow import to end with asterisk

> I found this case: > And it seems to me that the import regex dont see the asterisk. > > I attached a possible patch. Thanks again, John. You're right the regex is missing the asterisk include. Thanks for the patch fixing. This works but it will add redundant includes if the source block

[PATCH] ob-java: Allow import to end with asterisk

00:00:00 2001 From: John Herrlin Date: Tue, 26 Jan 2021 08:19:19 +0100 Subject: [PATCH] ob-java: Allow import to end with asterisk * lisp/ob-java.el (org-babel-java--imports-re): Allow import to end with asterisk. TINYCHANGE --- lisp/ob-java.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-

Re: [PATCH] ob-java, a proposal on import improvement

It's no problem. Didn't mean to rush you. Thanks again for the patch. Applied. On Sat, Jan 16, 2021 at 10:32 AM John Herrlin wrote: > > > Sorry for latency, 9to5 been killing it. Thx for the feedback, make > sense! Here is a new patch with the improvements. > > > > ian martins writes: > > >

Re: [PATCH] ob-java, a proposal on import improvement

Sorry for latency, 9to5 been killing it. Thx for the feedback, make sense! Here is a new patch with the improvements. >From 680e04217c8e4c536875379cac01edccd694c4cb Mon Sep 17 00:00:00 2001 From: John Herrlin Date: Sun, 10 Jan 2021 21:47:26 +0100 Subject: [PATCH] ob-java: Include static impo

Re: [PATCH] ob-java, a proposal on import improvement

John, would you mind if I go ahead and make the change I mentioned and push it with you as the author? On Tue, Jan 12, 2021 at 7:00 AM ian martins wrote: > > On Sun, Jan 10, 2021 at 3:55 PM John Herrlin wrote: > > ian martins writes: > > > I think the problem was that I was missing static > >

Re: [PATCH] ob-java, a proposal on import improvement

On Sun, Jan 10, 2021 at 3:55 PM John Herrlin wrote: > ian martins writes: > > I think the problem was that I was missing static > > imports, which you fixed in the first chunk of your patch. I don't > > think the rest of the change

Re: [PATCH] ob-java, a proposal on import improvement

nks! Here is a patch with the regexp fix. Take care! >From 3de5cf1c3173285a7f51ab436f02419f8c9f5ffb Mon Sep 17 00:00:00 2001 From: John Herrlin Date: Sun, 10 Jan 2021 21:47:26 +0100 Subject: [PATCH] ob-java: Include static imports in regex * lisp/ob-java.el (org-babel-java--imports-re): Inclu

Re: [PATCH] ob-java, a proposal on import improvement

> I can’t give an informed opinion about the patch, but the example looks > great! I did not know that Java support in org-babel is that good. Thanks. Yes, ob-java got an update with org 9.4.

Re: [PATCH] ob-java, a proposal on import improvement

On Fri, Jan 8, 2021 at 11:28 AM John Herrlin wrote: > I would like to combine imports from header-args with imports from a > source block. > ... > I didnt get the to work so I made a patch. John, Sorry that wasn't working. Thanks for investigating and submitting a fix. I think the problem was

Re: [PATCH] ob-java, a proposal on import improvement

John Herrlin writes: > I would like to combine imports from header-args with imports from a > source block. > > Here is an example: > > * RxJava > :PROPERTIES: > :header-args: :dir src :results output code > :header-args:java: :cmdline -classpath ./rxjava-1.3.8.jar:src:. :cmpflag >

[PATCH] ob-java, a proposal on import improvement

Hey, Happy new year and a good continuation! I would like to combine imports from header-args with imports from a source block. Here is an example: * RxJava :PROPERTIES: :header-args: :dir src :results output code :header-args:java: :cmdline -classpath ./rxjava-1.3.8.jar:src:.

Re: [PATCH] ob-java

ian martins writes: > On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri wrote: >> >> >> > It seems that you have changed some classloader settings in the new >> >> > code. I have examples which used to work perfectly; now they still >> >> > compile, but fail to run, throwing exception >> >> > >> >> >

Re: [PATCH] ob-java

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri wrote: > > >> > It seems that you have changed some classloader settings in the new > >> > code. I have examples which used to work perfectly; now they still > >> > compile, but fail to run, throwing exception > >> > > >> >

Re: [PATCH] ob-java

ian martins writes: >> > It seems that you have changed some classloader settings in the new >> > code. I have examples which used to work perfectly; now they still >> > compile, but fail to run, throwing exception >> > >> > java.lang.NoClassDefFoundError >> >> I had some extra time today, so

Re: [PATCH] ob-java

On Sat, Nov 14, 2020 at 6:48 AM Jarmo Hurri wrote: > Jarmo Hurri writes: > > > It seems that you have changed some classloader settings in the new > > code. I have examples which used to work perfectly; now they still > > compile, but fail to run, throwing exception > > > >

Re: [PATCH] ob-java

Hi again! Jarmo Hurri writes: > It seems that you have changed some classloader settings in the new > code. I have examples which used to work perfectly; now they still > compile, but fail to run, throwing exception > > java.lang.NoClassDefFoundError I had some extra time today, so I took a

Re: [PATCH] ob-java

Hi Jarmo, Jarmo Hurri writes: > (I wonder if it would be possible to have timestamps in worg. I have > bumped into situations before where I have not known the temporal > relationship between worg documentation and current org version.) Good point. I think worg documentation, when related to

Re: [PATCH] ob-java

That is true. I will make it less rigid. On Mon, Nov 9, 2020 at 9:07 AM Jarmo Hurri wrote: > > Hello Ian! > > ian martins writes: > > > Let me know how it goes. > > The new version seems to be sensitive to whitespace: > > # - > * this one works >

Re: [PATCH] ob-java

ian martins writes: > Let me know how it goes. Hello again. It seems that you have changed some classloader settings in the new code. I have examples which used to work perfectly; now they still compile, but fail to run, throwing exception java.lang.NoClassDefFoundError explained here:

Re: [PATCH] ob-java

Hello Ian! ian martins writes: > Let me know how it goes. The new version seems to be sensitive to whitespace: # - * this one works #+begin_src java :classname Foo :results output public class Foo { public static void

Re: [PATCH] ob-java

I'm sorry that happened. It must have been frustrating. If you executed a code block and no result was added to the buffer, then there's a chance it is fixed. Let me know how it goes. On Fri, Nov 6, 2020 at 12:21 AM Jarmo Hurri wrote: > > Hello Ian. > > ian martins writes: > > >> Being a

Re: [PATCH] ob-java

Hello Ian. ian martins writes: >> Being a heavy user, I wonder if worg documentation page is being kept >> up to date with the changes? > Yes, that page is up to date. Actually, the page is new. Brilliant! So the only thing that was not up to date was me. (I wonder if it would be possible

Re: [PATCH] ob-java

Yes, that page is up to date. Actually, the page is new. Are you using the latest? Were there any issues when you updated? On Thu, Nov 5, 2020, 11:32 AM Jarmo Hurri wrote: > > Hi there! > > I noticed that a lot of work is being put into Java in Babel. Excellent. > > Being a heavy user, I

Re: [PATCH] ob-java

Hi there! I noticed that a lot of work is being put into Java in Babel. Excellent. Being a heavy user, I wonder if worg documentation page is being kept up to date with the changes? https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html All the best, and stay safe. Jarmo

Re: [PATCH] ob-java

As I was trying to decide who is the author of the ob-java docs, I realized it's not clear how you're defining authorship due to my confusion about ob-java. I can think of three ways to determine authorship: 1. the person that wrote it 2. the people who influenced the code 3. the first person to

Re: [PATCH] ob-java

ian martins writes: > But I want to follow your conventions. I will put the authors of ob-C > and ob-python (Eric Schulte and Dan Davison) as the authors of > ob-java and ob-haxe. The implementations are nearly the same. it > wouldn't make sense for them to have different authors. Thanks for

Re: [PATCH] ob-java

I made the changes, updated the commit message for the large patch, and pushed. On Sat, Oct 24, 2020 at 10:40 PM Kyle Meyer wrote: > ian martins writes: > > > After making the changes, should I submit updated patches or is it fine > to > > push? > > Push away. Thanks again. >

Re: [PATCH] ob-java

ian martins writes: > After making the changes, should I submit updated patches or is it fine to > push? Push away. Thanks again.

Re: [PATCH] ob-java

Thanks for the feedback. In general, the changes are all intended to be backwards compatible. Thanks for pointing out changes that weren't. After making the changes, should I submit updated patches or is it fine to push? On Sat, Oct 24, 2020 at 1:05 PM Kyle Meyer wrote: > Hi ian, > > ian

Re: [PATCH] ob-java

This happened because the new ob-java wasn't based on the old ob-java. I wrote ob-haxe based on ob-C and ob-python and then derived ob-java from ob-haxe. I went back and forth about who should be the author of ob-haxe. I considered listing the authors of ob-C and ob-python, but I thought it

Re: [PATCH] ob-java

Hi ian, ian martins writes: >> * Changes >> >> - support for functional mode (~:results value~) >> - accept variables >> - don't require package, class, and main definitions >> - write source and result tempfiles to ~org-babel-temporary-directory~, >> but respects the ~:dir~ header >> - work

Re: [PATCH] ob-java

Hi Ian, feel free to install the patch when you think it's ready. One minor nitpick: -;; Author: Eric Schulte -;; Maintainer: Ian Martins +;; Author: Ian Martins I suggest you leave Eric Schulte as the author while adding yourself as the maintainer, even if the "change" is a big rewrite.

Re: [PATCH] ob-java

ian martins writes: > Actually I realized if I keep the commits separate and generate a patch set > instead of squashing then I can preserve authorship. Thank you for taking the time! It's not necessary and not important for me! > > These patches, which follow patch 0001, fix the spacing and

Re: [PATCH] ob-java

Actually I realized if I keep the commits separate and generate a patch set instead of squashing then I can preserve authorship. These patches, which follow patch 0001, fix the spacing and allow non-public classes. Thanks again for testing, debugging, and reporting. On Wed, Oct 21, 2020 at 9:54

Re: [PATCH] ob-java

ian martins writes: >> >> What do you think about having a configurable list where the user can >> add =org-babel-java--import-maybe=? In my current use case I could then >> add RxJava imports to that list and the imports could be removed from >> the source code block. > > > I think this can

Re: [PATCH] ob-java

> > What do you think about having a configurable list where the user can > add =org-babel-java--import-maybe=? In my current use case I could then > add RxJava imports to that list and the imports could be removed from > the source code block. I think this can already be done. imports can be

Re: [PATCH] ob-java

I did and it looks really good. The difference in this example: #+BEGIN_SRC java import rx.Observable; Observable.range(5, 3) .subscribe((Integer i) -> { System.out.println("Got: " + i); }, (Throwable t) -> { t.printStackTrace();},

Re: [PATCH] ob-java

Thanks for testing, and thanks for pointing that out. I will fix it so that `public` is optional. btw, in your example you didn't have to specify `:classname` since you defined the class name in the source block. btw2, did you notice that you can C-c C-c on source blocks that don't have main

Re: [PATCH] ob-java

Hey, Did some debugging and found out that my class didn't contained =public= and the patch requires it to be. This works fine: #+HEADER: :classname Main #+HEADER: :dir src #+HEADER: :cmdline -classpath ./rxjava-1.3.8.jar:. #+HEADER: :cmpflag -classpath ./rxjava-1.3.8.jar

Re: [PATCH] ob-java

Hey Ian, The changes list looks really nice! But I can't get the patch to work. The use case I have is this and it works fine in master. #+HEADER: :classname Main #+HEADER: :dir src #+HEADER: :cmdline -classpath ./rxjava-1.3.8.jar:. #+HEADER: :cmpflag -classpath

Re: [PATCH] ob-java

I noticed that the tests didn't run with "make test." This updates the patch so that they can. I didn't add java to the list of default languages because the java tests are slow. On Mon, Oct 5, 2020 at 9:23 AM ian martins wrote: > I wrote those examples in an org file so I could test as I wrote

Re: [PATCH] ob-java

I wrote those examples in an org file so I could test as I wrote them, and then exported it to make it more readable, but the export resulted in source block headers being lost. Here is the same without export: * Changes - support for functional mode (~:results value~) - accept variables -

[PATCH] ob-java

1 Changes = - support for functional mode (`:results value') - accept variables - don't require package, class, and main definitions - write source and result tempfiles to `org-babel-temporary-directory', but respects the `:dir' header - work with tramp 2 Examples

[PATCH] ob-java support for variables, functional mode, tramp, add tests

Hello. Attached is a patch to update the ob-java.el implementation. This allows package, class and imports to be provided in the code or header arguments or omitted, accepts variables, supports functional mode (:results value), writes temp files to the temp directory instead of current dir, works