Buffer local alias?

Buffer local alias?

[Thomas S. Dye]

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: Buffer local alias?

[Nick Dokos]

tsd@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: Buffer local alias?

[Bastien]

Nick Dokos <ndokos@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: Buffer local alias?

[Thomas S. Dye]

Bastien <bzg@gnu.org> writes:

> Nick Dokos <ndokos@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: Buffer local alias?

[Andreas Leha]

tsd@tsdye.com (Thomas S. Dye) writes:

> Bastien <bzg@gnu.org> writes:
>
>> Nick Dokos <ndokos@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: Buffer local alias?

[Thomas S. Dye]

Aloha Andreas,

Andreas Leha <andreas.leha@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

Re: Buffer local alias?

[Andreas Leha]

Hi Tom,

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha Andreas,
>
> Andreas Leha <andreas.leha@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: Buffer local alias?

[Eric S Fraga]

> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

[...]

>> 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.

I agree wholeheartedly with the sentiment expressed here.  Despite the
difficulties I have had resurrecting some LP org documents recently, the
benefits of the continual developments to org + babel are clear.

[...]

"Thomas S. Dye" <tsd@tsdye.com> writes:

> 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?

Very much so.  One of my recent fights with org was due to finally
getting back reviewers' comments on a paper I had submitted almost a
year ago.  If I had had an automatic link to the correct version of org,
the one that matched my document, it would have made things much
easier.  Obviously, I could have done this manually and probably should
have.

However, I think it may be quite difficult to automate what you are
proposing...

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.4-322-gece429

Re: Buffer local alias?

[Sebastien Vauban]

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: Buffer local alias?

[Sebastien Vauban]

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: Buffer local alias?

[Andreas Leha]

Hello Sebastien,

"Sebastien Vauban" <sva-news@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: Buffer local alias?

[Achim Gratz]

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: Buffer local alias?

[Andreas Leha]

Hi Achim,

Achim Gratz <Stromeko@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

Re: Buffer local alias?

[Achim Gratz]

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: Buffer local alias?

[Rick Frankel]

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: Buffer local alias?

[Thomas S. Dye]

Aloha Achim,

Achim Gratz <Stromeko@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