damonwang / xraylarch Goto Github PK

instead of a separate output window and input line, have a unified shell that prints a new prompt at the bottom when ready? We could put the larch->python transformations into the PyShell code with very little work.

I'd actually prefer to embed ipython, because I think it has better "magic" commands, coloring, error handling, and scipy/numpy integration, but I don't know how to put larch into ipython and I'd probably have to write a fair amount of glue to put ipython into a wx object.

the executable script that runs a CLI interpreter is called larch, so the source is in a directory called lib, which means to get the dev copy you need to import lib instead of import larch. This is bad because we'll have to change the import statements every time we package a new release up for production.

Interpreter.on_delete has no clause for
del a[5]

currently, defined variables are instances of a DefinedVar class, and these instances get bound to a name in the symbol table. The DefinedVar class just re-implements the property functionality.

If you change your search groups, do the bindings in your defined variables change also? That is, are the symbols resolved each time the variable is accessed, or just once when it is defined?

So if we have
_sys.path = [ 'A', 'B', 'C' ]
and each directory has a copy of foo, then
import foo
will import a copy from A, then overwrite that with the copy from B, then overwrite that with the copy from C. This is not only inefficient but counterintuitive. We should follow the example of the PATH environment variable, which is interpreted as descending priority.

Expect that
set_symbol('foo.bar.baz', 1)
would create a group foo containing a group bar containing an int baz which is equal to 1.

Most of the larch objects map onto Python objects already: e.g., DefinedVar, Group, etc.

e.g., builtin methods like capitalize for str objects

Most people will use this to browse through their data, so they will be more interested in variables than in methods.

Maybe move methods into the main text window for the object?

originally was, "larch doesn't import directory-style modules", before I figured out I had to customize the search path.

li = larch.interpreter.Interpreter()
li.push("a =")
li.push("1")

fails because the interpreter sees
a =
1

like what happens automatically when you open a file in the dataviewer

maybe a hook for changing to the Data tab?

I'd like to make
mf.diamond_line_002.plot(x=mf.diamond_line_002.Sample_X, y=mf.diamond_line_002.i0)
look more like
cd mf.diamond_line_002
plot(x=Sample_X, y=i0)

A quick wrapper around an assignment into _sys.localGroup might work, if larch is smart enough to automatically convert Python namespaces (e.g., class namespaces) into groups.

sample syntax:

open("foo.002")

and it would guess the filetype, create the appropriate DataSheet, and show some chrome for plotting the data

just need to override runsource and runcode to apply the larch->python transformations first and then punt to larch.Interpreter.interp

better for them to be first-class in the dataviewer application, at the same level as data sheets, so they can more easily draw from multiple datasheets for their input.

should ask Dr. Newville how often people plot from different sources in the same graph.

is there really a sensible way to solve this? I think we should just declare that larch modules cannot reuse python module names. This doesn't seem like a burdensome handicap.

li("not (yes or yes)") returns True

li("import csv")

where li is an interpreter, does not produce a csv symbol anywhere in the symbol table when run from within iPython

As a script, the initial import works but reloading does not restore deleted or altered attributes.

for i in arange(10):
print i
#endfor

produces no output, and no print statements following it produce any output either.