Re: [O] org-babel python eval discrepancy
Hey Dov,
Bull's eye! Never realized that could hurt.
It so happened that I set the correct python version in my shell before
starting emacs. However, my bashrc file was hardwired to a different
version, which org used every time for evaluating the src blocks.
Thanks for the help!
Dushyant
On Thu, Aug 3, 2017 at 2:22 PM Dov Grobgeld <dov.grobg...@gmail.com> wrote:
> Shell is using python3 and org-mode python2?
>
> On Aug 3, 2017 8:31 PM, "Dushyant Juneja" <juneja.dushy...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I have the following code block in my org mode based literate programming
>> notes:
>>
>> #+BEGIN_SRC python
>> print('1+2 > 4 is ', 1+2 > 4)
>> print("What is 3 + 2?", 3 + 2)
>> #+END_SRC
>>
>> When I tangle it and run the script, it gives me expected output as
>> follows:
>>
>> > python notes.py
>> 1+2 > 4 is False
>> What is 3 + 2? 5
>>
>> However, in buffer evaluation (using =C-c C-c= with cursor on src block)
>> gives me the following output, which seems unexpected:
>>
>> #+BEGIN_SRC python
>> print('1+2 > 4 is ', 1+2 > 4)
>> print("What is 3 + 2?", 3 + 2)
>> #+END_SRC
>>
>> #+RESULTS:
>> : ('1+2 > 4 is ', False)
>> : ('What is 3 + 2?', 5)
>>
>> Any hints what may be going wrong?
>>
>> Dushyant
>>
>
[O] Adding custom arguments to org-babel src code eval
Hi,
Is it possible to add custom arguments to source code evaluation in org
babel? For example, if the source code block is:
#+BEGIN_SRC python
# valid comment 1
print("Hi there!") # valid comment 2
print("# Invalid comment! #UsefulForHashtags!")
print ("Space is fine here!")
#+END_SRC
The general C-c C-c will evaluate it using the python interpreter. Hence
the result:
#+RESULTS:
: Hi there!
: # Invalid comment! #UsefulForHashtags!
: Space is fine here!
However, I would like to pass '-m trace --trace' arguments to the
interpreter, so that the resulting text capture is basically an output of
the following command:
> python -m trace --trace notes.py
--- modulename: notes, funcname:
notes.py(2): print("Hi there!") # valid comment 2
Hi there!
notes.py(3): print("# Invalid comment! #UsefulForHashtags!")
# Invalid comment! #UsefulForHashtags!
notes.py(4): print ("Space is fine here!")
Space is fine here!
--- modulename: trace, funcname: _unsettrace
trace.py(77): sys.settrace(None)
So far, I know I can do this via #+call syntax and a custom shell script.
However, that looks like an overkill for passing simple arguments to the
interpreter. I have tried :cmdline and :args "-m trace --trace", and
neither seem to work.
Any ideas?
Dushyant
[O] org-babel python eval discrepancy
Hi,
I have the following code block in my org mode based literate programming
notes:
#+BEGIN_SRC python
print('1+2 > 4 is ', 1+2 > 4)
print("What is 3 + 2?", 3 + 2)
#+END_SRC
When I tangle it and run the script, it gives me expected output as follows:
> python notes.py
1+2 > 4 is False
What is 3 + 2? 5
However, in buffer evaluation (using =C-c C-c= with cursor on src block)
gives me the following output, which seems unexpected:
#+BEGIN_SRC python
print('1+2 > 4 is ', 1+2 > 4)
print("What is 3 + 2?", 3 + 2)
#+END_SRC
#+RESULTS:
: ('1+2 > 4 is ', False)
: ('What is 3 + 2?', 5)
Any hints what may be going wrong?
Dushyant
Re: [O] [RFC] The "c" Org macro
A very useful macro indeed!
One suggestion: can this also be made to support nested headings. For
instance:
* Part {{{c}}}
** Part {{{c}}}.{{{c}}}
* Part {{{c}}}
should export to:
* Part 1
** Part 1.1
* Part 2
I reckon this will be very useful when a paragraphs need to be broken into
several subheadings for clarity/context management.
Dushyant
On Mon, May 8, 2017 at 10:01 AM Eric S Fraga wrote:
> On Monday, 8 May 2017 at 11:26, Nicolas Goaziou wrote:
> > Hello,
> >
> > I would like to scratch a long-standing itch and introduce the "c"
> > macro, which is basically a way to handle multiple counters in an Org
> > document. So, the following document
>
> This sounds like a very useful macro to have. Some suggestions:
>
> 1. I would prefer the argument to be called "COUNTER" instead of "SEED"
> as the latter is more commonly associated with random number
> generators. This would make the documentation clearer potentially.
>
> 2. I wonder if a second argument could be optionally available to allow
> the counter to start at an arbitrary number and/or be reset?
>
> I would definitely be using the macro for, as an example, in preparing
> exams and courseworks where I often have to manually put the numbers in.
>
> thanks,
> eric
>
> --
> : Eric S Fraga (0xFFFCF67D), Emacs 26.0.50, Org release_9.0.6-407-gc28ec3
>
[O] use-package with ox-latex
Hi all, I was trying to wrap ox-latex in a use-package configuration. My use-package statement is super simple: (use-package ox-latex :defer t) However, emacs cribs on this at startup as follows: package-compute-transaction: Package ‘ox-latex-’ is unavailable Any ideas of what could be going wrong here? I have seen many people use use-package for ox-latex, so I do not understand why this should happen now. As an initial check, I did see that ox-latex is not available as a package in package-list-packages output. It is available via find-library command in my org-installation, though. Thanks for the help in advance! Dushyant
Re: [O] Bug with (comment-line)
On Wed, Oct 26, 2016 at 4:12 PM Kaushal Modi <kaushal.m...@gmail.com> wrote: On Wed, Oct 26, 2016, 1:28 AM Dushyant Juneja <juneja.dushy...@gmail.com> wrote: bug or a feature? If latter, how do I comment current line in org-babel? It looks like this bug which was recently fixed in the master (dev) branch: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=21c6148bbe60c278abfb0f035c15c030ac0582c6 If this commit is not merged into the maint branch, you would need to git clone the master branch and build org locally to get it. The version available via package.el is the latest build of only the maint branch. My Org-mode version is 8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /.../.emacs.d/elpa/org-plus-contrib-20161024/) Looking at the commit date, it is 2016-10-15 10:31:25 (GMT) Any way I can test it whether I have this commit or not? Dushyant -- Kaushal Modi
Re: [O] Issue with :cache yes
Thanks for the quick response, Uli! On Wed, Oct 26, 2016 at 1:09 PM Ulrich J. Herter <u...@posteo.de> wrote: > Hi, > > Am Mittwoch, den 26.10.2016, 05:49 + schrieb Dushyant Juneja: > > * New Heading > > #+call: execBlk1( "newHeading" ) :cache yes > > Shouldn't it be #+call: execBlk1( args="newHeading" ) at this point? > I now get the following error: mapcar: Wrong type argument: listp, "args=\"newHeading\"" In fact, the error is now stubborn till I remove :cache yes. Where is it storing the cache? > > > > > However, when I try to export it to ascii (C-c C-e t A), I get the > > following error: > > > > ## > > org-babel-exp process sh at line 16... > > mapcar: Wrong type argument: listp, "args=\"newHeading\"" > > ## > > > > Is there something wrong in my use-model? I am basically trying to > > avoid re-evaluating code blocks during export, if I already have them > > evaluated in my buffer. > > I cannot reproduce your issue on org release_8.3.6-1246-g359afa.dirty. > May be you can try running M-x org-babel-execute-buffer before export > to make sure all results are up-to-date. > My org mode version: Org-mode version 8.3.6 (8.3.6-7-g4d7d52-elpaplus @ /.../.emacs.d/elpa/org-plus-contrib-20161024/) I see that this is the latest as per my recent package list fetch. Any ideas? Further, now I see that this gets evaluated even while export, irrespective of whether it is already eval'ed or not in the buffer. Dushyant > > > HTH Uli > > >
[O] Issue with :cache yes
Hi,
I have an org file (as below) with pre-computed outputs already available
in the RESULTS drawer:
##
#+OPTIONS: ':t *:t -:t ::t <:t H:3 \n:nil ^:{} arch:headline author:t
#+OPTIONS: c:nil creator:nil d:(not "LOGBOOK") date:t e:t email:nil
#+OPTIONS: f:t inline:t num:t p:nil pri:nil prop:nil stat:t tags:t
#+OPTIONS: tasks:t tex:t timestamp:t title:t toc:nil todo:t |:t
#+TITLE: Using cache in org-babel
#+DATE: <2016-10-26 Wed>
#+AUTHOR: Dushyant.Juneja
#+EMAIL: djuneja@djuneja-vd1
#+LANGUAGE: en
#+SELECT_TAGS: export
#+EXCLUDE_TAGS: noexport
#+CREATOR: Emacs 25.1.1 (Org mode 8.3.6)
# PROPERTY: cache yes
Trying to use cache in org mode.
#+name: execBlk1
#+BEGIN_SRC sh :shebang #!/bin/sh :var args="defVal" :exports results
:results verbatim :cache yes
date
sleep 30
echo $args
date
#+END_SRC
#+RESULTS[69b2da29c266b8bb5157905519c7afe157575196]: execBlk1
: Wed Oct 26 11:10:11 IST 2016
: defVal
: Wed Oct 26 11:10:41 IST 2016
* New Heading
#+call: execBlk1( "newHeading" ) :cache yes
#+RESULTS[b49b6acbaa204c4bff632070f1e0a1b686b7a8e2]:
: Wed Oct 26 11:12:01 IST 2016
: newHeading
: Wed Oct 26 11:12:31 IST 2016
##
However, when I try to export it to ascii (C-c C-e t A), I get the
following error:
##
org-babel-exp process sh at line 16...
mapcar: Wrong type argument: listp, "args=\"newHeading\""
##
Is there something wrong in my use-model? I am basically trying to avoid
re-evaluating code blocks during export, if I already have them evaluated
in my buffer.
This happens with #+PROPERTY: cache yes as well as in-line :cache yes
Dushyant
[O] Bug with (comment-line)
Hi, (comment-line) function (bound to C-x C-; by default) seems to have a bug. Normally, with pointer on a line, if I do C-x C-; - it comments the current line. In org-mode, it adds comment at the end of the line. For instance, I have the following verilog file (sth.sv) (line numbers for clarity only): 1: program sth; 2:input sth_else; 3: endprogram If I press C-x C-; on line 2, it becomes: program sth; // input sth_else; endprogram However, if I have the following in org mode: 1: #+BEGIN_SRC verilog :tangle cache.sv 2: program sth; 3:input sth_else; 4: endprogram 5: #+END_SRC Pressing C-x C-; with pointer on line 3 transforms it to: 1: #+BEGIN_SRC verilog :tangle sth.sv 2: program sth; 3:input sth_else; // 4: endprogram 5: #+END_SRC bug or a feature? If latter, how do I comment current line in org-babel? Dushyant
Re: [O] Fwd: bug with org-babel/sqlite?
Thanks, Kaushal for forwarding me the reply. Indeed, I was not on the list. I have requested a subscription now, nevertheless. Hi Nick, Yes. That seems to help. However, I suspect the bug is with ob-sqlite rather than sqlite itself. If I do the following directly in sqlite3 terminal, it seems to work just fine: 119 $ sqlite3 SQLite version 3.7.11 2012-03-20 11:35:50 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> .mode csv sqlite> create table foo(Year,Make,Model,Description,Price); sqlite> .import sample1.csv foo sqlite> select * from foo; Year,Make,Model,Description,Price 1997,Ford,E350,"ac, abs, moon",3000.00 1999,Chevy,"Venture ""Extended Edition""","",4900.00 1999,Chevy,"Venture ""Extended Edition, Very Large""","",5000.00 1996,Jeep,"Grand Cherokee","MUST SELL! air, moon roof, loaded",4799.00 Given that SQL is hence able to treat it properly, it looks like the bug lies with ob-sqlite wrongly interpreting the newline. Dushyant On Thu, Sep 15, 2016 at 6:32 AM Kaushal Modi <kaushal.m...@gmail.com> wrote: > Not sure if you have subscribed to the org mode mailing list. If not, you > would not have received this reply. So forwarding that to you. > > -- Forwarded message - > From: Nick Dokos <ndo...@gmail.com> > Date: Wed, Sep 14, 2016, 5:18 PM > Subject: Re: [O] Fwd: bug with org-babel/sqlite? > To: <emacs-orgmode@gnu.org> > > > Kaushal Modi <kaushal.m...@gmail.com> writes: > > > Hi Dushyant, > > > > The folks following the org mailing list might be able to help you out > on this. So I am forwarding this > > email there. > > > > I haven't tried recreating this as I do not use sqlite. > > > > But when you say that in the case where you use the default :results > sqlite doesn't work, what doesn't > > work? Do you get an error? > > > > -- Forwarded message - > > From: Dushyant Juneja <juneja.dushy...@gmail.com> > > Date: Wed, Sep 14, 2016 at 10:08 AM > > Subject: bug with org-babel/sqlite? > > To: help-gnu-em...@gnu.org <help-gnu-em...@gnu.org> > > > > Hi, > > > > Looks like I stumbled upon a bug with org-babel and sqlite. I have the > > following in my org file. PFA the bug description (bug.org). The > essence is > > that sqlite queries work with :results verbatim, but not otherwise. Any > > ideas on how to get past this? > > > > This is with emacs 24.5.2, RHEL6. > > > > Dushyant > > -- > > > > Kaushal Modi > > > > > > Changing the CSV file slightly gets rid of the problem: > , > | #+BEGIN_SRC csv :tangle sample1.csv > | Year,Make,Model,Description,Price > | 1997,Ford,E350,"ac, abs, moon",3000.00 > | 1999,Chevy,"Venture ""Extended Edition""","",4900.00 > | 1999,Chevy,"Venture ""Extended Edition, Very Large""",,5000.00 > | 1996,Jeep,Grand Cherokee,"MUST SELL! air, moon roof, loaded",4799.00 > | #+END_SRC > ` > ^ > The CSV file had a newline^here. > > If you eliminate the newline, things work as they should. Whether > that's a bug in ob-sqlite or sqlite itself, I have no idea. > > -- > Nick > > > -- > > Kaushal Modi >
