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
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: 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: %% 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
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: 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 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: 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: 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: 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?
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: 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?)
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?)
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?)
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: Grammars and biological data formats
I've already been thinking for awhile now that parsers need to be able to operate in a streaming fashion (when the grammars lend themselves to it, by not needing to lookahead, much if at all, to understand what they've already seen) so that strings that don't fit in memory all at once can be parsed. Any parser that returns results piecewise to the caller rather than all at once, such as by supporting callbacks, already makes for a streaming interface on that end, so it just needs to be lazy on the input end as well, and then one can parse arbitrary sized inputs while using little memory. Christopher's example is a good one. Another example that I would deal with is database dumps; the parsers in psql or mysql or others can obviously handle SQL dump files that are many gigabytes and are obviously parsing them in a streaming manner, but SQL files are really just program source code files. -- Darren Duncan On 2014-08-09, 3:09 PM, Fields, Christopher J wrote: (accidentally sent to perl6-lang, apologies for cross-posting but this seems more appropriate) I have a fairly simple question regarding the feasibility of using grammars with commonly used biological data formats. My main question: if I wanted to parse() or subparse() vary large files (not unheard of to have FASTA/FASTQ or other similar data files exceed 100’s of GB) would a grammar be the best solution? For instance, based on what I am reading the semantics appear to be greedy; for instance: Grammar.parsefile($file) appears to be a convenient shorthand for: Grammar.parse($file.slurp) since Grammar.parse() works on a Str, not a IO::Handle or Buf. Or am I misunderstanding how this could be accomplished? (just to point out, I know I can subparse() as well but that also appears to act on a string…) As an example, I have a simple grammar for parsing FASTA, which a (deceptively) simple format for storing sequence data: http://en.wikipedia.org/wiki/FASTA_format I have a simple grammar here: https://github.com/cjfields/bioperl6/blob/master/lib/Bio/Grammar/Fasta.pm6 and tests here: https://github.com/cjfields/bioperl6/blob/master/t/Grammar/fasta.t Tests pass with the latest Rakudo just fine. chris
Re: Questions for Survey about Perl
Richard Hainsworth wrote: Moreover, a survey should be testing perceptions, even if the perceptions contradict what some feel are facts. It sometimes pays to be agnostic about what can be counted as a fact to learn how other people think. Eg., in the real world there are those who perceive as fact the timeline of the history of life as set out in the Old Testament of the Bible, and there are those that look to other mechanisms for testing timeline theories, such as a the geological record. Dont want to start a religious war, just wanting to indicate that a survey can be useful if worded in a value-free manner. There are also those who perceive as fact that the biblical and geological timelines are not mutually exclusive and are both plausible. -- Darren Duncan
Re: Q: Code example in Using Perl 6 - methods and spaces.
Daniel Carrera wrote:
I tested the first program using the latest release of Rakudo Star.
The first program has the following:
my @sorted = @names.sort({ %sets{$_} }).sort({ %matches{$_} }).reverse;
This works correctly, but it's long and I'd rather format this line like this:
This works correctly, but I was surprised that this doesn't:
my @sorted = @names.sort({ %sets{$_} })
.sort({ %matches{$_} })
.reverse;
I was surprised when this didn't work. Does anyone know if this is a
bug in Rakudo, or if Perl 6 is really not supposed to have methods
separated by white space like this? The message from Rakudo was not
very informative. It just says Confused at line 28, near my @sorted.
A relevant reading would be
http://perlcabal.org/syn/S02.html#Whitespace_and_Comments I think; what you are
trying to do may not directly be allowed, though there may be workarounds such
as by using unspace.
-- Darren Duncan
Re: slurpy hash
David H. Adler wrote: Hm. So how are valid parameter names defined? Identifiers in perl6 seem to be composed of letters, digits and underscores (and hyphens and apostrophes between letters). Are parameter names defined differently? You certainly seem to be able to declare a variable $1. I believe that Perl 6 identifiers can be any string at all, but that then they have to appear quoted in the general case; the above restriction just refers to the common case of unquoted identifiers. This said, I'm not sure yet what the syntax is for quoting identifiers. -- Darren Duncan
how to pkg/distrib Perl 6 modules?
Now that, with Rakudo Star, it is relatively straightforward to install and use Perl 6, I'm wondering about the next step. I want to start writing and distributing Perl 6 modules in an easily installable but non-bundled manner, much as how one can do so today with Perl 5 modules. What is the best way to distribute Perl 6 modules these days? -- Darren Duncan
Re: very basic type checking
Moritz Lenz wrote: But I fear that optimizations are a risky business, considering our rather low test coverage (and considering that we don't really know how much of our code paths are actually covered by tests). In that case, perhaps Rakudo should have a config or compile-time (of Rakudo itself) option where it can be run either without or with any compile-time optimizations, where said optimizations have any changing the runtime behavior. This being under the assumption that a Rakudo codebase that doesn't support the optimizations is simpler and easier to prove correct or debug than one with them. Users suspecting a bug when they run with the optimizations could rerun without them to see if there's a difference. This idea isn't without precedent. I believe that Parrot has long had multiple run cores, such as ones with JIT or certain optimizations versus ones without. Or maybe this was an early development that later went away? -- Darren Duncan
Re: very basic type checking
yary wrote: Yes but- the OP wasn't asking about my Str $s; my Int $i=$s; not failing at compile time, the question was about my Int $i='abc'; or how about sub square(Int $n='o hai'); Would it be wrong for the cut-off point be after an immediate assignment/ declaration of a built-in type to a literal constant? Or does even checking that at compile time lead to headache? You're right, and this *should* be caught at compile time, because it is the low-hanging fruit, and can be tested with little effort. My point is that, because compile-time testing isn't essential, it was probably further down the priority queue of the Rakudo developers. It very much should be done, and relatively soon, but so far it was quite reasonable to have waited. -- Darren Duncan
Re: very basic type checking
Hiroki Horiuchi wrote:
My question is:
In current Rakudo,
my Int $i = '123';
causes a runtime error, not a compile time error.
How about in future Perl 6?
Generally speaking, in a dynamic language like Perl 6, one has to do the type
checking at runtime anyway, because we don't always have the information to do
it at compile time and because it is simpler. Runtime checks can always be
local while compile time checks may have to encompass an arbitrarily large
amount of other code that provides context.
Having just runtime checks is sufficient to begin with because they will still
always catch the errors. Compile time checks are then something you can add to
this in some, but not all, cases, and there are various degrees of diminishing
returns, where some compile time tests like the one you gave above would be very
easy to do but others are increasingly difficult.
An example of a problem that is more difficult to check at compile time is:
sub myop (Int $x, Int $y) {
return $x / $y;
}
Assuming that division by zero should be an error, a compile-time check won't
find a problem from just examining that code. Rather, a compile-time check
would have to check all the code that invokes myop, and any code that produces
the value to eventually give to $y, in order to know at compile time if the code
would try to divide by zero.
If all invocations of myop use a code literal for the $y argument, then this can
be checked at compile time, but if the argument is a variable, they have to look
further out.
-- Darren Duncan
Perl 6 Set::Relation port desired (was Re: How can i contribute for perl 6 ?)
Moritz Lenz wrote [on perl6-language]: On Tue, Sep 15, 2009 at 09:30:13AM +0530, Saravanan Thiyagarajan wrote: Would like to be a volunteer in working for perl-6. Can some one help me to get into right direction ? I've written about various options on perlmonks [1], but I think the best thing you can do right now is to pick a simple Perl 5 module, and port it to Perl 6. If you find any bugs along the way, join us in #perl6 on irc.freenode.net and tell us about your bug. If you are sure that it's really a bug, send a mail to rakudo...@perl.org. I have a medium-sized Perl 5 module, Set::Relation ( http://search.cpan.org/dist/Set-Relation/ ) that I'd be very happy if it were translated to Perl 6, but I currently lack the tuits as I'm focusing on other related projects at the moment. So if someone else wants to do that as a way to help the Perl 6 effort, they have my blessing and support. I believe that having a native relation type in Perl 6 would be valuable because there is so much of practical value you can do with them, and Set::Relation was created largely as a working proof of concept towards this end. Set::Relation was designed from day one to be translated to Perl 6, but I made it in Perl 5 + Moose first because that was a more stable platform, and I wanted to actually /use/ it in Perl 5 programs meanwhile. Set::Relation models the same relation values that relational databases are composed from, and includes probably all of the relational operators you've ever heard of plus some. Loosely speaking, a Set::Relation object is like a Set of Mapping (or Array of Hash where all Array elements are distinct), but that there is such a thing as the Set/Array having zero elements (tuples) but it still has a known identity described by 0..N Mapping/Hash keys (r/t attribute names). Traditionally the keys/attrs have been character strings but the model still works if they are any (ideally scalar) type; the point is that relation attributes are addressed by name rather than by position, but what constitutes a name can be flexible. Currently defined are 2 roles + 2 classes; the main role defines an immutable object and the second role extends it to add mutability; the V1 class does the mutable superset while the V2 class does only the immutable subset. I strongly recommend that a porter initially just tries the immutable role and V2, and ignores V1 and the mutable role for now, as it is a lot easier to implement this thing when you don't have to worry about deep copying. The current Set::Relation is licensed LGPLv3+ but I am willing to relicense it to Artistic v2+ if that assists a porting effort. -- Darren Duncan
Re: Logo considerations
Larry Wall wrote: On Tue, Mar 24, 2009 at 09:49:42AM -0700, Jon Lang wrote: : 2009/3/24 Larry Wall la...@wall.org: : http://www.wall.org/~larry/camelia.pdf Not picking on you in particular, but I think there's a tendency to go way too abstract in most of these proposals. I want something with gut appeal on the order of Tux. snip Hence, Camelia. I'm quite happy with Camelia being the basis for the logo for the Perl 6 language itself. Larry Wall wrote: If you guys want versions of Camelia in her attack mode, that's okay too. :) And in fact, the ö form looks more like a Hyper Attack Butterfly that is about to bite your face off... :) Please don't. I think the happy version is much better than any angry or violent version. We want the logo to evoke happiness after all. -- Darren Duncan
Re: Logo considerations
Timothy S. Nelson wrote [on p6l]: On Tue, 24 Mar 2009, Timothy S. Nelson wrote: On Mon, 23 Mar 2009, Richard Hainsworth wrote: Alternatively, if we stay away from animals, then how about something to do with parallelism, or super-positioning, or even a strange attractor, since perl6 can be strange and yet it is attractive. Ok, I've attached a logo mockup of lazy, (supposedly) parallel lions that are strangely attracted to each other. Think of this logo mockup as a wiki -- feel free to hack on it, especially if you can get the lions to be hubristically superpositioned while also remaining parallel and attracted. Or, if we made the magnetic lines of force hexagonal (inspired by Conrad Schneiker), and superpositioned (ie. superimposed) the whole thing over the Parrot logo, that would be kinda cool. Although if we keep going like this, the logo will look like a Graeme Base picture. If you're going for sciencey or mathey illustrations, then I think its important to include something that speaks quantum physics in there, since quantum superpositions aka Junctions are one of the big central user features that Perl 6 provides which is relatively new to languages in general. For example, one particularly iconic illustration is the cat in the sealed box with poison and a Geiger counter, aka Schrödinger's cat. Or rather than images of an alive and dead cat superimposed, you could have images of other mutually exclusive things superimposed. And depending on what things you choose, then those items can pull multiple-duty as other symbols (a boon to a logo); eg, those 2 lions, depending how you look at it, could be either powerful/lazy, or alive/dead. Mind you, you don't want to go too far away such that it isn't easy to perceive the quantum interpretation without being told it is there. On a related matter, remember that when going for a logo you don't want to make it *too* complicated. With symbols, often less is more. And also we probably want something that will work scaled up or down. It should certainly look good as black and white line-art. I know they are more examples, but some things I saw suggested looked a bit too complicated. On the other hand, arguably the gimel is too simple. But I'm sure something good can be worked out. -- Darren Duncan
strategy for multiple packages in fewer files (was Re: [file name extension])
At 8:41 AM -0800 1/7/08, Paul Hodges wrote: A small tangent that might be relevant -- what's the current convention for, say, putting several related packages in the same file? I do that frequently in my Perl modules, and so do modules like DBI. I believe that it is a good idea to do some package grouping into common files (though not necessarily having all packages in one file). Moreover, I belive that the common practice of unconditionally having a separate file for each package is very much a design smell and a bad idea. My suggested convention, which applies to both Perl 6 and Perl 5, is to group together in one file any packages that conceptually provide a single API which is used as a whole, and separate into different files any packages that conceptually provide separate APIs and/or separate functionality that is always used from optional extensions. Optional alternately meaning highly likely to be substituted by users for some other packages, is good to keep separate. For example, with DBI, you have one main file (DBI.pm) that declares a package for creating a DBMS connection object, and a package for the DBMS handle role, and a package for the statement handle role. Then for each DBI driver, you have 1 file that contains multiple packages, 1 each for implementing a DBMS handle and statement handle, et al. Various utilities used by DBI or DBD modules, such as SQL::Statement, are a separate file again, as while DBI may use it internally, it isn't part of the API of DBI. For another example, if you had your own implementation of some collection data type, eg a graph structure where you would have one package representing a node object and another one representing the whole graph, and users would interact with both directly, then those 2 packages should be stored in the same file. In fact, this also illustrates circular dependencies between objects (a graph is made of nodes, a node is useless outside a graph), and in cases like these, definitely they should be together. One rule of thumb is to look at your ideal documentation strategry. If you would naturally explain a component of your project such that multiple object types are conceptually joined at the hip, such that you need to understand all of the objects in order to understand one of them (see the graph example), then it makes sense to put the parts of the component in one file, and you can then document the 2 of them collectively rather than forcing separate documentation for each one that has to constantly refer back and forth to each other. My Muldis DB project (with separate Perl 6 and Perl 5 versions) version 0.6.0 has 13 packages grouped into 3 files: 1. Interface.pm (no deps) has Muldis::DB::Interface, ::Machine, ::Process, ::Var, ::FuncBinding, ::ProcBinding 2. Validator.pm (dep on Intf) has Muldis::DB::Validator 3. Example.pm (dep on Intf) has Muldis::DB::Engine::Example, ::Machine, ::Process, ::Var, ::FuncBinding, ::ProcBinding Version 0.7.0 (unreleased) has at least 13 packages grouped into this 1 additional file: 1. Value.pm (no deps, used by Example) has Muldis::DB::Engine::Example::Value, ::Universal, ::Scalar, ::Bool, ::Int, ::Rat, ::Blob, ::Text, ::QuasiTuple, ::Tuple, ::QuasiRelation, ::Relation, ::Cat_Order. 2. Further expected files would be like Operator.pm, Storage.pm, Runtime.pm, Compiler.pm; these would depend on Value.pm and be used by Example.pm, and each could potentially have multiple packages, though just 1 each is also possible. 3. Value|Operator.pm (optional user-caused 'require' at runtime) just has the Core data types and operators; for language extensions, they would probably add extra files per extension, such as ::Value::Temporal.pm and ::Operator::Temporal.pm et al. I think that this approach strikes a good balance serving ease of use, ease of maintenance, and resource efficiency. In p5, I might write a great Foo.pm that loads Foo::Loader.pm and Foo::Parser.pm and Foo::Object.pm; I'd usually drop them into seperate files and have one load the rest, so I could just use Foo; and get on with my code, but that does add some maintenance that could be skipped if loading the one file automatically grabbed all the relevant parts. Plusses and minuses there If the Foo:Widget and Foo:Gadget are only of use with the something in Foo proper, maybe it would be reasonable to toss them into the same file, though. snip As for your example, I would probably keep object/loader/parser as 3 files, especially if the loader/parser is likely to be subsituted by users for alternatives that use the same object, or there are situations where object would be used but the others wouldn't. Or combine if they are very simple. But really, you know better to make this call yourself, having more information on your circumstances. -- Darren Duncan P.S. Does anyone think that the main part of this email may provide a starting point for a general
Re: CGI.pm renaming (was Re: CGI Session management (was Re: the CGI.pm in Perl 6))
At 12:53 PM +1000 4/15/07, Jacinta Richardson wrote: Juerd wrote: Jacinta Richardson skribis 2006-09-21 0:13 (+1000): My biggest gripe with CGI's html methods is the inconsistency in their names. I use them every now and then, but I always have to go and look up the documentation. It's textfield isn't it? So that would make this one passwordfield: nope, it's password_field. popup_menu so scrolling_menu... Ah, no: scrolling_list. How do I make it multi-select again? Yes, this needs to be redesigned completely. Are you volunteering? Is this still needed? If so yes, I'm now volunteering! Where'd you like me to start? All the best, Jacinta Pursuant to Juerd Waalboer's contributions to the relevant perl6-users discussion threads on 20060917,21, a replacement effort has been started. See the ext/HTTP/ and ext/Web/ skeleton code in the current Pugs repository, which is basically a copy of Juerd's code in the discussion emails, which I wrapped with distributions on his behalf on 20070217. Presumably Juerd will get back to these when he has the tuits, but meanwhile you could try improving what he started. -- Darren Duncan
Re: Charsets in HTTP (was: the CGI.pm in Perl 6)
At 7:38 PM +0200 9/16/06, A. Pagaltzis wrote: * Darren Duncan [EMAIL PROTECTED] [2006-09-09 20:40]: 4. Make UTF-8 the default HTTP response character encoding, and the default declared charset for text/* MIME types, and explicitly declare that this is what the charset is. The only time that output should be anything else, even Latin-1, is if the programmer specifies such. No, please don't. For unknown MIME types, the charset should be undeclared. In particular, `application/octet-stream` should never have a charset forced on it if one is not assigned by the client code explicitly. Likewise, for `application/xml` and `application/*+xml`, a charset should NEVER be explicitly declared, as XML documents are self-describing, whereas declaring a charset forces using the charset declared in the HTTP header. This is very unwise (cf. Ruby's Postulate). Look again; I was only specifying that a default charset is used for text/* MIME types, not non-text/* MIME types; the latter would typically have no charset as you say. 5. Similarly, default to trying to treat the HTTP request as UTF-8 if it doesn't specify a character encoding; fallback to Latin-1 only if the text parts of the HTTP request don't look like valid UTF-8. This is not just unwise, it is actually wrong. Latin-1 is the default for `text/*` MIME types if no charset is declared. Using a different charset in violation of the HTTP RFCs is __BROKEN__. Okay, I retract that suggestion. Because the official HTTP spec says no-explicit-charset-means-Latin1. In fact, now that I'm writing all this out, I am starting to think that maybe CGI.pm6 should simply punt on charsets as CGI.pm does. Otherwise, the code and API would have to have able to deal with the full complexity of charsets in HTTP, and the docs would have to explain it, which is no picnic at all. I disagree. Regardless of the details, a Perl 6 replacement for CGI.pm *should* handle character set issues. Its users should simply be able to pull out correctly interpreted ready-to-use Str values when the HTTP request content type is text, and not have to know about what character set was used in the request. Analagously, if the user takes their Str values and supplies them to an HTTP response whose content type is text, they should not have to specify an output encoding if they don't want to, and UTF-8 is the best default because it can handle all possible characters that the Str repetoire can represent. The CGI.pm replacement by no means has to do the dirty work of processing encodings itself, such as mapping bytes to chars etc. Those details would be handled by something else, such as either Perl 6 itself or a Perl 6 analogy to Encode.pm. -- Darren Duncan
HTTP::Request/Response (was Re: the CGI.pm in Perl 6)
At 5:00 PM -0700 9/14/06, Aankhen wrote: There were a few discussions with Juerd and others in #perl6 about CGI.pm in Perl 6... if anyone's interested, I'll look for the logs. The major feeling was that there should be no CGI.pm (if someone was hellbent on using it, they could use the Perl 5 module). Rather, there needs to be proper seperation of concerns. Maybe instead of just importing CGI, you'd now import HTTP::Request::CGI and HTML::Generator (I'm throwing names out at random, although I did write HTTP::Request::CGI as a subclass of HTTP::Request whose members are populated in a manner similar to CGI.pm's parsing of %ENV). While I wasn't involved in that discussion, I agree with the sentiment you have expressed here, wherein there should be no CGI.pm in Perl 6. (Moreover, we should probably make an effort that no Perl 6 module will have just a top-level namespace as its name unless it is a core module or it is a framework.) Having had some prior experience in tackling this problem (eg, CGI::Portable), I will endeavour to work on / help with the Perl 6 analogy to HTTP::Request/Response, so to replace the use of corresponding aspects of CGI.pm. Note that the design strategy I had used in CGI::Portable was to have a pure container object representing a request and/or response, which was used sort of like this: 1. At start of handling an HTTP request, the main server runloop creates a new Request Container and has it populated by invoking a module function that knows about a particular environment, such as IO::Socket vs mod_perl vs CGI or whatever. 2. The main runloop calls the application's main per-request handling function; that function reads its HTTP input details from Request Container and writes its HTTP output details to Response Container. 3. At end of handling an HTTP request, the main server runloop invokes a module function that knows about a particular environment, and that function outputs whatever the Response Container represents. Note that, in the general case, the Request/Response containers would not have any ties to outside environment, though in specific cases where input and output are too large to easily fit in RAM at once, there can be enhancements. -- Darren Duncan
Re: Web.pm or something (Re: the CGI.pm in Perl 6)
At 5:00 PM +0100 9/13/06, David Cantrell wrote: On Tue, Sep 12, 2006 at 03:08:03PM -0700, Darren Duncan wrote: The word CGI generally speaks to an old, weak, and relatively inefficient technology ... modern proper stuff does not spin off a separate process for each server request; it reuses an existing server ala mod_perl. To me the Commong Gateway Interface means a standard method for dealing with data supplied by the user, nothing more. It certainly doesn't specify how you should implement it. Indeed, every mod_perl application I've seen uses CGI. I beg to differ. CGI is very much an implementation detail. It is a gateway protocol for how 2 different processes communicate. See: http://www.w3.org/CGI/ An HTTP server is often used as a gateway to a legacy information system; for example, an existing body of documents or an existing database application. The Common Gateway Interface is an agreement between HTTP server implementors about how to integrate such gateway scripts and programs. And: http://en.wikipedia.org/wiki/Common_Gateway_Interface The Common Gateway Interface (CGI) is a standard protocol for interfacing external application software with an information server, commonly a web server. This allows the server to pass requests from a client web browser to the external application. The web server can then return the output from the application to the web browser. Because this technology generally requires a fresh copy of the program to be executed for every CGI request, the workload could quickly overwhelm web servers, inspiring more efficient technologies such as mod_perl or ASP that allow script interpreters to be integrated directly into web servers as modules, thus avoiding the overhead of repeatedly loading and initializing language interpreters. So CGI is absolutely not a good name for a new and modern module's design where the module's functionality isn't CGI-specific. -- Darren Duncan
Re: the CGI.pm in Perl 6
At 3:11 PM -0500 9/9/06, Mark Stosberg wrote: I do share your sentiment that CGI.pm shouldn't be a clone of how P5 works. I'd like the HTML building methods to stay out, which wasn't even one of the differences you cared about yourself. On the other hand, there is a real benefit to in being similar enough so that porting from Perl 5 is easy. Radical differences can forked into Web.pm or something. If you want to see something more radical, have a look at my first major CPAN modules from 2001ish. Mainly HTML::FormTemplate and CGI::Portable. Between those and their dependencies (HTML::EasyTags, Class::ParamParser, Data::MultiValuedHash, CGI::MultiValuedHash), was an entire and cleaner and more modular re-implementation of CGI.pm plus a few extras (and minus a few bits; I never implemented file upload handling). It is also more or less backwards compatible with CGI.pm where it makes sense. The combination is a bit large to be a CGI.pm replacement, but I think that a lot can be learned from this if one wants to make more significant CGI.pm improvements. Note that I am still using those modules of mine for my own personal web sites, but I'm not aware that they ever took off with other people in a big way. I also don't plan to straight-port them to Perl 6 since in large I don't know if they really offer anything people want that other web frameworks don't. I also don't have a big stake in them like I do with my current database-centric modules (where I'm more certain they can have a big impact). However, I'm sure the web modules can influence improvements to CGI.pm in Perl 6, and I will do so at an appropriate time. -- Darren Duncan
Re: $1,000 prize for Perl 6 Wiki written in Perl 6
I'm wondering about some implementation logistics. For one thing, I'm assuming that a prize-qualifying solution won't be able to link-in legacy Perl 5 modules using Pugs' use perl5:Foo syntax; to do so would look bad if we are wanting to show off a Wiki solution using the NEW technology. Therefore, if this Wiki is going to be made sooner rather than later, what are we going to use for a storage engine? No Perl 6 RDBMS interface or implementation is ready yet, nor will it likely be for some time. Such is what larger scale Wikis use. So is this initial Wiki going to use a folder hierarchy of flat files, or a big YAML file, or something? This is fine for an initial version, of course, that is just showing things off, though it may be more difficult to scale. Perhaps v1 of the Wiki will use YAML or flat files, and v2 an RDBMS. Or is something more interesting on the horizon, like perhaps an RDF storage? -- Darren Duncan
