poverobuosodonati<poverobuosodon...@gmail.com> writes:
ob-csharp from org-contrib uses mcs here. I am wondering why you use
something different. Is there any syntax difference? Something else? (I
have no knowledge of C#)
In fact, this was a deliberate decision. ... Further, it is
recommended by mono itself to migrate to .NET (see
[[https://github.com/mono/mono][here]]) after Microsoft bought etc.
So all in all, I'd argue that using dotnet over mono is a good idea
looking forward.
Agree. Our general policy is to support the latest version of external
program/library/package in our code. Everything else is not guaranteed.
So, I have no problems switching to officially supported compiler.
Do I understand correctly that this more or less a syntax version?
If yes, we may want to customize it per-src block as a header argument
rather than globally.
...
I am a bit undecided whether or not it would make sense to expose
this as a header argument as I understand this to be rather "static" as
in there might not be a desire to change this from code block to code
block. What do you think?
ob-C exposes such things via :flags parameter.
For C#, it may or may not be a good idea. Here, I tend to agree with
Stefan Nobis - if it is easy for you (including adding docs and tests),
go for it. Otherwise optional.
If we do not implement it now and someone asks for it, it can be done
later.
... and here. (Also, typos in the variable name)
This might again become "chatty", i.e., a longish string. Further, this
is intended only for "completeness" reasons, i.e., I don't really expect
that this would be used frequently. What do you think: should it be a
header argument nonetheless? In the meantime, I fixed the typo at least ;)
I will rely upon your knowledge of C# here.
For the typo, I do not see it fixed in
https://codeberg.org/buoso/csharp-babel/src/branch/dev/ob-csharp.el
I suggest doing
(project-name (or (alist-get :project params) (gensym)))
(namespace (or (alist-get :namespace params) (gensym)))
inside execute function.
It will be much simpler.
The "problem" I have here is the following: it is not required to set
the namespace in the header arguments, but I need the same value for
that key in the =org-babel-expand-body:csharp= and
=org-babel-execute:csharp=. Thus, I "preprocess" the =params= and use a
copy of that which contains keys for ":project" and ":namespace".
Now for "execution only", it would be totally sufficient to do this only
in the execute function. For code-block expanding not to fail when there
is either no namespace or project key (or both), I do this also in the
expand function.
Your current version of the code only ever uses the following pattern:
(defun org-babel-expand-body:csharp (body params ;; processed-params
...
(params (org-babel--csharp-preprocess-params params))
(namespace (alist-get :namespace params))
(defun org-babel-execute:csharp (body params)
...
(let* ((params (org-babel--csharp-preprocess-params params))
(project-name (alist-get :project params))
(namespace (alist-get :namespace params))
Changing these into explicit (namespace (or (alist-get :namespace params)
(gensym)))
won't hurt.
Also, do note that org-babel-expand-body:csharp may be called by Org
babel itself, without going through org-babel-execute:csharp. See
org-babel-expand-src-block and org-babel-sha1-hash. So, you cannot rely
upon PARAMS argument containing processed header arguments.
What is the purpose of `ensure-directories-exist' here?
To create directory specified in :dir? If yes, you do not need to bother
- it is controlled by standard :mkdirp header argument.
This is a bit involved: yes, the directory passed with :dir is generated
automatically. But, the respective project will be within an additional
subdirectory that is called like the project itself is called. It is not
really obvious by this `ensure-directories-exist' function, but `.' here
denotes the path :dir/:project and :dir does not contain a :project
directory unless we ensure it.
Why do you create project inside working directory? These files will
remain there for every single src block you run, possibly littering that
directory.
This was "stolen" from ob-java.el, which does it like this. But yes,
nothing holds us back from using org-babel-temporary-directory. Adapted
it accordingly.
(base-dir (file-name-concat (if dir-param
(ensure-directories-exist)
org-babel-temporary-directory)
project-name))
Why not always using temporary directory?
Do note that ob-java is not normal in this regard. I did not touch the
code there simply because I am not sure about the reasons behind that
code. For other backends, I need a good reason to create files as a side
effect of evaluation other than in temporary directory.
Again, babel should take care about this according to :mkdirp. It is not
backend's job to create working directory.
This follows the same rational as above: we must ensure that directory
with name ":project" is existing before writing the generated files there.
I am wondering about the practical purpose of :project argument.
Normally, we do not want side effects from code block other than
specified by :results header argument.
So, project-type that is not 'class will not produce any results. May
you please explain why it is useful?
The other way round actually. When the project type is 'class, we do not
run it as there is no executable present in such a case. We want that
when the code-block is intended to be a "class library", i.e., does not
have a main function and therefore no executable entrypoint. This is
used to promote a code-block to the status of a "shared library" that
can be included in other code blocks/csharp projects to make use of the
functionality it provides.
To me, it looks like this is going into the territory of compiled
sources being the result of evaluation, as we discussed in
https://list.orgmode.org/orgmode/1819406926.505980.1701990611...@fidget.co-bxl/
But that's a totally new behavior we may want to discuss across backends
before implemeting.
Please rename this into org-babel-variable-assignments:csharp and let it
accept params argument.
Can you help me out here understanding this better? Is it a convention
or does it mean "refactoring" or doing it differently?
Yes, it is a convention.
org-babel-variable-assignments:<lang> is used during tangling
(`org-babel-tangle-single-block'). In your case, it is not strictly
necessary, as org-babel-expand-body:<lang> takes precedence, but the
naming scheme is nice to follow anyway (until we make this area better -
the current implicit naming convention is not documented and also rather
confusing)
