Suppressing verbosity in the replpad

Development Web
1

I am developing a replpad app but I want the users to go straight to a URL and start the app. I'd rather that they didn't have to type

import @rx

when a lot of module stuff is sent to the console interrupting the interface, eg

`== make module! [
    alpha: make bitset! #{00000000000000007FFFFFE07FFFFFE0}  
    rx: '#[action! {rx} [drug]]  
    ...

`

Maybe http://hostilefork.com/media/shared/replpad-js/@rx would be better and if a module is provided then verbose mode is automatically suppressed.

Anyway, suggestions for a standardised way to run our apps?

1 Like
2

if a module is provided then verbose mode is automatically suppressed.

My main thought about verbosity is that we should think about options beyond just "on" and "off".

Verbose output is something that is helpful when debugging, but you don't always know in advance if you're going to end up in a situation that needs debugging or not. So having a log running regardless is the best default option--then you can choose to view it after the fact.

This is demonstrated fairly well by the JavaScript console in browsers. Users aren't troubled by it if all goes well...but if something goes wrong you can bring it up. Errors are highlighted distinctly from just basic logging.

In the case of the ReplPad, we can actually leverage this by sending the information about module loads and such to the browser console--as opposed to the ReplPad console. That seems like a reasonable default, and then maybe have a way to send it to the standard output.

When you're running in a desktop console, there could be options:

  • Write informational logging output to a file
  • Mix it in with the console output
  • Just keep the last N lines of it in memory and be able to ask for it on an as-needed basis

One thing I worry about is superfluous logging that isn't visible getting out of hand and taking up memory and time... so there should be some way of knowing a lot of logging output is being made. Not sure when these notices would be given, but perhaps something it says when it prints out a prompt.

1 Like
3

This notation seems nice, but the way browsers work this can't be dispatched to a single script living at http://hostilefork.com/media/shared/replpad-js/.

When serving the ReplPad statically, the only way to do that is with the URI "query" and "fragment" portions...so it has to be done with things that follow a question mark or a hash mark. Such as http://hostilefork.com/media/shared/replpad-js/?import=@rx or similar.

In order to do better, there has to be actual server-side code before the page is fetched as part of the "dispatch", which somehow routes the information to the page. That would be worth it for a hosted service that's trying to be as slick as possible...but the ReplPad is not being prescriptive about the server-side hosting at this time.

It's something we should keep in mind for https://example.com/@rx when things are streamlined.

1 Like