Re: [O] update to ob-clojure.el
On Thu, 2014-04-10 at 10:36 +0200, Oleh wrote: Hi all, I've made an update to ob-clojure.el, which wasn't working for me with the new cider (the required function was removed). I haven't looked into 'nrepl or 'slime options for evaluation, is anyone using them? Eric, should 'nrepl option be removed as obsolete? And maybe 'slime as well? regards, Oleh I'm not sure about removing nrepl and slime, as there may be some still using them, especially nrepl. As long as it is not getting in the way, perhaps at this time it would be better to leave them in? I'm not sure the open-source and/or emacs-org philosophy on this kind of thing. Prior to updating the documentation for Clojure code blocks earlier this year, which was several years old, I did a lot of searching around and came to the conclusion that the slime and swank-clojure functionality was no longer being developed, and the community had moved on to nrepl. CIDER evolved from nrepl, and is the current direction. https://github.com/clojure-emacs/cider The revised documentation is very CIDER-centric: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-clojure.html Regards, Greg
Re: [O] Namespace problem org-mode / Clojure
That's great! A big thanks to Bastien for fixing the elisp, and keeping Clojure code blocks working smoothly. Speaking of org-mode and Clojure... You may be interested in the recent Clojure org-mode postings at the Google group: https://groups.google.com/forum/#!topic/clojure/hWqPXn1_pK4 https://groups.google.com/forum/#!topic/clojure/V8p3Q9UaNYw I'm planning to look at this later. It looks like quite a body of work using org-mode + Clojure. Regards, Greg On Wed, 2014-03-19 at 15:30 +0100, Volker Strobel wrote: A belated, but very big thanks to both of you! It works perfectly now :) Best, Volker
Re: [O] Namespace problem org-mode / Clojure
I installed the update and ran Volker's test code. It works! The namespace is preserved from block-to-block. Thank you Bastien! I experimented with the :session option, however, I am now not sure I understand how it is supposed to work. I believed it would cause the code block to switch namespaces with a unique session name, however, it does not do this. My older system (7.9 org) behaves the same. Regards, Greg On Mon, 2014-03-03 at 21:35 -0500, Soapy Smith wrote: Hi Bastien- I will check it tomorrow and report. Thank you! Regarding TODOs related to Clojure code blocks; where is the best place for them? Greg
Re: [O] Namespace problem org-mode / Clojure
Hi Bastien- I will check it tomorrow and report. Thank you! Regarding TODOs related to Clojure code blocks; where is the best place for them? Greg On Mon, 2014-03-03 at 13:54 +0100, Bastien wrote: Hi Volker and Greg, I hopefully fixed this in master. Can you pull and test? Thanks,
Re: [O] Namespace problem org-mode / Clojure
On Tue, 2014-02-25 at 06:20 -0500, Soapy Smith wrote: I will add this issue to the list of TODOs for Clojure code blocks. One thing I can do quickly is see if the problem exists in version 7.9 org with nrepl (prior to CIDER). I have a machine which still has the old configuration. I will try later today and report. Regards, Greg (alias Soapy Smith) The namespaces worked perfectly on the older machine with org 7.9 and nrepl. The problem is apparently isolated to the newest configuration using CIDER with org 8. Regards, Greg
Re: [O] Namespace problem org-mode / Clojure
I will add this issue to the list of TODOs for Clojure code blocks. One thing I can do quickly is see if the problem exists in version 7.9 org with nrepl (prior to CIDER). I have a machine which still has the old configuration. I will try later today and report. Regards, Greg (alias Soapy Smith) On Tue, 2014-02-25 at 10:22 +0100, Volker Strobel wrote: Hi Soapy, thank you! I feel at ease knowing that you could replicate the behavior, as I was trying to find the error in my settings for a long, long time (and as mentioned before, it did work for some time, and I've no clue why - I've played around with some settings in the init file). And yes, adding an explicit namespace declaration (ns, in-ns) to every code block works, but that's a rather roundabout way (I've many small snippets in the same namespace) and it produces a bit 'unsightly', tangled code. So, I'd be really glad, if this issue could be processed. Best, Volker
Re: [O] Namespace problem org-mode / Clojure
Hi Tom- I'm not yet good at elisp, but looking at the ob-clojure.el file, the header option :package is only associated with slime, not cider? Regards, Greg On Fri, 2014-02-21 at 12:36 -1000, Thomas S. Dye wrote: Aloha Volker, I don't use Clojure, but ob-clojure.el defines a header argument :package. You should be able to do something like: #+header: :package org-works.core to execute code in that name space. hth, Tom
Re: [O] Namespace problem org-mode / Clojure
Hi Volker- I tried the your example code blocks on my system, and I concur with most of the behavior you described. org-babel-execute-buffer does not work, as it comes back with error repl not connected. It did not cause a crash. However, if I add explicit namespace declaration to the 2nd block, it works! This is true even thought the 3rd block does not(???). I was thinking back to why I never encountered this problem, and it is because I have almost always used an explicit namespace declaration at the top of the block. Fortunately, after the first block, you don't have to use the optional parameters, includes etc. In your example (ns environment.my-test) added to subsequent code blocks you wish to execute in the same namespace should be sufficient. I think this should be considered the work-around until someone can explain what is going on, or, even better, can fix this. I'm the person who updated the worg documentation for Clojure code blocks. I'm thinking about adding a list of TODOs at the bottom, as there have been some other requests recently to the function behavior. This issue definitely will go on the list. Hopefully Bastien is monitoring and can comment if this is appropriate to add to the Clojure specific worg page (or should it go somewhere else). Regards, Greg
Re: [O] ob-clojure: presentation of map structures?
On Sun, 2014-02-02 at 01:42 -0500, Phill Wolf wrote:
Floundering among the options, I tried :results value pp. It yielded
this:
: {\Pluto\ 5,\n \Plattsburgh\ 4,\n \Philadelphia\ 3,\n
\Sankt-Peterburg\ 2,\n \Paris\ 1,\n \Peru\ 0}\n
pprint's good intentions are evident, but they collided with a
superior force.
There was a discussion of this at the Clojure google group:
https://groups.google.com/d/msg/clojure/gthjNWfAWKo/aKwuqh2qx68J
The tabularization problem was resolved, but the pp of the map behavior
is not changed. I tried a few permutations of :results options, and did
not get close to the Clojure pprint function.
The org manual says the pp option is This
option currently supports Emacs Lisp, Python, and Ruby. E.g., :results
value pp.
Regards,
Greg
Re: [O] Code block option :results raw does not replace #+RESULTS
On Fri, 2014-01-31 at 18:16 -0500, Nick Dokos wrote: Is this the expected behavior for this option? Yes - raw does not keep track of where the results begin and end and cannot erase the old ones before adding the new ones. Try calling org-babel-remove-result: you'll see that it gets rid of the #+RESULTS: line but it doesn't touch the actual results. Once it has inserted them, they become part of the buffer, outside the jurisdiction of the code block/babel. Nick That makes sense as I don't see the #RESULTS: line repeated. I'm adding that to my notes. Thank you for the explanation! Regards, Greg
Re: [O] Python Code Block error with header option :results output
On Sat, 2014-02-01 at 07:56 +0100, Christian Moe wrote: You should only use return like that in a python code block when you have :results value. To expand briefly on that (since this can be perplexing): The need to use `return' at all when returning the value is a special quirk of Python code blocks, and does not apply to (any?) other languages. As explained on Worg, with `:results value' (the default), Internally, the value is obtained by wrapping the code in a function definition in the external language, and evaluating that function. Therefore, code should be written as if it were the body of such a function. In particular, note that Python does not automatically return a value from a function unless a return statement is present, and so a ‘return’ statement will usually be required in Python. http://orgmode.org/manual/Results-of-evaluation.html So when using `:results output', using `return' causes an error because there is no function to return anything from. Yours, Christian Thank you Christian for the detailed explanation. It is indeed perplexing at first! Regards, Greg
[O] Export Dispatcher Insert Template Not Working?
Hello, I'm having trouble with the export dispatcher not inserting a template. I'm not sure I'm entering the commands correctly. I am attempting to insert the template for LaTeX. Here are the 2 different attempts which fail: C-c C-e (successfully opens the dispatcher buffer) l # l ret In mini-buffer: Wrong type argument: arrayp, nil or # l ret Same error in mini-buffer: Wrong type argument: arrayp, nil Am I entering the commands incorrectly? Regards, Greg
Re: [O] Export Dispatcher Insert Template Not Working?
Thank you Bastien, the change is confirmed working! Regards, Greg On Fri, 2014-01-31 at 18:04 +0100, Bastien wrote: Hi Greg, Soapy Smith soapy-sm...@comcast.net writes: Hello, I'm having trouble with the export dispatcher not inserting a template. I'm not sure I'm entering the commands correctly. I am attempting to insert the template for LaTeX. Here are the 2 different attempts which fail: C-c C-e (successfully opens the dispatcher buffer) l # l ret You need l # l TAB RET I push a change in master which make l # l RET work now. Let me know,
[O] Python Code Block error with header option :results output
Hello- I am not a user of Python (yet). During a comparison of code block behavior between Clojure and Python, I discovered a possible Python error. Here is the code block: #+begin_src python :results output a = (1, 2, 3, 4) return a #+end_src The evaluation of this block results in this error: File stdin, line 2 SyntaxError: 'return' outside function Could someone please comment if this is expected Python behavior? I am using org 8.2.4. Regards, Greg
[O] Code block option :results raw does not replace #+RESULTS
Hello- Here is an example Python code block: #+begin_src python :results value raw a = (1, 2, 3, 4) return a #+end_src #+RESULTS: (1, 2, 3, 4) (1, 2, 3, 4) The #+RESULT block above is after 2 evaluations. The default behavior of replace is not happening. The result stack will continue to grow with additional evaluations. I also confirmed the same behavior with a Clojure code block. Is this the expected behavior for this option? Regards, Greg
Re: [O] Clojure Code Block Results not Tabularized
Great news! I will update my system to the master. I will create an org file with permutations of the :results option and export to LaTeX and HTML. Perhaps even compare to Python behavior. I will attempt to push the test files to github later today. I need the git practice! Regards, Greg On Thu, 2014-01-30 at 12:11 +0100, Bastien wrote: Hi Greg, Soapy Smith soapy-sm...@comcast.net writes: The problem is that the results inserted into the org document should be tabularized. This should now be fixed in master -- thanks for further testing, and thanks to Eric for giving the solution.
Re: [O] Clojure Code Block Results not Tabularized
Here are the files from testing of Clojure code blocks with the latest master: https://github.com/Greg-R/org-babel-clojure-tests?source=cc The PDF file is the result of a LaTeX export. The code blocks were forced to appear as they do in the org file by wrapping them in begin_example/end_example. Is there a way to get the complete code blocks exported in an entire org file using a global option? Python code blocks are used for comparison. There were some differences. The coercion to tables (where appropriate) is working well. Regards, Greg On Thu, 2014-01-30 at 12:11 +0100, Bastien wrote: Hi Greg, Soapy Smith soapy-sm...@comcast.net writes: The problem is that the results inserted into the org document should be tabularized. This should now be fixed in master -- thanks for further testing, and thanks to Eric for giving the solution.
Re: [O] Clojure Code Block Results not Tabularized
Hi Christian, I think that is a very good point! From the manual, the explanation of what is returned as a result using :results raw raw The results are interpreted as raw Org mode code and are inserted directly into the buffer. If the results look like a table they will be aligned as such by Org mode. E.g., :results value raw. So, it doesn't say it will result in a table, but it will be aligned like a table! Whatever the case, the behavior of Clojure should be consistent with the other languages. Looking into the old set further, I find the :results header argument makes no difference: :results value :results value raw :results table (no header argument) All result in the same org table. So it looks like the old version was not behaving properly either. However, it was able to coerce the Clojure vector into an org table successfully. With the new system (version 8 org and CIDER), there are in fact 3 different results blocks: (no header argument) #+RESULTS: : [1 2 3 4] :results value raw #+RESULTS: [1 2 3 4] :results value #+RESULTS: : [1 2 3 4] :results table #+RESULTS: | [1 2 3 4] | Christian, could you try :results table with Python and reply back with the #+RESULTS:? Regards, Greg On Wed, 2014-01-29 at 08:57 +0100, Christian Moe wrote: Hi, I don't use Clojure so I may get this wrong, but: isn't this what you would expect with `:results raw'? Cf. these Python examples: #+begin_src python :results raw a = (1, 2, 3) return a #+end_src #+RESULTS: (1, 2, 3) #+begin_src python a = (1, 2, 3) return a #+end_src #+RESULTS: | 1 | 2 | 3 | Yours, Christian
Re: [O] Clojure Code Block Results not Tabularized
Yes, I agree the Clojure behavior is not quite correct. But all the functionality is there if both the old and new are combined. I think only a rearrangement of existing code is required. I like the idea of comparing to the behavior of Python code blocks. I've got a Coursera class coming up which will use Python, so I need to get it set it up here. Thank you for the assistance! Greg On Wed, 2014-01-29 at 13:58 +0100, Christian Moe wrote: Soapy Smith writes: Christian, could you try :results table with Python and reply back with the #+RESULTS:? Same as the default, i.e. a table, as expected. #+RESULTS: | 1 | 2 | 3 | The Babel/Clojure behavior you report does seem buggy. I'm afraid I can't be of further help, but hopefully others will pick up on this. Yours, Christian
[O] Clojure Code Block Results not Tabularized
Hello to the list, my first message here. This is in regards to code blocks in the Clojure language. The problem is that the results inserted into the org document should be tabularized. This is not happening using the latest version of org. Here is the simplest possible example: #+begin_src clojure :results value raw [1 2 3 4] #+end_src #+RESULTS: [1 2 3 4] The result block is not tabularized. In an older system, the result block is properly changed to an org table: #+RESULTS: | 1 | 2 | 3 | 4 | Here is a comparison of the systems, old and new, which produced the above results: PlatformOld New emacs 24.3.1 24.3.1 Leiningen 2.3.4 2.3.4 Java1.7._51 1.6.0_27 (both are OpenJDK 64 bit server VM) org 7.9 8.2.4 Old REPL: nrepl 0.1.8-preview New REPL: cider 0.6.0alpha The only thing strange I discovered about my new system is that it is using an older version of Java than the old system. Regards, Greg
