Re: FW: Periodic Table of the Operators
On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: > > My console can be any of several platforms - in the last couple of weeks > it has been a Linux box, a Windows PC, a Mac, a Sun workstation, and a > real vt320 attached to a Sun. My mail sits on a hosted Linux box. To > read it, I sometimes ssh in to the machine and read it using mutt in > screen. At other times I read it using Mozilla Thunderbird over IMAP. > In Thunderbird, the odd characters show up. But when I'm using a > terminal session, I have found that the only practical way of getting > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > course, the main culprit in forcing me to vt100 emulation. I can recommend PuTTY for windows. Secure, small[1], fast, featureful and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ I'm using it now to ssh from a windows laptop to read email using mutt in screen. Tim. [1] So small it easily fits on a floppy. I keep a copy on my USB memory drive.
Re: FW: Periodic Table of the Operators
On Tue, Jun 08, 2004 at 11:30:51AM +0100, Tim Bunce wrote: > On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: > > But when I'm using a > > terminal session, I have found that the only practical way of getting > > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > > course, the main culprit in forcing me to vt100 emulation. > I can recommend PuTTY for windows. Secure, small[1], fast, featureful > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > I'm using it now to ssh from a windows laptop to read email using > mutt in screen. I can get it working with a Windows client, or a Mac client, or a $other_client, but I could never find any combination of voodoo that would work with *all* clients, so that I can disconnect (while leaving mutt running) then reconnect some random time later on some other platform and have it Just Work and have odd characters show up correctly. TERM=vt100 was the only way to get consistent results. Yes, I tried putty. I also tried cygwin/xfree86/xterm/openssh, to no avail. -- Lord Protector David Cantrell | http://www.cantrell.org.uk/david Lefties are usually well-intentioned at least, and possess a far greater command of grammar and spelling. -- Noel, in soc.history.what-if
Re: Periodic Table of the Operators
On Tue 08 Jun 2004 12:35, David Cantrell <[EMAIL PROTECTED]> wrote: > On Tue, Jun 08, 2004 at 11:30:51AM +0100, Tim Bunce wrote: > > On Mon, Jun 07, 2004 at 10:52:32PM +0100, David Cantrell wrote: > > > But when I'm using a > > > terminal session, I have found that the only practical way of getting > > > consistent behaviour wherever I am is to use TERM=vt100. Windows is, of > > > course, the main culprit in forcing me to vt100 emulation. > > I can recommend PuTTY for windows. Secure, small[1], fast, featureful > > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > > I'm using it now to ssh from a windows laptop to read email using > > mutt in screen. > > I can get it working with a Windows client, or a Mac client, or a > $other_client, but I could never find any combination of voodoo that > would work with *all* clients, so that I can disconnect (while leaving > mutt running) then reconnect some random time later on some other > platform and have it Just Work and have odd characters show up correctly. > TERM=vt100 was the only way to get consistent results. Yes, I tried > putty. I also tried cygwin/xfree86/xterm/openssh, to no avail. isn't that what 'screen' is for? --8<--- man screen SCREEN(1) SCREEN(1) NAME screen - screen manager with VT100/ANSI terminal emulation SYNOPSIS screen [ -options ] [ cmd [ args ] ] screen -r [[pid.]tty[.host]] screen -r sessionowner/[[pid.]tty[.host]] DESCRIPTION Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells). Each virtual terminal provides the functions of a DEC VT100 terminal and, in addition, sev- eral control functions from the ISO 6429 (ECMA 48, ANSI X3.64) and ISO 2022 standards (e.g. insert/delete line and support for multiple character sets). There is a scroll- back history buffer for each virtual terminal and a copy- and-paste mechanism that allows moving text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out : : -->8--- -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using perl-5.6.1, 5.8.3, & 5.9.x, and 809 on HP-UX 10.20 & 11.00, 11i, AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/ http://archives.develooper.com/[EMAIL PROTECTED]/ [EMAIL PROTECTED] send smoke reports to: [EMAIL PROTECTED], QA: http://qa.perl.org
Apocalypse 6: IDs of subroutine wrappers should be objects
Hello,
quoting Apocalypse 6:
> You may ask a subroutine to wrap itself up in another subroutine in
> place, so that calls to the original are intercepted and interpreted by
> the wrapper, even if access is only through the reference:
>
> $id = $subref.wrap({
> # preprocessing here
> call;
> # postprocessing here
> }
[...]
> The $id is useful for removing a particular wrapper:
>
>$subref.unwrap($id);
One should be able to unwrap $subref using
$id.unwrap();
Or, given $id, it'd be cool if you could get the original $subref:
my $origsubref = $id.sub();
Additionally, $id could coerce to an ID number in numeric context, so
$subref.unwrap($id);
would still be valid code (==> TIMTOWTDI).
What are your opinions on this? BTW, Perl5/Tk has the same problem IMHO:
my $canvas = $widget->Canvas;
my $id = $canvas->createLine(...);
...;
$canvas->raise($id);
# Better:
$id->raise;
Sorry if this was discussed before, didn't found anything.
Ingo Blechschmidt
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
Ingo Blechschmidt wrote:
Hello,
quoting Apocalypse 6:
You may ask a subroutine to wrap itself up in another subroutine in
place, so that calls to the original are intercepted and interpreted by
the wrapper, even if access is only through the reference:
$id = $subref.wrap({
# preprocessing here
call;
# postprocessing here
}
[...]
The $id is useful for removing a particular wrapper:
$subref.unwrap($id);
One should be able to unwrap $subref using
$id.unwrap();
Something tells me that you shouldn't be able to do that. Wrapping is an
operation on the subref, which implies very strongly to me that
unwrapping should also be an action on the subref.
Or, given $id, it'd be cool if you could get the original $subref:
my $origsubref = $id.sub();
Additionally, $id could coerce to an ID number in numeric context, so
$subref.unwrap($id);
would still be valid code (==> TIMTOWTDI).
At the very least you'd have to be able to do that as well, I get this
uneasy feeling about having to do $id.unwrap();. unwrap would be the
wrong method anyway - it implies unwrapping $id itself, which seems
wrong because $id isn't wrapped, it's wrapped around something else.
Maybe $id.remove() or $id.tear_off() or $child.give_present($id), which
would cause unwrapping to happen very, very quickly and messily.
On the other hand, what happens when you call $id.unwrap() (or
$subref.unwrap($id)) if $id is an object? What happens to $id? Does it
turn into some kind of limbo object? Does it become undefined? Is it
right for $subref.unwrap($id) to be able to do that to $id? Is it right
for $id to be able to do it to itself?
Hmm. Not a very useful email really. Oh well. It's too hot to think
straight.
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
Ingo Blechschmidt writes: > One should be able to unwrap $subref using > $id.unwrap(); > > Or, given $id, it'd be cool if you could get the original $subref: > my $origsubref = $id.sub(); > > Additionally, $id could coerce to an ID number in numeric context, so > $subref.unwrap($id); > would still be valid code (==> TIMTOWTDI). Yep, definitely. $id would of course become invalid after such an operation, which I think is reasonable. Luke > What are your opinions on this? BTW, Perl5/Tk has the same problem IMHO: > my $canvas = $widget->Canvas; > my $id = $canvas->createLine(...); > ...; > $canvas->raise($id); > # Better: > $id->raise; > > > Sorry if this was discussed before, didn't found anything. > > > Ingo Blechschmidt
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
On Tue, Jun 08, 2004 at 01:08:13PM -, Ingo Blechschmidt wrote:
> Hello,
>
> quoting Apocalypse 6:
> > You may ask a subroutine to wrap itself up in another subroutine in
> > place, so that calls to the original are intercepted and interpreted by
> > the wrapper, even if access is only through the reference:
> >
> > $id = $subref.wrap({
> > # preprocessing here
> > call;
> > # postprocessing here
> > }
> [...]
> > The $id is useful for removing a particular wrapper:
> >
> >$subref.unwrap($id);
Hmmm. What happens when I do this?:
$id1 = $subref.wrap({ });
$id2 = $subref.wrap({ });
$id3 = $subref.wrap({ });
$id4 = $subref.wrap({ });
$subref.unwrap($id3);
First off, is this even valid?
Second, what does it do under the hood? Does it need to tear off
wrappers 1 and 2 before tearing off #3? Does it need to recompile
wrappers 1 and 2? What kind of speed hit am I looking at?
--Dks
Re: Apocalypse 6: IDs of subroutine wrappers should be objects
On Tue, 8 Jun 2004, David Storrs wrote:
> On Tue, Jun 08, 2004 at 01:08:13PM -, Ingo Blechschmidt wrote:
> > Hello,
> >
> > quoting Apocalypse 6:
> > > You may ask a subroutine to wrap itself up in another subroutine in
> > > place, so that calls to the original are intercepted and interpreted by
> > > the wrapper, even if access is only through the reference:
> > >
> > > $id = $subref.wrap({
> > > # preprocessing here
> > > call;
> > > # postprocessing here
> > > }
> > [...]
> > > The $id is useful for removing a particular wrapper:
> > >
> > >$subref.unwrap($id);
>
> Hmmm. What happens when I do this?:
>
>$id1 = $subref.wrap({ });
>$id2 = $subref.wrap({ });
>$id3 = $subref.wrap({ });
>$id4 = $subref.wrap({ });
>
>$subref.unwrap($id3);
>
> First off, is this even valid?
I'm pretty sure it is, yes.
> Second, what does it do under the hood?
First, it sends e-mail to our Quantum Ninjas who may or may not do
Horrible Things to you... (We're never sure)
> Does it need to tear off
> wrappers 1 and 2 before tearing off #3? Does it need to recompile
> wrappers 1 and 2?
There's no compilation for wrappers when they're installed, so there won't
be any need to recompile on removal. Wrappers will all be done with
chained PMCs, so we'll just remove the removed wrapper from the chain.
> What kind of speed hit am I looking at?
Should take no more than a week, on average. Two, tops.
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: This fortnight's summary
The Perl 6 Summarizer wrote: "PIO_unix_pipe()" Leo's implemented a "PIO_unix_pipe()" method which allows you to run an external program and capture the results with a Parrot IO handle. He doctored the "open" opcode to use it pipe = open "/bin/ls -l", "-|" While that's right regarding above syntax snippet, the credits for C belong to Melvin Smith, who'd implemented it in the first place. I did just (as normal) make it more workable. "Doctored" is ok, though ;) leo - this is the usual "thanks for your summariies, Piers, but ..."
Re: FW: Periodic Table of the Operators
Tim Bunce skribis 2004-06-08 11:30 (+0100): > I can recommend PuTTY for windows. Secure, small[1], fast, featureful > and free: http://www.chiark.greenend.org.uk/~sgtatham/putty/ > [1] So small it easily fits on a floppy. I keep a copy on my USB memory drive. So small that even on modem lines, you can afford to download it each time you start it: http://startputty.com/ - if you trust them. Juerd
