subject:"Re\: \[PATCH\] ob\-java"

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

2022-11-12 Thread Ihor Radchenko

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.
https://orgmode.org/list/m2ilkwso8r@me.com already reported this
exact failure.

I am not yet sure how to proceed there.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-12 Thread Rudolf Adamkovič

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 will be unrelated to java discussed herein.

Now you lost me.  :)

The linked mail has all the information already has its own thread.

Rudy
-- 
"Simplicity is complexity resolved."
-- Constantin Brâncuși, 1876-1957

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-11-12 Thread Ihor Radchenko

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,
> 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 will be unrelated to java discussed herein.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-11 Thread Rudolf Adamkovič

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 line of code.  Do you want me to
look into something further?

Rudy
-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-11-10 Thread Bruno Barbier

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!

Bruno

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

2022-11-10 Thread Ihor Radchenko

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" "nil" "Unknown header argument \":classname\""
> #s(org-lint-checker wrong-header-argument "Report wrong babel
> headers" org-lint-wrong-header-argument nil (babel))]) (2 ["8" "nil"
> "Unknown header argument \":imports\"" #s(org-lint-checker
> wrong-header-argument "Report wrong babel headers"
> org-lint-wrong-header-argument nil (babel))]) (3 ["8" "nil" "Unknown
> header argument \":cmpflag\"" #s(org-lint-checker
> wrong-header-argument "Report wrong babel headers"
> org-lint-wrong-header-argument nil (babel))]) (4 ["8" "nil" "Unknown
> header argument \":cmdarg\"" #s(org-lint-checker
> wrong-header-argument "Report wrong babel headers"
> org-lint-wrong-header-argument nil (babel))])))
>
>
> Adding (require 'ob-java) at the beginning of test-ob-java.el ensures
> that `org-babel-header-args:java' is defined, and the tests pass.

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-10 Thread Bruno Barbier




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. This is strange...
> And I cannot really fix it without being able to reproduce on my side.

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" "nil" "Unknown header argument \":classname\""
#s(org-lint-checker wrong-header-argument "Report wrong babel
headers" org-lint-wrong-header-argument nil (babel))]) (2 ["8" "nil"
"Unknown header argument \":imports\"" #s(org-lint-checker
wrong-header-argument "Report wrong babel headers"
org-lint-wrong-header-argument nil (babel))]) (3 ["8" "nil" "Unknown
header argument \":cmpflag\"" #s(org-lint-checker
wrong-header-argument "Report wrong babel headers"
org-lint-wrong-header-argument nil (babel))]) (4 ["8" "nil" "Unknown
header argument \":cmdarg\"" #s(org-lint-checker
wrong-header-argument "Report wrong babel headers"
org-lint-wrong-header-argument nil (babel))])))


Adding (require 'ob-java) at the beginning of test-ob-java.el ensures
that `org-babel-header-args:java' is defined, and the tests pass.

Bruno

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

2022-11-09 Thread Ihor Radchenko

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, Max is using Linux. This is strange...
And I cannot really fix it without being able to reproduce on my side.

>FAILED  test-org-table/sort-lines

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?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-09 Thread Rudolf Adamkovič

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
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59067

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
   FAILED  test-org-table/sort-lines

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-11-08 Thread Ihor Radchenko

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  test-org-table/toggle-column-width [...]
> ...  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
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59067

Now fixed on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5a6d00a3a343d64acbc34fb0c35da754f52d172c

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-08 Thread Rudolf Adamkovič

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  ob-java/lint-header-args-block [...]
   FAILED  ob-java/lint-header-args-buffer [...]
   FAILED  ob-java/lint-header-args-heading [...]
   FAILED  test-org-num/max-level [...]
   FAILED  test-org-num/skip-numbering [...]
   FAILED  test-org-num/update [...] 
   FAILED  test-org-table/sort-lines [...]
   FAILED  test-org-table/toggle-column-width [...]

The first three tests (`ob-java') pass interactively but fail with `make
test'.  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 [*].

Rudy

[*] https://list.orgmode.org/m2ilkwso8r@me.com/
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
-- Edsger Wybe Dijkstra, 1930-2002

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-11-08 Thread Ihor Radchenko

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 Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-11-08 Thread Max Nikulin


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 (((should-not (org-lint '(wrong-header-argume
  ert-fail(((should-not (org-lint '(wrong-header-argument))) :form (or
  (if (not (unwind-protect (setq value-602 (apply fn-600 args-601)) (s
  (let (form-description-604) (if (not (unwind-protect (setq value-602
  (let ((value-602 'ert-form-evaluation-aborted-603)) (let (form-descr
  (let* ((fn-600 #'org-lint) (args-601 (condition-case err (let ((sign
  (progn (org-mode) (let ((point (string-match "" inside-text))
  (unwind-protect (progn (org-mode) (let ((point (string-match "["8" "nil" "Unknown header argument \":classname\"" 
#s(org-lint-checker wrong-header-argument "Report wrong babel headers" 
org-lint-wrong-header-argument nil ...)])

   (2
["8" "nil" "Unknown header argument \":imports\"" 
#s(org-lint-checker wrong-header-argument "Report wrong babel headers" 
org-lint-wrong-header-argument nil ...)])

   (3
["8" "nil" "Unknown header argument \":cmpflag\"" 
#s(org-lint-checker wrong-header-argument "Report wrong babel headers" 
org-lint-wrong-header-argument nil ...)])

   (4
["8" "nil" "Unknown header argument \":cmdarg\"" 
#s(org-lint-checker wrong-header-argument "Report wrong babel headers" 
org-lint-wrong-header-argument nil ...)]

   FAILED   59/978  ob-java/lint-header-args-block (0.004049 sec)

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

2022-10-21 Thread Ihor Radchenko

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.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=bed47b437d8cde7a98bafdb07996e248b40f70e6

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2022-10-21 Thread Rudolf Adamkovič

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: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Fri, 21 Oct 2022 14:48:56 +0200
Subject: [PATCH] test-ob-java: Test Java source block header arguments at all
 levels
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* testing/lisp/test-ob-java.el (ob-java/lint-header-arguments):
Rename to ob-java/lint-header-args-block.

* testing/lisp/test-ob-java.el (ob-java/lint-header-args-heading):
Test source block header arguments at the heading level.

* testing/lisp/test-ob-java.el (ob-java/lint-header-args-buffer):
Test source block header arguments at the buffer level.

Reported-by: Rudolf Adamkovič 
Link: https://orgmode.org/list/m2y1ta9rqe@me.com
---
 testing/lisp/test-ob-java.el | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index a62d66557..1cc7fbeb2 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -27,7 +27,36 @@
 
 ;;; No Java required
 
-(ert-deftest ob-java/lint-header-arguments ()
+(ert-deftest ob-java/lint-header-args-buffer ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the buffer level.
+  (org-test-with-temp-text "
+#+property: header-args:java+ :dir /tmp
+#+property: header-args:java+ :classname com.example.Example
+#+property: header-args:java+ :imports com.example.OtherExample
+#+property: header-args:java+ :cmpflag -classpath .:/tmp/example/
+#+property: header-args:java+ :cmdline -classpath .:/tmp/example/
+#+property: header-args:java+ :cmdarg -verbose"
+(should-not (org-lint '(wrong-header-argument)
+
+(ert-deftest ob-java/lint-header-args-heading ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the heading level.
+  (org-test-with-temp-text "
+* Test
+:PROPERTIES:
+:header-args:java+: :dir /tmp
+:header-args:java+: :classname com.example.Example
+:header-args:java+: :imports com.example.OtherExample
+:header-args:java+: :cmpflag -classpath .:/tmp/example/
+:header-args:java+: :cmdline -classpath .:/tmp/example/
+:header-args:java+: :cmdarg -verbose
+:END:"
+(should-not (org-lint '(wrong-header-argument)
+
+(ert-deftest ob-java/lint-header-args-block ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the block level.
   (org-test-with-temp-text "
 #+header: :dir /tmp
 #+header: :classname com.example.Example
-- 
2.38.0

-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-10-21 Thread Rudolf Adamkovič

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
Subject: [PATCH] test-ob-java: Test Java source block header arguments at all
 levels
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* testing/lisp/test-ob-java.el (ob-java/lint-header-arguments):
Renamed to ob-java/lint-header-args-block.

* testing/lisp/test-ob-java.el (ob-java/lint-header-args-heading):
Test source block header arguments at the heading level.

* testing/lisp/test-ob-java.el (ob-java/lint-header-args-buffer):
Test source block header arguments at the buffer level.

Reported-by: Rudolf Adamkovič 
Link: https://orgmode.org/list/m2y1ta9rqe@me.com
---
 testing/lisp/test-ob-java.el | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/testing/lisp/test-ob-java.el b/testing/lisp/test-ob-java.el
index a62d66557..1cc7fbeb2 100644
--- a/testing/lisp/test-ob-java.el
+++ b/testing/lisp/test-ob-java.el
@@ -27,7 +27,36 @@
 
 ;;; No Java required
 
-(ert-deftest ob-java/lint-header-arguments ()
+(ert-deftest ob-java/lint-header-args-buffer ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the buffer level.
+  (org-test-with-temp-text "
+#+property: header-args:java+ :dir /tmp
+#+property: header-args:java+ :classname com.example.Example
+#+property: header-args:java+ :imports com.example.OtherExample
+#+property: header-args:java+ :cmpflag -classpath .:/tmp/example/
+#+property: header-args:java+ :cmdline -classpath .:/tmp/example/
+#+property: header-args:java+ :cmdarg -verbose"
+(should-not (org-lint '(wrong-header-argument)
+
+(ert-deftest ob-java/lint-header-args-heading ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the heading level.
+  (org-test-with-temp-text "
+* Test
+:PROPERTIES:
+:header-args:java+: :dir /tmp
+:header-args:java+: :classname com.example.Example
+:header-args:java+: :imports com.example.OtherExample
+:header-args:java+: :cmpflag -classpath .:/tmp/example/
+:header-args:java+: :cmdline -classpath .:/tmp/example/
+:header-args:java+: :cmdarg -verbose
+:END:"
+(should-not (org-lint '(wrong-header-argument)
+
+(ert-deftest ob-java/lint-header-args-block ()
+  ;; Test that the Org linter accepts every supported Java source
+  ;; block header argument at the block level.
   (org-test-with-temp-text "
 #+header: :dir /tmp
 #+header: :classname com.example.Example
-- 
2.38.0

-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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

2022-10-20 Thread Ihor Radchenko

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 originally had two regression tests, not one.  The other test
> checked the '#+property:' version, e.g.
>
> #+property: header-args:java+ :dir /tmp
> #+property: header-args:java+ :classname com.example.Example
> #+property: header-args:java+ :imports com.example.OtherExample
> #+property: header-args:java+ :cmpflag -classpath .:/tmp/example/
> #+property: header-args:java+ :cmdline -classpath .:/tmp/example/
> #+property: header-args:java+ :cmdarg -verbose
>
> However, the linter rejects these as unknown header arguments.  From
> what I understand, that look like a separate issue.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d98a49648066ce80f1193d36accb81253a4027df

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at

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

2021-04-26 Thread Bastien

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

2021-04-25 Thread ian martins

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 contributions.
> > The patch looks good. Applied.
>

Thanks for fixing this. I re-read the woof documentation and realized I
needed to put "Applied" at the beginning of the line.

if anyone is curious, to save you a search, the doc is here:
https://github.com/bzg/woof#basic-usage

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

2021-04-24 Thread Timothy



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

2021-04-24 Thread Timothy



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

2021-01-30 Thread ian martins

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 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 includes something that is also
> > in the list of classes to automatically include.
> >
> > for example, this:
> >
> > #+begin_src java :results value
> >   import java.util.*;
> >   return "test";
> > #+end_src
> >
> > will end up pulling in
> >
> > import java.util.List;
> > import java.util.*;
> >
> > It wouldn't hurt anything, but could probably be prevented by changing
> > the regexp in =org-babel-java--import-maybe= to look for asterisk as
> > well as =class=.  Do you feel like updating the patch?
> >
> > [1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314
>
> Here is an updated patch. It seems to work on my cases.
>
> Of topic, I am very happy with the latest updates on ob-java and I think
> it works really good! Thanks for the awesome work Ian!
>
> Stay safe!
>

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

2021-01-28 Thread John Herrlin


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 the asterisk
> include. Thanks for the patch fixing. This works but it will add
> redundant includes if the source block includes something that is also
> in the list of classes to automatically include.
>
> for example, this:
>
> #+begin_src java :results value
>   import java.util.*;
>   return "test";
> #+end_src
>
> will end up pulling in
>
> import java.util.List;
> import java.util.*;
>
> It wouldn't hurt anything, but could probably be prevented by changing
> the regexp in =org-babel-java--import-maybe= to look for asterisk as
> well as =class=.  Do you feel like updating the patch?
>
> [1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314

Here is an updated patch. It seems to work on my cases.

Of topic, I am very happy with the latest updates on ob-java and I think
it works really good! Thanks for the awesome work Ian!

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 end with asterisk.

TINYCHANGE
---
 lisp/ob-java.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index 07ff8e9ab..1f2b980f6 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -88,7 +88,7 @@ like javac -verbose."
   "Regexp for the package statement.")
 (defconst org-babel-java--imports-re (rx line-start (0+ space) "import"
  (opt (1+ space) "static")
-	 (1+ space) (group (1+ (in alnum ?_ ?.))) ; capture the fully qualified class name
+	 (1+ space) (group (1+ (in alnum ?_ ?. ?*))) ; capture the fully qualified class name
 	 (0+ space) ?\; line-end)
   "Regexp for import statements.")
 (defconst org-babel-java--class-re (rx line-start (0+ space) (opt (seq "public" (1+ space)))
@@ -311,7 +311,8 @@ RESULT-FILE is the temp file to write the result."
 (goto-char (point-min))
 (setq class-found (re-search-forward class nil t))
 (goto-char (point-min))
-(setq import-found (re-search-forward (concat "^import .*" package ".*" class ";") nil t))
+(setq import-found
+  (re-search-forward (concat "^import .*" package ".*\\(?:\\*\\|" class "\\);") nil t))
 (when (and class-found (not import-found))
   (org-babel-java--move-past org-babel-java--package-re)
   (insert (concat "import " package "." class ";\n")
-- 
2.30.0

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

2021-01-26 Thread John Herrlin



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 the asterisk
> include. Thanks for the patch fixing. This works but it will add
> redundant includes if the source block includes something that is also
> in the list of classes to automatically include.
>
> for example, this:
>
> #+begin_src java :results value
>   import java.util.*;
>   return "test";
> #+end_src
>
> will end up pulling in
>
> import java.util.List;
> import java.util.*;
>
> It wouldn't hurt anything, but could probably be prevented by changing
> the regexp in =org-babel-java--import-maybe= to look for asterisk as
> well as =class=.  Do you feel like updating the patch?
>
> [1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314

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

2021-01-26 Thread ian martins

> 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 includes something that is also
in the list of classes to automatically include.

for example, this:

#+begin_src java :results value
  import java.util.*;
  return "test";
#+end_src

will end up pulling in

import java.util.List;
import java.util.*;

It wouldn't hurt anything, but could probably be prevented by changing
the regexp in =org-babel-java--import-maybe= to look for asterisk as
well as =class=.  Do you feel like updating the patch?

[1] https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-java.el#L314

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

2021-01-16 Thread ian martins

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:
>
> > 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
> >> > > imports, which you fixed in the first chunk of your patch. I don't
> >> > > think the rest of the change is necessary. Could you revert the other
> >> > > chunks and re-test?
> >> >
> >> > Thats looks correct! Thanks!
> >> >
> >> > Here is a patch with the regexp fix.
> >>
> >> That's great. One small change, though. This only allows for a single
> >> space between "import" and "static" so if someone were to put in two
> >> it wouldn't work. I actually did the same thing in an earlier version
> >> and it caused a problem. Since then I went to =(1+ space)=
> >> everywhere. Could you also move the part that you're adding down to
> >> the next line. It's not that the line is too long, but it keeps it to
> >> one thing per line.
> >>
> >> The commit message is fine, but the first line shouldn't end in a period.
> >>
> >> ref: https://orgmode.org/worg/org-contribute.html#commit-messages

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

2021-01-16 Thread John Herrlin


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 imports in regex

* lisp/ob-java.el (org-babel-java--imports-re): Include static imports
in Java import regex.

TINYCHANGE
---
 lisp/ob-java.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index f70a50192..c9698bd72 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -87,6 +87,7 @@ like javac -verbose."
 	 (0+ space) ?\; line-end)
   "Regexp for the package statement.")
 (defconst org-babel-java--imports-re (rx line-start (0+ space) "import"
+ (opt (1+ space) "static")
 	 (1+ space) (group (1+ (in alnum ?_ ?.))) ; capture the fully qualified class name
 	 (0+ space) ?\; line-end)
   "Regexp for import statements.")
-- 
2.30.0



ian martins  writes:

> 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
>> > > imports, which you fixed in the first chunk of your patch. I don't
>> > > think the rest of the change is necessary. Could you revert the other
>> > > chunks and re-test?
>> >
>> > Thats looks correct! Thanks!
>> >
>> > Here is a patch with the regexp fix.
>>
>> That's great. One small change, though. This only allows for a single
>> space between "import" and "static" so if someone were to put in two
>> it wouldn't work. I actually did the same thing in an earlier version
>> and it caused a problem. Since then I went to =(1+ space)=
>> everywhere. Could you also move the part that you're adding down to
>> the next line. It's not that the line is too long, but it keeps it to
>> one thing per line.
>>
>> The commit message is fine, but the first line shouldn't end in a period.
>>
>> ref: https://orgmode.org/worg/org-contribute.html#commit-messages

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

2021-01-16 Thread ian martins

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
> > > imports, which you fixed in the first chunk of your patch. I don't
> > > think the rest of the change is necessary. Could you revert the other
> > > chunks and re-test?
> >
> > Thats looks correct! Thanks!
> >
> > Here is a patch with the regexp fix.
>
> That's great. One small change, though. This only allows for a single space 
> between "import" and "static" so if someone were to put in two it wouldn't 
> work. I actually did the same thing in an earlier version and it caused a 
> problem. Since then I went to =(1+ space)= everywhere. Could you also move 
> the part that you're adding down to the next line. It's not that the line is 
> too long, but it keeps it to one thing per line.
>
> The commit message is fine, but the first line shouldn't end in a period.
>
> ref: https://orgmode.org/worg/org-contribute.html#commit-messages

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

2021-01-12 Thread ian martins

 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 is necessary. Could you revert the other
> > chunks and re-test?
>
> Thats looks correct! Thanks!
>
> Here is a patch with the regexp fix.

That's great. One small change, though. This only allows for a single space
between "import" and "static" so if someone were to put in two it wouldn't
work. I actually did the same thing in an earlier version and it caused a
problem. Since then I went to =(1+ space)= everywhere. Could you also move
the part that you're adding down to the next line. It's not that the line
is too long, but it keeps it to one thing per line.

The commit message is fine, but the first line shouldn't end in a period.

ref: https://orgmode.org/worg/org-contribute.html#commit-messages

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

2021-01-10 Thread John Herrlin


ian martins  writes:

> 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 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 is necessary. Could you revert the other
> chunks and re-test?

Thats looks correct! Thanks!

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): Include static imports in Java import regex.

TINYCHANGE
---
 lisp/ob-java.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ob-java.el b/lisp/ob-java.el
index f70a50192..05f591ee3 100644
--- a/lisp/ob-java.el
+++ b/lisp/ob-java.el
@@ -86,7 +86,7 @@ like javac -verbose."
 	 (1+ space) (group (1+ (in alnum ?_ ?.))) ; capture the package name
 	 (0+ space) ?\; line-end)
   "Regexp for the package statement.")
-(defconst org-babel-java--imports-re (rx line-start (0+ space) "import"
+(defconst org-babel-java--imports-re (rx line-start (0+ space) "import" (opt space "static")
 	 (1+ space) (group (1+ (in alnum ?_ ?.))) ; capture the fully qualified class name
 	 (0+ space) ?\; line-end)
   "Regexp for import statements.")
-- 
2.30.0

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

2021-01-09 Thread ian martins

> 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

2021-01-09 Thread ian martins

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 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 is necessary. Could you revert the other
chunks and re-test?

This works for me using master, and your patch produces nearly the
same code (only import order differs):

#+begin_src java :results output :imports java.util.HashMap
  import java.util.Map;

  Map hash = new HashMap<>();
  hash.put("one", 1);
  hash.put("two", 2);
  System.out.println(hash);
#+end_src

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

2021-01-08 Thread Dr. Arne Babenhauserheide


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 
> -classpath ./rxjava-1.3.8.jar:src:. :imports rx.Observable rx.Subscriber
>   :END:
>
>   #+BEGIN_SRC java
> import static rx.Observable.empty;
> import static rx.Observable.just;
> import static rx.Observable.range;
>
> Observable
> .range(5, 5)
> .flatMap(x -> just(x * 2))
> .flatMap(x -> (x != 10) ? just(x) : empty())
> .subscribe(System.out::println);
>   #+END_SRC

> What do you think about it?

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.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature

Re: [PATCH] ob-java

2020-12-13 Thread Bastien

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
>> >> >
>> >> > java.lang.NoClassDefFoundError
>> >>
>
> This should be fixed with 93087e0b3a. Thanks for reporting, and sorry
> I missed your first email. I found it. It went to spam for some
> reason.

FWIW I'm closing this so that the ob-java thread does not appear on
updates.orgmode.org anymore.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-java

2020-11-17 Thread ian martins

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
> >> >
> >> > java.lang.NoClassDefFoundError
> >>

This should be fixed with 93087e0b3a. Thanks for reporting, and sorry
I missed your first email. I found it. It went to spam for some
reason.

Also I added two sections to the doc: one that explains the current
defaults and tells how to change them [1], and another that explains
where source and class files go [2].

[1] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#orgb4194fe
[2] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org0948fdf

Re: [PATCH] ob-java

2020-11-14 Thread Jarmo Hurri



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 I took a look at ob-java.el. Unless
>> header argument dir is set, java is run in a temporary directory. So I
>> can get around this problem by setting header argument
>>
>> :dir "."
>>
>> which is nice, at least as a workaround.
>
> You're right that this is a change. I will revert the default
> behaviour. in the meantime you could do something like
>
> (setq org-babel-default-header-args:java
>   (cons '(:dir . ".")
> org-babel-default-header-args:java))
>
> in your init file after loading org to fix it everywhere.

Thanks a bunch, will do.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

2020-11-14 Thread ian martins

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
> >
> > java.lang.NoClassDefFoundError
>
> I had some extra time today, so I took a look at ob-java.el. Unless
> header argument dir is set, java is run in a temporary directory. So I
> can get around this problem by setting header argument
>
> :dir "."
>
> which is nice, at least as a workaround.

It looks like you quoted a previous email there but I never saw it.

You're right that this is a change. I will revert the default
behaviour. in the meantime you could do something like

(setq org-babel-default-header-args:java
  (cons '(:dir . ".")
org-babel-default-header-args:java))

in your init file after loading org to fix it everywhere.

> I am not sure what the default behaviour should be. At the moment,
> though, I do not think temporary dir is a good default, because by
> default the program will then the "miss" all opened (data) files as
> well. Right?

I agree we should not change the default behavior, but I'm not sure
about data files. The run directory shouldn't change, just the place
where the files are written. when I run this block the java and
classfiles are written to my babel temp dir but it prints out the path
of the org file.

#+begin_src java :results output silent
System.out.println( System.getProperty("user.dir"));
#+end_src

> Perhaps all babel languages have a common policy here that I am not
> aware of.

I've not seen it documented, but the other babel languages I've used
write to the temp dir. Java is the only one I'm aware of that
defaulted to writing to the current directory.

> But in any case it looks to me that the behaviour has changed now, so if
> it is changed in the stable branch (I am running master), I think it
> should be documented clearly (as an incompatible change). Perhaps it
> already is documented like that.

Yes, you're right that is a change. The current behavior is documented
in ob-doc-java [1], but it isn't called out as a change in behavior.
This is because I didn't notice it as a change, or I'd have not done
it. These changes happened in part because I wrote ob-java in a
circuitous way. I first wrote ob-haxe (for the language haxe) based on
ob-C and ob-python and then made ob-java from it. When I wrote ob-haxe
I wasn't thinking about maintaining ob-java behaviour, and it wasn't
documented, and there weren't tests, so when I had a new ob-java it
wasn't easy to see what might have changed. It is very helpful that
you tested your existing source blocks and investigated changes.
Thanks for reporting. I'll bring back the old default behavior.

[1] 
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-java.html#org932f876

Re: [PATCH] ob-java

2020-11-14 Thread Jarmo Hurri

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 look at ob-java.el. Unless
header argument dir is set, java is run in a temporary directory. So I
can get around this problem by setting header argument

:dir "."

which is nice, at least as a workaround.

I am not sure what the default behaviour should be. At the moment,
though, I do not think temporary dir is a good default, because by
default the program will then the "miss" all opened (data) files as
well. Right?

Perhaps all babel languages have a common policy here that I am not
aware of.

But in any case it looks to me that the behaviour has changed now, so if
it is changed in the stable branch (I am running master), I think it
should be documented clearly (as an incompatible change). Perhaps it
already is documented like that.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

2020-11-10 Thread Bastien

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 a specific
Org feature, should mention the Org version it relates to, rather than
a timestamp.  As an additional info, the timestamp is good, but not
enough.

Let's try to follow this convention from now on.

-- 
 Bastien

Re: [PATCH] ob-java

2020-11-10 Thread ian martins

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
>   #+begin_src java :classname Foo :results output
> public class Foo
> {
>   public static void main(String[] args)
>   {
> System.out.print("hello, world");
>   }
> }
>   #+end_src
>
>   #+RESULTS:
>   : hello, world
>
> * this one does not (space after word =main=)
>   #+begin_src java :classname Foo2 :results output
> public class Foo2
> {
>   public static void main (String[] args)
>   {
> System.out.print("hello, world");
>   }
> }
>   #+end_src
> # -
>
> All the best,
>
> Jarmo
>
>
>

Re: [PATCH] ob-java

2020-11-09 Thread Jarmo Hurri

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:

https://stackoverflow.com/questions/17973970/how-to-solve-java-lang-noclassdeffounderror

I have attached a minimal example demontrating the problem.

1. You can see the error if you evaluate the code in the org
   file. Please observer that the submodule java file has been compiled
   to a class just fine.
   
2. If you untangle the org file, and then run

   javac LoadError.java
   java LoadError

   you should see that there is no problem with the code.

This issue is critical for me, because a lot of code I have depends on
other code (in git submodules).

Can you please tell me how this proceeds? (I may have to roll back to an
earlier org version soon.)

All the best,

Jarmo



load-error.tar.gz
Description: load error demo

Re: [PATCH] ob-java

2020-11-09 Thread Jarmo Hurri



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 main(String[] args)
  {
System.out.print("hello, world");
  }
}
  #+end_src

  #+RESULTS:
  : hello, world

* this one does not (space after word =main=)
  #+begin_src java :classname Foo2 :results output
public class Foo2
{
  public static void main (String[] args)
  {
System.out.print("hello, world");
  }
}
  #+end_src
# -

All the best,

Jarmo

Re: [PATCH] ob-java

2020-11-06 Thread ian martins

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 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 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.)
>
> > Are you using the latest?
>
> Yes.
>
> > Were there any issues when you updated?
>
> At some point I was using the latest at that time, and my org java stuff
> broke in the middle of a presentation during class. I have not had the
> time to check whether the very latest solves these issues. I will start
> preparing some new material now, and will let you know if anything weird
> happens.
>
> I greatly appreciate the effort you are putting into this package.
>
> All the best, and stay safe.
>
> Jarmo
>
>
>

Re: [PATCH] ob-java

2020-11-05 Thread Jarmo Hurri

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 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.)

> Are you using the latest? 

Yes.

> Were there any issues when you updated?

At some point I was using the latest at that time, and my org java stuff
broke in the middle of a presentation during class. I have not had the
time to check whether the very latest solves these issues. I will start
preparing some new material now, and will let you know if anything weird
happens.

I greatly appreciate the effort you are putting into this package.

All the best, and stay safe.

Jarmo

Re: [PATCH] ob-java

2020-11-05 Thread ian martins

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 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

2020-11-05 Thread Jarmo Hurri



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

2020-10-31 Thread ian martins

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 check in the filename

At first I thought I wrote ob-java by rule 1.  I didn't start from the old
ob-java, and I replaced the entire file.  The patch shows only 10 random
lines of over 400 matched the original ob-java.  If we don't count the
lines that also match ob-template.el, there are only 5.

When you said I didn't write it I thought rule 2 was the next most
reasonable, so I made the authors those that wrote the code that I
referenced.  But after thinking about it more it can't be this.  Adding
languages to babel isn't documented well enough for anyone to do it without
looking at an existing implementation, so going by rule 2 all languages
would be authored by whoever wrote the first one, and they're not.

I'm not sure but I think you'd say I wrote ob-haxe, the ob-haxe tests, the
ob-java tests, and the ob-java docs, but not ob-java.  These match up with
rule 3.  I don't think rule 3 is the one anyone would pick from the list,
but maybe most would subconsciously use it as a heuristic for rule 1, since
rule 1 is hard to establish.  I think the change in authorship is clear for
ob-java because it was replaced in one patch, usually changes are
incremental.  Each file is The Ship of Theseus.  Even if we took the
trouble to determine how much any person wrote, it is difficult to decide
for oneself let alone agree on the amount of change required to establish
new authorship.

But rule 3 doesn't work if a file is rewritten.  If Dostoevsky checks in
the text of "Crime and Punishment" as book.txt, and then Dr. Seuss replaces
the content with "The Cat in the Hat," we'd have to say Dostoevsky wrote
"The Cat in the Hat."

So I think either you didn't notice that I'd replaced the file, or you
considered the lines that matched sufficient for continuity, or you're
thinking about authorship in a way I haven't guessed.  Could you clarify?

On Wed, Oct 28, 2020 at 5:13 AM Bastien  wrote:

> 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 doing so!
>
> --
>  Bastien
>

Re: [PATCH] ob-java

2020-10-28 Thread Bastien

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 doing so!

-- 
 Bastien

Re: [PATCH] ob-java

2020-10-25 Thread ian martins

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

2020-10-24 Thread Kyle Meyer

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

2020-10-24 Thread ian martins

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 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 with tramp
>
> Thanks for all the work you've put into this.  As someone that knows
> nothing about Java and hasn't touched ob-java, that sounds good :)
>
> I see this got a "feel free to install" elsewhere in this thread, so
> here are a few scattered and superficial remarks.
>
> > Subject: [PATCH] ob-java.el: Add support for variables, return values,
> tramp
> >
> > * lisp/ob-java.el: Add support for variables and return values.  Write
> > tempfiles to the org-babel-temporary-directory.  Make package, class,
> > and main method definitions optional.
> >
> > * testing/lisp/test-ob-java.el: Add tests.
>
> I think the changelog entry should technically have
> per-function/variable entries.
>
> More importantly from my perspective, it would be great for the message
> to explain what the current state is, why it is problematic, and what
> the patch's solution is.  For this patch, that'd probably be much too
> large, which is a good indication that it'd be better presented as a
> split up series.  But, at this point, that's not something I think you
> should do for this patch, especially given there doesn't seem to be a
> java/ob-java user with the bandwidth to provide a detailed review.
>
> > -(defcustom org-babel-java-command "java"
> > -  "Name of the java command.
> > -May be either a command in the path, like java
> > -or an absolute path name, like /usr/local/bin/java
> > -parameters may be used, like java -verbose"
> > +(defvar org-babel-default-header-args:java '()
> > +  "Default header args for java source blocks.")
> > +
> > +(defconst org-babel-header-args:java '((imports . :any))
> > +  "Java-specific header arguments.")
> > +
> > +(defvar org-babel-java-compiler-command "javac"
> > +  "Name of the command to execute the java compiler.")
> > +
> > +(defvar org-babel-java-runtime-command "java"
> > +  "Name of the command to run the java runtime.")
>
> Rather than dropping org-babel-java-command and org-babel-java-compiler
> entirely, can you make this change in a way that doesn't break for users
> that have already customized org-babel-java-command?
>
> Also, shouldn't org-babel-java-compiler-command and
> org-babel-java-runtime-command be user options rather than defvars?
>
> In general, are the changes here expected to be backwards compatible for
> current ob-java users?
>
> > +(defcustom org-babel-java-hline-to "null"
> > +  "Replace hlines in incoming tables with this when translating to
> java."
> >:group 'org-babel
> > -  :version "24.3"
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> >:type 'string)
> >
> > -(defcustom org-babel-java-compiler "javac"
> > -  "Name of the java compiler.
> > -May be either a command in the path, like javac
> > -or an absolute path name, like /usr/local/bin/javac
> > -parameters may be used, like javac -verbose"
> > +(defcustom org-babel-java-null-to 'hline
> > +  "Replace `null' in java tables with this before returning."
> >:group 'org-babel
> > -  :version "24.3"
> > -  :type 'string)
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> > +  :type 'symbol)
>
> For both these options, s/9.3/9.5/.  And please drop :version, letting
> it be handled by customize-package-emacs-version-alist.
>
> >  (defun org-babel-execute:java (body params)
> > -  (let* ((classname (or (cdr (assq :classname params))
> > - (error
> > -  "Can't compile a java block without a
> classname")))
> > -  (packagename (file-name-directory classname))
> > -  (src-file (concat classname ".java"))
> > +  "Execute a java source block with BODY code and PARAMS params."
> > +  (let* (;; if true, run from babel temp directory
> > + (run-from-temp (not (assq :dir params)))
> > + ;; class and package
> > + (fullclassname (or (cdr (assq :classname params))
> > +(org-babel-java-find-classname body)))
> > + ;; just the class name
> > + (classname (car (last (split-string fullclassname "\\."
> > + ;; just the package name
> > + (packagename (if (seq-contains fullclassname ?.)
>
> Please avoid seq- for compatibility with older versions of Emacs.
>
> > +(defun org-babel-java-evaluate (cmd result-type result-params
> result-file)
> > +  "Evaluate using an external java process.
> > +CMD the command to execute.
> > +
> > +If RESULT-TYPE equals 'output

Re: [PATCH] ob-java

2020-10-24 Thread ian martins

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
wouldn't make sense since they may not have heard of haxe, and they may not
like my code or want their names on it. I didn't really think about the
author of the new ob-java, since it came directly from ob-haxe.

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.

On Sat, Oct 24, 2020 at 7:58 AM Bastien  wrote:

> 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.
>
> Thanks,
>
> --
>  Bastien
>

Re: [PATCH] ob-java

2020-10-24 Thread Kyle Meyer

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 with tramp

Thanks for all the work you've put into this.  As someone that knows
nothing about Java and hasn't touched ob-java, that sounds good :)

I see this got a "feel free to install" elsewhere in this thread, so
here are a few scattered and superficial remarks.

> Subject: [PATCH] ob-java.el: Add support for variables, return values, tramp
>
> * lisp/ob-java.el: Add support for variables and return values.  Write
> tempfiles to the org-babel-temporary-directory.  Make package, class,
> and main method definitions optional.
>
> * testing/lisp/test-ob-java.el: Add tests.

I think the changelog entry should technically have
per-function/variable entries.

More importantly from my perspective, it would be great for the message
to explain what the current state is, why it is problematic, and what
the patch's solution is.  For this patch, that'd probably be much too
large, which is a good indication that it'd be better presented as a
split up series.  But, at this point, that's not something I think you
should do for this patch, especially given there doesn't seem to be a
java/ob-java user with the bandwidth to provide a detailed review.

> -(defcustom org-babel-java-command "java"
> -  "Name of the java command.
> -May be either a command in the path, like java
> -or an absolute path name, like /usr/local/bin/java
> -parameters may be used, like java -verbose"
> +(defvar org-babel-default-header-args:java '()
> +  "Default header args for java source blocks.")
> +
> +(defconst org-babel-header-args:java '((imports . :any))
> +  "Java-specific header arguments.")
> +
> +(defvar org-babel-java-compiler-command "javac"
> +  "Name of the command to execute the java compiler.")
> +
> +(defvar org-babel-java-runtime-command "java"
> +  "Name of the command to run the java runtime.")

Rather than dropping org-babel-java-command and org-babel-java-compiler
entirely, can you make this change in a way that doesn't break for users
that have already customized org-babel-java-command?

Also, shouldn't org-babel-java-compiler-command and
org-babel-java-runtime-command be user options rather than defvars?

In general, are the changes here expected to be backwards compatible for
current ob-java users?

> +(defcustom org-babel-java-hline-to "null"
> +  "Replace hlines in incoming tables with this when translating to java."
>:group 'org-babel
> -  :version "24.3"
> +  :version "25.2"
> +  :package-version '(Org . "9.3")
>:type 'string)
>  
> -(defcustom org-babel-java-compiler "javac"
> -  "Name of the java compiler.
> -May be either a command in the path, like javac
> -or an absolute path name, like /usr/local/bin/javac
> -parameters may be used, like javac -verbose"
> +(defcustom org-babel-java-null-to 'hline
> +  "Replace `null' in java tables with this before returning."
>:group 'org-babel
> -  :version "24.3"
> -  :type 'string)
> +  :version "25.2"
> +  :package-version '(Org . "9.3")
> +  :type 'symbol)

For both these options, s/9.3/9.5/.  And please drop :version, letting
it be handled by customize-package-emacs-version-alist.

>  (defun org-babel-execute:java (body params)
> -  (let* ((classname (or (cdr (assq :classname params))
> - (error
> -  "Can't compile a java block without a classname")))
> -  (packagename (file-name-directory classname))
> -  (src-file (concat classname ".java"))
> +  "Execute a java source block with BODY code and PARAMS params."
> +  (let* (;; if true, run from babel temp directory
> + (run-from-temp (not (assq :dir params)))
> + ;; class and package
> + (fullclassname (or (cdr (assq :classname params))
> +(org-babel-java-find-classname body)))
> + ;; just the class name
> + (classname (car (last (split-string fullclassname "\\."
> + ;; just the package name
> + (packagename (if (seq-contains fullclassname ?.)

Please avoid seq- for compatibility with older versions of Emacs.

> +(defun org-babel-java-evaluate (cmd result-type result-params result-file)
> +  "Evaluate using an external java process.
> +CMD the command to execute.
> +
> +If RESULT-TYPE equals 'output then return standard output as a
> +string.  If RESULT-TYPE equals 'value then return the value
> +returned by the source block, as elisp.
> +
> +RESULT-PARAMS input params used to format the reponse.
> +
> +RESULT-FILE filename of the tempfile to store the returned value in
> +for 'value RESULT-TYPE.  Not used for 'output RESULT-TYPE."

Convention nit: Prefer `symbol' to 'symbol (e.g., s/'output/`output'/).
I didn't check closely if this applies to other docstrings in this
patch.

> +

Re: [PATCH] ob-java

2020-10-24 Thread Bastien

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.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-java

2020-10-22 Thread John Herrlin



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 allow
> non-public classes.
>
> Thanks again for testing, debugging, and reporting.

It's been a pleasure!

>
> On Wed, Oct 21, 2020 at 9:54 AM John Herrlin  wrote:
>
>>
>> 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 already be done. imports can be added to the headers,
>> and
>> > babel allows file-wide headers, so you could add a =#+HEADER: :import
>> > rx.Observable= line to the file and all source blocks would get it.  it's
>> > slightly different in that =org-babel-java--import-maybe= skips imports
>> > that it thinks aren't needed. also if there are any non-java source
>> blocks
>> > in the same file, these imports could be added to them which would be
>> bad,
>> > so when mixing multiple languages in the same file this wouldn't be an
>> > option.
>>
>> Thanks for pointing that out! It work just fine!
>>
>> >
>> > NIT
>> >> Some spacing when writing =public static...=
>> >>
>> >
>> > Thanks for fixing the spacing. I don't think I can give you credit for
>> the
>> > patch, though, without leaving it out until ob-java is accepted.
>>
>> I dont need any credits, the important part is the result!
>>
>> I have made a couple of more runs and I cant find anything that doesnt
>> work!
>>
>> >
>> > On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:
>> >
>> >>
>> >> 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();},
>> >>  () ->{ System.out.println("Ending
>> >> stream"); });
>> >> #+END_SRC
>> >>
>> >> from the ones I posted yesterday is tremendous!
>> >>
>> >> I am not very experienced with Emacs lisp but I think it's pretty easy
>> >> to understand how things works and follow the code. The comments are
>> >> also of good help. I really appreciate the work you have done!
>> >>
>> >>
>> >> 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.
>> >>
>> >>
>> >> NIT
>> >>
>> >> Some spacing when writing =public static...=
>> >>
>> >>#+BEGIN_SRC diff
>> >>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
>> >>  index 94c3f69cf..4f3904871 100644
>> >>  --- a/lisp/ob-java.el
>> >>  +++ b/lisp/ob-java.el
>> >>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the
>> result."
>> >> (org-babel-java--move-past org-babel-java--class-re)
>> >> (insert "\npublic static void main(String[] args) {
>> >>   System.out.print(\"success\");
>> >>  -}\n\n"))
>> >>  +}\n\n"))
>> >>
>> >>   ;; special handling to return value
>> >>   (when (eq result-type 'value)
>> >>#+END_SRC
>> >>
>> >>
>> >>
>> >> ian martins  writes:
>> >>
>> >> > 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 methods and it'll compile without error?
>> >> >
>> >> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin 
>> wrote:
>> >> >
>> >> >>
>> >> >> 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
>> >> >>#+BEGIN_SRC java :results output code
>> >> >>  import rx.Observable;
>> >> >>  public class Main {
>> >> >>  public static void main(String[] args) {
>> >> >>  Observable.range(5, 5)
>> >> >>  .subscribe(System.out::println);
>> >> >>  }
>> >> >>  }
>> >> >>#+END_SRC
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ian martins  writes:
>> >> >>
>> >> >> > I noticed that the tests didn't run with "make

Re: [PATCH] ob-java

2020-10-22 Thread ian martins

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 AM John Herrlin  wrote:

>
> 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 already be done. imports can be added to the headers,
> and
> > babel allows file-wide headers, so you could add a =#+HEADER: :import
> > rx.Observable= line to the file and all source blocks would get it.  it's
> > slightly different in that =org-babel-java--import-maybe= skips imports
> > that it thinks aren't needed. also if there are any non-java source
> blocks
> > in the same file, these imports could be added to them which would be
> bad,
> > so when mixing multiple languages in the same file this wouldn't be an
> > option.
>
> Thanks for pointing that out! It work just fine!
>
> >
> > NIT
> >> Some spacing when writing =public static...=
> >>
> >
> > Thanks for fixing the spacing. I don't think I can give you credit for
> the
> > patch, though, without leaving it out until ob-java is accepted.
>
> I dont need any credits, the important part is the result!
>
> I have made a couple of more runs and I cant find anything that doesnt
> work!
>
> >
> > On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:
> >
> >>
> >> 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();},
> >>  () ->{ System.out.println("Ending
> >> stream"); });
> >> #+END_SRC
> >>
> >> from the ones I posted yesterday is tremendous!
> >>
> >> I am not very experienced with Emacs lisp but I think it's pretty easy
> >> to understand how things works and follow the code. The comments are
> >> also of good help. I really appreciate the work you have done!
> >>
> >>
> >> 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.
> >>
> >>
> >> NIT
> >>
> >> Some spacing when writing =public static...=
> >>
> >>#+BEGIN_SRC diff
> >>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
> >>  index 94c3f69cf..4f3904871 100644
> >>  --- a/lisp/ob-java.el
> >>  +++ b/lisp/ob-java.el
> >>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the
> result."
> >> (org-babel-java--move-past org-babel-java--class-re)
> >> (insert "\npublic static void main(String[] args) {
> >>   System.out.print(\"success\");
> >>  -}\n\n"))
> >>  +}\n\n"))
> >>
> >>   ;; special handling to return value
> >>   (when (eq result-type 'value)
> >>#+END_SRC
> >>
> >>
> >>
> >> ian martins  writes:
> >>
> >> > 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 methods and it'll compile without error?
> >> >
> >> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin 
> wrote:
> >> >
> >> >>
> >> >> 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
> >> >>#+BEGIN_SRC java :results output code
> >> >>  import rx.Observable;
> >> >>  public class Main {
> >> >>  public static void main(String[] args) {
> >> >>  Observable.range(5, 5)
> >> >>  .subscribe(System.out::println);
> >> >>  }
> >> >>  }
> >> >>#+END_SRC
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> ian martins  writes:
> >> >>
> >> >> > 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

Re: [PATCH] ob-java

2020-10-21 Thread John Herrlin



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 already be done. imports can be added to the headers, and
> babel allows file-wide headers, so you could add a =#+HEADER: :import
> rx.Observable= line to the file and all source blocks would get it.  it's
> slightly different in that =org-babel-java--import-maybe= skips imports
> that it thinks aren't needed. also if there are any non-java source blocks
> in the same file, these imports could be added to them which would be bad,
> so when mixing multiple languages in the same file this wouldn't be an
> option.

Thanks for pointing that out! It work just fine!

>
> NIT
>> Some spacing when writing =public static...=
>>
>
> Thanks for fixing the spacing. I don't think I can give you credit for the
> patch, though, without leaving it out until ob-java is accepted.

I dont need any credits, the important part is the result!

I have made a couple of more runs and I cant find anything that doesnt
work!

>
> On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:
>
>>
>> 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();},
>>  () ->{ System.out.println("Ending
>> stream"); });
>> #+END_SRC
>>
>> from the ones I posted yesterday is tremendous!
>>
>> I am not very experienced with Emacs lisp but I think it's pretty easy
>> to understand how things works and follow the code. The comments are
>> also of good help. I really appreciate the work you have done!
>>
>>
>> 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.
>>
>>
>> NIT
>>
>> Some spacing when writing =public static...=
>>
>>#+BEGIN_SRC diff
>>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
>>  index 94c3f69cf..4f3904871 100644
>>  --- a/lisp/ob-java.el
>>  +++ b/lisp/ob-java.el
>>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the result."
>> (org-babel-java--move-past org-babel-java--class-re)
>> (insert "\npublic static void main(String[] args) {
>>   System.out.print(\"success\");
>>  -}\n\n"))
>>  +}\n\n"))
>>
>>   ;; special handling to return value
>>   (when (eq result-type 'value)
>>#+END_SRC
>>
>>
>>
>> ian martins  writes:
>>
>> > 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 methods and it'll compile without error?
>> >
>> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:
>> >
>> >>
>> >> 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
>> >>#+BEGIN_SRC java :results output code
>> >>  import rx.Observable;
>> >>  public class Main {
>> >>  public static void main(String[] args) {
>> >>  Observable.range(5, 5)
>> >>  .subscribe(System.out::println);
>> >>  }
>> >>  }
>> >>#+END_SRC
>> >>
>> >>
>> >>
>> >>
>> >> ian martins  writes:
>> >>
>> >> > 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
>> 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
>> >> >> - 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
>> >> >>
>> >> >> * Examples
>> >> >> **

Re: [PATCH] ob-java

2020-10-21 Thread ian martins

>
> 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 added to the headers, and
babel allows file-wide headers, so you could add a =#+HEADER: :import
rx.Observable= line to the file and all source blocks would get it.  it's
slightly different in that =org-babel-java--import-maybe= skips imports
that it thinks aren't needed. also if there are any non-java source blocks
in the same file, these imports could be added to them which would be bad,
so when mixing multiple languages in the same file this wouldn't be an
option.

NIT
> Some spacing when writing =public static...=
>

Thanks for fixing the spacing. I don't think I can give you credit for the
patch, though, without leaving it out until ob-java is accepted.

On Wed, Oct 21, 2020 at 1:59 AM John Herrlin  wrote:

>
> 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();},
>  () ->{ System.out.println("Ending
> stream"); });
> #+END_SRC
>
> from the ones I posted yesterday is tremendous!
>
> I am not very experienced with Emacs lisp but I think it's pretty easy
> to understand how things works and follow the code. The comments are
> also of good help. I really appreciate the work you have done!
>
>
> 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.
>
>
> NIT
>
> Some spacing when writing =public static...=
>
>#+BEGIN_SRC diff
>  diff --git a/lisp/ob-java.el b/lisp/ob-java.el
>  index 94c3f69cf..4f3904871 100644
>  --- a/lisp/ob-java.el
>  +++ b/lisp/ob-java.el
>  @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the result."
> (org-babel-java--move-past org-babel-java--class-re)
> (insert "\npublic static void main(String[] args) {
>   System.out.print(\"success\");
>  -}\n\n"))
>  +}\n\n"))
>
>   ;; special handling to return value
>   (when (eq result-type 'value)
>#+END_SRC
>
>
>
> ian martins  writes:
>
> > 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 methods and it'll compile without error?
> >
> > On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:
> >
> >>
> >> 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
> >>#+BEGIN_SRC java :results output code
> >>  import rx.Observable;
> >>  public class Main {
> >>  public static void main(String[] args) {
> >>  Observable.range(5, 5)
> >>  .subscribe(System.out::println);
> >>  }
> >>  }
> >>#+END_SRC
> >>
> >>
> >>
> >>
> >> ian martins  writes:
> >>
> >> > 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
> 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
> >> >> - 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
> >> >>
> >> >> * Examples
> >> >> ** Example 1
> >> >> This outputs "hello."  If class and main definitions aren't given the
> >> >> code block will be wrapped in generic ones.
> >> >>
> >> >> #+begin_src java :results output silent
> >> >>   System.out.print("hello");
> >> >> #+end_src
> >> >>
> >> >> This is exactly equivalent:
> >> >>
> >> >> #+begin_src java :results output silent
> >> >>   public

Re: [PATCH] ob-java

2020-10-21 Thread John Herrlin



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();},
 () ->{ System.out.println("Ending stream"); });
#+END_SRC

from the ones I posted yesterday is tremendous!

I am not very experienced with Emacs lisp but I think it's pretty easy
to understand how things works and follow the code. The comments are
also of good help. I really appreciate the work you have done!


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.


NIT

Some spacing when writing =public static...=

   #+BEGIN_SRC diff
 diff --git a/lisp/ob-java.el b/lisp/ob-java.el
 index 94c3f69cf..4f3904871 100644
 --- a/lisp/ob-java.el
 +++ b/lisp/ob-java.el
 @@ -220,7 +220,7 @@ RESULT-FILE is the temp file to write the result."
(org-babel-java--move-past org-babel-java--class-re)
(insert "\npublic static void main(String[] args) {
  System.out.print(\"success\");
 -}\n\n"))
 +}\n\n"))

  ;; special handling to return value
  (when (eq result-type 'value)
   #+END_SRC



ian martins  writes:

> 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 methods and it'll compile without error?
>
> On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:
>
>>
>> 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
>>#+BEGIN_SRC java :results output code
>>  import rx.Observable;
>>  public class Main {
>>  public static void main(String[] args) {
>>  Observable.range(5, 5)
>>  .subscribe(System.out::println);
>>  }
>>  }
>>#+END_SRC
>>
>>
>>
>>
>> ian martins  writes:
>>
>> > 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 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
>> >> - 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
>> >>
>> >> * Examples
>> >> ** Example 1
>> >> This outputs "hello."  If class and main definitions aren't given the
>> >> code block will be wrapped in generic ones.
>> >>
>> >> #+begin_src java :results output silent
>> >>   System.out.print("hello");
>> >> #+end_src
>> >>
>> >> This is exactly equivalent:
>> >>
>> >> #+begin_src java :results output silent
>> >>   public class Main {
>> >>   public static void main(String[] args) {
>> >>   System.out.print("hello");
>> >>   }
>> >>   }
>> >> #+end_src
>> >>
>> >> ** Example 2
>> >> This also outputs "hello."
>> >>
>> >> #+begin_src java :results value silent
>> >>   return "hello";
>> >> #+end_src
>> >>
>> >> ** Example 3
>> >> This generates the class "Example" in the package "org.orgmode" in the
>> >> current directory.
>> >>
>> >> #+begin_src java :results output silent :classname org.orgmode.Example
>> >> :dir .
>> >>   System.out.print("hello, org-mode");
>> >> #+end_src
>> >>
>> >> ** Example 4
>> >> The "Hey" class defines a static method but no main. C-c C-c on the
>> >> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>> >>
>> >> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>> >> block will write "./org/orgmode/Main.java" and compile and run it.
>> >>
>> >> #+begin_src java :results output silent :dir .
>> >>   package org.orgmode;
>> >>
>> >>   public class Hey {
>> >>   public static String say() {
>> >>   return "hey";
>> >>   }
>> >>   }
>> >> #+end_src
>> >>
>> >> #+begin_src java :results output silent :dir .
>> >>   package org.orgmode;
>> >>
>> >>   public

Re: [PATCH] ob-java

2020-10-20 Thread ian martins

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 methods and it'll compile without error?

On Tue, Oct 20, 2020 at 3:17 PM John Herrlin  wrote:

>
> 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
>#+BEGIN_SRC java :results output code
>  import rx.Observable;
>  public class Main {
>  public static void main(String[] args) {
>  Observable.range(5, 5)
>  .subscribe(System.out::println);
>  }
>  }
>#+END_SRC
>
>
>
>
> ian martins  writes:
>
> > 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 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
> >> - 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
> >>
> >> * Examples
> >> ** Example 1
> >> This outputs "hello."  If class and main definitions aren't given the
> >> code block will be wrapped in generic ones.
> >>
> >> #+begin_src java :results output silent
> >>   System.out.print("hello");
> >> #+end_src
> >>
> >> This is exactly equivalent:
> >>
> >> #+begin_src java :results output silent
> >>   public class Main {
> >>   public static void main(String[] args) {
> >>   System.out.print("hello");
> >>   }
> >>   }
> >> #+end_src
> >>
> >> ** Example 2
> >> This also outputs "hello."
> >>
> >> #+begin_src java :results value silent
> >>   return "hello";
> >> #+end_src
> >>
> >> ** Example 3
> >> This generates the class "Example" in the package "org.orgmode" in the
> >> current directory.
> >>
> >> #+begin_src java :results output silent :classname org.orgmode.Example
> >> :dir .
> >>   System.out.print("hello, org-mode");
> >> #+end_src
> >>
> >> ** Example 4
> >> The "Hey" class defines a static method but no main. C-c C-c on the
> >> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
> >>
> >> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
> >> block will write "./org/orgmode/Main.java" and compile and run it.
> >>
> >> #+begin_src java :results output silent :dir .
> >>   package org.orgmode;
> >>
> >>   public class Hey {
> >>   public static String say() {
> >>   return "hey";
> >>   }
> >>   }
> >> #+end_src
> >>
> >> #+begin_src java :results output silent :dir .
> >>   package org.orgmode;
> >>
> >>   public class Main {
> >>   public static void main(String[] args) {
> >>   System.out.print(Hey.say());
> >>   }
> >>   }
> >> #+end_src
> >>
> >> Instead of C-c C-c, we could have added tangle headers and written the
> >> source files out by tangling.
> >>
> >> ** Example 5
> >> This prints the variable from the header
> >>
> >> #+begin_src java :var msg="hello, org-mode" :results output silent
> >>   System.out.print(msg);
> >> #+end_src
> >>
> >> ** Example 6
> >> This prints "hello, org-mode." The table is provided to the method as a
> >> list of lists.
> >>
> >> #+name: table
> >> | message | hello, org-mode  |
> >>
> >> #+begin_src java :var tbl=table :results output silent
> >>   System.out.print(tbl.get(0).get(1));
> >> #+end_src
> >>
> >> ** Example 7
> >> This example returns a list.
> >>
> >> Note that you're allowed to specify imports without defining the class
> >> or main methods.
> >>
> >> #+begin_src java :results value :exports both
> >>   import java.util.Arrays;
> >>
> >>   return Arrays.asList("message", "hello, org-mode");
> >> #+end_src
> >>
> >> #+RESULTS:
> >> | message | hello, org-mode |
> >>
> >> On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:
> >>
> >>> 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
> >>> ==
> >>> Some examples follow.  See the tests

Re: [PATCH] ob-java

2020-10-20 Thread John Herrlin



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
   #+BEGIN_SRC java :results output code
 import rx.Observable;
 public class Main {
 public static void main(String[] args) {
 Observable.range(5, 5)
 .subscribe(System.out::println);
 }
 }
   #+END_SRC




ian martins  writes:

> 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 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
>> - 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
>>
>> * Examples
>> ** Example 1
>> This outputs "hello."  If class and main definitions aren't given the
>> code block will be wrapped in generic ones.
>>
>> #+begin_src java :results output silent
>>   System.out.print("hello");
>> #+end_src
>>
>> This is exactly equivalent:
>>
>> #+begin_src java :results output silent
>>   public class Main {
>>   public static void main(String[] args) {
>>   System.out.print("hello");
>>   }
>>   }
>> #+end_src
>>
>> ** Example 2
>> This also outputs "hello."
>>
>> #+begin_src java :results value silent
>>   return "hello";
>> #+end_src
>>
>> ** Example 3
>> This generates the class "Example" in the package "org.orgmode" in the
>> current directory.
>>
>> #+begin_src java :results output silent :classname org.orgmode.Example
>> :dir .
>>   System.out.print("hello, org-mode");
>> #+end_src
>>
>> ** Example 4
>> The "Hey" class defines a static method but no main. C-c C-c on the
>> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>>
>> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>> block will write "./org/orgmode/Main.java" and compile and run it.
>>
>> #+begin_src java :results output silent :dir .
>>   package org.orgmode;
>>
>>   public class Hey {
>>   public static String say() {
>>   return "hey";
>>   }
>>   }
>> #+end_src
>>
>> #+begin_src java :results output silent :dir .
>>   package org.orgmode;
>>
>>   public class Main {
>>   public static void main(String[] args) {
>>   System.out.print(Hey.say());
>>   }
>>   }
>> #+end_src
>>
>> Instead of C-c C-c, we could have added tangle headers and written the
>> source files out by tangling.
>>
>> ** Example 5
>> This prints the variable from the header
>>
>> #+begin_src java :var msg="hello, org-mode" :results output silent
>>   System.out.print(msg);
>> #+end_src
>>
>> ** Example 6
>> This prints "hello, org-mode." The table is provided to the method as a
>> list of lists.
>>
>> #+name: table
>> | message | hello, org-mode  |
>>
>> #+begin_src java :var tbl=table :results output silent
>>   System.out.print(tbl.get(0).get(1));
>> #+end_src
>>
>> ** Example 7
>> This example returns a list.
>>
>> Note that you're allowed to specify imports without defining the class
>> or main methods.
>>
>> #+begin_src java :results value :exports both
>>   import java.util.Arrays;
>>
>>   return Arrays.asList("message", "hello, org-mode");
>> #+end_src
>>
>> #+RESULTS:
>> | message | hello, org-mode |
>>
>> On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:
>>
>>> 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
>>> ==
>>> Some examples follow.  See the tests for more examples.  I'll write
>>> proper docs after review.
>>>
>>> 2.1 Example 1
>>> ~
>>>
>>>   This outputs "hello."  If class and main definitions aren't given the
>>>   code block will be wrapped in generic ones.
>>>
>>>   ,
>>>   | System.out.print("hello");
>>>   `
>>>
>>>   This is exactly equivalent:
>>>
>>>   ,
>>>   | public class Main {
>>>   | public static void main(String[] args) {
>>>   | System.out.print("hello");
>>>   | }
>>>   | }
>>>   `
>>>
>>>
>>> 2.2 Example 2
>>> ~
>>>
>>>   This also outputs "hello."
>>>
>>>   ,
>>>   | return "hello";
>>>   `
>>>
>>>
>>> 2.3 Example 3
>>> ~
>>>
>>>   This

Re: [PATCH] ob-java

2020-10-20 Thread John Herrlin



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 ./rxjava-1.3.8.jar
   #+BEGIN_SRC java :results output code
 import rx.Observable;
 class Main {
 public static void main(String[] args) {
 Observable.range(5, 5)
 .subscribe(System.out::println);
 }
 }
   #+END_SRC

The error message I get is the following:

   #+BEGIN_SRC text
 /home/john/git/org-files/programming/src/Main.java:5: error: class Main is 
already defined in package unnamed package
 class Main {
 ^
 /home/john/git/org-files/programming/src/Main.java:6: error: Illegal 
static declaration in inner class Main.Main
 public static void main(String[] args) {
 ^
 modifier 'static' is only allowed in constant variable declarations
 2 errors
   #+END_SRC


Best regards
John


ian martins  writes:

> 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 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
>> - 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
>>
>> * Examples
>> ** Example 1
>> This outputs "hello."  If class and main definitions aren't given the
>> code block will be wrapped in generic ones.
>>
>> #+begin_src java :results output silent
>>   System.out.print("hello");
>> #+end_src
>>
>> This is exactly equivalent:
>>
>> #+begin_src java :results output silent
>>   public class Main {
>>   public static void main(String[] args) {
>>   System.out.print("hello");
>>   }
>>   }
>> #+end_src
>>
>> ** Example 2
>> This also outputs "hello."
>>
>> #+begin_src java :results value silent
>>   return "hello";
>> #+end_src
>>
>> ** Example 3
>> This generates the class "Example" in the package "org.orgmode" in the
>> current directory.
>>
>> #+begin_src java :results output silent :classname org.orgmode.Example
>> :dir .
>>   System.out.print("hello, org-mode");
>> #+end_src
>>
>> ** Example 4
>> The "Hey" class defines a static method but no main. C-c C-c on the
>> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>>
>> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>> block will write "./org/orgmode/Main.java" and compile and run it.
>>
>> #+begin_src java :results output silent :dir .
>>   package org.orgmode;
>>
>>   public class Hey {
>>   public static String say() {
>>   return "hey";
>>   }
>>   }
>> #+end_src
>>
>> #+begin_src java :results output silent :dir .
>>   package org.orgmode;
>>
>>   public class Main {
>>   public static void main(String[] args) {
>>   System.out.print(Hey.say());
>>   }
>>   }
>> #+end_src
>>
>> Instead of C-c C-c, we could have added tangle headers and written the
>> source files out by tangling.
>>
>> ** Example 5
>> This prints the variable from the header
>>
>> #+begin_src java :var msg="hello, org-mode" :results output silent
>>   System.out.print(msg);
>> #+end_src
>>
>> ** Example 6
>> This prints "hello, org-mode." The table is provided to the method as a
>> list of lists.
>>
>> #+name: table
>> | message | hello, org-mode  |
>>
>> #+begin_src java :var tbl=table :results output silent
>>   System.out.print(tbl.get(0).get(1));
>> #+end_src
>>
>> ** Example 7
>> This example returns a list.
>>
>> Note that you're allowed to specify imports without defining the class
>> or main methods.
>>
>> #+begin_src java :results value :exports both
>>   import java.util.Arrays;
>>
>>   return Arrays.asList("message", "hello, org-mode");
>> #+end_src
>>
>> #+RESULTS:
>> | message | hello, org-mode |
>>
>> On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:
>>
>>> 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
>>> ==
>>> Some examples follow.  See the tests for more examples.  I'll write
>>> proper docs after review.
>>>
>>> 2.1 Example 1
>>> ~
>>>
>>>   This outputs "hello."  If class and main definitions aren't given the
>>>   code block

Re: [PATCH] ob-java

2020-10-09 Thread ian martins

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 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
> - 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
>
> * Examples
> ** Example 1
> This outputs "hello."  If class and main definitions aren't given the
> code block will be wrapped in generic ones.
>
> #+begin_src java :results output silent
>   System.out.print("hello");
> #+end_src
>
> This is exactly equivalent:
>
> #+begin_src java :results output silent
>   public class Main {
>   public static void main(String[] args) {
>   System.out.print("hello");
>   }
>   }
> #+end_src
>
> ** Example 2
> This also outputs "hello."
>
> #+begin_src java :results value silent
>   return "hello";
> #+end_src
>
> ** Example 3
> This generates the class "Example" in the package "org.orgmode" in the
> current directory.
>
> #+begin_src java :results output silent :classname org.orgmode.Example
> :dir .
>   System.out.print("hello, org-mode");
> #+end_src
>
> ** Example 4
> The "Hey" class defines a static method but no main. C-c C-c on the
> "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>
> The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
> block will write "./org/orgmode/Main.java" and compile and run it.
>
> #+begin_src java :results output silent :dir .
>   package org.orgmode;
>
>   public class Hey {
>   public static String say() {
>   return "hey";
>   }
>   }
> #+end_src
>
> #+begin_src java :results output silent :dir .
>   package org.orgmode;
>
>   public class Main {
>   public static void main(String[] args) {
>   System.out.print(Hey.say());
>   }
>   }
> #+end_src
>
> Instead of C-c C-c, we could have added tangle headers and written the
> source files out by tangling.
>
> ** Example 5
> This prints the variable from the header
>
> #+begin_src java :var msg="hello, org-mode" :results output silent
>   System.out.print(msg);
> #+end_src
>
> ** Example 6
> This prints "hello, org-mode." The table is provided to the method as a
> list of lists.
>
> #+name: table
> | message | hello, org-mode  |
>
> #+begin_src java :var tbl=table :results output silent
>   System.out.print(tbl.get(0).get(1));
> #+end_src
>
> ** Example 7
> This example returns a list.
>
> Note that you're allowed to specify imports without defining the class
> or main methods.
>
> #+begin_src java :results value :exports both
>   import java.util.Arrays;
>
>   return Arrays.asList("message", "hello, org-mode");
> #+end_src
>
> #+RESULTS:
> | message | hello, org-mode |
>
> On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:
>
>> 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
>> ==
>> Some examples follow.  See the tests for more examples.  I'll write
>> proper docs after review.
>>
>> 2.1 Example 1
>> ~
>>
>>   This outputs "hello."  If class and main definitions aren't given the
>>   code block will be wrapped in generic ones.
>>
>>   ,
>>   | System.out.print("hello");
>>   `
>>
>>   This is exactly equivalent:
>>
>>   ,
>>   | public class Main {
>>   | public static void main(String[] args) {
>>   | System.out.print("hello");
>>   | }
>>   | }
>>   `
>>
>>
>> 2.2 Example 2
>> ~
>>
>>   This also outputs "hello."
>>
>>   ,
>>   | return "hello";
>>   `
>>
>>
>> 2.3 Example 3
>> ~
>>
>>   This generates the class "Example" in the package "org.orgmode" in the
>>   current directory.
>>
>>   ,
>>   | System.out.print("hello, org-mode");
>>   `
>>
>>
>> 2.4 Example 4
>> ~
>>
>>   The "Hey" class defines a static method but no main. C-c C-c on the
>>   "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>>
>>   The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>>   block will write "./org/orgmode/Main.java" and compile and run it.
>>
>>   ,
>>   | package org.orgmode;
>>   |
>>   | public class Hey {
>>   | public static String say() {
>>   | return "hey";
>>   | }
>>   | }
>>   `
>>
>>   ,
>>   | package org.orgmode;
>>   |
>>   | public class Main {
>>

Re: [PATCH] ob-java

2020-10-05 Thread ian martins

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
- 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

* Examples
** Example 1
This outputs "hello."  If class and main definitions aren't given the
code block will be wrapped in generic ones.

#+begin_src java :results output silent
  System.out.print("hello");
#+end_src

This is exactly equivalent:

#+begin_src java :results output silent
  public class Main {
  public static void main(String[] args) {
  System.out.print("hello");
  }
  }
#+end_src

** Example 2
This also outputs "hello."

#+begin_src java :results value silent
  return "hello";
#+end_src

** Example 3
This generates the class "Example" in the package "org.orgmode" in the
current directory.

#+begin_src java :results output silent :classname org.orgmode.Example :dir
.
  System.out.print("hello, org-mode");
#+end_src

** Example 4
The "Hey" class defines a static method but no main. C-c C-c on the
"Hey" source block will write "./org/orgmode/Hey.java" and compile it.

The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
block will write "./org/orgmode/Main.java" and compile and run it.

#+begin_src java :results output silent :dir .
  package org.orgmode;

  public class Hey {
  public static String say() {
  return "hey";
  }
  }
#+end_src

#+begin_src java :results output silent :dir .
  package org.orgmode;

  public class Main {
  public static void main(String[] args) {
  System.out.print(Hey.say());
  }
  }
#+end_src

Instead of C-c C-c, we could have added tangle headers and written the
source files out by tangling.

** Example 5
This prints the variable from the header

#+begin_src java :var msg="hello, org-mode" :results output silent
  System.out.print(msg);
#+end_src

** Example 6
This prints "hello, org-mode." The table is provided to the method as a
list of lists.

#+name: table
| message | hello, org-mode  |

#+begin_src java :var tbl=table :results output silent
  System.out.print(tbl.get(0).get(1));
#+end_src

** Example 7
This example returns a list.

Note that you're allowed to specify imports without defining the class
or main methods.

#+begin_src java :results value :exports both
  import java.util.Arrays;

  return Arrays.asList("message", "hello, org-mode");
#+end_src

#+RESULTS:
| message | hello, org-mode |

On Mon, Oct 5, 2020 at 8:35 AM ian martins  wrote:

> 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
> ==
> Some examples follow.  See the tests for more examples.  I'll write proper
> docs after review.
>
> 2.1 Example 1
> ~
>
>   This outputs "hello."  If class and main definitions aren't given the
>   code block will be wrapped in generic ones.
>
>   ,
>   | System.out.print("hello");
>   `
>
>   This is exactly equivalent:
>
>   ,
>   | public class Main {
>   | public static void main(String[] args) {
>   | System.out.print("hello");
>   | }
>   | }
>   `
>
>
> 2.2 Example 2
> ~
>
>   This also outputs "hello."
>
>   ,
>   | return "hello";
>   `
>
>
> 2.3 Example 3
> ~
>
>   This generates the class "Example" in the package "org.orgmode" in the
>   current directory.
>
>   ,
>   | System.out.print("hello, org-mode");
>   `
>
>
> 2.4 Example 4
> ~
>
>   The "Hey" class defines a static method but no main. C-c C-c on the
>   "Hey" source block will write "./org/orgmode/Hey.java" and compile it.
>
>   The "Main" class calls the "Hey" class. C-c C-c on the "Main" source
>   block will write "./org/orgmode/Main.java" and compile and run it.
>
>   ,
>   | package org.orgmode;
>   |
>   | public class Hey {
>   | public static String say() {
>   | return "hey";
>   | }
>   | }
>   `
>
>   ,
>   | package org.orgmode;
>   |
>   | public class Main {
>   | public static void main(String[] args) {
>   | System.out.print(Hey.say());
>   | }
>   | }
>   `
>
>   Instead of C-c C-c, we could have added tangle headers and written the
>   source files out by tangling.
>
>
> 2.5 Example 5
> ~
>
>   This prints the variable from the header
>
>   ,
>   | System.out.print(msg);
>   `
>
>
> 2.6 Example 6
> ~
>
>   This prints "hello, org-mode." The table is provided to the method as
>   a list of lists.
>
>

64 matches

Mail list logo