Re: [O] Buffer local alias?
Andreas Leha writes: Yes, I know. That's why I am sighing a bit: Both approaches need work or are inconvenient in one way or the other. That trait of reproducibility is shared with security. You might want to have alook at this: https://www.vagrantup.com/ (no direct experience yet). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ DIY Stuff: http://Synth.Stromeko.net/DIY.html
Re: [O] Buffer local alias?
On 2014-01-16 11:44, Achim Gratz wrote: Andreas Leha writes: Yes, I know. That's why I am sighing a bit: Both approaches need work or are inconvenient in one way or the other. That trait of reproducibility is shared with security. You might want to have alook at this: https://www.vagrantup.com/ (no direct experience yet). FWIW, I've just started using vagrant and virtualbox for creating a reproducible development environment for a ruby-on-rails class I am teaching. So far, it's great. Trying to get students to setup a rails dev environment, esp. on windows, is extremely difficult. With vagrant I have created a script which will build an ubuntu vm with everything needed (ruby, postgres, etc.) installed and configured. (Identical every time modulo 'apt-get upgrade'.). I then distribute THAT to the students (via vagrant), guaranteeing they are all working on identical virtual machines. rick
Re: [O] Buffer local alias?
Aloha Achim, Achim Gratz strom...@nexgo.de writes: Andreas Leha writes: Yes, I know. That's why I am sighing a bit: Both approaches need work or are inconvenient in one way or the other. That trait of reproducibility is shared with security. You might want to have alook at this: https://www.vagrantup.com/ Ah, very nice. Proof that it's a good idea to stir old pots now and again. Thanks for bringing this to the attention of the mailing list. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Buffer local alias?
Hi Tom, t...@tsdye.com (Thomas S. Dye) writes: Aloha Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I am not as organized as Tom is. So the chances to use my up-to-date orgmode and successfully export any of my org documents from a year ago (they are almost all 'Literate Programming' documents and, thus, maybe more fragile?) are slim. I do not have numbers, but it seems like I'll need to adapt such documents all the time. I know that this problem is a problem of balancing backward compatibility with new features, better design, etc and cannot be solved. And I see the win in (most of) the breaking changes. But let me just express my vote for even more awareness of people like me, who do not read all release notes, forget most of the messages from the mailing list and as a result need 2 hours to export some document from last year again today. A change like this one (renaming sbe to org-sbe) is a small change and will only be an annoyance in one years time. The drop of the implicit naming of call lines, for example, was (and still will be for some of my files) a bigger issue. I fully agree that it is challenging to prepare an Org mode file that can be moth-balled for a while, then resuscitated to full functionality without a lot of work. Perhaps one way to deal with this is to have the Org mode literate programming (reproducible research) file choose which version of Org-mode to use. Due to my difficulties in reproducing my own document from a year ago, I stopped calling my Org-mode documents 'reproducible research' ;-) Something like the following? #+name: org-mode-version #+begin_src sh cd path/to/org-mode-git-repo git checkout rev #+end_src # Local Variables: # eval: (and (fboundp 'org-sbe) (not (fboundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe org-mode-version) # eval: (org-reload t) # End: I haven't the faintest idea if this is a good idea or a snake pit of potential problems. Is the idea worth experimenting with? IIRC, org-reload is not too well supported and might even vanish one day. I could not find that discussion on a quick search, though. So, this approach might be potentially problematic, indeed. Regards, Andreas
Re: [O] Buffer local alias?
Nick Dokos wrote: I read about defalias and saw that this should be used at the point that the original definition is made, so I followed the pointer to fset and naively tried this in the local variables: # eval: (and (boundp 'org-sbe) (not (boundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe setup-common-lisp) But this gets me the following error: File local-variables error: (void-function sbe) Can someone offer a suggestion? @Thomas: I just launch an idea: group the above two lines in one `progn' construct? Use fboundp, instead of boundp: the latter checks the variable binding slot, whereas the former checks the function binding slot. @Nick: I always thought that `boundp' checked in both variable and function slots, not only in the variable slot. An attempt makes me think you're right, but that's not what I understood from the docstring: ╭ │ boundp is a built-in function in `C source code'. │ │ (boundp SYMBOL) │ │ Return t if SYMBOL's value is not void. │ Note that if `lexical-binding' is in effect, this refers to the │ global value outside of any lexical scope. ╰ Best regards, Seb -- Sebastien Vauban
Re: [O] Buffer local alias?
Hello Andreas, Andreas Leha wrote: The drop of the implicit naming of call lines, for example, was (and still will be for some of my files) a bigger issue. Could you remind me what's the problem you're talking of? Best regards, Seb -- Sebastien Vauban
Re: [O] Buffer local alias?
Hello Sebastien, Sebastien Vauban sva-n...@mygooglest.com writes: Hello Andreas, Andreas Leha wrote: The drop of the implicit naming of call lines, for example, was (and still will be for some of my files) a bigger issue. Could you remind me what's the problem you're talking of? Evaluating a #+call line used to produce a result block named with the name of the called code block and the arguments used. That is not the case any more. Something like (off the top of my head): --8---cut here---start-8--- #+call: foo(bar=1) #+call: foo(bar=2) #+results: foo(bar=1) | the | results | #+results: foo(bar=2) | the | results | --8---cut here---end---8--- Now, one has to name the call line to get a named results block. I would not call it a problem, though. The change just meant that I had to introduce a lot of names for call lines in some of my files where I relied on that implicit naming of results. I know, that I have not adapted all affected files of mine. So, if ever I wanted to re-export these, I will need to do some more naming of call lines... All the best, Andreas
Re: [O] Buffer local alias?
Andreas Leha writes: I am not as organized as Tom is. So the chances to use my up-to-date orgmode and successfully export any of my org documents from a year ago (they are almost all 'Literate Programming' documents and, thus, maybe more fragile?) are slim. I do not have numbers, but it seems like I'll need to adapt such documents all the time. We've discussed this before… If you want anything reproducible, you either need to keep it up-to-date with rolling releases and regression tests or you need an environment that can be frozen (i.e. a VM with the data plus the OS and applications). Anything less than that is coming back to bite you at some inconvenient moment. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Buffer local alias?
Hi Achim, Achim Gratz strom...@nexgo.de writes: Andreas Leha writes: I am not as organized as Tom is. So the chances to use my up-to-date orgmode and successfully export any of my org documents from a year ago (they are almost all 'Literate Programming' documents and, thus, maybe more fragile?) are slim. I do not have numbers, but it seems like I'll need to adapt such documents all the time. We've discussed this before… If you want anything reproducible, you either need to keep it up-to-date with rolling releases and regression tests or you need an environment that can be frozen (i.e. a VM with the data plus the OS and applications). Anything less than that is coming back to bite you at some inconvenient moment. Yes, I know. That's why I am sighing a bit: Both approaches need work or are inconvenient in one way or the other. I am following the first approach, since I sort of can live with that kind of impaired reproducibility and I really want (some of) the new features constantly added to Org. I just want to say: For me, the more backwards compatible Org stays the better. That's why I vote for the alias in the initial topic of this thread. And for similar measures in other cases, where backwards compability is as 'cheap' as in this case. It will just mean a little less work for me in the end. Regards, Andreas
[O] Buffer local alias?
Aloha all, My evolving reproducible research documents make use of Dan Davison's idea recently re-introduced by Seb Vauban: * Local variables :noexport: # Local Variables: # eval: (org-sbe setup-common-lisp) # End: Here, the source code block named `setup-common-lisp' is defined elsewhere in the file. The problem from the point of view of reproducible research is that org-sbe used to be named sbe, so for the research to be reproducible across that recent change I need to be able to configure things so the command that happens to be on the user's computer is used. I read about defalias and saw that this should be used at the point that the original definition is made, so I followed the pointer to fset and naively tried this in the local variables: # eval: (and (boundp 'org-sbe) (not (boundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe setup-common-lisp) But this gets me the following error: File local-variables error: (void-function sbe) Can someone offer a suggestion? All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] Buffer local alias?
t...@tsdye.com (Thomas S. Dye) writes: Aloha all, My evolving reproducible research documents make use of Dan Davison's idea recently re-introduced by Seb Vauban: * Local variables :noexport: # Local Variables: # eval: (org-sbe setup-common-lisp) # End: Here, the source code block named `setup-common-lisp' is defined elsewhere in the file. The problem from the point of view of reproducible research is that org-sbe used to be named sbe, so for the research to be reproducible across that recent change I need to be able to configure things so the command that happens to be on the user's computer is used. I read about defalias and saw that this should be used at the point that the original definition is made, so I followed the pointer to fset and naively tried this in the local variables: # eval: (and (boundp 'org-sbe) (not (boundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe setup-common-lisp) But this gets me the following error: File local-variables error: (void-function sbe) Can someone offer a suggestion? Use fboundp, instead of boundp: the latter checks the variable binding slot, whereas the former checks the function binding slot. Nick
Re: [O] Buffer local alias?
Nick Dokos ndo...@gmail.com writes: Use fboundp, instead of boundp: the latter checks the variable binding slot, whereas the former checks the function binding slot. Also, I thought sbe was unknown enough to rename it directly instead of creating an alias. If many people are using sbe, maybe an alias is better -- but I'd rather not to add it. -- Bastien
Re: [O] Buffer local alias?
Bastien b...@gnu.org writes: Nick Dokos ndo...@gmail.com writes: Use fboundp, instead of boundp: the latter checks the variable binding slot, whereas the former checks the function binding slot. Also, I thought sbe was unknown enough to rename it directly instead of creating an alias. If many people are using sbe, maybe an alias is better -- but I'd rather not to add it. Thanks Nick. This works: * Local variables :noexport: # Local Variables: # eval: (and (fboundp 'org-sbe) (not (fboundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe setup-common-lisp) # End: Bastien, for my use case there is no reason to define an alias. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Buffer local alias?
t...@tsdye.com (Thomas S. Dye) writes: Bastien b...@gnu.org writes: Nick Dokos ndo...@gmail.com writes: Use fboundp, instead of boundp: the latter checks the variable binding slot, whereas the former checks the function binding slot. Also, I thought sbe was unknown enough to rename it directly instead of creating an alias. If many people are using sbe, maybe an alias is better -- but I'd rather not to add it. Thanks Nick. This works: * Local variables :noexport: # Local Variables: # eval: (and (fboundp 'org-sbe) (not (fboundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe setup-common-lisp) # End: Bastien, for my use case there is no reason to define an alias. I am in favor of such an alias. In that particular case it seems that it would not hurt much (IMO) and it would increase backward compatibility. Let me take the opportunity to sigh a little bit: I am not as organized as Tom is. So the chances to use my up-to-date orgmode and successfully export any of my org documents from a year ago (they are almost all 'Literate Programming' documents and, thus, maybe more fragile?) are slim. I do not have numbers, but it seems like I'll need to adapt such documents all the time. I know that this problem is a problem of balancing backward compatibility with new features, better design, etc and cannot be solved. And I see the win in (most of) the breaking changes. But let me just express my vote for even more awareness of people like me, who do not read all release notes, forget most of the messages from the mailing list and as a result need 2 hours to export some document from last year again today. A change like this one (renaming sbe to org-sbe) is a small change and will only be an annoyance in one years time. The drop of the implicit naming of call lines, for example, was (and still will be for some of my files) a bigger issue. Regards, Andreas
Re: [O] Buffer local alias?
Aloha Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I am not as organized as Tom is. So the chances to use my up-to-date orgmode and successfully export any of my org documents from a year ago (they are almost all 'Literate Programming' documents and, thus, maybe more fragile?) are slim. I do not have numbers, but it seems like I'll need to adapt such documents all the time. I know that this problem is a problem of balancing backward compatibility with new features, better design, etc and cannot be solved. And I see the win in (most of) the breaking changes. But let me just express my vote for even more awareness of people like me, who do not read all release notes, forget most of the messages from the mailing list and as a result need 2 hours to export some document from last year again today. A change like this one (renaming sbe to org-sbe) is a small change and will only be an annoyance in one years time. The drop of the implicit naming of call lines, for example, was (and still will be for some of my files) a bigger issue. I fully agree that it is challenging to prepare an Org mode file that can be moth-balled for a while, then resuscitated to full functionality without a lot of work. Perhaps one way to deal with this is to have the Org mode literate programming (reproducible research) file choose which version of Org-mode to use. Something like the following? #+name: org-mode-version #+begin_src sh cd path/to/org-mode-git-repo git checkout rev #+end_src # Local Variables: # eval: (and (fboundp 'org-sbe) (not (fboundp 'sbe)) (fset 'sbe 'org-sbe)) # eval: (sbe org-mode-version) # eval: (org-reload t) # End: I haven't the faintest idea if this is a good idea or a snake pit of potential problems. Is the idea worth experimenting with? Pleased to appear well-organized, Tom -- Thomas S. Dye http://www.tsdye.com
