RE: [GD-General] Eiffel

[Jamie F. <ja...@qu...>]

<Snip>
ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).
</Snip>

Although it would be nice to have a system where such things are persistent
regardless of whether or not you leave the machine on.

Jamie


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of J
C Lawrence
Sent: 24 December 2001 20:29
To: ph...@me...
Cc: gam...@li...
Subject: Re: [GD-General] Eiffel


On Mon, 24 Dec 2001 11:50:26 -0000
Philip Harris <ph...@me...> wrote:

> I can see why that would cause problems under windows although I
> would guess that your multiple Emacs frames would be one window
> with a lot of children on Windows.

Ahh, MDI.  <retch>

I tend to run windows in terms of contexts.  A virtual desktop will
have a number of windows on it, all applying or related to a given
task.  Typically this will mean a few XEMacs frames, a few xterms, a
few browser windows, etc.  Then repeat that on the next desktop for
the next task (more accurately "frame of mind").

Sometimes its system based.  Currently I have a desktop devoted to
some IPSec work I'm doing on Alice (system name), another devoted to
some InterMezzo stuff going on on Koala, a desktop for root sessions
on various machines (grouped for security reminders), one devoted to
some work stuff I'm doing locally on a protocol stack, another for a
private PHP project, etc

> It's interesting (at least to me) that you find that sort of
> environment so efficient.

I got used to it -- started with the approach roughly 14 years ago
and have never looked back.

> I tend to work the opposite way, the less windows, files and apps
> open at any one time the quicker things move along. Perhaps it's
> Windows imposing its will on me...

At any given time I'll tend to work only on a small subset.  But
then I change subsets fairly regularly.  It might take me several
days, occasionally more than a month, to get back to any particular
context set (private projects particularly tend to suffer such long
gaps), but when I do everything is still there ready and waiting in
the exact same relationship, with the exact same XEmacs edit history
and internal context etc as it had the instant I stopped working on
it -- easy for the mental gears to click back into and start up
again.

ObNote: My work system is inherently built on the assumption that my
systems will have uptimes measured in months.  As such I can
establish and preserve such "work contexts" for extended periods,
building and maintaining their value.  Typically I log into my
desktop once and then don't log back out again until I install a new
kernel (once or twice a year).

  Yeah, its Linux, so I tend to follow the hectic kernel upgrade
  path.  I'd rather do upgrades, and thus reboots, every other year,
  but there are always too many interesting things depending on some
  new kernel rev to tempt me away to upgrading.

> Obviously your approach works very well for you. Do you know of
> other people who work the same way?

I know of a few (perhaps a half dozen), not that many.  Of course a
few of them have copied from me -- usually after having copied my
FVWM RC (which seems to be a viral meme in its own right).

> Is it an apporach you've been using a long time or it still
> evolving?

At the low level it evolves constantly as I adopt new tools and
changes smaller practices.  As you can see from the screenshots
directory I posted a while back, its wasn't that long ago I finally
decided that icons were evil and evicted them from my system.
Similarly I recently moved from Netscape to Galeon (a Gecko based
browser which supports a number of useful UI features such as being
able to restart with all the same windows open and all the same
pages loaded as it had when it was brought down).

My browsing habits haven't changed in detail.  I still follow the
same pattern of reading a page and opening a new window (or TAB in
Galeon's case) on every interesting link as I go along (I almost
never use the forward/back buttons), but now I tend to group pages
in Galeon Windows on a task, character, and interest basis.  As such
I have a Galeon window each containing multiple TABs devoted only to
pages which will require long term study research (typically online
books), another to firewall research, another to IPSec, another to
MUD-Dev, another to blogs, another to performance metrics, another
to Kanga.Nu, another to temp/trash stuff...etc.

> I'm just interested because that sort of approach doesn't seem
> efficient to me at all.

I suspect our work methods are not that different within a single
given project.  In any given contenxt I usually have little going on
(a couple XEmacs frames, a few xterms, a browser or two, a couple
supporting apps, and that's about it).  The likely difference is
that I maintain state and context for many projects and sub-projects
as I go along, that I expect to keep them (and do) for variously
long periods, that I fork such contexts regularly, and that I pop
among them easily.

  I get a lot of startled looks from passersby.

The ticket is not trying to work with them all at once, but building
and storing work contexts such that they're easily context shiftable
among.  Easy support for mental context shifting is the basic
assumption of this work method.

My problem now, and my current big interest in XEMacs UI
development, is seeing how I can shove that same work process down
into editing sessions within XEmacs on a large project.  Too often I
get into a "What is this token and why is it being used quite like
this?" research project, which of course recursively forks as I dig
down into other identical researches on other tokens. I need a way
to tag and lock context frames on those investigations so that I can
later pop back to them, and then usefully pop about among them,
possibly with a matching annotation system.  Barry Warsaw's WinRing
elisp looks very useful as a component for this, but I haven't
settled on a basic approach yet.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general