Re: Raku regex assert doesn't match
Thank you William, that boolean condition check option looks like it is in the
direction of the answer I sought.
FYI, the reason I spelled out the character class explicitly rather than using
"" was because I wanted it strictly applied to ASCII chars and not
everything Unicode considers a char, and this seemed the best way to be sure.
-- Darren Duncan
On 2023-07-30 9:30 p.m., William Michels via perl6-users wrote:
Hi Darren (and Marcel),
Two different approaches:
https://docs.raku.org/language/regexes#Conjunction:_&;
<https://docs.raku.org/language/regexes#Conjunction:_&;>
From the docs:
/"For example if you have a regex quoted that matches a quoted string, then `/
&& <-[x]>* /` matches a quoted string that does not contain the
character `x`."/
Second approach :
https://stackoverflow.com/questions/64909029/is-it-possible-to-do-boolean-assertions-with-raku-regex
https://docs.raku.org/language/regexes#Regex_Boolean_condition_check
Testing "Regex Boolean condition check" with a one-liner:
~ % cat cats_dogs_jays.txt
cat
dog
jay
null cat
false dog
true jay
~ % raku -ne 'put $/ if $_ ~~ m:g/ ( + ) "false" | "true" }> /;' cats_dogs_jays.txt
cat
dog
jay
cat
dog
jay
HTH, Bill.
On Jul 30, 2023, at 08:59, Marcel Timmerman wrote:
On 30-07-2023 06:21, Darren Duncan wrote:
Hello, I have a Raku regex question.
See the following:
token nonquoted_alphanumeric_text
{
>
<[ A..Z _ a..z ]> <[ 0..9 A..Z _ a..z ]>*
}
What I want is for "nonquoted_alphanumeric_text" to match any simple ASCII
bareword EXCEPT a few special cases indicated in the example.
I was hoping there might be some better way of specifying this than my example.
Is there any more direct way in Raku to say, match this pattern initially,
but if the result equals these exceptional values then treat it as having not
matched.
I am looking for a fully declarative solution in the grammar itself, not
something involving post-processing.
Thank you.
-- Darren Duncan
You can try: <|wb>*
Raku regex assert doesn't match
Hello, I have a Raku regex question.
See the following:
token nonquoted_alphanumeric_text
{
>
<[ A..Z _ a..z ]> <[ 0..9 A..Z _ a..z ]>*
}
What I want is for "nonquoted_alphanumeric_text" to match any simple ASCII
bareword EXCEPT a few special cases indicated in the example.
I was hoping there might be some better way of specifying this than my example.
Is there any more direct way in Raku to say, match this pattern initially, but
if the result equals these exceptional values then treat it as having not matched.
I am looking for a fully declarative solution in the grammar itself, not
something involving post-processing.
Thank you.
-- Darren Duncan
Re: Rust community in distress
The video is less than 10 minutes long, its not that much effort to watch. The TL;DW is some bad stuff happened but some things are improving after. -- Darren Duncan On 2023-06-09 12:26 a.m., Veesh Goldman wrote: Could I get a TL;DW on that video? I love Rust, and would hate to see anything bad happen to it On Fri, Jun 9, 2023 at 9:40 AM İsmail Arılık wrote: This is the open source world! So if there is a problem between the management of Rust and the community, a fork would come and be popular soon. Leaving Rust shouldn't be an option I think since it is really a good language. On Fri, Jun 9, 2023, 07:04 Darren Duncan wrote: And here Rust seemed to be massively gaining in popularity, and was just supported officially for Linux kernel driver support etc. -- Darren Duncan On 2023-06-08 11:17 a.m., Parrot Raiser wrote: > See https://youtu.be/QEnuzwCWpgQ > > This is not meant to be an example of schadenfreude. Rust is an interesting > language, whose ecological niche has little in common with Perl's or Raku's. Its > principal rival is Go, which is definitely more corporate. Alphabet already > controls far too much. (Yes, that sentiment may not be compatible with a gmail > account.) > It is unfortunate when any worthwhile Open Source project suffers from community > or personality conflicts. It's worth noting them, to help us avoid similar > situations.
Re: Rust community in distress
And here Rust seemed to be massively gaining in popularity, and was just supported officially for Linux kernel driver support etc. -- Darren Duncan On 2023-06-08 11:17 a.m., Parrot Raiser wrote: See https://youtu.be/QEnuzwCWpgQ <https://youtu.be/QEnuzwCWpgQ> This is not meant to be an example of schadenfreude. Rust is an interesting language, whose ecological niche has little in common with Perl's or Raku's. Its principal rival is Go, which is definitely more corporate. Alphabet already controls far too much. (Yes, that sentiment may not be compatible with a gmail account.) It is unfortunate when any worthwhile Open Source project suffers from community or personality conflicts. It's worth noting them, to help us avoid similar situations.
Re: Using fez
On 2022-07-10 10:56 a.m., Elizabeth Mattijsen wrote: Fez (aka https://360.zef.pm) will provide *all* versions. The above url just displays a big data structure when visiting it in a web browser, and not a normal website, is that correct? -- Darren Duncan
Re: author specification
. Per the Apocalypse 12 example, originally I was using "http://muldis.com; qualified with "https://; as a seeming standard way of being explicit that my "auth" is an internet domain name and not say a CPAN id or whatever. However, per developments in the last few years like "HTTPS Everywhere" and such, with the web in general treating unencrypted HTTP like an obsolete protocol people shouldn't be using anymore because security, it made me think that I need to rethink my own "auth". So something I was hoping to get input on is what is a recommended way to use an internet domain name, say "muldis.com" or alternately its reversed "com.muldis" form, as an "auth" while making it explicit that this is an internet domain name, but without naming any protocols like "http" or "https" etc. Is there some kind of best standard format for indicating this, eg "domain:muldis.com" but standard? So what are thoughts on what I said? -- Darren Duncan On 2022-05-06 6:48 a.m., yary wrote: But I'm understanding from this conversation is that people have different ideas of what the auth field means. 1. It shows who is responsible for this code. It is independent of which home the author chooses, where home is GitHub, gitlab, cpan, zef,p6c etc. 2. It shows who is responsible for this code, and its main home. Auth does not change when stored on other homes. 3. It shows who's responsible for this code in this home. It changes depending on which home it is being uploaded to. So it helps to consider some cases and how we handle it. 1. Long time Perl contributor has a CPAN authority, and decides to migrate all existing projects to github as a main home. 2. Long time perl contributor has a CPAN authority, no Git account (local development). She decides to distribute new Raku projects in zef primarily, mirrored in CPAN because she loves metacpan's API and interface. 3. New contributor has modules in GitHub account, is agnostic as to ecosystems. Wants every ecosystem to reflect latest pushes to main branch in their git account. How should the auth field work for these cases? More cases welcome... (Welcome to the bikeshead? ️) On Mon, May 2, 2022, 3:23 PM Marcel Timmerman wrote: Hi, I was wondering about the 'auth' specification in the meta file or on the class/module/package. I was used to specify it as 'github:MARTIMM' because I store the stuff on GitHub for all the goodies it offers. Now I see//that fez wants to start with 'fez:' and when I look at the raku.land site for a module of mine I see a remark /'/The uploading author of cpan:MARTIMM does not match the META author of github:MARTIMM.' because I upload it to CPAN nowadays and have never specified somewhere that the auth has become 'cpan:MARTIMM'. I feel that this is not useful (even correct) to pin someone to use an auth specification with a defined prefix for some ecosystem one is using. So changing to another ecosystem forces that person to change the auth everywhere in its code and meta files to get rid of any errors or warnings. Besides that, the change of the author on the same code poses the question later on, if that code is forked and changed by someone else or that it is still the same developer working on it? Regards, Marcel
Re: hope we have the distributed computing [Raku]
On 2021-11-27 12:16 a.m., Piper H wrote: but in [Raku] why won't we make that a distributed computing framework like Spark? Then it will help a lot to the data programmer who already knows perl. I expect a lot from this project. Piper, are you offering to lead your proposed project and be the primary developer working on it? -- Darren Duncan
Re: Please create a Raku community channel
On 2021-03-13 2:27 p.m., Vadim Belman wrote: Concerning the accidental duplication of projects, aside of the fact that it is dissipation of scarce community resources, the good side is that there will be two options to choose from. I will be happy to see both project launched. One could eventually become part of the official site, the other may be ran independently. One way or another I hope there will be more gains from it than loses. These projects could be merged if both authors are conducive to it, now that this is known. If there is reason for them to stay separate, I don't see why they can't BOTH be official sites, like Version 1 plus Version A, no reason to have to pick one. -- Darren Duncan
Re: Please create a Raku community channel
I agree, I would also like to know of this official channel and join it. -- Darren Duncan On 2021-03-12 11:21 p.m., Richard Hainsworth wrote: This is a request to the Raku Coordinating Council that was elected at the end of last year. Please name a channel where community wide plans or announcements are made. Or may be establish one. I found out yesterday by the intervention of a regular participant in the community that a new documentation website is being worked on. I joined a conversation on the raku-dev IRC and discovered that the plans are quite far established. Since I have been working full-time for three months on a project that could (not should!!) serve as the infra-structure of a new site, I was really quite surprised and I am sure many of you will understand it was jarring. I follow all the conversations on this email list. I have found it very difficult (due to my own technical incompetence relating to github) to set up my github preferences to get regular notification about issues. I have also found that the IRC chats are streams of consciousness that are difficult for me to manage. It seems however, that it is my fault that I was taken by surprise by the news of a different documentation website and that I should have been following all the issues on the documentation repo or the problem solving repo. It *IS* reasonable for Raku developers and community organisers to make it the responsibility of a participant to follow conversations, but I would suggest that the current scattering of conversations, on the IRC chat, various github repositories, this email list, is not *optimal* for the development of a coherent Raku community. It is also - I would suggest - a waste of human resources if the same objectives are pursued by multiple enthusiasts without any coordination or communication. If the Raku Council were to designate some channel, whether its an email list, an IRC chat, or a github repo, or maybe a discord or slack or other channel as the main community resource, then I would make sure I could read all the messages there and stay in touch with what is happening. Hence my request to the Raku council to consider improving communication between developers and the wider Raku community. Regards Richard Hainsworth aka finanalyst
Re: My OOP keeper
Thank you to those who replied to my question with private messages. I now understand what is meant by "keeper" here. -- Darren Duncan On 2021-02-14 1:38 p.m., Darren Duncan wrote: On 2021-02-12 8:12 p.m., ToddAndMargo via perl6-users wrote: I have been working on this keeper for several months an though it was time to share and get feedback. Once you understand OOP (Object Orientated Programming) and Raku's elegant implementation, it becomes an extremely powerful tool. And the nice part is that Raku made it really easy! Like a hash on steroids. I don't understand the terminology "keeper" in this context. Usually the term "keeper" is talking about something related to security. All I saw in this email was documentation of the Raku OO system. So does "keeper" mean "documentation" here? Otherwise please explain, thank you. -- Darren Duncan
Re: My OOP keeper
On 2021-02-12 8:12 p.m., ToddAndMargo via perl6-users wrote: I have been working on this keeper for several months an though it was time to share and get feedback. Once you understand OOP (Object Orientated Programming) and Raku's elegant implementation, it becomes an extremely powerful tool. And the nice part is that Raku made it really easy! Like a hash on steroids. I don't understand the terminology "keeper" in this context. Usually the term "keeper" is talking about something related to security. All I saw in this email was documentation of the Raku OO system. So does "keeper" mean "documentation" here? Otherwise please explain, thank you. -- Darren Duncan
Re: Checking for nil return
On 2020-12-29 6:26 a.m., Ruud H.G. van Tol wrote: Basically, never mix error-state and return-value. Rather use a different channel/dimension for each. Such a separation can't be absolute though. One needs to be able to user-define routines that implement additional generic Failure related features, and in that case they WOULD be normal arguments or return values. And so the regular type system still needs to support having anything at all as an argument or return value. -- Darren Duncan
FYI - Raku grammar compile speedup with preceding surrounder syntax
FYI,
So I don't know the factors determining how fast Raku can compile ("perl6 -c
filename") a grammar, but:
Anecdotally I have just seen that using the surrounder syntax "left ~ right
middle" rather than "left middle right" makes my 16KB MUON-defining grammar
compile in 1 second rather than 6-7 seconds on my 2013 machine.
See
https://github.com/muldis/Muldis_Object_Notation/commit/568713257c474ad393d2dd6777e2147432cf6ec5
for the exact diff in question that led to this speedup.
-- Darren Duncan
Re: The SF Perl Raku Study Group, 10/4 at 1pm PDT
These messages are archived on the public internet as far as I know so you've just made your room and its password published publicly. I hope your Zoom has a waiting room enabled. -- Darren Duncan On 2020-10-01 12:24 p.m., Joseph Brenner wrote: Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information? The Raku Study Group. October 4th, 1pm in California, 9pm in the UK Zoom meeting link: https://us02web.zoom.us/j/88535076025?pwd=MHBOTDltVitVMlh4R2Z5WUFaSDYwQT09 Passcode: 4RakuRoll RSVPs are helpful, though not necessary: https://www.meetup.com/San-Francisco-Perl/events/273646647/
Re: Place for examples in a Raku module?
I would put the examples folder at the root level of the distro, as a peer to lib and a peer to the tests folder. -- Darren Duncan On 2020-08-13 9:25 p.m., Stuart Hungerford wrote: Hi, I'd like to add some example modules to a Raku module I'm working on. These are not strictly tests, nor stand-alone scripts, but modules of compilable code that show suggested ways to use the roles and classes in the module. They're not strictly needed to make use of the module. I can see I could create an "examples" sub-directory in the lib directory of the module and make sure it does not appear in the "provides" metadata for the module. I think I could also create pod6 documents with large sections of embedded code too but I figure there must be idiomatic Raku ways of doing this. Any advice much appreciated, Stu
Re: doing an inner join via cross-product
This reminds me of my 2009 Set::Relation Perl module, which works to help you do
SQL features like this in your application, but will soon be superseded by
another module that also has a Raku version. -- Darren Duncan
On 2020-07-19 1:02 p.m., Joseph Brenner wrote:
I was thinking about the cross-product operator the other day,
and I was wondering if there might be a convenient way of
filtering the resulting cartesian product to do something like a
database inner join:
my @level = ( godzilla => 9 ,gremlin => 3, hanuman => 5 );
my @origin = ( godzilla => 'jp', tingler => 'us', hanuman => 'il' );
my @results = ( @level X @origin ).grep({ $_[0].keys eq $_[1].keys });
say @results; # ((godzilla => 6 godzilla => jp) (hanuman => 5
hanuman => il))
That's easy enough, though the resulting data structure isn't very neat.
I started looking for ways to rearrange it:
my %joined;
for @results -> $row {
say "row: ", $row; # e.g. row: (godzilla => 9 godzilla => jp)
say $row.map({ .keys });# e.g. ((godzilla) (godzilla))
say $row.map({ .values }); # e.g. ((9) (jp))
my $monster =| $row[0].keys; # e.g. godzilla
my @attributes =| $row.map({ .values }); # e.g. [9 jp]
%joined{ $monster } = @attributes;
}
say %joined; # {godzilla => [9 jp], hanuman => [5 il]}
I can do it more compactly, but it risks getting unreadable:
my %joined2 =| @results.map({ $_[0].keys => .map({ .values }).flat });
In any case, the %joined structure feels more perlish, for
example it's easier to use it to generate reports:
for %joined.keys -> $key {
printf "%12s: level: %-2d origin: %3s\n", $key, %joined{ $key }.flat;
}
# hanuman: level: 5 origin: il
#godzilla: level: 9 origin: jp
Is there some neater way of doing this that I'm missing?
Re: irrational nubmer?
On 2020-02-20 2:22 p.m., ToddAndMargo via perl6-users wrote: On 2020-02-20 00:41, Darren Duncan wrote: On 2020-02-20 12:10 a.m., Tobias Boege wrote: Granted, Todd would not have anticipated this answer if he calls arbitrary length integers "magic powder" and the question "I have computed this Int/Num/Rat in Raku, is it rational?" does indeed not make any sense. But there are computer languages that can do better. Given FatRats, such modules can be written for Raku today. Actually the question "is it rational" DOES make sense, however its answer is trivial, the answer is always "yes"; EVERY (not-NaN/Inf/etc) number a language-defined Raku data type can represent is exactly expressible as the ratio of 2 integers. -- Darren Duncan Well, I wonder if there is an overflow bit that would tell your is the number was going on and on after you did an operation on it. What would the practical value of that be? The only commonly used numeric types that have bits for tracking exceptional cases are IEEE floating point numbers, and it is already explicitly known that most typical operations producing results of that type are producing inexact rounded results. So if they are already expected to be inexact or rounded, it doesn't matter if the exact answer would have been rational or irrational. -- Darren Duncan
Re: irrational nubmer?
On 2020-02-20 12:10 a.m., Tobias Boege wrote: Granted, Todd would not have anticipated this answer if he calls arbitrary length integers "magic powder" and the question "I have computed this Int/Num/Rat in Raku, is it rational?" does indeed not make any sense. But there are computer languages that can do better. Given FatRats, such modules can be written for Raku today. Actually the question "is it rational" DOES make sense, however its answer is trivial, the answer is always "yes"; EVERY (not-NaN/Inf/etc) number a language-defined Raku data type can represent is exactly expressible as the ratio of 2 integers. -- Darren Duncan
Re: irrational nubmer?
Hello ToddAndMargo, The answer to your question depends on how the number is represented. If you are using a symbolic data type, meaning one that represents a number as a logical formula akin to program source code, and the operators on that data type work by manipulating tree expressions into other tree expressions, then you can easily represent an irrational number, and you can determine if a number is irrational, using mathematical proofs. Eg, programming languages like Wolfram Mathematica or their ilk probably work in exactly this fashion. Otherwise, if you are using a non-symbolic data type like typical integer or floating-point data types, then even if they support arbitrarily large precision, they still can only represent rationals, and the test for irrational is easy, the answer is always "not irrational" for these types. All the numeric types built into Raku are non-symbolic, so the test is simply "false". There probably are or probably can be symbolic numeric types, but they wouldn't be core. -- Darren Duncan On 2020-02-19 6:57 p.m., ToddAndMargo via perl6-users wrote: Hi All, This is a complete trivia question. Is there a test to see if a number is irrational, such as the square root of two? And how does Int handle a irrational number? Is there a limit to magic Larry powder? Many thanks, -T
Re: perl6 with XS
Raku has the Native Call interface https://docs.raku.org/language/nativecall which is what you use instead. -- Darren Duncan On 2020-02-02 6:36 p.m., wes park wrote: HI In perl5 we can use the underline C library for example JSON C with XS interface. In perl6 how can we implement it? Thanks Wes
Re: problems with xor
On 2020-01-17 9:00 p.m., ToddAndMargo via perl6-users wrote: Still don't know what they used the word "sub" The term "sub" is short for "subroutine", and declaring routines that way is part of the Perl legacy that lasted into Raku. -- Darren Duncan
Re: Once again - You say one thing and do another Re: Bug to report: cardinal called an integer
On 2020-01-16 3:09 a.m., Elizabeth Mattijsen wrote: I wonder if this is how you treat your family as well. If you do, then I feel sorry for your family. And wouldn't be surprised if they abandoned you. That is unnecessarily harsh and uncalled for Liz, the last sentence particularly. -- Darren Duncan
Re: Bug to report: cardinal called an integer
On 2020-01-16 9:22 a.m., ToddAndMargo via perl6-users wrote: Since folks do not like the programming/math term "carinal", it would be perfectly happy if the error message was changed from: This type cannot unbox to a native integer: P6opaque, Str to This type cannot unbox to a native unsigned integer: P6opaque, Str I also believe the latter would work best for this. -- Darren Duncan
Re: Bug to report: cardinal called an integer
On 2020-01-12 11:32 p.m., ToddAndMargo via perl6-users wrote: On 2020-01-12 20:03, Darren Duncan wrote: A uint32 is NOT specifically a cardinal. Since a uint32 ca not be negative or a fraction, it is a cardinal. Other operating system do call them cardinals, such as Modula2. Pascal, C++ (I think C too), Java, and so on and so forth. Yes, a uint32 CAN represent a cardinal, but it can ALSO represent an ordinal or a nominal or various other things. A uint32 is just as much an ordinal as a cardinal, so insisting on calling it a cardinal means the type can't be used as an ordinal, or a variety of other things. https://www.dictionary.com/browse/ordinal-number ordinal number noun Also called ordinal numeral. any of the numbers that express degree, quality, or position in a series, as first, second, and third *(distinguished from cardinal number)*. Mathematics. a symbol denoting both the cardinal number and the ordering of a given set, being identical for two ordered sets having elements that can be placed into one-to-one correspondence, the correspondence preserving the order of the elements. https://www.dictionary.com/browse/cardinal-number cardinal number noun Also called cardinal numeral. any of the numbers that express amount, as one, two, three, etc. *(distinguished from ordinal number)*. No idea how you are mixing these two. I can see how yo would use a cardinal in programming to denote an ordinal, if that is what you are getting at. These are different semantics applied to the same representations. You tell me, take the following sequence: 0, 1, 2, 3, 4, ... Does that sequence denote cardinals, or ordinals, or both, or something else? I would say both. If you say it is only cardinals or only ordinals, then how do you determine that it is just one and not the other. Calling this an unsigned integer (u int) is much more accurate as it doesn't presume a particular semantics such as that we are storing a count rather than a position for example, it says what we actually know, and no more. I am sorry, I have no idea what you are trying to say. I do not care if you call a cardinal an unsigned integer. Just don't call it an integer. The high bit in a cardinal is part of the number and denotes a negative number in an integer. What high bit? We're talking about mathematical definitions here, that's what you're quoting from Wikipedia. Cardinals and ordinals and integers etc don't have "bits" in mathematics, never mind a high bit. The way I see it, you are making the mistake of confusing mathematical concepts with possible representations for them in a computer. A cardinal or ordinal or integer is a mathematical concept that is not defined in terms of bits. Each of these has possible representations in a computer as a sequence of bits. The same bit pattern that a uint32 holds can possibly represent either a cardinal or an ordinal but is not a cardinal or an ordinal itself. You are also wrong on saying that the values one can store in a uint32 are not integers; they definitely ARE integers. Every cardinal is an integer. Where do you get that. A cardinal can not be negative. An Integer can. And the structure is even different: the high bit in an integer denote the sign of the integer; the high bit in a cardinal is just a higher positive number. So they are not the same by any shake. Again, take the following: 0, 1, 2, 3, 4, ... I say that each of these is both a cardinal AND an integer. True that a cardinal can not be negative, but both a cardinal and an integer CAN be positive, so any positive whole number IS an integer just as it also IS a cardinal. -- Darren Duncan
Re: Bug to report: cardinal called an integer
Brad is saying what I've been saying, while a uint CAN represent a cardinal number, one does NOT ALWAYS represent a cardinal number, so saying this only IS a cardinal number is WRONG. -- Darren Duncan On 2020-01-13 12:56 p.m., Brad Gilbert wrote: Ok looking into it, zero is inside of the set of cardinal numbers. It is still wrong to call a uint a cardinal number. It's just wrong for a different reason. Looking through various definitions, a cardinal number is a number which represents a count of sets. So a uint could be used to represent a cardinal number, but it could just as easily be a number that represents something other than a count. If it is being used to index into a list it would be an ordinal number. (And so definitely not a cardinal number.) Calling them cardinal numbers would imply something about them that may or may not be true. If it is being used to store a bitmask, then it would be wrong to call it a cardinal, ordinal, or even a natural number. It may also be wrong to call it an integer, but at least that is what CPU designers call it.
Re: Bug to report: cardinal called an integer
On 2020-01-09 10:10 a.m., ToddAndMargo via perl6-users wrote: A bug to report: $ p6 'my uint32 $c; $c = "ABC";' This type cannot unbox to a native integer: P6opaque, Str in block at -e line 1 "uint32" is not an "integer". It is a cardinal. If they really want to use the word "integer" for cardinal, they should change the wording to "unsigned integer". Picky, picky, picky ToddAndMargo, you are wrong on this. A uint32 is NOT specifically a cardinal. At best you can say it can be characterized by a cardinal or be isomorphic to one. A uint32 is just as much an ordinal as a cardinal, so insisting on calling it a cardinal means the type can't be used as an ordinal, or a variety of other things. Calling this an unsigned integer (u int) is much more accurate as it doesn't presume a particular semantics such as that we are storing a count rather than a position for example, it says what we actually know, and no more. You are also wrong on saying that the values one can store in a uint32 are not integers; they definitely ARE integers. Every cardinal is an integer. If you want to be precise, calling a uint32 an "unsigned integer" or "cardinal" is inaccurate in the same way that calling it an "integer" is. In either case, the variable can only hold a proper subset of either type, not all of them. If you're calling integer wrong then one will have to call the type something like "integers in the range 0..^2**32". -- Darren Duncan
Re: rakudo.org outdated?
On 2020-01-06 1:18 a.m., Patrick Spek via perl6-users wrote: On Sun, 5 Jan 2020 18:27:01 -0800 Darren Duncan wrote: The normal Rakudo Star releases so far are compiled, [...] For Mac and Windows, perhaps, but the release is similar as it always was for GNU+Linux. And I'm mostly aiming for that since that's what I use (and also what I can test). Hence, I need people to verify they can make binaries for Windows and Mac (and actually do it as well) before I can continue. If your version requires users to run a Makefile or make or cc or whatever or have a working C compiler, then it is a source release and not the same thing. I never intended to make a "binary" release. I intended to make a Rakudo Star release, and I personally don't care if that'd be a binary or source. In the case of GNU+Linux, it's a source release. As long as we know what to expect. So it sounds like you're just making a single source release of Rakudo Star that users of any operating system would compile themselves, and not separate Linux/Mac/Win versions as had been the case before. In that case, I can do basic build testing on MacOS for you. I would just try following the same instructions as Linux users more or less. -- Darren Duncan
Re: rakudo.org outdated?
On 2020-01-05 1:51 p.m., Patrick Spek via perl6-users wrote: On Sat, 4 Jan 2020 22:23:30 -0800 Darren Duncan wrote: Last I recall, there was no Mac installer for Rakudo Star at all, nor was there any need for one. The compiled project is simply in a zip file which the end-uaer unzips and then the resulting folder is ready to use as is. Don't know about Windows. If anything, on the Mac, having an installer has always been a misfeature, and most applications don't have one. -- Darren Duncan Looking at the archives on rakudo.org[1], there are .dmg files, which are packages for Mac I believe. Though, I'm not using a Mac, so please tell me if these are just Mac specific archives to be unzipped. As yary said, a .dmg file is just a disk image, like a .iso, and for all intents and purposes is the same as a zip file. A key benefit of a .dmg is that you can inspect its contents without having to decompress everything so it remains a single compressed file to the main filesystem. So a .dmg is NOT an installer. One can optionally contain an installer, but it can also and typically does just contain the application itself, and you just drag and drop to copy it to the location you want to use it in like copying from one disk to another. Both .dmg and .zip files will simply open in the MacOS Finder, no special software needed. The tarball I've created requires compilation in addition to just "unzipping", though. I'm not sure if that's a problem for regular Mac users. If it's not, I guess the Mac part is not an obstacle for getting a release out. [1]: https://rakudo.org/files/star The normal Rakudo Star releases so far are compiled, so all an end user needs to do is double-click the disk image and drag-copy the folder to their filesystem. That, and also add its "bin" subfolder to their path. If your version requires users to run a Makefile or make or cc or whatever or have a working C compiler, then it is a source release and not the same thing. The MacOS does NOT have a C compiler installed out of the box, although they make it very easy to install one on demand. In the MacOS Terminal if one simply tries to invoke "make" or "gcc" or whatever, they will get a fake executable that offers to install Apple's MacOS Developer Tools (or alternately XCode, but I recommend you don't if you're just doing basic portable Unix stuff), and then a minute or two later you have your C compiler etc, which will then automatically be kept up to date by Apple's Software Update in the same way the MacOS itself is. You probably don't want to do that though, users expect the pre-compiled binaries. -- Darren Duncan
Re: rakudo.org outdated?
On 2020-01-04 5:21 p.m., Patrick Spek via perl6-users wrote: On Sat, 4 Jan 2020 15:43:37 -0800 Darren Duncan wrote: Isn't there typically automated test suites that can prove in a few minutes that Rakudo works on a particular platform? Would running this typically be good enough to show that nothing broke in an update? -- Darren Duncan I wrote automated tests for GNU+Linux using GitLab CI, which are being introduced in this release. However, I can't "test" making a Windows or Mac installer, and then test if they also work. I have no idea how installers for either of these platforms are made, and I also don't think I can use GitLab CI for either of those platforms. Last I recall, there was no Mac installer for Rakudo Star at all, nor was there any need for one. The compiled project is simply in a zip file which the end-uaer unzips and then the resulting folder is ready to use as is. Don't know about Windows. If anything, on the Mac, having an installer has always been a misfeature, and most applications don't have one. -- Darren Duncan
Re: rakudo.org outdated?
Isn't there typically automated test suites that can prove in a few minutes that Rakudo works on a particular platform? Would running this typically be good enough to show that nothing broke in an update? -- Darren Duncan On 2020-01-04 11:10 a.m., Patrick Spek via perl6-users wrote: On Fri, 3 Jan 2020 23:28:38 +0100 Laurent Rosenfeld via perl6-users wrote: Hi Patrick, I'm sure you have plenty of things to do and I don't want to put too much pressure on you, but it would be really nice to have a good and more recent Rakudo Star version available, especially in view of the recent renaming of the language. I agree with you, especially the "good" part. Since Rakudo Star has to work for more people than just me, I'm a little hesitant to move quickly with it. I can't test it on Mac or Windows, for instance, but there are users on both platforms, and having a good but old release is probably better for them than new but broken. However, if the community would rather I mark the current -rc1 as a proper release, I can do that too. I just don't want to harm the community at large. And, by the way, more generally, having a nine-month-old release to offer on the main download site looks quite bad anyway. It's not you, but something must be wrong in the process. It used to be on a three month interval, and I'd like to go to a two or three month interval myself as well. I can try to make that happen once I know for certain that the current release process works.
Re: Cardinals
Todd, nothing you said disagrees with what I said, and I referenced that same Wikipedia article. (Though perhaps I could have been more accurate in saying a cardinal is characterized by an integer rather than saying it is an integer with a particular interpretation.) In particular, the article is explicit that there is no limit to how many cardinal numbers there are. So saying cardinal number is equivalent to a fixed size 32-bit integer is wrong, which is my point. (Also, negative quantities/counts are a common concept, but I can accept that the formal definition of cardinal excludes them.) -- Darren Duncan On 2020-01-03 12:03 a.m., Todd Chester via perl6-users wrote: On 2020-01-02 22:19, Darren Duncan wrote: On 2020-01-02 10:01 a.m., ToddAndMargo via perl6-users wrote: How do I do a 32 bit unsigned integer (cardinal)? I have a situation where I need to be able to have the first bit be a one and not have Raku think it is a negative number. Why do you use the term "cardinal" to refer to a 32 bit unsigned integer? The term "cardinal" in practice is just an integer/number of any magnitude with the added semantics of representing a quantity/count of something in contrast to say an ordinal position or name of something. Cardinals can't be negative. Think of them as counting numbers The term definitely does not represent a fixed-size number and it can also be negative. You are confusing a cardinal with an integer. An easy mistake to make -- Darren Duncan Hi Darren, Cardinal number https://simple.wikipedia.org/wiki/Cardinal_number "Cardinal numbers (or cardinals) are numbers that say how many of something there are, for example: one, two, three, four, five, six. They are sometimes called counting numbers. " Cardinal Numbers https://www.mathsisfun.com/numbers/cardinal-ordinal-nominal.html "A Cardinal Number says how many of something there are, such as one, two, three, four, five. A Cardinal Number answers the question 'How Many?'" Modula-2 Basic Data Types https://www.modula2.org/sb/env/index75.htm CARDINAL 16-bit compiler: 2 bytes 0 to 65535 32-bit compiler: 4 bytes 0 to 4,294,967,295 I was pretty good at Modula2 back in the day, :-) -T
Re: Cardinals
On 2020-01-02 10:01 a.m., ToddAndMargo via perl6-users wrote: How do I do a 32 bit unsigned integer (cardinal)? I have a situation where I need to be able to have the first bit be a one and not have Raku think it is a negative number. Why do you use the term "cardinal" to refer to a 32 bit unsigned integer? The term "cardinal" in practice is just an integer/number of any magnitude with the added semantics of representing a quantity/count of something in contrast to say an ordinal position or name of something. The term definitely does not represent a fixed-size number and it can also be negative. -- Darren Duncan
Re: Perl6 -> Raku? whats the scope?
While that is useful, and could be something I settle for, its not really the same thing at all. Any other domain could be setup to redirect to perl6.org, and I haven't seen any official word that raku.org is the official replacement, though it would be nice to be. When perl6.org redirects to some raku domain, then I'd have the most confidence that is indeed the official replacement. That or some formal announcement that this is the domain that will be used and not say raku-lang.org or something. Maybe I'll just have to use raku.org for now in my documents, but keep a close eye on the situation and be ready to change it again quickly if something else actually becomes the official replacement. -- Darren Duncan On 2019-10-16 9:09 a.m., Joseph Brenner wrote: Last I looked, raku.org redirects to perl6.org already. On 10/15/19, Darren Duncan wrote: One of the earliest steps that I hope gets implemented as soon as possible is that the previous official web domain for Perl 6 which is *.perl6.org gets an official replacement such as *.raku.org which has identical structure and content but for the domain, and any visits to the former 301 redirect to the latter. Basically I'm ready to go and update all references in my own projects or websites to the new name but I consider having a canonical web address to link to for Raku just as perl6.org was to be essential to updating my stuff, as I need something proper to reference.
Re: Perl6 -> Raku? whats the scope?
One of the earliest steps that I hope gets implemented as soon as possible is that the previous official web domain for Perl 6 which is *.perl6.org gets an official replacement such as *.raku.org which has identical structure and content but for the domain, and any visits to the former 301 redirect to the latter. Basically I'm ready to go and update all references in my own projects or websites to the new name but I consider having a canonical web address to link to for Raku just as perl6.org was to be essential to updating my stuff, as I need something proper to reference. -- Darren Duncan
Is it possible for Str to not be well formed?
I'm defining an API that takes only well formed Str objects, meaning it would
only accept Str whose Unicode codepoints are all in the set
{0..0xD7FF,0xE000..0x10} and in particular there are no UTF-16 surrogate
characters, and it would do so as a yes/no stricture without coercing anything
outside of the set.
I am aware of how behind the scenes Perl 6 uses multiple levels of abstraction
for Str objects, and in particular may often use Normal Form G to utilize
codepoints above 0x10 to be able to represent graphemes in constant space.
I have a few questions:
1. Do I even have to test the Str at all? Does Perl 6 guarantee that all Str
are well formed, such that for example if one tried to decode UTF-16 that
contained invalid surrogate codepoints (single ones or ones not properly paired
up) that this would fail early, or is it possible that a Str could be created
without fuss that contains the invalid surrogates? I suspect Perl 6' inherent
laziness would make passing through invalid codepoints more likely, but perhaps
that isn't the case.
2. Does Perl 6 ever have Str that are not internally in some normal form? That
is, if a file contains say a mixture of NFC and NFD, the actual codepoints will
be preserved at the start until some operation requires them to be in a normal
form? I'm thinking this may be a good case for laziness, eg you don't need
normal forms to just move data around, but it can help if you want to count
graphemes, so it only normalizes when such an operation happens.
3. If a Str can contain invalid surrogates or be wrong in some other way, what
is the best / most performant way to test that a Str is only valid? Context is
akin to a "Str where ..." and what we put in the "...".
4. How can I get the actual codepoints from a Str without normalizing them
first? I realize for typical use cases, explicitly using the NFC/NFD etc
methods, or "ords" which uses NFC, is the most correct, but if say I just want
what we already have, how would I do that? I realize the result may not be
particularly useful in the face of NFG.
For a wider context, I know that in other programming languages like .NET or
Java it is possible for their strings to have invalid surrogates, and I'm trying
to figure out if Perl 6 can have the same problem or not.
Thank you.
-- Darren Duncan
Re: Announce: Rakudo Perl 6 compiler, Release #131 (2019.07)
On 2019-07-17 2:18 p.m., Aleks-Daniel Jakimenko-Aleksejev wrote: On behalf of the Rakudo development team, I’m very happy to announce the July 2019 release of Rakudo Perl 6 #131. Rakudo is an implementation of Perl 6 on the Moar Virtual Machine[^1]. New in 2019.07: + SPECIAL NOTES: + Upcoming releases after this one will have a different changelog format + Java 9 is now required for JVM backend [ea94966d][8a37b931][b1fac3d6] I question this decision. If we're not going to support Java 8, then why not make Java 11 the minimum dependency instead of Java 9? Java 8 and 11 have long term support while Java 9 and 10 are already no longer supported. Who now can use Java 9 but not use Java 11? -- Darren Duncan
Re: Fastest way to convert from a Buf to a Str?
On 2019-02-02 7:22 PM, ToddAndMargo via perl6-users wrote: I need to read a file into a buffer (NO CONVERSIONS!) and then convert it to a string (again with no conversions). I think you're making an impossible request. If preserving exact bytes is important, then you want to keep your data in a type that represents a sequence of bytes, such as Blob of Buf. A Str represents a sequence of characters, which are NOT bytes, so if you're wanting to have a Str that is saying you don't care about the bytes. Given what you keep saying, I'd say skip the Str and just use Buf or Blob etc full stop. -- Darren Duncan
Re: An interesting math formula to share
Your saying "count all the number" is confusing and doesn't seem to relate to what follows. Did you mean to say "sum all the number"? -- Darren Duncan On 2018-07-10 2:02 AM, ToddAndMargo wrote: Hi All, Remembering from my school days, a famous mathematician whose name I forget came up with a formula as a kid that made math history. As it transpires, when in school, they disciplined him by making his count all the number from 1 to some large number. It took him only a few minutes. They thought he cheated, so they sent him back with an even larger number to add up. Same couple of minutes. Blew his teacher's minds every number they gave him. Seems he had discovered that if you laid the number out forward, then reverse underneath N=5 1 + 2 + 3 + 4 + 5 = 15 5 + 4 + 3 + 2 + 1 = 15 - 6 6 6 6 6 = 30 If you add the columns, you always got N+1 and N times. And that make the formula 1+2+3..N = (N+1)*N/2 I always have fun recreating this formula from the forward and reverse tables added as columns. So feed the following an integer and have fun! Yup. He blew his teacher's mind! -T $ echo "5" | p6 'my $N=slurp(); say $N*($N+1)/2;' 15 $ echo "6" | p6 'my $N=slurp(); say $N*($N+1)/2;' 21 $ echo "100" | p6 'my $N=slurp(); say $N*($N+1)/2;' 5050
Re: A proposal for Perl's branding - let's free all the butterflies
On 2018-02-16 11:15 AM, Nigel Hamilton wrote: Here is a suggestion for Perl's branding: http://nigelhamilton.com/perl-branding-proposal.html I like your proposal. But its details would need fleshing out more, particularly at the end, where it says this: Perl $new_runtime_name_for_perl5_goes_here (tm) Perl $new-runtime-name-for-perl6-goes-here (tm) That implies that the only things being branded this way are runtimes, and not the languages themselves, which I thought was meant to be under that umbrella. So for example: Perl $new_language_name_for_perl5_goes_here (tm) Perl $new-language-name-for-perl6-goes-here (tm) -- Darren Duncan
Re: Naming debate- what's the location for it?
If we assume the use of NQP is part of the project's identity, then yes that makes sense. Historically that wasn't the case, eg the earlier Rakudo were written to Parrot PIR directly, and there's the possibility this could change again, though I see that as unlikely. Not a bad idea. -- Darren Duncan On 2018-02-16 3:07 AM, Lloyd Fournier wrote: I'm about to publish some blog posts with using Perl 6 to demonstrate some cryptographic primitives. I was thinking about calling it "rakudo" to at least intrigue people and make them google it. Couldn't we call the language rakudo and the implementation nqp-rakudo? (ie a rakudo implementation in nqp) LL On Thu, Feb 15, 2018 at 5:02 AM Patrick R. Michaud wrote: On Wed, Feb 14, 2018 at 05:55:54PM +, raiph mellor wrote: > (Perl) Rakudo > === > > If jnthn and pmichaud and larry can warm to this idea, then: > [...] > The 'Perl' could be dropped from Rakudo specific propaganda, > calling the language just Rakudo instead, to reinforce that it refers > to 6e and beyond. But the Perl could be retained in any material > covering both Raptor and Rakudo as a reunified tech / community. FWIW, I am VERY MUCH AGAINST the idea of naming a language after its implementation. I've seen the confusion it causes in other environments and we ought not repeat that mistake here, especially since we don't have to. Whatever things end up being called, don't confuse the implementation(s) with the language definition. Pm
Re: Naming debate- what's the location for it?
Bad idea. There should not be any number in the name, in any way shape or form. No six, no ten, or any other. Differentiating factors should be something not a number. -- Darren Duncan On 2018-02-09 9:15 PM, Brent Laabs wrote: Might as well follow Apple and Microsoft and call it Perl Ten. Yes, spelled out. On Fri, Feb 9, 2018 at 8:16 PM, Parrot Raiser wrote: On 2/10/18, Darren Duncan wrote: > I think if we want to keep "Perl" in the name we should use "C" as a precedent. > Other related languages keeping "C" include "Objective C", "C#", "C++", > > Perl++ would work.
Re: Naming debate- what's the location for it?
On 2018-02-09 12:55 PM, Eaglestone, Robert J wrote: I think a name change is too radical. /And yet/. I think Steve has a point, though I don’t know what to do about it. The developers in my little corner of the world may not be up on the new-language-of-the-week, but even they see Perl as a has-been, write-only language, so when their brain matches /perl/i they automatically toss it in the bit bucket. Some of them are too nice to say it outright. Some aren’t. Personally I think having the "6" as part of the name is the worst part of the situation. Its too confusing with a version number. I think if we want to keep "Perl" in the name we should use "C" as a precedent. Other related languages keeping "C" include "Objective C", "C#", "C++", and its much more clear those are separate languages, even if C-alike. So one way or another, "6" should be dropped from the name of the language formally. Then we either have "Foo Perl" or "Perl Foo" or "Foo". After this is done, regular "Perl" can also be free to increment its first version number for major releases (albeit skipping 6 to avoid confusion) just as Postgres and many other projects do these days, as staying at 5.x forever is weird. -- Darren Duncan
Re: Naming debate- what's the location for it?
My personal favorite resolution is to officially name the language Rakudo, full stop. The implementation that was/is using the name would be renamed to something else so it isn't the same as the language. Then we say "Rakudo" is a sibling language of "Perl", full stop. Then "Perl 6" becomes a deprecated alias for Rakudo, used informally rather than formally from now on, and officially considered a historical footnote rather than anything still cited in official documentation or marketing. The unqualified name "Perl" continues to refer to the original lineage (currently at version 5.x) such as what 99% of the world means when they refer to it. Remember, we can still say "Rakudo is a sibling of Perl" for all the reasons we currently do without actually calling it any kind of "Perl" as an individual; we don't actually lose the family thing. For documentation/marketing materials and to help with continuity, we can typically reference "the Rakudo language, a sibling of Perl", where the latter part is then more of a description. This is what I really think should and that I would like to happen. -- Darren Duncan On 2018-02-08 12:47 PM, yary wrote: ...and "rakudo" even better by that criterion. And then there's how "rakudo" is already named in many files, databases, websites, and that's enough to make me think it's a "good enough" name. Though I'd like to change that implementation's name to something else if we start calling the language Rakudo! I quite like having the distinction between the language and its implementations. No one confuses C with cc, gcc, pcc, tcc, mvcc, XCode, or Borland. Using the name "rakudo" to mean the language makes me feel a little bad in that it muddies that distinction further, and gives this current implementation a special status. A status which it earned, we're not talking about calling the Perl6 language "pugs" or "parrot" or "niecza" for a reason. /me shrugs.
Re: %% with zero denominator
On 2017-12-11 5:21 PM, Sean McAfee wrote: Well, /any/ function or operator that returns a boolean /could/ return a Failure instead of (or in addition to) False to provide additional information to those who want it, but if the condition is not really a Failure, wouldn't that be misleading? Like this highly contrived example: For my part, in the design of my Muldis D programming language (whose design is influenced a lot by Perl 6), I use the data type name "Excuse" as my analogous core concept to Failure or the Exception of some languages. The idea is we have some context where a normal value doesn't exist, so the Excuse value gives the excuse for not having one. The singleton Excuse value named No_Reason is the canonical analogy to a generic unqualified null/nil/undef singleton typical in other languages. The Excuse value named Div_By_Zero is what would result from a number of mathematical operators, and there are others for common situations, and users can define more. The idea here is that an Excuse can either be a stored value such as how null is used in a SQL database, or it can be a result from an operation that doesn't give a normal result. An Excuse does compare equal to itself. -- Darren Duncan
Re: %% with zero denominator
Putting aside the edge case of what to do when the divisor is zero, which could also be tested for prior to attempting to call the operator: An "is evenly divisible by" operator is an immensely useful one to have built-in to the language; not only is "x %% y" much more direct to the real question than "(x % y) == 0)", it can also be optimized because we don't actually care what the quotient or remainder values are. This being similar to how asking "is this list empty" is more direct and optimizable than asking for the count of elements and comparing that to zero, and it also has meaning for list-like uncountable collections. -- Darren Duncan On 2017-12-11 1:02 PM, Vittore Scolari wrote: I think that this stems from a confusion between the divisibility problem in integer number (on a ring) and the divisibility problem resolved by the perl6 %% operator. Personally I think that %% is useless while the former is useful and missing. But I have nothing against useless operators On Mon, Dec 11, 2017 at 9:56 PM, Darren Duncan wrote: On 2017-12-11 12:22 PM, Sean McAfee wrote: Well, not really. I don't think x %% 0 should return a Failure at all. 1 / 0 is an expression which can evaluate to no sensible value, so it makes sense to fail there. By the question "Is one divisible by zero?" has the simple answer "No." I strongly disagree with you. First of all, the reason there is no sensible value is that the answer is BOTH "yes" and "no" at the same time, so you can't choose one. Zero DOES divide evenly into anything, and typically does so an infinite number of times. Bottom line, there is no good reason to answer either "yes" or "no" for zero. There are three distinct kinds of answers to the question "is x evenly divisible by y": 1. When dividing x by y there are no leftovers (yes). 2. When dividing x by y there are leftovers (no). 3. When dividing anything by zero there is no sensible value (Failure). It is very important to distinguish the above 3 cases. The main use case of %% is to gate logic where if 2 numbers do evenly divide we do some particular arithmetic with the results and if they don't but it is a valid division then we do other particular arithmetic with the results. The expression "x %% y" is to be equivalent to "(x % y) == 0)". -- Darren Duncan
Re: %% with zero denominator
On 2017-12-11 12:22 PM, Sean McAfee wrote: Well, not really. I don't think x %% 0 should return a Failure at all. 1 / 0 is an expression which can evaluate to no sensible value, so it makes sense to fail there. By the question "Is one divisible by zero?" has the simple answer "No." I strongly disagree with you. First of all, the reason there is no sensible value is that the answer is BOTH "yes" and "no" at the same time, so you can't choose one. Zero DOES divide evenly into anything, and typically does so an infinite number of times. Bottom line, there is no good reason to answer either "yes" or "no" for zero. There are three distinct kinds of answers to the question "is x evenly divisible by y": 1. When dividing x by y there are no leftovers (yes). 2. When dividing x by y there are leftovers (no). 3. When dividing anything by zero there is no sensible value (Failure). It is very important to distinguish the above 3 cases. The main use case of %% is to gate logic where if 2 numbers do evenly divide we do some particular arithmetic with the results and if they don't but it is a valid division then we do other particular arithmetic with the results. The expression "x %% y" is to be equivalent to "(x % y) == 0)". -- Darren Duncan
books for learning Perl 6
As was announced a few days ago, see https://perl6book.com which is a good site for outlining what books on learning Perl 6 exist and suggestions on where different kinds of users should start based on their needs. -- Darren Duncan
Re: Fwd: Re: Is win 32 being worked on?
On 2017-07-25 2:08 PM, Steve Mynott wrote: To clarify Rakudo itself *should* compile on 32 bit Windows systems (using either MSVC or mingw and maybe cygwin). The problem with Rakudo Star is that some of the C based modules probably don't work. So is it feasible to remove those modules from Rakudo Star? What manner of functionality are they? Would their lack be a problem for most people? It seems to me that one of these things should happen: 1. Modules that don't work with all platforms normally supported by a Rakudo Star distribution get dropped from Rakudo Star. 2. Win32 is dropped from the main list of Rakudo Star distributions. 3. The problematic modules are expressly excluded from the Win32 distros, and this fact is documented, while there can otherwise be up to date Win32 distros with the core and all other features besides these modules. If the modules you describe are considered essential, they should receive updates to run with Win32; otherwise they should be dropped from Star as they are clearly not considered that essential. Dropped modules can still be installed separately as add-ons where they work. -- Darren Duncan
Re: Fwd: Re: Is win 32 being worked on?
I would question why any desktop computer manufacturers were still even shipping non-64-bit capable hardware in 2010. Apple Macintoshes were 64 bit Intel across the board in 2006, or 11 years ago. People like to accuse Apple of being constantly behind the curve on hardware compared to other PC makers, and yet other makers were shipping 32 bit only still 4 years after Apple stopped? -- Darren Duncan On 2017-07-25 12:16 PM, Mark Carter wrote: On 2017-07-25 11:05 AM, Mark Carter wrote: On 25/07/2017 18:34, Darren Duncan wrote: How often would someone reasonably be using a cutting edge tool like Rakudo on Windows without having a 64 bit Windows these days? Thing is, I have a computer from 2010, Win 7 32-bit. It's fast enough for me, and does what I want it to do. I'm not going to spend money just to run Perl6. It doesn't even compile on cygwin. Python is available in 32-bit. Why not perl6?
Re: Is win 32 being worked on?
I recommend removing the reference/link to the Rakudo Star 32 bit Windows installer from http://rakudo.org/how-to-get-rakudo/ and leave only platforms that are reasonably up to date. The old 32 bit Windows installers can still be in the archives of course, but grouping it with the other installers that are 1.5 years newer and gaining isn't doing anyone any favors. The highlighted ones should be in sync on functionality. This link could return if the 32 bit Windows catches up. How often would someone reasonably be using a cutting edge tool like Rakudo on Windows without having a 64 bit Windows these days? -- Darren Duncan On 2017-07-23 10:29 AM, Steve Mynott wrote: Rakudo itself probably does compile on Windows 32-bit (or least it did last time I tried it). But here is no Rakudo Star 32 bit MSI due to problems with modules not working -- I think linenoise failed to compile last time I tried it (and I believe it only works under GCC not MSVC on 64 bit). I'm afraid there is a lot of bitrot with modules not working under Windows I'm afraid in general (both 64 bit and 32 bit). We really need a volunteer Windows programmer to take a look at things since most of us run under various UNIX type OSes regularly rather than Windows. S On 21 July 2017 at 10:37, Todd Chester <toddandma...@zoho.com> wrote: On 07/21/2017 01:57 AM, Mark Carter wrote: On 21/07/2017 09:50, Todd Chester wrote: I may be wrong, but I do believe what you want is called "Rakudo Star". You can download it from https://rakudo.perl6.org/downloads/star/ But no recent win 32-bit. https://rakudo.perl6.org/downloads/star/rakudo-star-2016.01-x86%20(no%20JIT).msi seems to be the last one
Re: Announce: Rakudo Star Release 2017.07
On 2017-07-25 10:05 AM, Brandon Allbery wrote: On Tue, Jul 25, 2017 at 11:45 AM, Darren Duncan wrote: However I assume it is the 3 bullet points that the release announcement highlights: advanced macros, non-blocking I/O, bits of Synopsis 9 and 11. The fact the announcement highlights these implies they are part of the creators' definition of "complete". The "advanced macros" part, at least, probably needs to go away: a large part of the problem is that nobody actually knows what "advanced macros" for Perl 6 should do, or even look like. (See for example masak's 007, which is a playground for macros to try to get a handle on the question of what they ought to be/do.) I agree with your point and should further say that I think at this point the Rakudo announcements should stop naming that features are missing except where they are key show-stopper-for-some features. Don't highlight the fact that some things are missing. That would always be the case. At this point things are complete enough that most people wouldn't even notice things were missing if they weren't told and it doesn't affect them. In my opinion, non-blocking I/O is the only thing on the list that deserves to be highlighted, that and the warnings about the level of JVM support. -- Darren Duncan
Re: Announce: Rakudo Star Release 2017.07
On 2017-07-25 8:32 AM, Steve Mynott wrote: On 25 July 2017 at 16:23, Darren Duncan <dar...@darrenduncan.net> wrote: There's a key difference however. While programming languages continue to evolve, the expectation is that a production-complete Rakudo would always be a functional superset (or equal to) the Perl 6 language specification which is current at the time. The Perl 6 language specification is the test suite. So if the test suite passes then it's complete! Which is of course a tautology. So by that definition, "complete" is that the arbitrary subset of the spec that an implementation chooses to do passes the tests for those parts, and the rest of the tests skip rather than fail. So I think it is reasonable for Rakudo to actually implement ALL of 6.c before too long, that it would catch up, and otherwise the intent is that Rakudo would be leading on things that eventually become 6.d etc later. Which missing parts are you concerned about? I'm not personally concerned about any parts at this time. It is ToddAndMargo that is concerned about it, who asked the question. However I assume it is the 3 bullet points that the release announcement highlights: advanced macros, non-blocking I/O, bits of Synopsis 9 and 11. The fact the announcement highlights these implies they are part of the creators' definition of "complete". -- Darren Duncan
Re: Announce: Rakudo Star Release 2017.07
There's a key difference however. While programming languages continue to evolve, the expectation is that a production-complete Rakudo would always be a functional superset (or equal to) the Perl 6 language specification which is current at the time. So I think it is reasonable for Rakudo to actually implement ALL of 6.c before too long, that it would catch up, and otherwise the intent is that Rakudo would be leading on things that eventually become 6.d etc later. The original question would be more accurately phrased, "Any idea when Rakudo will release implementing the full Perl 6.c?" -- Darren Duncan On 2017-07-25 1:02 AM, Elizabeth Mattijsen wrote: If that is the question, the answer is: the junction of “never" and “now". Which would also be the answer for Pumpking Perl 5, or any other programming language like ever. Because as long as people are using it, a programming language will evolve. Much like any human endeavour I would say. On 25 Jul 2017, at 09:42, Andrew Kirkpatrick <uberm...@gmail.com> wrote: I assume the meaning is, roughly when is the implementation expected to cover the entire spec? Answering this is probably an exercise in futility, because its up to the community and not anyone in particular. On 25 July 2017 at 17:00, Elizabeth Mattijsen <l...@dijkmat.nl> wrote: [snip] Any idea when the full Rakudo will be released? What do you mean by “the full Rakudo” ? Rakudo Star is the Rakudo compiler release with a set of useful modules added (“batteries included”). So you could argue that Rakudo doesn’t get fuller than with Rakudo Star!
Re: Announce: Rakudo Star Release 2017.07
On 2017-07-24 11:40 AM, Steve Mynott wrote: A useful and usable production distribution of Perl 6 The download links on http://rakudo.org/how-to-get-rakudo/ still name the April release and will need updating. -- Darren Duncan
Re: set (+) set = bag ?
On 2017-07-21 1:33 PM, Elizabeth Mattijsen wrote: On 21 Jul 2017, at 21:30, Darren Duncan <dar...@darrenduncan.net> wrote: Firstly, I believe ∆ (U+2206) is the standard symbol for symmetric difference, and not circled minus as the above url currently gives. https://en.wikipedia.org/wiki/Symmetric_difference seems to agree, showing it as the first choice. However, ⊖ appears to be the second choice. FWIW, I think ∆ better matches the Texas variant (^) . The circled plus is also overloaded for XOR (which itself has at least 2 more-preferred alternatives) and other things, while ∆ (U+2206) isn't AFAIK overloaded for anything and in any event ∆ (U+2206) is much more consistent with all the other standard set/bag operators in format and it is what the literature prefers to use. What you say about (^) Texas version isn't a similarity I thought about, but then that gives my proposal extra support if anything. The circled plus should be dropped from use for this meaning. Secondly, I see there's an operator for multiplying 2 bags (which I hadn't heard of before, but okay), but there should also be an operator for multiplying 1 bag by a natural number, that is a scalar multiply of a bag. Unless it is assumed the standard hyper-operator syntax is best for this. If I get this right, you’d want: .Bag * 3 give (:3a,:6b).Bag ? I guess that with * being commutative, 3 * .Bag would be the same result. You are correct in all points above. But then, what would .Bag * .Bag be? I would suggest that this option is either undefined or it has the same meaning as the bag multiplication operator, eg, (:2a,:2b).Bag. Another way of looking at this is, say if we're starting with the existing bag circled-times bag operator, replacing one bag operand with a number N is like replacing it with what is conceptually an infinite-cardinality bag having :Ne for "e" in turn being every possible value in the type system; the infinite bag reduces to one having only matching unique members and replicates those matches by a cardinality of N. -- Darren Duncan
Re: set (+) set = bag ?
On 2017-07-21 12:30 PM, Darren Duncan wrote:
On 2017-07-21 5:07 AM, Timo Paulssen wrote:
You want (|) to get the union of two sets as a set.
https://docs.perl6.org/language/setbagmix#Set%2FBag_Operators
hth
- Timo
Right. Every set operation except 1 (multiset sum) should result in a set, and
is just a special case of the same behavior as the bag operation. Optionally
the Set implementation of multiset sum could toss the duplicates and still
result in a Set, thus being an alias for union with Sets, rather than resulting
in a bag that it otherwise normally would. Depends on designer prefs I suppose.
Now, looking at that link, I can see at least 2 things that perhaps ought to be
changed.
Firstly, I believe ∆ (U+2206) is the standard symbol for symmetric difference,
and not circled minus as the above url currently gives.
Secondly, I see there's an operator for multiplying 2 bags (which I hadn't heard
of before, but okay), but there should also be an operator for multiplying 1 bag
by a natural number, that is a scalar multiply of a bag. Unless it is assumed
the standard hyper-operator syntax is best for this.
Replying to myself. AFAIK, actually hyper-operators would NOT do the scalar
multiply I speak of. For a bag like {5,7}, a hyper by 2 would yield {10,14} but
the scalar I'm looking for is that {5,7} by 2 yields {5,5,7,7}.
-- Darren Duncan
Re: set (+) set = bag ?
On 2017-07-21 5:07 AM, Timo Paulssen wrote: You want (|) to get the union of two sets as a set. https://docs.perl6.org/language/setbagmix#Set%2FBag_Operators hth - Timo Right. Every set operation except 1 (multiset sum) should result in a set, and is just a special case of the same behavior as the bag operation. Optionally the Set implementation of multiset sum could toss the duplicates and still result in a Set, thus being an alias for union with Sets, rather than resulting in a bag that it otherwise normally would. Depends on designer prefs I suppose. Now, looking at that link, I can see at least 2 things that perhaps ought to be changed. Firstly, I believe ∆ (U+2206) is the standard symbol for symmetric difference, and not circled minus as the above url currently gives. Secondly, I see there's an operator for multiplying 2 bags (which I hadn't heard of before, but okay), but there should also be an operator for multiplying 1 bag by a natural number, that is a scalar multiply of a bag. Unless it is assumed the standard hyper-operator syntax is best for this. -- Darren Duncan
Re: Can this OR be shortened?
Just speculating, but try replacing the "||" with the "|" operator which should
create an ANY Junction, if I'm not mistaken, which may then do what you want. --
Darren Duncan
On 2017-03-24 5:58 PM, ToddAndMargo wrote:
Hi All,,
if $Terminal ~~ /xterm/ || /linux/ {}
does not work
But this does
if $Terminal ~~ /xterm/ || $Terminal ~~ /linux/ {}
Can the if statement be shortened such that I do not
have to repeat $Terminal?
Many thanks,
-T
Re: [perl #130845] Some things that are less than 5 aren't
On 2017-02-23 10:00 PM, Joachim Durchholz wrote: Somewhat offtopic: toolforger: p6: say Inf cmp Inf camelia: rakudo-moar 320c2f: OUTPUT: «Same» I.e. Inf compares equal to itself - is this intentional? Even if that isn't valid mathematically, for our purposes in a programming language, Inf is a singleton. I would have a serious problem with any programming language where it isn't the case that asking "is $x the same thing as $x in every possible way" doesn't result in TRUE for all possible values of $x. That's one reason I seriously dislike SQL's NULL that don't equal themselves. -- Darren Duncan
Re: per 5 converter?
On 2017-02-13 2:11 AM, ToddAndMargo wrote: On 02/12/2017 05:12 PM, Darren Duncan wrote: On 2017-02-12 5:08 PM, ToddAndMargo wrote: I presume my eyes would tell where I made the boo-boo. Lets hope! I am real tired of Perl 5's stone age subs declarations. @_, oh brother. In principle there is nothing wrong with @_ at least from the perspective that it is quite useful to be able to have a single variable or keyword to represent the entire argument list as a single value. Logically, a single value is what an entire argument list is anyway, with individual arguments being components of that. -- Darren Duncan Except Perl 5 is a high level language and is suppose to be more friendly to use. @_ is reminiscent of the difficulties encountered with assembly code, especially having to work with reference pointers to return array values. (I do love arrays of hashes.) Perl 6 fixes this big time! If for no other reason, this is why I am migrating to Perl 6. I use "subs" to death. Totally addicted to them and can't live without them . And, Perl 6 makes it easy to understand values passed to subs at a glance. Not to mention not having to waste time renaming $_[x] over to an understandable name. I think the important thing is having choice. Declaring parameters in terms of named variables is normal and important, but when one does that it would still be ideal to get a single extra variable that has all the arguments in it as components, for when it is useful. -- Darren Duncan
Re: per 5 converter?
On 2017-02-12 5:08 PM, ToddAndMargo wrote: I presume my eyes would tell where I made the boo-boo. Lets hope! I am real tired of Perl 5's stone age subs declarations. @_, oh brother. In principle there is nothing wrong with @_ at least from the perspective that it is quite useful to be able to have a single variable or keyword to represent the entire argument list as a single value. Logically, a single value is what an entire argument list is anyway, with individual arguments being components of that. -- Darren Duncan
Re: Can I call myself
Any decent programming language supports self-recursion, where a subroutine may invoke itself. Perl 6 explicitly also supports this, and even has a special keyword for a routine to refer to itself without knowing its own name, especially useful for anonymous subs; I don't remember that keyword but it may have been something like "SUB" or "SELF". -- Darren Duncan On 2017-02-04 12:34 AM, ToddAndMargo wrote: Hi All, Just out of curiosity, in Perl 6 can a subroutine call itself? -T I am fighting with a broken Net:FTP::rmdir in Perl 5 that will not recuse as advertised (it is very intermittent). And I can not use Net::Ftp in Perl 6 as it is hosed and so is the Inline. And it seems that Perl 5 doesn't like me calling myself, which would do wonders for looping on rmdir until I get everything.
Re: fixing infinities and ranges etc
On 2016-10-30 4:11 PM, Darren Duncan wrote: On 2016-10-30 5:45 AM, yary wrote: Before/AfterEverything are also easy to understand, and would be as natural to use for sorting strings, eg. for saying if a database NULL should go before the empty string or after everything else. On the other hand, if I'doing something with tangents and handling pi/2, I'd rather be thinking about PosInf as my exception and not AfterEverything. So, the main thing that I think should exist is a generic before/after-everything concept so that it can be used to indicate that generic intervals are unbounded at either end and that generic 'cmp' etc are automatically defined for every other type and them and use as identity values for min/max. So, following up on this, ... I went with the singleton names Before_All_Others and After_All_Others in my abstract database protocol API for Perl 6, and explicitly documented that these are a type-agnostic analogy to negative/positive infinity whose sole purpose is to canonically sort before or after every other value in the type system, and they expressly do NOT represent any mathematical or physical concept of infinity, including those in IEEE floating point, which should be defined separately where useful. Example uses of these singletons are to represent the endpoints of partially or totally unbounded intervals/ranges, or be the identity values for "min" and "max", or be the result when one calls "pred" or "succ" on the first/last value of an orderable type. And so, I also want to propose that Perl 6 add the 2 singletons X::BeforeAllOthers and X::AfterAllOthers for similar type-generic use cases. Yet other singletons or values can exist to meaningfully represent mathematical infinities etc such as the IEEE floats support so appropriate semantics exist in peoples' code. -- Darren Duncan
Re: [perl #130260] [LTA] Curly quotes are referred to as “smart quotes”, this is not entirely right
I want to give my strong support for this proposal. Call them "curly" quotes.
The term "smart" is BAD in this context. Just like how short cars are not
"smart" even if people say that, only self-driving cars deserve that name. --
Darren Duncan
On 2016-12-04 10:04 AM, Aleks-Daniel Jakimenko-Aleksejev (via RT) wrote:
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #130260]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130260 >
Code:
say ‘hello
Result:
===SORRY!=== Error while compiling -e
Unable to parse expression in smart single quotes; couldn't find final "’"
at -e:1
--> say ‘hello⏏
expecting any of:
argument list
smart single quotes
term
From this article https://en.wikipedia.org/wiki/Quotation_mark (perhaps not the
best reference, but still):
“The "smart quotes" feature in some computer software can convert vertical
quotation marks to curly ones”
“Curved and straight quotes are also sometimes referred to as smart quotes (“…”) and regular quotes
("…") respectively; these names are in reference to the name of a function found in
several word processors that automatically converts straight quotes typed by the user into curved
quotes, attempting to be "smart" enough to determine which typed quotes are opening and
closing.”
There is nothing “smart” about these quotes in our case. In fact, I type these
quotes directly and am somewhat pissed off by the message (these quotes did not
get into my code accidentally because some software decided to change them).
I suggest to refer to them as “curly quotes”, this is perhaps the best way
(other ways would be “book” and “typographic”, but again this is a bit off).
Re: [perl #128897] [LTA] [MATH] "-0".Num isn't negative
And here I thought IEEE floats had distinct values to represent overflows and underflows that were distinct from both the zeros and the infinities. -- Darren Duncan On 2016-11-22 8:19 PM, Zefram wrote: Zoffix Znet via RT wrote: The reason we have a negative floating point zero at all is more due to underlying implementations at whose level such zeros are used to signal various exceptions. No, that's not what negative zero is about in floating point. (Maybe you're thinking of ones-complement integer formats.) In floating point, zero doesn't only represent exact zero quantities, it also represents underflow, and it's useful to know from which side of zero a quantity underflowed. Generally, IEEE 754 provides well defined semantics for signed zeroes throughout, which put negative zero on a par with positive zero. Are you able to describe any usecases where the string cast resulting in a positive zero as opposed to negative zero creates a problem? Getting the right zero particularly matters in trigonometry and in complex arithmetic, where the zeroes are on opposite sides of many branch cuts. For example: atan2(0e0, -1) 3.14159265358979 atan2(-0e0, -1) -3.14159265358979 The above behaviour is correct and desirable. In a situation where the arguments come from string input, getting this correct behaviour depends on the Str->Num conversion properly supporting signed zeroes. -zefram
Re: fixing infinities and ranges etc
On 2016-10-30 5:45 AM, yary wrote: I'm not sure I entirely understand the proposal- does it change Inf aka ∞ ? Part of the issue I think is that the existing "Inf" aka "∞" don't seem to be very clearly defined. What I could find so far, at least with respect to Ranges, is that they are just syntactic alternatives to the Whatever *. They don't seem to be actual typed values that one can say use as declared types for things. Otherwise I like it, and prefer the X::NegInf and X::PosInf,spellings as being easy-to-understand & a good Huffman-encoding. Ok. Before/AfterEverything are also easy to understand, and would be as natural to use for sorting strings, eg. for saying if a database NULL should go before the empty string or after everything else. On the other hand, if I'doing something with tangents and handling pi/2, I'd rather be thinking about PosInf as my exception and not AfterEverything. So, the main thing that I think should exist is a generic before/after-everything concept so that it can be used to indicate that generic intervals are unbounded at either end and that generic 'cmp' etc are automatically defined for every other type and them and use as identity values for min/max. At the same time, I think some people would want to distinguish between these and a mathematical concept of infinity in a similar manner that people distinguish orderable and ordered and ordinal etc. What I mean by the latter is, "ordered" and "ordinal" have rather precise meanings in set theory or mathematics etc, meanings that don't apply to a lot of data types we tend to sort on. For example, ordered/ordinal strictly speaking wouldn't apply to character strings and they may not apply consistently to the general case of rational numbers and so on; for some types we just want to be able to sort them deterministically but the actual sort order might not be meaningful within the domain. So I made up the term "orderable" to refer to what generic "cmp" or SQL "order by" etc do. The before/after-everything singleton are meant specifically to apply to this "orderable" concept. So, having that, the question is whether we want to have distinct infinity concepts for numbers from those, and I suspect we might. In maths we have directional infinities on a line, but there's also the concept of something being infinite that is not directional such as an unbounded volume, and there's also countable vs uncountable infinities etc. We may not want to imply any of those with our before/after-everything concept which is meant to serve a different purpose. X::BE and X::AE are too short to use outside of this discussion, especially as "BE" is the common verb "be." Maybe X::OBE and X::OAE for "ordered before/after everything"? Anyway, this part is bike-shedding, my main point is that the singletons simply exist and what their properties are. Before/AfterEverything ... would be as natural to use for sorting strings, eg. for saying if a database NULL should go before the empty string or after everything else. So, now this brings up a different thing. A Perl 6 analogy to a SQL Null would ALSO be a Failure singleton type, for example X::NoReason, basically it means that we don't have a normal value of the domain here AND we are giving absolutely no explanation for why the normal value is missing. A SQL Null in general means means "we don't have a normal value and we aren't saying why", it does NOT mean "not applicable" or "unknown" or "missing" or "not matched" or anything like that, it doesn't even say which of those it is. As far as I could tell the Perl 6 Nil singleton had this X::NoReason meaning, but if it actually doesn't, then we should have a new X::NoReason to be more explicit about that. This would mean that a Perl 6 Nil actually IS giving a reason why the normal value is absent. As a final note today, I will mention that the subject of this email thread is relevant to this thing that I'm working on, a DBI for Perl 6 with a PSGI/Plack inspired design, meaning a no-mandatory-shared-code database interface: https://github.com/muldis/Muldis-DBI-Duck-Coupling-Perl6/blob/master/lib/Muldis/DBI/Duck_Coupling/API.pod -- Darren Duncan
fixing infinities and ranges etc
I have observed that the current Perl 6 spec and implementations seem deficient in regards to representing some special values or conditions, in particular the concept of the two linear directional infinities or otherwise special values that naturally sort before and after everything else. Moreover, some discussion I saw on the matter shows that these issues had been punted, so here I'm trying to propose a resolution or process to that end. Here are some links for context: * http://irclog.perlgeek.de/perl6/2014-08-20#i_9217322 * https://docs.perl6.org/type/Range#method_infinite * https://github.com/rakudo/rakudo/blob/nom/src/core/Range.pm Here are some proposals and comments: 1. I think the best way to represent various special values like this is as singleton types, basically in the same way various Failure or Exception are handled, such as the various X::Foo classes. So for example, we should add X::NegInf and X::PosInf, or alternately per Larry's comment in the first link, something like X::BeforeEverything and X::AfterEverything or X::BE and X::AE. Actually we may want both the infs and the BE/AEs where distinguishing them is useful. Similarly I recommend adding such singletons for various other math concepts such as X::DivByZero and X::ZeroToTheZero etc. 2. In the case of NegInf/PosInf (alternately read as BE/AE from now on), generic ordering sensitive operators like cmp would have signatures defined such as (NegInf, Any), there would be 4 combos of those, which would be defined to always return FALSE or TRUE as appropriate; as such, all values would be comparable with these singletons automatically. Also, any dyadic min/max operators would use these singletons as their identity values. 3. Regular types such as Int or Rat or Str etc should be pure and just include normal values, that is just actual numbers for the numeric types etc. Then, contexts that might produce or want to recognize failure conditions alternately accept or return the appropriate Failure singletons mentioned, as if a type union were defined over the regular types and the failure types; users can choose whether they want to allow the special values explicitly by either including or excluding them from signatures, so naming eg just Int will only accept actual numbers. 4. Independent of the above points, the current Range class has a problem in that it doesn't distinguish which endpoint is infinite. Just as it currently distinguishes whether each endpoint is open or closed, it needs to distinguish whether each endpoint is infinite or finite. All 4 of these cases need to be distinguished: 5..10, -Inf..10, 5..Inf, -Inf..Inf and I hope it should be self-evident why that is important. For starters, it is completely valid to ask whether a value is in any of the given ranges; for half-infinite ranges, it is a generalized form for asking if the value is larger or smaller than the finite end; for fully-infinite ranges, the answer is always TRUE. Another way to think about it is that a Range is just a concise way of expressing a set. The current Range class simply has a boolean attribute that says is the Range infinite, yes or no, and that needs fixing. 5. A generic solution to representing Ranges properly is to use the two special singletons I mentioned be the endpoint values. A lot of comparing operations would then just work. Using the range to generate a list of member values would also work in some cases, depending where the infinities are and in what direction we are enumerating. So what are the thoughts on this? Can we get appropriate improvements into Perl 6d and implementations etc? Also, is any of what I said actually already done? Certainly some key parts at least are not. Thank you. -- Darren Duncan
Re: coded size limits on Perl data types?
Thank you for this Timo, and to everyone else who replied. It did indeed address what I wanted to know. -- Darren Duncan On 2016-09-13 5:15 AM, Timo Paulssen wrote: I'll answer based on the data structures MoarVM uses internally: On 09/13/2016 05:13 AM, Darren Duncan wrote:> (Pretend the actual hardware has infinite memory so we wouldn't run > out of hardware first.) > > 1. Maximum size of a (non-machine) integer? We're using libtommath, which declares the "used" and "alloc" fields of the mp_int as "int", iow a 32bit signed (???) integer. 2. Maximum number of elements in an array? MVMArray declares the "elems", "start" and "ssize" fields to be MVMuint64, so they can become quite a bit bigger than strings. 3. Maximum number of elements in a hash? the "uthash" library we're using declares the "num_buckets" and "num_items" fields as unsigned (so 32bit unsigned integer). 4. Maximum number of bytes/codepoints/etc in a character string? MVMString declares its "num_graphs" as a MVMuint32, but a graph can be multiple codepoints and as such multiple bytes when encoded. Following the above, does the Perl 6 language specify any such > limits, or does it define the above things to be infinite? I don't think it does. Hope that helps! - Timo
coded size limits on Perl data types?
Ostensibly Perl 6 is meant to be a language ready for the next hundred years. As such, I am wondering where either Perl 6 or its implementations have hard-coded limits based on current or projected hardware limitations, or where they don't. Examples of what I would like to know, do any limits exist on each of the following and if so then what are they? (Pretend the actual hardware has infinite memory so we wouldn't run out of hardware first.) 1. Maximum size of a (non-machine) integer? 2. Maximum number of elements in an array? 3. Maximum number of elements in a hash? 4. Maximum number of bytes/codepoints/etc in a character string? Possible reasons for the limits include that a fixed-size integer may be used to record the count of elements in a collection, including to mark the size of a collection having pieces of a bigint, or using a fixed-size integer for indexing into an array, say. Following the above, does the Perl 6 language specify any such limits, or does it define the above things to be infinite? Do any Perl 6 implementations support the above being infinite, or do they use fixed-size numbers to track anything that would effectively limit the types? Thank you. -- Darren Duncan
Re: can a method name contain a funny character?
On 2016-04-12 6:59 AM, Brandon Allbery wrote:
On Tue, Apr 12, 2016 at 9:51 AM, Brock Wilcox <awwa...@thelackthereof.org>
wrote:
Heart doesn't work for me, but other symbols seem fine. I don't know why. I
also didn't need to quote them. Here is a REPL session from a Rakudo
2016.01.1:
> sub Δ($x) { say "got $x" }
Δ is a perfectly valid letter in the Greek alphabet. Unicode doesn't care that
you prefer to think of it as a symbol.
On the other hand, Unicode has a lot of actual Mathematical Symbols for stuff
like this, so you don't have to use what it considers Greek letters when you
mean symbols.
For example, ∆ is U+2206 named INCREMENT.
Is that not better, or is an actual Greek letter desired in the above example?
-- Darren Duncan
Re: Very small feature suggestion
On 2016-03-09 7:59 AM, Parrot Raiser wrote: Software that traps a user with no obvious way to quit is annoying, (especially if one is just starting to learn it). When Perl 6 is invoked with no options, it starts the REPL, simply offering the ">" prompt, with no explanation of how to get out. Anyone used to software is likely to have no problems guessing "exit", (perhaps after will terminate it, but a newbie might not. How much work would it be to print "To return to the command line, type exit or ^D" when first invoked? I think this is a great idea. There is also precedent for a REPL to print a similar statement like "for help type this". -- Darren Duncan
Re: It's time to use "use v6.c"
On 2016-02-06 11:35 AM, Brandon Allbery wrote: On Sat, Feb 6, 2016 at 2:30 PM, yary <not@gmail.com> wrote: this morning I installed the 2016.01 R*. Now I'm at the NYC perl6 study group, and a helpful neighbor asked me to start up p6doc. This is something of an edge case. It is reasonable for stuff that is supposed to ship *with* perl6 to bend the rules; the problem is that nobody realized that p6doc was broken (this was discovered earlier today), so R* silently (grumble) didn't include it and you got some other p6doc instead. I agree with yary. I also think that dog-fooding it should be done where possible. If stuff that ships with perl6 can't be written using all the same best practices as code users should write, then its a problem. This includes not having "use v6.c". While exceptions may exist, any time they do, that should become a case study for whether there is truly a good reason for the code to work that way, or if there isn't. Keep in mind that the standard libraries are right now some of the primary examples Perl 6 developers would have to look at on how to write Perl 6 code. -- Darren Duncan
Re: is there a Perl 5 converter?
On 2016-01-20 5:02 PM, ToddAndMargo wrote: or is it all by hand? If you mean a source code translator, I don't know of one right now but I wouldn't be surprised if one exists, that at least handles a common subset of Perl 5 code. I expect having one will be a priority if it isn't around now. Maybe around 5 years ago I recall that the Perl 5 interpreter was updated to retain all source metadata in its parse tree partly so that this could be a basis to generate the original Perl 5 source, or alternately generate corresponding Perl 6 from it. See also the CPAN module PPI which may be a basis for one. You may not need a source translator though. The Perl 6 module Inline::Perl5 lets you simply use Perl 5 modules in Perl 6 programs as if they were Perl 6 modules. The source translation I'm aware of is generally by hand, and often people doing it are also doing significant rewrites to take better advantage of the new Perl 6 features and idioms that a more mechanical automatic translation wouldn't. Did that tell you anything useful? -- Darren Duncan
Re: Perl 6 Advocacy Suggestion
I very much agree with this idea, of arguing Perl 6 as a teaching language. Academia are the ones that would appreciate what Perl 6 offers the most in the short term, whereas industry would demand a higher standard for it becoming popular. And the first can lead to the second. -- Darren Duncan On 2016-01-19 9:19 AM, Parrot Raiser wrote: I believe Damian Conway thinks P6 would be a very good CS teaching language. On 1/19/16, Tom Browder <tom.brow...@gmail.com> wrote: On Tue, Jan 19, 2016 at 10:18 AM, Steve Mynott <steve.myn...@gmail.com> wrote: I think targeting Perl 6 at CS academic teachers is an excellent idea as a way of generally promoting use of the language. But I'd be wary of "bashing" current choices such as Python and don't believe any objective comparison of the two languages is possible. Python is in any case derived from ABC which was explicitly designed for teaching purposes. I'm not suggesting bashing Python, Steve, I just think some comparison is necessary.
Re: perl 6 for rhel?
Red Hat is quite conservative. Usually what happens in situations like this when you want more up to date stuff you get it from alternate repositories that make Red Hat compatible packages. See also repositories for Fedora or Cent OS. -- Darren Duncan On 2016-01-10 11:16 PM, ToddAndMargo wrote: On 01/10/2016 11:05 PM, Brandon Allbery wrote: On Mon, Jan 11, 2016 at 2:02 AM, ToddAndMargo <toddandma...@zoho.com <mailto:toddandma...@zoho.com>> wrote: Anyone know if Perl 6 will be available for Red Hat Enterprise Linux 7 any time soon? That's up to Red Hat. Considering that they refuse to fix their Perl 5 packaging which has been fundamentally broken (not to mention ancient) throughout EL5 and EL6, don't hold your breath. I posted I posted https://bugzilla.redhat.com/show_bug.cgi?id=1297077 https://bugzilla.redhat.com/show_bug.cgi?id=1296363 but no response back
Re: $epsilon = 1.0e-6 feels too big for Rat()
Considering that a non-fat Rat has a 64-bit denominator, I would expect conversions from Num to make use of that full precision by default, and not round off to 6 decimal places. -- Darren Duncan
Re: release?
On 2015-12-29 1:58 PM, simran wrote: * ParrotVM seems to be pretty much dead? (this is not a trolling question, it appears from certain emails on this list in the past few days that this seems to be an opinion, i'm just taking it at face value...) On one hand I just interpreted this as ParrotVM being de-prioritized. Getting *A* working Rakudo out the door, even if on fewer VMs, was more important than keeping all the VMs in sync, in the short term. I anticipate that Parrot will or may catch up later to MoarVM+JVM in fully supporting Rakudo. On the other hand, it is possible that Parrot has had its day. Since Parrot is no longer needed to have an effective running Perl 6, there would have to be other reasons for Parrot to continue to be viable ongoing. This could be as simple as that enough people want to keep maintaining it and provide another option for Rakudo. Or it could be because Parrot has other unique features over the other VMs that are compelling. For what I want, as long as I can target NQP, that is as low level as I care to get in this ecosystem, and the fact that runs in MoarVM and JVM is enough for me. NQP over multiple VMs provides the promises of Parrot as far as I'm concerned, a common environment multiple programming languages can compile to and interact with each other. I do have my own programming language almost ready to run. The current plan is to make it run over alternatively C# and Perl 5 first, and NQP and Ruby and Python and Java after. I don't know yet if there is value to targeting Perl 6 at large when I have NQP; I could, but NQP is more important to do in practice I think. -- Darren Duncan
Re: release?
Thanks for all the responses, and I agree with them.
At the same time, I think I was misunderstood, so I will try and clarify my
position now.
1. I fully understand the distinction between a version of the Perl 6 language
spec, or of components thereof (such as of grammar, standard library, test
suite, etc), and a version of a Perl 6 implementation or component thereof (such
as Rakudo, NQP, MoarVM, JVM etc), and a version of a distributing package of the
above (such as Rakudo Star, or Debian packages, or CentOS packages, etc).
2. I advocate such a separation and distinct versioning of such things as the
above. The Rakudo version and Perl 6 spec version are not the same and
shouldn't be.
3. Code written in Perl 6 should declare at least one version of the Perl 6
spec it conforms to and should be treated as, optionally a version it is known
not to conform to, etc. Unlike some other people, I think declaring such a
version the code expects to work with should be mandatory. Each implementation
will either natively support a declared version, or emulate it, or not support
it, etc.
4. As a key point to this discussion, I believe that something as complicated
as the Perl 6 spec itself is bound to have regular updates or bug fixes itself,
where bug means either a documentation mistake or a bug in the test suite etc.
As such, I believe it is perfectly reasonable for the Perl 6 spec itself to have
more finely grained version numbers.
5. Given the prior point, I had until now understood Perl 6.c, 6.d etc, which I
only realized the existence of that scheme in the last month or so, to be
transitional names, and we would use a number-based scheme at some point, for
the language spec itself. Perhaps with a semantic version where incrementing
some numbers added features or possibly removed them, and other numbers just
fixed bugs without being considered a forwards or backwards breaking change.
Here's a question:
If language specifications trail implementations by a significant margin, then
how does Perl 6 code idiomatically declare that it depends on features that say
Rakudo added which aren't in the spec? Does it use an "auth" of "Rakudo" or
something like that? I didn't see your talk so maybe you covered this.
Note, up until now, I had considered using alternate "auth" to indicate a fork
of the spec or such, though in hindsight of your implementations leading spec
comment, I assume this is also how one indicates dependencies on a spec-leading
compiler.
Thank you.
-- Darren Duncan
On 2015-12-29 5:46 AM, Patrick R. Michaud wrote:
On Tue, Dec 29, 2015 at 01:57:57AM -0800, Darren Duncan wrote:
On that note, are there going to be Perl 6 versions 6.x.y where {x,y} are
integers? Will 6.0.0 be the first such one? -- Darren Duncan
This was the topic of my FOSDEM talk last year, and then again at YAPC::NA.
"Perl 6" is a language, not an implementation of that language. Think of "Perl 6" as being like
"C", "C++", "Javascript", etc., where the language is separate from the (many) implementations of
that language.
There are two key points to make:
1. Language specification should follow implementations, not precede them.
This has been found to be true for many programming languages, and it's the way
things work in the Internet RFC/STD process. An update to a language spec
recognizes and ratifies the features that have been largely agreed upon by
implementations and users, as opposed to prescribing what the next version of
the language ought to look like. First is rough consensus, then running code,
and *then* formalization into a specification.
So, if language specification follows implementation, it's not possible for Rakudo or other implementations to use
language version numbers as their primary versioning scheme. To take an example from the C language: My gcc compiler
says it's version 5.2.1, but there's not a version "5.2.1" of the C Programming Language. Similarly, one
doesn't speak of the "C89", "C99", or "C11" release of GCC.
2. It doesn't make a lot of sense to think of major/minor version numbers such as 6.x.y when discussing a language
specification. Compiler releases happen often, incorporating new features, bug fixes, and small incremental changes.
Language specification changes tend to happen on longer timescales -- there's not really a notion of a "minor
release" on such timescales. So, the language specifications are being versioned as "6.a",
"6.b", "6.c", etc., instead of a scheme incorporating minor version increments.
Yes, this separation of language specification and implementation can be unnerving to
those that are so used to Perl 5's tight coupling of the two, including using a common
"version number" for both. But that tight coupling is partly
Re: release?
On that note, are there going to be Perl 6 versions 6.x.y where {x,y} are
integers? Will 6.0.0 be the first such one? -- Darren Duncan
On 2015-12-29 12:51 AM, Tobias Leich wrote:
Hi, the first official Perl 6 (the language) release is not called 6.0.0, it is
called 6.c.
And this is what has been shipped with the Rakudo compiler release 2015.12.
Cheers, Tobias
Am 27.12.2015 um 20:33 schrieb webmind:
Hiya,
I'm a bit confused, there is a major release for Perl 6, but I know
wonder if this is the 6.0.0 release or when this will be?
Thanks
web
Re: Constants as members of a class
Since all you want is a constant, try declaring a submethod that has no
arguments and returns the value, instead, its the same thing. -- Darren Duncan
On 2015-12-17 6:46 PM, TS xx wrote:
Hello dear perl6 users,
I was in the need of declaring a member variable as a constant integer. After
many syntax tryouts I came to this one:
class MyClass {
has int $.myConst;
method new () {
return self.bless();
}
submethod BUILD () {
constant $!myConst = 1;
}
method showMyConst () {
print $!myConst;
}
}
But I'm getting the followinf error message: "Twigil-Variable constants not yet
implemented. Sorry."
The only place in the docs where I have found any reference to constants is in
here: https://doc.perl6.org/language/variables#The_%3F_Twigil
But it's not what I am looking for :/
So my questions are:
Is the syntax right and the thing isn't implemented yet?
Is the syntax (or the full concept) wrong?
Do I have and old interpreter (This is perl6 version 2015.02 built on MoarVM
version 2015.02)?
Thanks to all.
Kind Regards,
Emiliano
Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
On 2015-10-15 5:27 AM, yary wrote: Short answer: everything must declare which semantics it expects- everything in Panda/CPAN at least. And we already knew it, just need to do it. I believe this is something Perl 6 should require in general, if it doesn't. That is, it should be MANDATORY for Perl 6 code to declare what version of Perl it expects. (The sole exception is one-liners.) If we don't do this, people are going to be lazy and not say anything, and then there will be a large base of code that officially is just saying "any version of Perl 6 will do" but they silently actually expect Perl 6.0.0.0 semantics. We're always going to be stuck with this problem if we don't make declarations mandatory now. That's a much more important change to ingrain into those several hundred existing modules, if they aren't already, nevermind the :D thing. -- Darren Duncan
Exploit the versioning (was Re: Backwards compatibility and release 1.0)
I have a proposal. Unlike with say the GLR, perhaps this whole :D thing may be a good test case for the Perl 6 feature of explicit language versioning. How about we don't make the :D change now, and give more thought as to whether we actually want to do it at all. If we do decide it is worthwhile, lets make it so that the :D change is part of Perl 6.1 say, along with any other changes we decide in the near future would be a good idea. Then, programs that explicitly say "use 6.1" or such will get :D as default, while those that don't or say "use 6.0" etc will get the current behavior with :D not being default. I say, save any further major breaking changes before this Christmas for things that would be really hard to change later and are sure to be worthwhile now, and the :D thing is not one of those. What do you think? -- Darren Duncan On 2015-10-14 2:54 AM, Moritz Lenz wrote: So a large percentage of the module updates are done by group of maybe five to a dozen volunteers. So, do the math: 5 people updating 70% of 390 modules. Modules they are usually not all that familiar with, and usually don't have direct access. So they need to go through the pull request dance, waiting for reaction from the maintainer. In short, it sucks. The ecosystem hasn't yet fully recovered from the s/done/done-testing/ change, nor from the GLR, nor from the need to prefix 'unit' to some declarations. And this is why I'm getting increasingly frustrated and angry when people propose major breaking changes, brushing off the implications for the ecosystem and its maintainers with "but it's not 6.0", "shouldn't be a problem", "we aren't stable yet". We want to release Perl 6 by Christmas, and it'll reflect *very* badly on us and the language if many modules in the ecosystem are broken. And any change that requires us to touch all .pm files will result in that.
Re: Exploit the versioning (was Re: Backwards compatibility and release 1.0)
On 2015-10-14 6:14 AM, Parrot Raiser wrote: Is this particular change one that could be implemented algorithmically, or at least partially so? (E.g. For all modules check for the presence of a ":D". If it's there, no action. If not, insert a line of code. Run a test. If successful, post change. If not, alert a human) I think this can be done, yes, and in principle it would be a good idea. But the problem Moritz seemed to be raising is that each of the Perl 6 modules is possibly in different repositories under a wide variety of users, and it would still count on a lot of people to take action to accept those changes in order to not have a lot of breaking. While I agree that changing the modules would be better quality-wise, my versioning proposal is likely more practical if we're trying to focus on stability now for a Christmas release. I mean, this situation seemed to be a solid example of why Perl 6's versioning scheme exists in the first place, to deal elegantly with things like this. -- Darren Duncan
Re: Backwards compatibility and release 1.0
I had a related thought. We want Perl 6 to be the best it can be out of the gate when it is declared production ready at Christmas or whatever. If it is better for the default to be that parameters must be defined where not explicitly declared otherwise, then that is what Perl 6 should specify, and it doesn't matter about the 390+ modules that exist now. Perl 6 is supposed to be a break it all at once release, and this situation is no different. Having :D being default seems right to me, that would seem to huffman code for the safer behavior which users most likely want by default. -- Darren Duncan On 2015-10-13 1:52 AM, Richard Hainsworth wrote: Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: But hopefully none of them breaking backwards compatibility on such a large scale. The last few backwards incompatible changes still cause pain in the ecosystem. We have 390+ modules, and hand-waving away all trouble of maintaining them seems a bit lofty. Surely, the idea of keeping the release number below 1.0 is to warn early adopter developers that code is subject to change and thus in need of maintenance? Seems strange that after so long and "Christmas" is finally coming up that Rakudo 1.0 is going to be associated with modules that do not comply with the "standard". So if :D is the default specified by the standards, then all modules should be expected to conform to that standard when V1.0 comes out. It does not matter really what the standard actually is, :D or not, so long as what is defined to be the standard is adhered to. Perl6 gives huge flexibility to developers to change standard for themselves, but surely there should be some common 'starting' ground, and modules for general use should adhere to it. When the language and implementation were being co-developed, it was reasonable to expect that different modules would have different states of compliance. But surely V1.0 is a different sort of milestone? 'Hand-waving' all the trouble of maintaining the modules surely is not the issue. Ensuring that the modules comply with the standard set for Perl6 as implemented by Rakudo V1.0 is a reasonable expectation for anyone using the Rakudo version of Perl6 going forward. Even if there is an argument that I have missed in the above about the need for modules to adhere to the standard prescribed by the Perl6, would it not be in the interests of PR around Perl6 for the very first V1.0 implementation to be accompanied by modules that have been brought as close to the standard as possible? These modules will help future developers to understand how to use the language.
Re: To :D or not to :D
On 2015-10-12 1:25 PM, Patrick R. Michaud wrote: On Mon, Oct 12, 2015 at 09:51:13PM +0200, Mark Overmeer wrote: Can you give me an example? Many other languages are capable to live without undef and have first class type objects. Keep in mind that what Perl 6 calls a "type object" isn't quite the same as class objects in other languages -- a Perl 6 typename is really an undefined instance of a class. In other words, the identifiers C, C, C etc. refer to instances of those classes just like the literals C<3>, C<4/5>, and C<[1,2,3]> are instances of those classes. They share the same method spaces. Hey, that sounds like a nice elegant design, I learned something new. -- Darren Duncan
Re: Language design
On 2015-06-16 2:15 PM, The Sidhekin wrote: On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler mich...@zedeler.dk wrote: ...and unpredictable performance is a cost you're willing to pay? I don't write performance-critical applications, but even if I did, why would I prefer getting the wrong answer faster? I agree with Sidhekin and similar mentalities. On the range between safety/correctness and speed, a good programming language / tool should always default to the most safe/correct option when the user doesn't specify where on the range they want, and leave it to the power users to explicitly make the trade-off when they know what they're doing. In this case, people who explicitly want floats because of performance rather than exact rationals do indeed count as power users. Normal people are more interested in not being surprised by the answers they get to what should be common-sense questions, such as when adding 10.3 to 14.2. I should also point out that finance / anything to do with money is an extremely common use case that cares very much about math being exact, its not just esoteric science applications. This all being said, I draw the line where implementing is much more complicated to serve esoteric cases. So for example while exact precision rationals absolutely should be default / part of core, something like symbolic values eg exact representations of irrational numbers, are perfectly valid to, and probably shouldn't, be part of core. Exact rationals are not particularly complicated. Its perfectly reasonable to expect in the core that if someone does math that is known to deal with irrationals in general, that loss of precision then is acceptable. -- Darren Duncan
Re: versioning - how to request different 'ver' per 'auth'?
Please get the #perl6 consensus then. I had suspected the answer would be that
the solution would be the :ver code being able to see what :auth was selected
and dispatch based on that. Otherwise supporting the wider version declaration
to have a tree structure, where :ver was embedded inside :auth etc. Note that I
raised this question on #perl6 myself shortly before writing perl6-language, but
the email version is better organized. -- Darren Duncan
On 2015-06-10 11:38 PM, Tobias Leich wrote:
Hi, that is a very interesting use case, and IMO a very valid one.
Currently the semantics are, to also explain the correct syntax of the
pair that follows a 'use NAME':
:authBar and :ver1.2 etc are of type Pair. Wenn the compiler hits a
use statement, it smartmatches
the distribution's auth/name/ver against the value of the corresponding
Pair.
That means these Pairs are valid:
:authBar # match literally
:auth(/\w+/) # regex match
:auth($author) # okay if $author is known at compile time
:auth(*.chars == 6) # oaky, whatevercode
:auth({ $_.starts-with('Bla') }) # okay, closure
:auth(- $auth { $auth ~~ /Bla/ }) # okay, something callable with arity
== 1
:auth({ $^auth ~~ /Bla/ }) # okay, something callable with arity == 1
etc
That also means we cannot match different version patterns for different
:auth patterns, because we only
pass one value to the Pair's value to smartmatch against. What I can
imagine though is that if the matcher
is callable, and has an arity of 2, we pass the CompUnit as the first
and the $auth as the second argument.
That needs consensus in #perl6 though.
Cheers, Tobias
Am 11.06.2015 um 05:26 schrieb Darren Duncan:
So I have a question about versioning, either/especially about
compilation units, but also Perl 6 itself.
For context I refer to http://design.perl6.org/S11.html#Versioning .
With regard to use statements and specifying 'auth' or 'ver' to
restrict between versions, it seems to me that the spec defines them
interacting in a cross-product fashion.
For example, given this possibly incorrect syntax:
use Dog:authcpan:TPF cpan:JRANDOM:ver(4-6, 10-15);
... that would be satisfied by any of TPF versions 4-6,10-15 or
JRANDOM versions 4-6,10-15.
However, what I want is to restrict the 'ver' differently depending on
the 'auth', treating them more as the hierarchy they are, assuming
that different authorities may go off and use different versioning
schemes.
The question I have is how to 'or' the following into a single 'use
Dog' that isn't any less restrictive:
use Dog:authcpan:TPF:ver(v1.2.1..v1.2.3);
use Dog:authcpan:JRANDOM:ver(v14.3..v16.2);
That is, the cross-product answer is not restrictive enough.
I don't know if this hypothetical use case has been discussed before,
but if not, I hope that the Perl 6 specification has or can gain a
clean way to say how its done.
Thank you.
-- Darren Duncan
Re: New Logo Design for perl6 modules
Or a pumpkin for that matter, since Perl 5 is Pumpkin Perl. -- Darren Duncan On 2015-06-11 7:42 PM, Darren Duncan wrote: I was going to say that too, about the camel trademark issues, so can you make a version using an onion instead of a camel? See http://www.perlfoundation.org for what I refer to. -- Darren Duncan On 2015-06-10 11:34 PM, Moritz Lenz wrote: Hi, On 06/10/2015 02:01 PM, Lin Yo-an wrote: Hi folks! I designed a logo for CPAN, and I think it can be used for perl6 modules, don't know if you're interested in it? https://twitter.com/c9s/status/608549774648692736 Great, I like it! Is there a high-res version available? What's the license? Any chance we can get a p5/p6 twin theme (like, one with a butterfly, in addition to the one with the camel)? It would be awesome to have cpan.org or metacpan.org and modules.perl6.org with clearly related but distinct art work. One word of caution: the use of the camel in relation to Perl is a trademark by O'Reilly. Cheers, Moritz
Re: New Logo Design for perl6 modules
I was going to say that too, about the camel trademark issues, so can you make a version using an onion instead of a camel? See http://www.perlfoundation.org for what I refer to. -- Darren Duncan On 2015-06-10 11:34 PM, Moritz Lenz wrote: Hi, On 06/10/2015 02:01 PM, Lin Yo-an wrote: Hi folks! I designed a logo for CPAN, and I think it can be used for perl6 modules, don't know if you're interested in it? https://twitter.com/c9s/status/608549774648692736 Great, I like it! Is there a high-res version available? What's the license? Any chance we can get a p5/p6 twin theme (like, one with a butterfly, in addition to the one with the camel)? It would be awesome to have cpan.org or metacpan.org and modules.perl6.org with clearly related but distinct art work. One word of caution: the use of the camel in relation to Perl is a trademark by O'Reilly. Cheers, Moritz
versioning - how to request different 'ver' per 'auth'?
So I have a question about versioning, either/especially about compilation units, but also Perl 6 itself. For context I refer to http://design.perl6.org/S11.html#Versioning . With regard to use statements and specifying 'auth' or 'ver' to restrict between versions, it seems to me that the spec defines them interacting in a cross-product fashion. For example, given this possibly incorrect syntax: use Dog:authcpan:TPF cpan:JRANDOM:ver(4-6, 10-15); ... that would be satisfied by any of TPF versions 4-6,10-15 or JRANDOM versions 4-6,10-15. However, what I want is to restrict the 'ver' differently depending on the 'auth', treating them more as the hierarchy they are, assuming that different authorities may go off and use different versioning schemes. The question I have is how to 'or' the following into a single 'use Dog' that isn't any less restrictive: use Dog:authcpan:TPF:ver(v1.2.1..v1.2.3); use Dog:authcpan:JRANDOM:ver(v14.3..v16.2); That is, the cross-product answer is not restrictive enough. I don't know if this hypothetical use case has been discussed before, but if not, I hope that the Perl 6 specification has or can gain a clean way to say how its done. Thank you. -- Darren Duncan
Re: Synopses size and revision state
Also, there are other newer API docs than the Synopsis that are useful for study, but printing all this stuff seems very excessive, even more so because the Synopsis etc keep changing. I advise against printing this stuff in bulk. -- Darren Duncan On 2015-05-15 7:54 AM, Elizabeth Mattijsen wrote: On 15 May 2015, at 16:05, Parrot Raiser 1parr...@gmail.com wrote: Without doing too much work, can anyone offer an estimate of the volume of the Perl 6 Synopses? I'm assuming that by now, they are unlikely to undergo serious modification. I'm trying to estimate the cost of rendering them to dead-tree versions for study. (Personal limitation; I can look up a command definition online, but for study and mental integration, it's got to be something like a real book.) at 4+ lines and 100 lines / page, that would be about 400 pages ? Liz
Re: Can a user cheat and call a class's private method?
On 2015-05-12 12:40 PM, R. Ransbottom wrote: On Mon, May 11, 2015 at 03:22:46PM -0700, Darren Duncan wrote: you can use trusts. Also having to do this may indicate bad code design. -- Darren Duncan I saw Moritz' and Carl's responses and I agree with the smell issue. Given that the code exists and needs testing, 'augment' seems preferable to 'trust'. 'augment' avoids the predeclaration issue and simplifies the test code by removing indirection. Is class finalization implemented? Searching the synopses, I found only a mention. The other question is whether your private need to be private. Generally speaking tests should only be against a public interface, and if you really need to test something private then maybe a refactoring of the thing being tested is in order. For example splitting it into multiple classes where what was private becomes the public API of a utility consumed by the other class. Any private routines you should be able to test sufficiently indirectly by way of public routines that use them, if the code is well organized. -- Darren Duncan
Re: Can a user cheat and call a class's private method?
See Moritz Lenz' response to this thread on March 26. To summarize, you can use
trusts. Also having to do this may indicate bad code design. -- Darren Duncan
On 2015-05-11 2:13 PM, R. Ransbottom wrote:
I need to test some private routines, so is there a way to do that?
Is there a downsize to augment for this?
# source
class Dog {
method bark { say( #bark); return bark }
method !pee { say( #pee ); return pee}
}
# test
#use MONKEY_TYPING;
use Test;
use v6;
plan 4;
my Dog $t;
ok( Dog.bark eq bark, Good loud Dog );
ok( $t.bark eq bark, Good loud dog );
augment class Dog { # augment should be a test
# do private tests in private
ok( Dog!pee eq pee, Good bad Dog );
ok( $t!pee eq pee, Good bad dog );
}
Re: Is there an equivalent env var to PERL5LIB for Perl 6 module locations?
I for one did not know/remember about PERL6LIB and rather all I knew was the more ambitious plan at http://design.perl6.org/S11.html about CompUnitRepo and such. -- Darren Duncan
Re: Function Signatures: Return Types (replace wantarray?)
On 2015-03-19 4:17 PM, Tom Browder wrote: On Thu, Mar 19, 2015 at 5:58 PM, Tobias Leich em...@froggs.de wrote: The multi dispatcher *only* chooses the multi candidate by matching arguments to parameters. The return type is not considered. Okay, I have now kind of found that in the synopses (which are a bit confusing for me considering the function return type is discussed as part of the function signature). Yeah, that is something I think should be changed. While in some respects a return type is part of the signature, it perhaps may be better to not call it such, and just declare return type outside the signature. -- Darren Duncan
Re: Function Signatures: Return Types (replace wantarray?)
I think as a general principle, multi methods should dispatch entirely on their
parameter signatures, and dispatching on return type is just a bad design that
leads to trouble. If you want different return types for identical parameters,
you should give those 2 versions different method base names. -- Darren Duncan
On 2015-03-19 3:20 PM, Tom Browder wrote:
I need to replace the Perl 5 'wantarray' and think a multi method with
differing return types should do it.
So I've tried this:
multi method foo($a, $b -- {Num,Num}) { #... }
multi method foo($a, $b -- Num) { #... }
and get errors like:
Missing block
at Ellipsoid.pm:672
-- ethod to($lat1, $lon1, $lat2, $lon2 -- �{Rat, Rat})
from test_ellipsoid.pl:12
I've tried parentheses, square brackets, and no grouping characters
instead of curly braces but that doesn't change the error.
Question:
How does one properly provide differing function return type signatures?
Thanks.
Best,
-Tom
Re: Function Signatures: Return Types (replace wantarray?)
So, I think that a proper solution here is for there to be a single method foo
that has the desired parameter signature, and have that method return a single
object which acts like / has the roles/interfaces of both of the return types
that 'wantarray' would have chosen between. Therefore, each caller context can
call foo() and use the result in the way it expects to. -- Darren Duncan
On 2015-03-19 4:00 PM, Tom Browder wrote (in private):
On Thu, Mar 19, 2015 at 5:53 PM, Darren Duncan dar...@darrenduncan.net wrote:
I think as a general principle, multi methods should dispatch entirely on
their parameter signatures, and dispatching on return type is just a bad
design that leads to trouble. If you want different return types for
I don't disagree, Darren, but for the moment I'm trying to translate a
Perl 5 CPAN module to Perl 6 and trying to keep the API as close as
possible to the original.
On 2015-03-19 3:58 PM, Tobias Leich wrote:
The multi dispatcher *only* chooses the multi candidate by matching
arguments to parameters. The return type is not considered.
Btw, the syntax for returning an arrayish thing might be: method foo($a,
$b -- Positional) { ... }
Am 19.03.2015 um 23:53 schrieb Darren Duncan:
I think as a general principle, multi methods should dispatch entirely
on their parameter signatures, and dispatching on return type is just
a bad design that leads to trouble. If you want different return
types for identical parameters, you should give those 2 versions
different method base names. -- Darren Duncan
On 2015-03-19 3:20 PM, Tom Browder wrote:
I need to replace the Perl 5 'wantarray' and think a multi method with
differing return types should do it.
So I've tried this:
multi method foo($a, $b -- {Num,Num}) { #... }
multi method foo($a, $b -- Num) { #... }
and get errors like:
Missing block
at Ellipsoid.pm:672
-- ethod to($lat1, $lon1, $lat2, $lon2 -- �{Rat, Rat})
from test_ellipsoid.pl:12
I've tried parentheses, square brackets, and no grouping characters
instead of curly braces but that doesn't change the error.
Question:
How does one properly provide differing function return type signatures?
Re: Bag with explicit 0 elements?
On 2015-02-28 3:27 PM, Elizabeth Mattijsen wrote: An interesting thought for the non-mutable cases of Set, Bag and Mix. For the mutable cases (SetHash, BagHash, MixHash), setting the element to 0, is effectively deleting it. For the non-mutable case, I guess we could argue that *if* you specified it, it should exist as such. Will ponder about this… If you're going to support that alternative, it should still be easy for one to get the behavior where the non-mutable cases don't contain elements with a count of zero. Zeros can easily arise when doing operations like set difference or intersection etc, and we would want consistency between values that arise that way versus ones explicitly selected with a literal. -- Darren Duncan
Re: S02 mistake re Blob?
On 2015-02-21 2:45 AM, Moritz Lenz wrote: Hi Darren, On 21.02.2015 08:51, Darren Duncan wrote: I notice from looking at http://design.perl6.org/S02.html that Blob is listed both as being a role and as a type. See http://design.perl6.org/S02.html#Roles for an example of the former, and http://design.perl6.org/S02.html#Immutable_types for an example of the latter. -- Darren Duncan so, you think roles aren't types? (Also, roles auto-pun into classes upon usage). When I said type I meant class. As I recall from the rest of the spec, things were either roles or classes. You can't instantiate a role directly, so if a Blob is declared as a role you can't just instantiate one directly, isn't that how it works? Either way it seemed to be getting treated differently. -- Darren Duncan
S02 mistake re Blob?
I notice from looking at http://design.perl6.org/S02.html that Blob is listed both as being a role and as a type. See http://design.perl6.org/S02.html#Roles for an example of the former, and http://design.perl6.org/S02.html#Immutable_types for an example of the latter. -- Darren Duncan
