Re: perl6's new name?
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 major release of the Rakudo implementation), would do much to improve adoption. Camelia could work, but I'll throw in another suggestion that's been in my head for a while: *PANL* - short for "Perl 6 is A New Language". Alternatively, its components can be referred to as the "PAN Language", "PAN Interpreter", "PAN Specification", etc with a possible logo being a frying pan (held by a camel?) mixing up all of the best language concepts & tools ;-) It's short and makes clear that this is a part of the Perl family (for those that care), while still conveying that it is, for all intents and purposes, a new language. -David On Tue, Aug 13, 2019 at 1:21 AM BELOSCAR Christian < christian.belos...@gmail.com> wrote: > Camelia : Excellent idea Eliza, I totally agree with yours arguments and > what a sympathetic non technical name > accorded with its logo and attracting young programmers too. I vote for > this choice with enthusiasm ! > > Chris > > Le lun. 12 août 2019 à 08:15, Eliza a écrit : > >> Hello perl6 world, >> >> I saw the perl6 github issue, just was confused will perl6 change its >> name? >> >> Perl 6 was initially conceived to be the next version of Perl 5. It took >> way too long to mature to an initial release. Meanwhile, people >> interested in taking Perl 5 along, took back the reigns and continued >> developing Perl 5. >> >> Having two programming languages that are sufficiently different to not >> be source compatible, but only differ in what many perceive to be a >> version number, is hurting the image of both Perl 5 and Perl 6 in the >> world. Since the word "Perl" is still perceived as "Perl 5" in the >> world, it only seems fair that "Perl 6" changes its name. >> >> Since Larry has indicated, in his video message to the participants of >> PerlCon 2019 in Riga, that the two sister languages are now old and wise >> enough to take care of themselves, such a name change would no longer >> require the approval of the BDFL. >> >> I would therefore propose to change the name to "the Camelia Programming >> Language" or "Camelia" for short, for several reasons: >> >> the search term "camelia programming language" already brings you to the >> right place. This means that changing the name to "Camelia" will have >> minimal impact on findability on search engines such as Google and >> DuckDuckGo. >> >> the logo / mascot would not need changing: it's just that it now also >> becomes the actual name of the programming language. >> >> "Camelia" in its name, still carries something Perlish inside of it. >> >> The concept of "Camelia" being an implementation of a specification in >> "roast", still stands. The alternative, to use "Rakudo" as the name of >> the language, would cause confusion with the name being used to indicate >> an implementation, and would endanger the separation between >> specification and implementation. >> >> Choosing yet another name, such as Albus, would mean having to start >> from scratch with marketing and getting the name out there. Hence my >> preference for a known name such as "Camelia". >> >> The "Camelia" logo is still copyright Larry Wall, so it would allow >> Larry to still be connected to one of the programming languages that he >> helped get into the world. >> >> https://github.com/perl6/problem-solving/issues/81 >> >> regards, >> Eliza >> >
Memory leak with NativeCall
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
library in an easier/more-comprehensive way than I could otherwise --
though this memory leak is preventing me from running the long-duration
tests that I need to.
I'm currently running 2017.12.1
(commit c84ed2942d224e4cd524fa389e0603e4e4642f77) under a 32-bit Docker
Ubuntu image (I started with 2017.10). I can easily observe the memory
leak using "docker stats". At it's worst, with my full application, I'm
seeing approximately 0.01 GiB of memory per second getting lost.
Below is sample code that is able to reproduce the leak. I believe that it
has something to do with the callback, maybe with the C-string conversion.
Please advise,
thanks,
-David
test_memleak.pl6:
use v6;
use NativeCall;
constant LIB_DTEST = 'libtestlib.so';
sub dtest_log_init(&dt_csv_log (Str)) is native(LIB_DTEST) {*};
sub test_cb() is native(LIB_DTEST) {*};
sub dt_csv_log(Str $data)
{
prompt "dt_csv_log($data)";
}
sub MAIN()
{
dtest_log_init(&dt_csv_log);
while 1 {
# prompt "Call test_cb()";
test_cb();
}
}
test_memleak.c:
#include
void (*dtlf)(char* s);
void dtest_log_init(void (*fp)(char* s))
{
printf("Assigning dtlf to fp=0x%x\n", (int)fp);
dtlf = fp;
}
void test_cb(void)
{
dtlf("test_cb");
}
The following is a snippet from my Dockerfile that installed perl6:
&& git clone https://github.com/rakudo/rakudo/ /root/rakudo \
&& echo 'export
PATH="$HOME/rakudo/install/bin:$HOME/rakudo/install/share/perl6/site/bin:$PATH"'
>> ~/.bashrc \
&& cd ~/rakudo && git checkout master && git pull \
&& git checkout $(git describe --abbrev=0 --tags) \
&& perl Configure.pl --gen-moar --gen-nqp --backends=moar \
&& make && make install \
Re: Memory leak with NativeCall
It looks like the String may not be at fault - changing the argument to an
int32 pointer results in the same memory leak. In either case, the
variable is allocated on the static in the C function and would be
automatically freed when the function returns, so the problem has to be
some temporary attributes that Perl6/Nativecall is allocating but not
freeing up to wrap the callback's inputs.
Thanks for the response Michael (and feel better).
On Sun, Jan 21, 2018 at 9:35 PM, Michael Stemle
wrote:
> I believe that this is actually a result of Perl 6 delegating
> responsibility of memory management for arguments passed to callbacks from
> native code to the native code.
>
> I wonder if the issue is that you're sending a constant which is being
> reallocated and recreated and never cleared out from the native code.
>
> Keep in mind, however, I'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'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
> library in an easier/more-comprehensive way than I could otherwise --
> though this memory leak is preventing me from running the long-duration
> tests that I need to.
>
> I'm currently running 2017.12.1 (commit
> c84ed2942d224e4cd524fa389e0603e4e4642f77)
> under a 32-bit Docker Ubuntu image (I started with 2017.10). I can easily
> observe the memory leak using "docker stats". At it's worst, with my full
> application, I'm seeing approximately 0.01 GiB of memory per second getting
> lost.
>
> Below is sample code that is able to reproduce the leak. I believe that
> it has something to do with the callback, maybe with the C-string
> conversion.
>
> Please advise,
> thanks,
> -David
>
>
> test_memleak.pl6:
>
> use v6;
> use NativeCall;
>
> constant LIB_DTEST = 'libtestlib.so';
>
> sub dtest_log_init(&dt_csv_log (Str)) is native(LIB_DTEST) {*};
> sub test_cb() is native(LIB_DTEST) {*};
>
> sub dt_csv_log(Str $data)
> {
> prompt "dt_csv_log($data)";
> }
>
> sub MAIN()
> {
> dtest_log_init(&dt_csv_log);
>
> while 1 {
> # prompt "Call test_cb()";
> test_cb();
> }
> }
>
>
> test_memleak.c:
>
> #include
> void (*dtlf)(char* s);
> void dtest_log_init(void (*fp)(char* s))
> {
> printf("Assigning dtlf to fp=0x%x\n", (int)fp);
>dtlf = fp;
> }
> void test_cb(void)
> {
> dtlf("test_cb");
> }
>
>
> The following is a snippet from my Dockerfile that installed perl6:
>
> && git clone https://github.com/rakudo/rakudo/ /root/rakudo \
> && echo 'export
> PATH="$HOME/rakudo/install/bin:$HOME/rakudo/install/share/perl6/site/bin:$PATH"'
> >> ~/.bashrc \
> && cd ~/rakudo && git checkout master && git pull \
> && git checkout $(git describe --abbrev=0 --tags) \
> && perl Configure.pl --gen-moar --gen-nqp --backends=moar \
> && make && make install \
>
>
>
>
Re: Memory leak with NativeCall
Done, thanks.
https://github.com/rakudo/rakudo/issues/1440
On Mon, Jan 22, 2018 at 4:14 PM, Elizabeth Mattijsen wrote:
> This feels like a bug to me. So please make report this as a potential
> issue, either by mailing rakudo...@perl.org, or by creating an issue on
> http://github.com/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'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
> library in an easier/more-comprehensive way than I could otherwise --
> though this memory leak is preventing me from running the long-duration
> tests that I need to.
> >
> > I'm currently running 2017.12.1 (commit
> > c84ed2942d224e4cd524fa389e0603e4e4642f77)
> under a 32-bit Docker Ubuntu image (I started with 2017.10). I can easily
> observe the memory leak using "docker stats". At it's worst, with my full
> application, I'm seeing approximately 0.01 GiB of memory per second getting
> lost.
> >
> > Below is sample code that is able to reproduce the leak. I believe that
> it has something to do with the callback, maybe with the C-string
> conversion.
> >
> > Please advise,
> > thanks,
> > -David
> >
> >
> > test_memleak.pl6:
> > use v6;
> > use NativeCall;
> >
> > constant LIB_DTEST = 'libtestlib.so';
> >
> > sub dtest_log_init(&dt_csv_log (Str)) is native(LIB_DTEST) {*};
> > sub test_cb() is native(LIB_DTEST) {*};
> >
> > sub dt_csv_log(Str $data)
> > {
> > prompt "dt_csv_log($data)";
> > }
> >
> > sub MAIN()
> > {
> > dtest_log_init(&dt_csv_log);
> >
> > while 1 {
> > # prompt "Call test_cb()";
> > test_cb();
> > }
> > }
> >
> > test_memleak.c:
> > #include
> > void (*dtlf)(char* s);
> > void dtest_log_init(void (*fp)(char* s))
> > {
> > printf("Assigning dtlf to fp=0x%x\n", (int)fp);
> >dtlf = fp;
> > }
> > void test_cb(void)
> > {
> > dtlf("test_cb");
> > }
> >
> > The following is a snippet from my Dockerfile that installed perl6:
> > && git clone https://github.com/rakudo/rakudo/ /root/rakudo \
> > && echo 'export
> > PATH="$HOME/rakudo/install/bin:$HOME/rakudo/install/share/perl6/site/bin:$PATH"'
> >> ~/.bashrc \
> > && cd ~/rakudo && git checkout master && git pull \
> > && git checkout $(git describe --abbrev=0 --tags) \
> > && perl Configure.pl --gen-moar --gen-nqp --backends=moar \
> > && make && make install \
> >
>
Re: [perl #130512] Proc::Async STDIN isn't handled correctly for all apps
It sounds like the functionality here would be a low-priority feature request, that perhaps might belong in a separate module from a technical perspective. In either case, the official documentation ( https://docs.perl6.org/type/Proc::Async) needs to be updated to reflect this limitation. Providing methods to tap into STDIN and STDOUT of a launched application combined with the statement of "Proc::Async allows you to run external commands asynchronously, capturing standard output and error handles, and optionally write to its standard input." would reasonably imply to any developer/user that this library is meant to work for any command. The subtleties of pipes versus PTYs are not mentioned anywhere in the documentation, and is a topic that nobody not familiar with the low-level guts of the terminals is likely to know (myself included). While it adds a lot of overhead, the "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 at 11:20 PM, David E. > wrote: > > > SSH is one example. When using key-based logins everything works > > perfectly. If not using key-based logins (as required for a certain > piece > > of hardware I need to work with), the password prompt is not captured by > > Proc::Async. STDIN is read directly from the user shell, and the prompt > > itself is never output from the 'tapped' stdout. Further, SSH will > refuse > > to get even that far if the "-T" parameter is not given to it. > > > > Screen is another example (I'm trying to use this because > > Device::SerialPort hasn't been ported to Perl6 yet). No matter what I > try, > > screen always aborts with the error "Must be connected to a terminal." > > > > Strictly speaking, this is not a bug: the interface for these kinds of > programs is usually some variant of expect (the original being in Tcl, with > versions for Perl 5, Python, and other languages). ptys are a more limited > and more complex (and *far* less portable, in particular not possible on > Windows) resource than pipes, and general subprocess interfaces usually > aren't suitable; and adding the necessary logic to allow ptys to work > properly complicates the common case considerably. > > The portability concern also means that pty support likely does not belong > in Perl 6's core, but should be provided by a POSIX support module. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > >
Re: TAI time
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
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->{'name'} eq "Fido"
> > >
> > > print ref $spot;# yes, "Dog"
> > >
> > > $spot = new Dalmation; # now $spot is a Dalmation object
> >
> > Yes, but the Dalmation $spot will *not* have the name "Fido," will it?
>
> Nope, $spot is now an entirely new object.
Well then, that makes this example rather wasteful, doesn't it?
my Dog $spot;
if ($input eq 'Collie') {
$spot = Collie->new;
} elsif ($input eq 'Dalmation') {
$spot = Dalmation->new;
}
Becuase we're creating two objects when we really only want one.
David
Re: RFC 171 (v2) my Dog $spot should call a constructor implicitly
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 *not* have the name "Fido," will it?
David
Re: RFC 188 (v1) Objects : Private keys and methods
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
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 constructor called, than FGS *call* a > > > > constructor. Maybe you can reduce the syntax necessary to do that, but > > > > please don't do it behind our backs. > > > > > > Well then, that's one nay vote. :) > > > >Make that two. > > Three. I was hoping to be strike three! Four. David
Re: RFC 193 (v1) Objects : Core support for method delegation
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 problem with the "stupid" part! D
Re: RFC 193 (v1) Objects : Core support for method delegation
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 => []; # Use none of them. Yes, I realize that not putting attr4 in there at all is the same (default) thing. It's just kind of a semantic thing in my mind. But maybe It's just *my* mind. ;-) Thanks, David
Re: RFC 193 (v1) Objects : Core support for method delegation
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 good, IMHO. >> attr3 => [*] > > Read my lips: No New Syntax! Of course - I was just making the analogy, really. :) >> This way, I know that an empty arrayref means "all methods" rather than >> "none." > > Kinda redundant since that's the default behaviour, but perhaps useful as > a documentation mechanism. Unless you change the default behavio[u]r to "don't delegate any method calls to this object!". David
Re: RFC 193 (v1) Objects : Core support for method delegation
"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 you? David
Re: RFC 193 (v1) Objects : Core support for method delegation
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 via a pragma: > > use delegation > attr1 => [qw( method1 method2 method3 )], > attr2 => [qw( method4 method5 )], > attr3 => [], > attr4 => [], > # etc. > ; When I see those empty arrayrefs, I think "delegate to *no* methods in those classes stored in attr3 and att4," rather than "delegate all method calls to those attributes." Just in the name of greater clarity, I might like to see something like URI suggested: attr3 => [ALL] Or perhaps (to borrow from SQL and to ignore the question of typeglobs for the moment): attr3 => [*] This way, I know that an empty arrayref means "all methods" rather than "none." Comments? Thanks David
