Re: perl6's new name?

2019-08-13 Thread David E.
It's been said before, but I do think that the "Perl6" name is holding back adoption. Too many people think of the old Perl, and have no interest in looking at what's changed in a new version of the "same" language. Whatever the new name ultimately becomes, changing it (perhaps timed with a new ma

Memory leak with NativeCall

2018-01-21 Thread David E.
I'm not certain where to report this (ie: rakudo vs MoarVM), so I'm starting here. After some experimentation, I finally traced down a segfault I've been getting to a memory leak in the NativeCall interface. I'm using it to facilitate testing of a 32-bit embedded (meaning no dynamic allocation) C

Re: Memory leak with NativeCall

2018-01-22 Thread David E.
7;ve been sick lately and I am on heavy > antihistamines, so I could just have medicine head. > > Here's the document I'm drawing this guess from: https://docs.perl6.org/ > language/nativecall#Function_arguments > > On Jan 21, 2018, at 19:24, David E. wrote: > > I

Re: Memory leak with NativeCall

2018-01-23 Thread David E.
om/rakudo/rakudo . > > Thank you! > > > On 22 Jan 2018, at 01:24, David E. wrote: > > > > I'm not certain where to report this (ie: rakudo vs MoarVM), so I'm > starting here. > > > > After some experimentation, I finally traced down a segfault I&#

Re: [perl #130512] Proc::Async STDIN isn't handled correctly for all apps

2017-01-20 Thread David E.
he "ssh -t -t" approach seems to be the best workaround until somebody develops a true Expect module for Perl6, or extends Proc::Async to support PTYs. On Tue, Jan 17, 2017 at 3:41 PM, Brandon Allbery via RT < perl6-bugs-follo...@perl.org> wrote: > On Wed, Jan 4, 2017 a

Re: TAI time

2000-08-18 Thread David E. Wheeler
Mark-Jason Dominus wrote: > > TAI is an international time standard. It has a number of technical > advantages over UTC. One of these advantages is that it doesn't have > any silly truck with leap seconds. ... Why, this sounds perfect, Mr. D! When will you write the RFC? David

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-01 Thread David E. Wheeler
Michael Fowler wrote: > > On Fri, Sep 01, 2000 at 11:41:47AM -0700, David E. Wheeler wrote: > > Michael Fowler wrote: > > > > > > my Dog $spot; # $spot is now a blessed Dog object > > > $spot->name("Fido");# $spot

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-01 Thread David E. Wheeler
Michael Fowler wrote: > > my Dog $spot; # $spot is now a blessed Dog object > $spot->name("Fido");# $spot->{'name'} eq "Fido" > > print ref $spot;# yes, "Dog" > > $spot = new Dalmation; # now $spot is a Dalmation object Yes, but the Dalmation $spot will *

Re: RFC 188 (v1) Objects : Private keys and methods

2000-09-02 Thread David E. Wheeler
On 1 Sep 2000, Perl6 RFC Librarian wrote: > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects : Private keys and methods Here, here & amen, Damian! This one gets my instant vote! David

Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly

2000-09-02 Thread David E. Wheeler
On Sat, 2 Sep 2000, Nick Ing-Simmons wrote: > Damian Conway <[EMAIL PROTECTED]> writes: > > > > But I agree that anything beyond that is simply horrible. You'll only > > > > drive more people *away* from OO, because it generates so horribly > > > > inefficient code. If you want a constructo

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Damian Conway wrote: > > Stupid, stupid, stupid! Of course, that should be: > > attr3 => __ALL__ > > and then delegated methods can be named any(crazy)thing. Damn, Damian, don't be so hard on yourself! You're right about __ALL__, of course, but I suspect that most of us would have a pr

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Damian Conway wrote: > Err, that *is* the default behaviour. Delegation doesn't occur unless > you specify it. Or am I missing your meaning here? use delegation attr1 => [qw( method1 method2 method3 )], attr2 => [qw( method4 method5 )], attr3 => __ALL__, # Use all of them. attr4

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Damian Conway wrote: > It was (and is) a good suggestion. I suspect however that it should be > > attr3 => [__ALL__] > > so that classes can still have an C method delegated. > (Yes, now they can't have an C<__ALL__> method, > but maybe that's a Good Thing ;-) Agreed. Yes, that's very goo

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
"David L. Nicol" wrote: > > When you want to turn off an inherited delegation in an ISA situation? Um, I don't think I understand the question. Delegation is not inherited. Any module you inherit from you won't use for delegation, AFAIK. They're two different beasts. Or am I misunderstanding yo

Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread David E. Wheeler
Perl6 RFC Librarian wrote: > > This and other RFCs are available on the web at > http://dev.perl.org/rfc/ > > =head1 TITLE > > Objects : Core support for method delegation This idea rocks, Damian! I want it now! Just one suggestion, however... > The proposed delegation mechanism would work