Brython Shell Live Demo

[Carl Smith]

I recently started porting some of the ideas from another shell to create a Brython one. There's now a version of the Brython one online for people to play with. This is just a demo. There's lots of missing features [it doesn't even have line history yet], and probably only works in Chrome, but I'll keep pushing to this URL over time so people can easily see what's going on.

Only two controls have been implemented [Meta means Cmd on Mac and Ctrl everywhere else]:

    Meta+Enter: Execute the contents of the 'slate'.

    Meta+Escape: Clear the screen of output.

I'll update this thread with any news.

Thanks -- cs

[Christophe Gragnic]

On Mon, May 19, 2014 at 5:05 PM, Carl Smith <carl....@gmail.com> wrote:
> I'll update this thread with any news.

Can we update this thread with rants too? ;)
I guess you are aware of them, just to let you know someone tested it.
If not I can post issues

1) I miss the >>>.
2) If the expression doesn't return None, maybe you should print the
returned value.
3) I guess I'm off-topic if I give these links:
http://terminal.jcubic.pl/
https://github.com/replit/jsrepl
since your goal is to implement a REPL yourself, but they may be of
good inspiration.
4) About the links at the top right « docs | repo | chat », I was
surprised that you link to
Brython sites. I thought «docs» were about this REPL, «repo» the repo
of your REPL
and «chat» a multi user REPL (note the idea!).

Congrats so far, the visuals are really nice.


chri

--

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg

[Carl Smith]

Can we update this thread with rants too? ;)

Of course :) 

I guess you are aware of them, just to let you know someone tested it.
If not I can post issues

1) I miss the >>>

As the shell develops to be a bit more like nush, you'll find that you tend to use the little, built-in command system for a lot of things, and there'll be the option to attach your own little parsers too, so you end up using commands more than you'd expect. The rest of the time, you're writing substantial blocks of code, often commands, but also classes and so on, so you don't really miss the prompt in practice. Note that the commands are always one liners and auto execute on a newline [so you can just hit Enter].

It all feels more like a cross between an text editor and a CLI. It's ACE, so you can toggle line numbers, scroll lines/blocks of text, fold blocks etc. in the slate, but it's also a lot like a REPL.

 

2) If the expression doesn't return None, maybe you should print the
returned value.

Yep. It's just early days. It should.

 

3) I guess I'm off-topic if I give these links:
http://terminal.jcubic.pl/
https://github.com/replit/jsrepl
since your goal is to implement a REPL yourself, but they may be of
good inspiration.

Thanks. I hadn't seen the top one, but had seen the other. Nice one.

    WARNING: The rest of this post is all big ideas...

The thing I'm looking to do differently is to kind of embrace the browser, not just run inside it.

There've been quite a few efforts to build clientside terminal emulators, and other stuff like that. Fair play to them, I'm not knocking it, but vim and all those old school apps are dead to me. REPLs are still awesome, so I want them, but have no reason then to obey the constraints of old school terminals.

I personally love HTML5. JavaScript's becoming an excellent language for event oriented, GUI hacking, but it needs something like Python too. JS is good for functional stuff, hooking up the UI, handling events and so on. Python can handle complexity and scale easily. The recipe is HTML5 and Python3.

One thing nush has, which I'll be adding to this shell's globals by default, is a put function to complement print. The idea is printed stuff is escaped to look exactly like regular stdout, where put stuff is not escaped, so you can put HTML unescaped [literally anything your browser can render]. You can also update this HTML, so an object could have a graphical repr that updates over time or whatever you need.

HTML5 is the graphics layer Python sorely needs.

You can also open new tabs and push stuff to them, and share local storage between them; it doesn't have to be in the shell. nush uses tabs to allow you to open a fuller looking instance of ACE in its own tab, letting you use your browser a bit like a tabbed text editor, but still allows you to open a smaller one in the shell [internally by simply pointing an iframe at the same URL as the editor tabs use].

It all starts to fall together after a while. You get to use the full awesomeness of HTML5, instead of rows of monospaced strings, to build anything from little scripts to massive extensions, and a lot of it is very simple to do [no Web to abstract]. The shell still uses monospace strings a lot, but only because they're still the best way for a lot of stuff.

4) About the links at the top right « docs | repo | chat », I was
surprised that you link to
Brython sites. I thought «docs» were about this REPL, «repo» the repo
of your REPL
and «chat» a multi user REPL (note the idea!).

You're right, they probably will confuse. nush has pretty tooltips. I'll keep it in mind [idea noted - it'd be sweet to do live stuff - that'd be an extension].

  

Congrats so far, the visuals are really nice.

Cheers.

If anyone is still reading this, you're obviously interested enough to read the whole post, so I may as well explain what the point is.

My thing on this is to totally integrate the three main interfaces we use everyday, APIs, CLIs and GUIs, into a fat user interface, a FUI :) The way nush kind of works, but it hasn't been made explicit yet, is with these FUI style objects. They're not special; they're just objects that are designed take advantage of the three interfaces the shell provides.

By having methods and attributes that are well suited to interactive use, objects provide an API. It's also not difficult to make some of those methods work as nush style commands, so now the object also has a CLI. It can render mini GUIs in the shell, or pop open one or more tabs to get crazy, so it has a GUI.

These FUI style objects typically live in the global namespace and act as interfaces. You may have a docs one that can render it's stuff in the GUI, but where user's tend to control it with the CLI.

Some will provide services to others, a filesystem one may be useful to the user, but then other objects can also call to it to do work for them too.

These objects can [often will] define a __getattr__ method, so they can take a call to an arbitrary method, pass the call to a server, and return the response [or raise the correct exception].

The big idea is that you can use a shell as your primary interface to the rest of your world again, like a proper hacker, but this time with HD fucking graphics ;)

Thanks again -- cs

[Carl Smith]

* Just added Line History. Use Meta+Up and Meta+Down to scroll it.

- Also removed the nasty looking flash of default ace editor that was visible before the styles we're applied.

[Carl Smith]

Two new shell builtins, put and view...

The put function complements print, but currently only accepts strings as arguments. It does not escape strings and has empty strings as defaults for its sep and end keywords. You can use it to print rendered HTML to the board.

The view function takes a path to a file [as a string] and puts a HTML element to the board based on the file type [based on the extension]. You can use it to view video, audio, imagery and text files [from any origin].

These functions will be much more flexible in the future. They're just a starting point.

[Carl Smith]

Just pushed a new version of the shell.

The view command I'd added got pulled. It can be an extension. Everything else has been tidied up. The shell now has intuitive command history, the put function that takes any objects as args, and the styles have been cleaned up. Exceptions look nicer and the shell inserts whitelines intelligently.

It's still pretty minimal, but it feels nice to use now.

[Kiko]

--

I don't see the point.

What is the objective of your shell?

-The errors are not shown

-Some errors are not caught. For example, if I write psaoijdgopiaw and press crtl+enter I can't see any error in the shell nor the browser console.

-What is the use for 'put'

-Is is possible to manage the DOM and see the result? For example, if I want to create a table, is it possible to see the result?

-I can't see reference to shortcuts nor instructions.

 

You received this message because you are subscribed to the Google Groups "brython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brython+u...@googlegroups.com.
To post to this group, send email to bry...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brython/6e8a710a-a9aa-42ae-b843-0bb41028697b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Carl Smith]

Hi Kiko. Thanks for taking the time.

 

I don't see the point.

What is the objective of your shell?

I have ideas I'd like to explore, but the main point of me posting it here is simply that Brython currently has no shell besides the console and 'editor' on the website. Those tools are not something you can actually use to write software.

 

-The errors are not shown

-Some errors are not caught. For example, if I write psaoijdgopiaw and press crtl+enter I can't see any error in the shell nor the browser console.

Thanks. It is buggy, but I'm working on it. A lot of these things are bugs in Brython, so it's a matter of working through them over time. Interactive programming leans on Brython in ways that write and roll style programming doesn't, so things are bound to come up.

-What is the use for 'put'

The print function's output must be escaped, so it's useful to have a function that can print unescaped strings. It can also check if the object being put has defined it's own HTML repr, and use that string, while still escaping the repr for other objects [only str type objects pass through without processing].

 

-Is is possible to manage the DOM and see the result? For example, if I want to create a table, is it possible to see the result?

If you'd like to see string representations of runtime DOM fragments, for now, you just have to use Dev Tools, but you could write a shell extension that does that stuff in Python if you liked. I'd personally rather extend Dev Tools to play nice with Brython.

 

-I can't see reference to shortcuts nor instructions.

I'm just adding one, but the shortcuts are simple to remember; there are only four:

Meta+Enter: enter the code

Meta+Esc: clear the screen

Meta+Up and Meta+Down: scroll line history

Thanks again.

[Carlo Oliveira]

I like this shell very much. It is clean and maximizes the code workspace. I would like to use in my python classes, and I would ask for a more thorough error report and an option to switch on line numbering.

Thanks for this initiative.

Carlo

[Pierre Quentel]

Nice work Carl. The shell looks good, with a few improvements such as those suggested by Carlo (error line number is a must in my opinion) it will be yet another way of running Python code in the browser, not far from what the Skulpt home page provides

I found that importing Brython-specific builtin modules such as browser or browser.html work, so it's possible to insert DOM elements in the page just like with the Brython editor

There is just one thing I'm not comfortable with, it's the functions put() and view() added to Python built-in names. We had long discussions on the forum months ago, at a time when many names were added by Brython inside the Python namespace, and we concluded that it was better to keep only the CPython names, and to use imports to add other names. For instance, "doc" was a built-in name, it was removed and now it must be inserted in the namespace by "from browser import doc"

If you think functions put and view are useful in the shell I would suggest to put them in a module (shell.py ?) and import them with "from shell import put, view"

Thanks and keep us informed of the next steps
- Pierre

[Carl Smith]

On Sunday, 25 May 2014 20:14:02 UTC+1, Carlo Oliveira wrote:

I like this shell very much. It is clean and maximizes the code workspace. I would like to use in my python classes, and I would ask for a more thorough error report and an option to switch on line numbering.

Thanks for this initiative.

You're very welcome Carlo, thanks. I was looking at exceptions last night and think I have it working better now. I need to pull the newest version of Brython and then I'll push to the demo URL. Either way, getting the most out of exceptions and tracebacks is a priority. Line numbering is available already in the editor, it's built into Ace, I just need to add some way to toggle it on and off easily, but there's no simple way to add line numbers to the output. Is that what you meant?

I'll be adding an editor soon that'll open files in new tabs, there's a screenshot here that shows roughly what it'll look like [tabs with the same origin share a filesystem]. That will have line numbers too.

Thanks again.

[Carl Smith]

On Monday, 26 May 2014 21:30:38 UTC+1, Pierre Quentel wrote:

Le vendredi 23 mai 2014 16:32:21 UTC+2, Carl Smith a écrit :

Just pushed a new version of the shell.

The view command I'd added got pulled. It can be an extension. Everything else has been tidied up. The shell now has intuitive command history, the put function that takes any objects as args, and the styles have been cleaned up. Exceptions look nicer and the shell inserts whitelines intelligently.

It's still pretty minimal, but it feels nice to use now.

Nice work Carl. The shell looks good, with a few improvements such as those suggested by Carlo (error line number is a must in my opinion) it will be yet another way of running Python code in the browser, not far from what the Skulpt home page provides

I hope to go a little beyond what they have, taking advantage of Brython's DOM and JS APIs, where Skulpt, as I understand it, just runs CPython compiled to JS, so it lacks browser hooks.

 

I found that importing Brython-specific builtin modules such as browser or browser.html work, so it's possible to insert DOM elements in the page just like with the Brython editor

There is just one thing I'm not comfortable with, it's the functions put() and view() added to Python built-in names. We had long discussions on the forum months ago, at a time when many names were added by Brython inside the Python namespace, and we concluded that it was better to keep only the CPython names, and to use imports to add other names. For instance, "doc" was a built-in name, it was removed and now it must be inserted in the namespace by "from browser import doc"

If you think functions put and view are useful in the shell I would suggest to put them in a module (shell.py ?) and import them with "from shell import put, view"

Thanks and keep us informed of the next steps
- Pierre

Thanks for the feedback Pierre. You're right about the namespace. I think in a shell it's ok to load some useful extras, but that should still be something the user configures. I've removed the view function already and was toying with removing the put one too. I'll do that. They can go in a module. They were half baked anyway. Removing them and focussing on doing the core features properly is better.

Cheers -- Carl

[Carl Smith]

Quick reflection on introducing stuff into the namespace: The app defines a Shell class and creates a single instance of it named shell. It exists mainly to hold the internals in their own namespace, but it has to exist somewhere for the app to work. It seems ok to leave that one object available as a global, maybe named sh, and have it provide an API to wrap some common stuff, handle config and so on. If it can be cleaned up so anything undocumented or internal can live in sh.internals, then it could provide a nice interface to the app. With the command syntax thing, it could be really helpful. Python syntax can be awkward for interactive coding.

sh.edit("/main.py")

.sh.edit /main.py

e = sh.edit

.e /main.py

It's ok to add a little magic in an interactive environment.