Provide Scheme sandbox.

Provide Scheme sandbox.

[Keith, 2011-12-08 00:38:07]

Very nice.
If you make it this easy, I might learn Scheme...
nah.

http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
File Documentation/extending/scheme-tutorial.itely (right):

http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
Documentation/extending/scheme-tutorial.itely:76: available calling
available with this command-line
@example
lilypond scheme-sandbox.ly
@end example

[dak, 2011-12-08 09:07:01]

On 2011/12/08 00:38:07, Keith wrote:
> Very nice.
> If you make it this easy, I might learn Scheme...
> nah.

Well, it is like converting people to Emacs.  Those who have gotten burnt 20
years ago are a lost cause.  You can't erase their childhood memories.  And they
look with envy and disbelief and inferiority if some newcomers seemingly get
along without much of an apparent problem.  And when they interview them or look
over their shoulders, they don't see anything to suggest that their apparent
mastership has cost them lots of sweat.  And you ask them, and they don't seem
to understand.

So you decide that you are just wired differently, and Emacs is not for you.

What you don't understand is that Emacs is no longer scanning your weaknesses of
understanding and kneeing you in the gut whenever you do something as careless
as typing a backspace.

I am working on that "Why would I be afraid of Scheme?  It seems simple." angle.
 And no mistake: if you consider working in C++ easier than in Scheme, something
is utterly wrong.

#{ ... #} goes to some lengths to defuse Scheme programming, too.  Its power has
vastly increased in the last half year or so.

>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
> File Documentation/extending/scheme-tutorial.itely (right):
> 
>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
> Documentation/extending/scheme-tutorial.itely:76: available calling
> available with this command-line
> @example
> lilypond scheme-sandbox.ly
> @end example

I prefer "command line" but other than that, I'll bow to your judgment.  I am so
used to command lines that I don't think of mentioning them.

Not uploading a separate Rietveld patch for just that, but changing it in my
copy.

[Ian Hulin (gmail), 2011-12-08 11:32:28]

On 2011/12/08 09:07:01, dak wrote:
> On 2011/12/08 00:38:07, Keith wrote:
> > Very nice.
> > If you make it this easy, I might learn Scheme...
> > nah.
> 
> Well, it is like converting people to Emacs.  Those who have gotten burnt 20
> years ago are a lost cause.  You can't erase their childhood memories.  And
they
> look with envy and disbelief and inferiority if some newcomers seemingly get
> along without much of an apparent problem.  And when they interview them or
look
> over their shoulders, they don't see anything to suggest that their apparent
> mastership has cost them lots of sweat.  And you ask them, and they don't seem
> to understand.
> 
> So you decide that you are just wired differently, and Emacs is not for you.
> 
> What you don't understand is that Emacs is no longer scanning your weaknesses
of
> understanding and kneeing you in the gut whenever you do something as careless
> as typing a backspace.
> 
> I am working on that "Why would I be afraid of Scheme?  It seems simple."
angle.
>  And no mistake: if you consider working in C++ easier than in Scheme,
something
> is utterly wrong.
> 
> #{ ... #} goes to some lengths to defuse Scheme programming, too.  Its power
has
> vastly increased in the last half year or so.
> 
> >
>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
> > File Documentation/extending/scheme-tutorial.itely (right):
> > 
> >
>
http://codereview.appspot.com/5453045/diff/1/Documentation/extending/scheme-t...
> > Documentation/extending/scheme-tutorial.itely:76: available calling
> > available with this command-line
> > @example
> > lilypond scheme-sandbox.ly
> > @end example
> 
> I prefer "command line" but other than that, I'll bow to your judgment.  I am
so
> used to command lines that I don't think of mentioning them.
> 
> Not uploading a separate Rietveld patch for just that, but changing it in my
> copy.

Hi David,
A Scheme sandbox is a good idea, in fact it is *A Very Good Idea*.

However, before we focus down on this solution, might it not be a good thing to
consider this:
get LilyPond in its build to provide a library of all its scheme stuff defined
in C++.
Then in our sandbox we open a Guile REPL loading the library as an extension,
and then provide a stub lily.scm to do the stuff main.cc does in code e.g.
(define-module (lily)), and all the stuff LilyPond does in initialization when
it runs its first pass through lily.scm  (like scheme-level command-line
options, building the rest of the (lily) module by loading the component
scm/*.scm files, etc. before doing its second-pass call to actually start
running procedure lilypond-main in lily.scm).

The stub version of lily.scm could then output the guile repl prompt, and some
instructions on how to set trace and breakpoints, and then tell the user how to
start compiling your Lily source from there.

If we could get to this scenario, we have a LilyPond available as a true
extension available in scheme rather than the current rather messed-up status of
an embedded app which is trying to be extensible via guile.

To conclude, I support what you want to provide, but have a good long think
about how you provide it, as you're getting into the messy area the Lily/Scheme
interface, and this may be a bigger ask than you originally envisaged.

Cheers,
Ian

[dak, 2011-12-08 14:39:56]

On 2011/12/08 11:32:28, Ian Hulin (gmail) wrote:
> 
> Hi David,
> A Scheme sandbox is a good idea, in fact it is *A Very Good Idea*.
> 
> However, before we focus down on this solution, might it not be a
> good thing to consider this:
> get LilyPond in its build to provide a library of all its scheme stuff defined
> in C++.
> Then in our sandbox we open a Guile REPL loading the library as an extension,
> and then provide a stub lily.scm to do the stuff main.cc does in code e.g.
> (define-module (lily)), and all the stuff LilyPond does in initialization when
> it runs its first pass through lily.scm  (like scheme-level command-line
> options, building the rest of the (lily) module by loading the component
> scm/*.scm files, etc. before doing its second-pass call to actually start
> running procedure lilypond-main in lily.scm).
> 
> The stub version of lily.scm could then output the guile repl
> prompt, and some instructions on how to set trace and breakpoints,
> and then tell the user how to start compiling your Lily source from
> there.

Why would you want to compile your Lily source from there?

Anyway, nobody is keeping you from typing

#{ \include "myfile.ly" #}

at the Guile prompt.  And if you want to set trace and breakpoints,
take a look at ly/guile-debugger.ly

The sandbox has the advantage of starting right in the lilypond-module
instead of guile-user.  One could make guile-debugger.ly do the same,
but since guile-debugger.ly is mostly a write-only project and I have
no idea who uses it for what purpose, I decided that a simple sandbox
that actually runs _inside_ of Lilypond instead of an outside module
would be preferable to most people.

And obviously, nobody thinks as guile-debugger.ly as being Scheme
tutorial level stuff since it is only mentioned in CG.

> If we could get to this scenario, we have a LilyPond available as a
> true extension available in scheme rather than the current rather
> messed-up status of an embedded app which is trying to be extensible
> via guile.  To conclude, I support what you want to provide, but
> have a good long think about how you provide it, as you're getting
> into the messy area the Lily/Scheme interface, and this may be a
> bigger ask than you originally envisaged.  Cheers, Ian

It is only a bigger task if you _want_ it to be a bigger task.  Guile
is an extension language for Lilypond, and for some reason you seem to
think that you need to turn Lilypond into an extension of Guile in
order to be allowed to talk to Guile.

Obviously, I disagree.

[pacovila, 2011-12-08 23:54:43]

2011/12/8  <dak@gnu.org>:
> What you don't understand is that Emacs is no longer scanning your
> weaknesses of understanding and kneeing you in the gut whenever you do
> something as careless as typing a backspace.

Copying/pasting from/to other programs in/from Emacs still appear in
my scan. I never know when it will work and when it will not.  Only
center-click usually works.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

[dak, 2011-12-09 01:37:38]

Francisco Vila <paconet.org@gmail.com> writes:

> 2011/12/8  <dak@gnu.org>:
>> What you don't understand is that Emacs is no longer scanning your
>> weaknesses of understanding and kneeing you in the gut whenever you do
>> something as careless as typing a backspace.
>
> Copying/pasting from/to other programs in/from Emacs still appear in
> my scan. I never know when it will work and when it will not.  Only
> center-click usually works.

Center click copies the active selection.  To copy the active selection
into the clip board, try the explicit act of M-w in Emacs.  The mouse
highlighting (and selection) disappears, but now the paste button in the
other application works.  And vice versa.  X _has_ separate mechanisms
for a highlighted selection and the clipboard.  Other applications work
similarly.

They usually make things easier by intermingling those two things.
Emacs doesn't.  One reason is that a common workflow is killing a region
in one buffer (C-w) and pasting it in another one (C-y).  If another X
application, like a browser coming up with a page with a highlighted
entry, steals the selection in between, you don't really want to have
Emacs overwrite its last kill with it.

You can customize Emacs to mix those behaviors as well, but if you
develop habitual workflows where this mix is useful, chances are that
you will lose information unintendedly at one time.

With a web browser, the source of information usually is not touched.
With an editor, it is.

-- 
David Kastrup