Live editing...

[kirby.urner]

There's been some chatter on edu-sig (python.org) of late regarding
Python's
capabilities in the "edit/continue" tradition, meaning debugging
tools, and/or
IDE tools, that give the developer real time write access to running
programs.

I think a good design would be something like the ZODB, or the ZODB
itself,
to save the entire working environment, like a Smalltalk image, at
which point
a "supervisor Python" (a whole different instance, perhaps on another
chip),
could do "brain surgery" on the "hibernating Python" (like a patient
undergoing
surgery).

You basically simulate or emulate the "operating table" version,
without putting
yourself at its mercy. If you break it completely, while doing your
brain surgery,
just abort the instance and roll back to the previously saved
version. It's like
sitting on top of a version control system, while never getting to
directly edit the
currently operating version (the supervisor).

The alternative, allowing a developer to undermine his/her own running
platform,
seems to unnecessarily conflate a runtime and design time mode, which
isn't
just some stupid prejudice.

We need that separation, just as we keep distance between production
and
development copies of things.

Don't fix a running engine if you can fix an emulated running engine.
Once you're
happy with your changes, commit, and set it running for real. It
still might crash,
which is why you're glad for rollback capabilities.

Smalltalk images meet CVS?

Python atop Mercurial?

Kirby

 

[Ben Finney]

This is unrelated to the topic of the original poster, and is
unrelated to Python; hence the off-topic marker. I'm also not saying
anything targeted at the original poster, but rather using this
message as an opportunity to ask a question.

There's been some chatter on edu-sig (python.org) of late regarding
Python's
capabilities in the "edit/continue" tradition, meaning debugging
tools, and/or
IDE tools, that give the developer real time write access to running
programs.

[... more lines of broken line wrapping...]

What the blazes is Google doing with messages that such a high
proportion of them come through in this painful-to-read double-wrapped
format? I'm referring to the fact that the lines appear to have been
wrapped at one length, and then each line broken again into a long and
a short line.

These are so awkward to read that I usually skip straight past them
without attempting to parse them, which isn't a benefit to anybody
(leaving aside snide remarks about the potential of negative value
from my contributions).

Is it some setting that users are enabling, or is it the default
behaviour?

More importantly, whom do we beat with the clue-by-four to make it
stop?

 

[Paul Rubin]

[... more lines of broken line wrapping...]

What the blazes is Google doing with messages that such a high
proportion of them come through in this painful-to-read double-wrapped
format? I'm referring to the fact that the lines appear to have been
wrapped at one length, and then each line broken again into a long and
a short line.

Users write in a text editor formatting the text into lines of
reasonable size, separated by newline characters. They then paste the
text into a web form, which reformats it with slightly shorter lines
(breaking up the user's longer lines) but leaves the user's newlines
in place.

 

[kirby.urner]

What the blazes is Google doing with messages that such a high
proportion of them come through in this painful-to-read double-wrapped
format? I'm referring to the fact that the lines appear to have been
wrapped at one length, and then each line broken again into a long and
a short line.

I entirely agree with Ben Finney's remarks. Painful for
an author to see a post mangled that way too, writers
being also readers.

Back to the original thread (sort of): I think the deeper
issue is the relationship between "shell" (REPL),
"debugger" (per WingIDE 101 for example) and "runtime"
ala Python just crunching through a .py file.

The OLPC people are pushing for exotic "live debugging"
and think Python is deficient in this regard, not as a
language so much as an environment (which Guido need take
no responsibility for, though he often has and does).

My tossing out of some ZODB-based solutions was mostly
just an ice-breaker. I don't mind that it ended up
prompting discussions of formatting.

Anyway, back to thinking about iterator types:
http://mail.python.org/pipermail/edu-sig/2007-August/008168.html
( python.next() might trigger a fork/jump to a next "live"
interpreter, leaving behind "snake skin" or "ghost" interpreter
available for "live" interventions? ).

Kirby

 

[mensanator]

[... more lines of broken line wrapping...]

What the blazes is Google doing with messages that such a high
proportion of them come through in this painful-to-read double-wrapped
format? I'm referring to the fact that the lines appear to have been
wrapped at one length, and then each line broken again into a long and
a short line.

Users write in a text editor formatting the text into lines of
reasonable size, separated by newline characters. They then paste the
text into a web form, which reformats it with slightly shorter lines
(breaking up the user's longer lines) but leaves the user's newlines
in place.

Google used to provide a preview before actual posting,
but that is no longer available, so there's nothing the
poster can do about it.