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) -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
