Valuespace: discussion
Ville M. Vainio
ILeo has the "LeoWorkbook" concept. However, that quickly creates a
setup which is hard to manage, because it requires you to execute
scripts in certain sequence, perhaps doing some work in ipython shell,
etc.
Valuespace aims to make the same problem domain (sort of using leo
like a spreadsheet) easier to tackle. I think it is easier to approach
- just write your "application" in a tree and run vs-update.
"Application" consists of two passes:
1. Evaluate the whole leo tree in tree-order, with following rules:
Headline "@= foo" => assign body to foo
@a => evaluate body of parent, with following rules:
"@x foo()" => execute one line of python code
@x {
import os
print "many"
print "lines"
@x }
@x =foo {
assign
many
lines
to variable foo
@x }
Pass 2: evaluate @r nodes.
Everything else is ignored. This lets you "annotate" large bodies of
text with python code, extracting and processing information according
to your needs.
Everything is run in namepace g.vs, so you can refer to g.vs.foo in
your ctrl+b scripts. Namespace persists, unless you do vs-reset.
The alternative, doing things in leo scripts that traverses outline
itself becomes cumbersome quite easily.
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
Interesting stuff
> @x {
> import os
> print "many"
> print "lines"
>
> @x }
g is available in @x block, I assume?
Does
@x {
g.vs.dirs = {'N':0, 'E':90, 'S':180, 'W':270}
@x }
work?
And when you say g.vs namespace persists, for what timescale? Session
or forever or?
And would
@x =projA.left {
stuff on
the left
@x }
@x =projB.left {
gone already
@x }
store things in g.vs.projA.left and g.vs.projB.left? Maybe this only
matters if persistence is long term.
And if persistence is long term, is g.vs shared between different
outlines?
Cheers -Terry
Kent Tenney
http://packages.python.org/manuel/
Manuel extends rst, adding cool code running and testing stuff.
> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>
>
Ville M. Vainio
>> @x {
>> import os
>> print "many"
>> print "lines"
>>
>> @x }
>
> g is available in @x block, I assume?
Plan is to expose c,p,g there. Didn't do it yet (turns out having 1.8
yo son makes you busy).
> Does
>
> @x {
>
> g.vs.dirs = {'N':0, 'E':90, 'S':180, 'W':270}
>
> @x }
>
> work?
That will work soon, but now you can just do
dirs = {'N':0, 'E':90, 'S':180, 'W':270}
This is because @x blocks are executed so that g.vs is the global
namespace (i.e. as if you had entered everything in the vs.py module).
> And when you say g.vs namespace persists, for what timescale? Session
> or forever or?
Just session. To persist stuff you would probably use c.db['foo'] = 12
or g.app.db.
> And would
>
> @x =projA.left {
>
> stuff on
> the left
>
> @x }
>
> @x =projB.left {
>
> gone already
>
> @x }
>
> store things in g.vs.projA.left and g.vs.projB.left? Maybe this only
> matters if persistence is long term.
Yes, it would. If you check out valuespace stuff in contrib branch, it
does this.
You would have to do
@x {
projA = Bunch()
}
earlier in the tree though.
> And if persistence is long term, is g.vs shared between different
> outlines?
g.app.db is shared between leo processes (by virtue of being PickleShareDB.
Ville M. Vainio
> Is this sort of like Manuel?
> http://packages.python.org/manuel/
Partly, though valuespace is much simpler and general. E.g this seems familiar:
http://packages.python.org/manuel/#capture
However, valuespace is in no way specific to rst, or documentation
needs. Rather, I see valuespace (just like I see ILeo / LeoWorkbook)
as a way to make Leo tree "become alive", i.e. embed functionality in
a richer way than just adding scripts and @buttons would accomplish.
BTW, a fun hack would be creating leo commands from snippets of text:
--------
blah
blah
@x =foo {
print c
print g
@x }
@x add_leo_command('print-vars', foo)
blah blah
blah
-------------
This is easy, just add definition for add_leo_command to "prelude" @x
block earlier in the leo tree.
Ville M. Vainio
> Plan is to expose c,p,g there. Didn't do it yet (turns out having 1.8
> yo son makes you busy).
Pushed now. c,p,g are available as in leo ctrl+b scripts.
Edward K. Ream
> - just write your "application" in a tree and run vs-update.
> "Application" consists of two passes:
>
> 1. Evaluate the whole leo tree in tree-order, with following rules:
I am beginning to understand :-)
Wouldn't it be clearer to replace the term "rendering" with "evaluating"?
That would suggest @eval <expr> rather than @r <expr>
What do you think?
Edward
P.S. Unless you would prefer doing so, I would like to try my hand at
writing a docstring based on this discussion. Is this alright with
you?
EKR
Edward K. Ream
> That would suggest @eval <expr> rather than @r <expr>
I'd also like to use the terms pass1 and pass2 instead of update_vs
and render_phase(c), and also getScript instead of untangle.
OK with you?
Edward
Edward K. Ream
> I'd also like to use the terms pass1 and pass2 instead of update_vs
> and render_phase(c), and also getScript instead of untangle.
>
> OK with you?
One other thing. I see leo/external/stringlist.py uses old-style sentinels.
Is it alright with you if I put an @file node for stringlist.py in
leoPy.leo? That will convert the sentinels.
Edward
Edward K. Ream
On Apr 8, 6:57 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> One other thing.
And another thing :-) I'd like to create a plugin controller for this
plugin. This will allow more flexibility, for example for options.
At present, the plugin uses print statements to report "Lets".
Options to send to the log or a file would be useful.
In other words, it would be good to make extending this plugin as easy
as possible. I have the feeling we are going to be doing that a
bit :-)
Edward
Edward K. Ream
On Apr 8, 7:09 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> In other words, it would be good to make extending this plugin as easy
> as possible. I have the feeling we are going to be doing that a
> bit :-)
EKR
Edward K. Ream
On Apr 8, 6:46 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> Wouldn't it be clearer to replace the term "rendering" with "evaluating"?
>
> That would suggest @eval <expr> rather than @r <expr>
On second thought, how about documenting @r as producing a *result*
rather than "rendering"?
That "mnemonic" might more clearly indicate that @r happens in pass 2.
Edward
Ville M. Vainio
> That would suggest @eval <expr> rather than @r <expr>
>
> What do you think?
I prefer the brevity of @r. Also, it Renders the Result in node body,
so r is appropriate ;-).
> P.S. Unless you would prefer doing so, I would like to try my hand at
> writing a docstring based on this discussion. Is this alright with
> you?
That would be great. I find myself having more enthusiasm than I have
time, unfortunately.
Ville M. Vainio
>> That would suggest @eval <expr> rather than @r <expr>
>
> I'd also like to use the terms pass1 and pass2 instead of update_vs
> and render_phase(c), and also getScript instead of untangle.
I don't like 'getScript' because there isn't necessarily any script
around. getScript is what it calls behind the scenes.
I also don't like using camelCase for python function names.
update_vs is okay imho (because that's what it does) - it can be
called without being part of "pass1".
render_phase => render_results would make sense. Again, locking the
name of a function to a "phase" is probably not a good idea.
render_results could be used for other purposes as well.
Ville M. Vainio
> One other thing. I see leo/external/stringlist.py uses old-style sentinels.
>
> Is it alright with you if I put an @file node for stringlist.py in
> leoPy.leo? That will convert the sentinels.
Go ahead.
Ville M. Vainio
> And another thing :-) I'd like to create a plugin controller for this
> plugin. This will allow more flexibility, for example for options.
Have a blast :). I wrote it knowing I only have a bit of time for
implementation, so I didn't bother making it "modular" or whatnot.
Just promise one thing - avoid subclasses :). I personally dislike
subclassing in Python, it makes the code more complex than it needs to
be.
> At present, the plugin uses print statements to report "Lets".
> Options to send to the log or a file would be useful.
I think we can just comment that stuff out when we don't need them
anymore. They are for debugging.
> In other words, it would be good to make extending this plugin as easy
> as possible. I have the feeling we are going to be doing that a
> bit :-)
Let's hope so :). I plan to add at least @cl nodes from ILeo, i.e. if
you have something like this
@= foo
---body---
@cl MyData
blah blah
blah
What it gets translated to is:
g.vs.foo = MyData("blah blah\nblah")
Also see "@cl definitions" from
http://mail.python.org/pipermail/python-list/2008-February/530134.html
(ah, that mail brings me back; valuespace is spiritual successor of
ILeo work, a more "mature" and conservative implementation of the
ideas, if you will)
Or
http://webpages.charter.net/edreamleo/IPythonBridge.html#cl-definitions
Ville M. Vainio
> Seems like markup to serialize hierarchies and generate content,
> a markup/templating syntax specific to Leo.
>
> Is that description anywhere close?
Not really :).
@r nodes generate content, but otherwise the introduced rules are
about *collecting* instead of generating. @r nodes generate (body)
text from data collected by the (imho more interesting / important) @x
parts.
My next plan is to plug in a templating system to really generate text
from data in g.vs. This requires analysis of the existing ones:
http://wiki.python.org/moin/Templating
and, picking one that can optimally be installed in /leo/external. Or
we could support several of these from plugins. Mako / Jinja2 /
Cheetah...
Semantically, the templating system would be like @nosent, but the
text gets expanded before written to disk.
Edward K. Ream
> On Fri, Apr 8, 2011 at 3:09 PM, Edward K. Ream <edre...@gmail.com> wrote:
>
>> And another thing :-) I'd like to create a plugin controller for this
>> plugin. This will allow more flexibility, for example for options.
>
> Have a blast :). I wrote it knowing I only have a bit of time for
> implementation, so I didn't bother making it "modular" or whatnot.
>
> Just promise one thing - avoid subclasses :).
No fear of that.
Edward
Terry Brown
"Ville M. Vainio" <viva...@gmail.com> wrote:
> http://wiki.python.org/moin/Templating
That list lists Genshi as an XML templating system, but it also
supports text. Genshi allows complex python in the template, which
can, if misused, violate logic / presentation separation, but, if used
wisely, lets you get stuff done without having to learn how the
template system represents "%04d"%x for example. In Django's templates
that would be {{x|stringformat:"04d"}}, in Genshi it would be
${"%04d"%x} (from memory). Both are ok, but Genshi's requires less
learning.
I'm not sure of Genshi's development status.
Cheers -Terry