I'd like to note that Hash tables don't preserve the order they're created, and
that this isn't a perl6 thing, this is intrinsic to the definition of hash
tables.
On October 3, 2017 9:06:47 AM EDT, Andrew Kirkpatrick
wrote:
>Thanks, your script enticed me to explore different ways of
>construc
With perl5, that could have been something like. "perl -Mmy -e ...", but I
don't have access to a perl6 at this instant to compare. There should be a flag
you can use to include a module into the.running environment before evaluating
the
"-e" code.
Using "use" within the "-e" string should wor
Thank you! I'd have hated for my echo of your knowledge to be the only tip he
got, and you included a pointer to the option he needed, which I didn't try
from my phone:-)
As for LWP being a pain, I see it differently, filling the specs for a web
client --- many specs --- is a pain. The curl project is trying to wrap a
blanket around that pain.
I just googled perl6 libcurl, and got
https://github.com/CurtTilmes/perl6-libcurl
That's definitely where I'd start.
I'm not expert in curl, nor even http client coding, so I just checked the
curl(1) man page on my system, it says:
-L, --location
(HTTP) If the server reports that the
requested page has moved to a different
location (indicated with a Location:
I think it'd be cool to notice, and properly report, write errors, rather than
silently ignoring them.
Back when lwall was asking for things we wanted perl6 to do, I asked to be able
to wrap builtins specifically so I could
use Fatal qw(print).
Yes, perl5 often ignores write errors, but no, I
Well, tastes can reasonably differ on that point. Bunging all of the
complexity, of implementation, of design tradeoffs, and of documentation, into
one big module might suit some tastes. Not mine, as either an implementor or a
user.
Not all uses need all components, and I for myself would rathe
Well put.
The clearest description of Python's approach I've read, explained it as a
lexer that tracked indentation level, and inserted appropriate tokens when it
changed.
Hostile or not, thanks for your informative reply.
Thank you, very much. Yes, I'm disappointed, but I'd rather know.
Having the minutia of the programmatic run-time state of the parse then
influence the parse itself, is at the heart of the perl5 phenomenon "only Perl
can parse perl", which I rather hope isn't going to be preserved in perl6.
Bootstrapping is funny that way.
Besides the tools in the environment, you've got to have at least 1GB RAM
available to build perl6. I can compile it within the Gnuroot Debian app on
my Nexus 5, which has 2GB total real ram, so it has enough even inside the
Android app. I can't similarly buil
Figuring out the environment, and how to best fit into it, is tricky, wants a
richly powerful programming language, like perl. Ideally one that's almost
certainly already available. Someday, Perl6 will be that language.
Actually, now that I think about it, I'm not as sure. Maybe, eventually, a full
perl6 compiler and runtime written entirely in perl6 might, possibly, be nice;
but using, and interoperating with, existing mature tools like e.g. make and
gcc has some big advantages, too.
I think that would be great. Also lovely if it were completely correct, which I
think is perhaps the biggest focus now, or nice and compact and fast, which
still has a way to go. Many lovely goals to enjoy working on.
I think perl6 isn't self bootstrapping, yet. Unless I've gotten myself
confused, some of the environment sniffing and basic build automation is in
perl5, and the foundation is in C. Also wants make.
Have more than 1GB RAM --- or plenty of swap, and vast patience.
Thanks, very much.
That talk inspired unhappiness in me, and I've even written my thoughts out,
but as all I've got is an unconstructive rant, I'm keeping it as an inspiration
until I can offer my own perl6 package manager that suits my prejudices.
A sample of one: if the problem is that perl6
A C char** is an array (of unknown length) of pounters to C strings ( each of
unknown length).
I don't know NativeCall, can't tell you how it should be declared, but I hope
that highlights the issue.
Thanks for the helpful note.
Perhaps I need to get to coding my own module installer. I appreciate that
"everything, everywhere, must support i18n" is noble, but I think it's pretty
ugly to encode filenames in the install tree on all systems, because there
exist systems that can't represent som
Thanks for the explanation. Sounds like an unfortunate situation, rather than
letting the system admin choose modules within the limits of filesystem
namespace, it's using a separate database, opaque to filesystem tools. I hope
this is just a temporary hack until a mature solution is hammered o
I never got panda to install, so I use zef.
The only module I've installed was Readline, to shut up the blind nagging
whenever I run perl6 for a repl.
Zef seems to have left files containing the string Readline in
share/perl6/site, plus .perl6/precomp. The filenames are hashes, perhaps from a
I think you're right, and the rpm packaging of perl5 is rather similar -- but
simpler, as there aren't the bifurcations into moarvm vs jvm, and panda vs zef.
But perl6 is young yet.
Happily, it's not too hard to package a single compiler, e.g. rakudo-moar. And
as long as you're comfy with rpmbu
Agreed. I too found panda didn't successfully install, so I just switched from
rakudo-star to rakudo, and I use zef. This package looks like it tries to build
rakudo-star, panda doesn't, it installs what bits succeed, and quietly ignores
those that don't.
I think the packager should work from r
https://www.reddit.com/r/perl6/comments/4f6jx5/building_perl6_on_android_in_gnuroot_debian/
TLDR: LDFLAGS=-Wl,-z,noexecstack And then zef install --force Readline
Moarvm wants to try to execute code off the stack, but doesn't have to. Android
blocks attempts to execute code on the stack with sel
2004-02-26T14:26:47 Larry Wall:
> Well now, I remember Perl 0, sonny.
Does that still exist anywhere? I don't have anything older than
perl 1.
> They don't make 'em like they used to...
That they don't. On Bent Linux (my own distro, based on uClibc
instead of glibc) I get
; ls -l perl1 perl5.8.
Is the destruction going to be timely enough for
IO::File->new(">foo")->print("foo\n");
print `cat foo`;
to behave predictably?
-Bennett
pgp0.pgp
Description: PGP signature
2003-08-18T13:52:50 K Stol:
> After reading most of the messages on timely destruction, I still
> don't quite understand what it is. If someone has a spare minute
> free, could you please explain?
The other explanations certainly have formality to commend them, but
somehow they didn't make clear t
2003-03-18T13:54:12 Michael Lazzaro:
> A perl5-native parser can be rigged up fairly easily, but it's
> *numbingly* slow compared to the C version. I mean, 20-50 times
> slower, by my guess.
That's the nature of the beast; XML requires a lexer which knows
about more than just two or so character
2001-01-03-21:43:39 Dan Sugalski:
> I think one of the things we might want to do is figure out what people use
> signals for [...] The big one I can think of is interrupting
> timers. [...] (Excepting I/O signalish things, which will get
> handled elsewhere)
How about, goosing long-lived daemon
2000-12-05-13:02:56 Nathan Torkington:
> I say that the person who *does* the work deserves the right to
> choose what format it is in. So long as we can make navigable
> webpages out of it, that person can write on a Commodore 64 for
> all I care.
Would you accept a restatement of: as long as wh
2000-11-02-17:30:56 Nathan Torkington:
> Here are the things to order, in my order:
>
> Robustness
> Portability
> Maintainability
> Testability
> Reusability
> Speed
> Simplicity
> Size
A couple of negligible wibbles to toss in: would it make sense to
separate "Simplicity" into
2000-11-02-16:30:36 John Porter:
> Bennett Todd wrote:
> > Java is crappy engineering with superb marketing,
>
> This is so wide of reality, I conclude that you don't know the
> first thing about Java.
Conclude whatever you like. I started by reading the language and VM
I'm probably pouncing on a point you didn't intend to make,
disagreeing with something you didn't intend to say here, picking on
subtleties of how you phrased it, so I'm gonna omit the
attribution:-). I still wanna pounce on this.
> [ all sorts o' reality omitted ] how many people are going to
>
I started to write:
Is there a reason for introducing an asymmetry, or
should this proposal read "... and /^/ equivalent to
/\A/ ..."?
but then I re-re-read perlre(1) and realized that that is the
current behavior already: this proposal is hammering out a little
bit of irregularity,
I can see the motivation for wanting this, but there's a cost I
haven't read anyone mentioning yet: this is abandoning backward
compatibility with a regex notation that has remained pretty
consistent in ed(1) and grep(1) and things inspired by them since I
guess the early '70s, when they were born
Is Vertical Tab used as whitespace in any current system?
I thought it was an artifact of the old line printers doing heavy
duty forms stuff, and went out with them.
-Bennett
PGP signature
2000-09-27-22:03:19 Randal L. Schwartz:
> So, I'd be happy to make everything an object under three conditions:
>
> 1) it doesn't interfere with *optimized* language constructs for
> the most common tasks
>
> 2) it isn't being put in just to satisfy some theory that making
> everything an object
2000-09-27-21:53:34 Michael Fowler:
> You can ask "why?" (or "why not?") until you're blue in the face,
> and the question would still be valid. He just doesn't want to,
> nor do I.
We may have a misunderstanding here about what "it" is.
> If $str = "foo" and m/foo/ are somehow magical objects,
2000-09-27-17:37:07 Randal L. Schwartz:
> f I want a language where everything is an object, I know
> where to find it.
If the only excuse for tossing this is some kind of gut revulsion
towards objects, I sure hope the RFC doesn't get withdrawn, and the
folks with that revulsion take some tummy m
2000-09-27-15:19:23 Simon Cozens:
> On Wed, Sep 27, 2000 at 03:17:01PM -0400, Bennett Todd wrote:
> > I'd cite ruby as an indication that it shouldn't have to inflict any
> > performance hit
>
> *boggle*. That's classic. Ruby *is* a performance hit.
2000-09-27-15:08:10 Simon Cozens:
> Never too late to withdraw, sir. [1] The less crap we make Larry
> wade through, the better.
Regarding the specific issue at hand, could you please offer
something more specific than "you'd like it withdrawn"? Is there a
reason why it's impossible to implement
2000-09-27-05:28:01 Piers Cawley:
> Simon Cozens <[EMAIL PROTECTED]> writes:
> > On Wed, Sep 27, 2000 at 05:25:28AM -, Perl6 RFC Librarian wrote:
> > > At the suggestion of others I've opted to freeze rather than
> > > withdraw.
> >
> > How might I persuade you to reconsider?
>
> I was kind
2000-09-26-05:18:57 Paris Sinclair:
> > (%alphabet) = $string =~ tr/a-z//;
>
> also a little more concise (and certainly more efficient...) than
>
> %alphabet = map { $_ => eval "\$string =~ tr/$_//" } (a..z);
However, compared to say
$hist[ord($_)]++ for split //, $string;
2000-09-26-08:10:54 Webmaster:
> Simon Cozens [EMAIL PROTECTED] Wrote:
> >Perl 6 needs some kind of internationalisation and therefore message
> >catalogue support. Really needs, with great urgency.
>
> Doesn't RFC 85 address this to some extent? By offering up 'error codes'
> can't the programme
2000-09-25-12:04:44 Matt Youell:
> Unless I hear compelling arguments to the contrary, I'll be
> withdrawing RFC 161 on Tuesday due to lack of interest.
If the only grounds is lack of interest, please just freeze it. It
can be tossed later if people turn up strong counterarguments, like
difficult
2000-09-13-13:56:07 John van V:
> 2000-09-12-20:35:32 Bennett Todd:
> > The exact same design targets --- really really fast, teensy
> > memory footprint --- that define the microcontroller embedded
> > market, also define the entry to these roles on the biggest
> >
2000-09-13-03:29:16 Hildo Biersma:
> Some would argue that a better design is required. Apache 2.0 will
> use a mixed thread/process model, and mod_perl 2.0 will run
> selected threads within one process, precisely to alleviate these
> problems. So it's not necessarily perl's fault...
Some would
2000-09-11-16:23:20 Dan Sugalski:
> At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote:
> >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote:
> > > INN has been embedding Perl for years, quite successfully.
> >
> >There's embedding and there's embedding. Embedding in an UNIX server
> >
2000-09-07-19:50:35 Adam Turoff:
> > Given that it's only available to people who happen to run supported
> > platforms,
>
> OK. That pegged the fud-o-meter. The list of supported platforms
> listed on http://www.perforce.com/perforce/loadprog.html is hovering
> around fifty, [...]
Sure hope
2000-09-07-17:11:50 Dan Sugalski:
> Perl 5's development issues have nothing to do with the code
> repository -- [...]
That's certainly possible, but since the reason we're gathered here
together working on trying to launch perl6 is a collective belief
that perl5 has become unmaintainable for fu
2000-09-05-10:53:25 Dan Sugalski:
> >I don't think it's a good idea to build Perl6 development
> >infrastructure around non-free software.
>
> I don't think we should make decisions about the software we use
> for development based on political views. The decisions should be
> based on technical
2000-08-28-18:47:06 Tom Christiansen:
> It strikes me as a bit reminiscent of (one reason) why Larry
> didn't make a+b work on strings, since then while with numbers,
> a+b and b+a would be the same, with strings they would not be, and
> we have these rather deeply held convictions about such matt
Tom Christiansen <[EMAIL PROTECTED]> writes:
> Keywords that *cannot* be overridden are chop, defined, delete, do,
> dump, each , else, elsif, eval, exists, for, foreach, format, glob,
> goto, grep, if, keys, last, local, m, map, my, next, no, package,
> pop, pos, print, printf, prototype, push, q
2000-08-27-12:03:07 Peter Scott:
> > use Fatal qw(:io ...);
> > no Fatal qw(:arithmetic);
>
> Bingo, yes. I will make appropriate changes to RFC 80. You might
> think about whether RFC 70 needs to be changed.
I don't think so; while I mention styles of changes and growth for
F
2000-08-22-16:40:13 Peter Scott:
> >I'm not sure, but I think Chaim's main point was just that, not
> >that divide-by-zero should be ignored too.
>
> Well, it could be made user-selectable, right Bennett? Do you envisage
> being able to say
>
> use Fatal qw(Arithmetic IO etc)
>
> usi
2000-08-22-15:13:23 Peter Scott:
> I too would rather say
>
> my $fh = open $filename or die "Couldn't copy source: $!"
>
> than
>
> my $fh; try { $fh = open $filename } catch { die "Couldn't copy
> source: ", $@->syserr }
I'd usually rather just say
my $fh = open $
58 matches
Mail list logo
