Ihor Radchenko writes:
> Zelphir Kaltstahl writes:
>
>>> This is expected. Noweb includes the src block code without altering it.
>>> See 16.11 Noweb Reference Syntax
>>>
>>> We may probably clarify this in the manual. Would it be helpful?
>> I think it would be helpful. I merely tried Python,
Zelphir Kaltstahl writes:
>> Now, the main question is whether it is safe to use `define' in all the
>> scheme implementations. If it is, would you be interested in turning
>> your personal fix into a patch for ob-scheme?
>
> Sure! Would need to familiarize myself with with process of doing
On 3/11/23 10:58, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
The issue is not with defining via (define ...) inside a (let ...) in Guile. It
is about importing macros at the time, when the body of the (let ...) is already
evaluated, which is at a later phase than macro expansion. By
Zelphir Kaltstahl writes:
>> This is expected. Noweb includes the src block code without altering it.
>> See 16.11 Noweb Reference Syntax
>>
>> We may probably clarify this in the manual. Would it be helpful?
> I think it would be helpful. I merely tried Python, because it was at hand
> and
>
Zelphir Kaltstahl writes:
> The issue is not with defining via (define ...) inside a (let ...) in Guile.
> It
> is about importing macros at the time, when the body of the (let ...) is
> already
> evaluated, which is at a later phase than macro expansion. By wrapping inside
> a
> (let ...)
Daniel Kraus writes:
> If I could freely choose if a :var declaration in one source block
> should create a global variable for all other blocks in this session,
> I would say making it only available in the defining source block
> is more natural (i.e. use let instead of def).
You can always
On 3/9/23 14:11, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
OK, to wrap up (ha!), I want to ask:
(q1) What is a rationale, if any, behind the let-wrapping?
It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel,
On 3/9/23 14:10, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
START
#+name: python-imports
#+begin_src python :python /usr/bin/python3 :results output replace drawer :var
x=4
import math
y = math.sqrt(x)
# print(y)
#+end_src
#+name: python-usage
#+begin_src python :python
On 3/9/23 14:04, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
I am not sure (let ...) is a correct wrapper for noweb included source blocks.
What, if I write a (define ...) in my source block and want to use that source
block via noweb in another source block? Expected behavior I think
Ihor Radchenko writes:
> Zelphir Kaltstahl writes:
>> (q1) What is a rationale, if any, behind the let-wrapping?
>
> It makes sense in ob-emacs-lisp to not litter global Emacs state.
> In other ob-* lisp backends, I am not sure.
> I am CCing Daniel, the maintainer of ob-clojure (we have no
Zelphir Kaltstahl writes:
> OK, to wrap up (ha!), I want to ask:
>
> (q1) What is a rationale, if any, behind the let-wrapping?
It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel, the maintainer of ob-clojure (we have
Zelphir Kaltstahl writes:
> START
> #+name: python-imports
> #+begin_src python :python /usr/bin/python3 :results output replace drawer
> :var x=4
> import math
>
> y = math.sqrt(x)
> # print(y)
> #+end_src
>
> #+name: python-usage
> #+begin_src python :python /usr/bin/python3 :return
Zelphir Kaltstahl writes:
> I am not sure (let ...) is a correct wrapper for noweb included source
> blocks.
> What, if I write a (define ...) in my source block and want to use that
> source
> block via noweb in another source block? Expected behavior I think would be
> to
> be able to
On 3/8/23 20:38, Bruno Barbier wrote:
Hi Zelphir,
Zelphir Kaltstahl writes:
On 3/7/23 20:52, Bruno Barbier wrote:
Also thanks for the idea with sessions + separate import source block. I thought
that should work, but apparently that also has the same error, when running for
the first time:
Hi Zelphir,
Zelphir Kaltstahl writes:
> On 3/7/23 20:52, Bruno Barbier wrote:
> Also thanks for the idea with sessions + separate import source block. I
> thought
> that should work, but apparently that also has the same error, when running
> for
> the first time:
>
> ...
Oh, I see. I
Zelphir Kaltstahl writes:
> Actually, now that I think about it, the whole problem is gone, when
> replacing
> the wrapping let with 2 separate (define ...), which I originally thought org
> would do:
> ...
> Is there a reason it has to be wrapped in a let, instead of simply define-ing
> the
On 3/7/23 20:52, Bruno Barbier wrote:
Zelphir Kaltstahl writes:
If org merely wraps in a `let`, it should not notice any of the multiple values
business, because that is something done internally in `let-values`.
The "let", to define the org variables, ends up putting the "import"
inside
On 3/7/23 20:52, Bruno Barbier wrote:
Zelphir Kaltstahl writes:
If org merely wraps in a `let`, it should not notice any of the multiple values
business, because that is something done internally in `let-values`.
The "let", to define the org variables, ends up putting the "import"
inside
Zelphir Kaltstahl writes:
> There seems to be an issue with returning multiple values,
By the way, (Common) Lisp also has problems with multiple values in Org, as I
have recently learned in a discussion with the author of SLY (the modern
alternative to SLIME), João Távora. He says:
> But this
Zelphir Kaltstahl writes:
> If org merely wraps in a `let`, it should not notice any of the multiple
> values
> business, because that is something done internally in `let-values`.
>
The "let", to define the org variables, ends up putting the "import"
inside the scheme expression, like this:
On 07/03/2023 18:27, Zelphir Kaltstahl wrote:
because somehow there is no ob-racket and I think I would need that.
See the following thread for a couple of links. Disclaimer: I have never
used racket, so I do not know real state of affairs.
On 3/7/23 15:36, Ihor Radchenko wrote:
Zelphir Kaltstahl writes:
* Multiple values involving =:var= variables
#+begin_src scheme :eval query-export :results output replace drawer :var x=1
:var y=2
(import (except (rnrs base) error vector-map)
(only (guile)
lambda*
Zelphir Kaltstahl writes:
> * Multiple values involving =:var= variables
>
> #+begin_src scheme :eval query-export :results output replace drawer :var x=1
> :var y=2
> (import (except (rnrs base) error vector-map)
> (only (guile)
>lambda*
>λ)
>
Hello Org users!
I think I found a bug in how org-babel works with at least GNU Guile source
blocks. I could not reproduce this for example with a racket source block,
because somehow there is no ob-racket and I think I would need that. I could try
other Schemes like maybe Chicken, if there
24 matches
Mail list logo
