Re: PostgreSQL: Raku as a "trusted" language?
El mié, 15 may 2024 a las 21:08, William Michels () escribió: > Thanks for your response, JJ. > > I'm wondering if the "trusted" moniker is conferred when a > (specified/bespoke) language version sufficiently sanitizes input? > Not only that, also output to the filesystem and network. > > If so, your Unicode::Security module would seem to be right on the mark: > > https://raku.land/zef:jjmerelo/Unicode::Security > > https://github.com/JJ/raku-unicode-security > :-) It might help, I guess. But that would be just something to detect possibly insecure strings. Cheers JJ
Re: PostgreSQL: Raku as a "trusted" language?
>From what I'm seeing, my impression is that you need to create a specific version, possibly with Pg bindings, to become either trusted or untrusted; there's no Trusted "node" (or bun, for that matter), but a "v8js" version of JavaScript. Any PL (procedural language) version of the language would be used to create embedded procedures. The user base for such a thing does not guarantee the effort needed to create such a version of Rakudo (which, from what I can tell, would need to be refactored at the NPQ level, since "trusted" versions can't, for instance, access the filesystem) El mié, 17 abr 2024 a las 21:04, William Michels via perl6-users (< perl6-us...@perl.org>) escribió: > Hi, > > Thinking about which database to use with Raku, I started following a > question from StackOverflow--here: > > "list of PostgreSQL trusted languages?" > > https://dba.stackexchange.com/questions/156631/list-of-postgresql-trusted-languages > > From that page I learned that there are both "trusted" and "untrusted" > modes for use of Perl with PostgreSQL: > > "45.5. Trusted and Untrusted PL/Perl" > https://www.postgresql.org/docs/current/plperl-trusted.html > > Which led me to a matrix of programming languages and trust modes: > > "PL Matrix" > https://wiki.postgresql.org/wiki/PL_Matrix > > On the final PL link above, Raku doesn't appear at all--so the questions > arise: > > 1. How can the Raku community get Raku added on the "PL Matrix" page? > > 2. How can the Raku community get Raku accepted as a "trusted" PL for use > with PostgreSQL? > > > Thx, > > Bill. > > -- JJ
Re: Help with %?RESOURCES variable
Can you maybe list %?RESOURCES? I see nothing wrong with it, but just in
case.
El lun, 17 abr 2023 a las 18:01, David Santiago ()
escribió:
>
> I'm trying to use the variable %?RESOURCES without success. It doesn't
> work even when i install it locally with zef
>
> I have the following:
>
> demanuel@archlinux test> cat resources/text.txt
> This is my test file
> demanuel@archlinux test> cat bin/run-me
> sub MAIN(){
> say %?RESOURCES{"text.txt"}.slurp(:close);
> }
> demanuel@archlinux test> cat META6.json
> {
> "raku" : "6.d",
> "name" : "Test",
> "api" : "1",
> "auth" : "demanuel",
> "version" : "0.0.1",
> "description" : "my resources test",
> "authors" : [ "demanuel" ],
> "license" : "GPLv3",
> "resources": [
> "text.txt"
> ]
> }
> demanuel@archlinux test> tree
> .
> ├── bin
> │ └── run-me
> ├── lib
> ├── META6.json
> └── resources
> └── text.txt
>
> 4 directories, 3 files
> demanuel@archlinux test> raku -I ./lib bin/run-me
> Nil
> demanuel@archlinux test> zef install .
> ===> Testing: Test:ver<0.0.1>:auth:api<1>
> ===> Testing [OK] for Test:ver<0.0.1>:auth:api<1>
> ===> Installing: Test:ver<0.0.1>:auth:api<1>
>
> 1 bin/ script [run-me] installed to:
> /home/demanuel/.raku/bin
> demanuel@archlinux test> run-me
> Nil
> demanuel@archlinux test>
>
>
>
>
> Can someone point me what i'm doing wrong?
>
> Best regards,
> David Santiago
>
>
--
JJ
We want you to write an article for the Advent Calendar!
And you, and you, yes, you too. There are still some slots available. You want to talk about your module, your experience, a little tutorial, whatever, request a slot here https://github.com/Raku/advent/blob/master/raku-advent-2022/authors.md (and also send me via email a way to contact you) Cheers -- JJ
Re: JPEG meta-data timestamps
Chapter 2 of my Raku Recipes, published by APress, includes that as one of the recipes. Here's the code for that recipe: https://github.com/JJ/perl6-recipes-apress/blob/09a3465726ce96549946401970ae282baa4ba60d/Chapter-2/get-image-size.rk El dom, 9 oct 2022 a las 8:28, Fernando Santagata (< nando.santag...@gmail.com>) escribió: > Actually there's a Raku module: > > https://raku.land/cpan:FRITH/Image::Libexif > > It's a thin-layer interface to the libexif, but it works. > > On Sat, Oct 8, 2022 at 10:21 PM rir wrote: > >> Are there any Raku modules for extracting meta-data from >> JPEG files? I have looked but not found. >> >> At this point, I just want to extract dates to re-timestamp >> the files. Later, I might use the fix in the pictures to >> map to personally defined places. >> >> Rob >> >> >> >> >> >> >> > > -- > Fernando Santagata > -- JJ
Re: Raku name change
That was notified a long time ago. IIRC, the PR was merged, but has not been deployed yet. Cheers El sáb, 1 ene 2022 a las 19:05, Richard Hainsworth () escribió: > Just noticed when creating new module on GitHub, the dropdown for the > .gitignore template has an entry for 'perl6' but not for raku. > > -- JJ
Re: continuous testing
Hi, El sáb, 1 ene 2022 a las 12:44, Richard Hainsworth () escribió: > JJ > Thanks. That is very useful. One interesting question. > > I notice from this setup that you chart the COMMITS, and the raku program > uses 'say' to output the results. > That's not really needed, it's just a bit of goldplating. > But how do you access these charted results? > You need to click on the log. But you can safely ignore that. Cheers JJ
Re: continuous testing
Try the new GitHub actions with the recently renovated Docker image. See it in action, for instance, here: https://github.com/JJ/p6-pod-load/blob/master/.github/workflows/test.yaml El vie, 31 dic 2021 a las 19:57, Richard Hainsworth () escribió: > Thanks > On 31/12/2021 18:27, Fernando Santagata wrote: > > Hi Richard, > this is a link to the GitHub official documentation: > > https://docs.github.com/en/actions > > You can also copy a configuration from another project and adapt it to > your needs. For example this one installs some C libraries, some module > dependencies and runs the tests: > > > https://github.com/frithnanth/raku-Math-Libgsl-Interpolation/blob/master/.github/workflows/test.yml > > On Fri, Dec 31, 2021 at 5:56 PM Richard Hainsworth > wrote: > >> Fernando, >> >> Thanks. >> >> Any link / blog / article about how to set up GitHub action up for Raku? >> >> Regards, >> >> Richard >> On 31/12/2021 16:52, Fernando Santagata wrote: >> >> Hi Richard, >> apparently Travis CI has discontinued its free open source plan. >> I switched to GitHub actions; don't know what's available on other >> platforms. >> >> On Fri, Dec 31, 2021 at 5:43 PM Richard Hainsworth < >> rnhainswo...@gmail.com> wrote: >> >>> I noticed that the .travis files have been removed from some >>> distributions. >>> >>> Also a .circleci file exists in the Raku Docs repo. >>> >>> Is there a preferred / recommended / list of continuous testing >>> environments? >>> >>> Is there a preferred / rapid way to handle Raku modules? >>> >>> Regards, >>> >>> Richard >>> >>> >> >> -- >> Fernando Santagata >> >> > > -- > Fernando Santagata > > -- JJ
Re: Last day for FOSDEM submission
Well, we can very well ship a Docker image that includes Raku by default... Cheers El vie, 31 dic 2021 a las 14:21, Wesley Peng via perl6-users (< perl6-us...@perl.org>) escribió: > Replacing Bash scripts with Raku? That’s an interesting thing. Can Linux > be shipped with Raku by default? > > > > hello people, > > I just discovered this this morning: > > > https://www.reddit.com/r/rakulang/comments/rrcp4c/steal_these_ideas_for_raku_fosdem_talks/ > > I don't remember if there was a previous annoucement in this list but > it's still possible to jump in. > > I just submitted one on "Replacing Bash scripts with Raku" > > * features and way of doing things i love from zsh > * the raku way [1] > * getting started with raku ecosystem (raku.land, zef, Ddt, fez, rakudoc, > prove6, ...) > > gather/take=while read, Seq vs Pipes, ...) and ideas of modules > > 1: the raku way are things like > > *sh│ raku > ───┼─ > | │ Seq.map > xargs -P │ .race > while read │ gather/take > > At some point it could become an Intro section on the Raku documentation > site. > > If a native/fluent english speaker want to take over it: i'll be more > than happy to co-author the talk as well (i really feel like i'm a > disaster as > speaker). > > Regards > marc > > -- JJ
Re: Rakudo-Star 2021.12 (Windows MSI and Linux RSTAR) packages
Great! Thanks. El sáb, 25 dic 2021 a las 12:18, escribió: > Hi all. > > The Rakudo-Star 2021.12 Windows MSI and Linux RSTAR packages are > available at [1]. The previous Windows MSI build under [2] is also > updated to 2021.10... just in case someone was using this repo and it's > versions somewhere. @Coke | @jnthn | @lizmat | @moritz | @rba | > @sena_kun | @timo: Would appreciate if one of you could copy packages > from either [1] or [2] to [3] ... Regards AntonOks [1]: > https://github.com/AntonOks/star/releases/latest [2]: > https://github.com/AntonOks/rakudo-star-win/releases [4]: > https://github.com/rakudo/star > > -- JJ
Re: Merry Xmas day
Merry Xmas for you too! I wish I knew. There's no fixed roadmap, and I, for one, do not really know what's going to happen. We'll probably get closer to 6.e, and there are wonderful things in the core by the crafty and wonderful core developers. Cheers El mar, 21 dic 2021 a las 12:09, yonghua () escribió: > Merry Xmas and happy new year every one. > May I know what's the plan for raku development in the new year 2022? > > Thanks. > -- JJ
Re: fixing the documentation
Thanks a lot. Cheers El vie, 19 nov 2021 a las 0:08, Marc Chantreux () escribió: > Hello, > > > The best would be if you propose a PR or open an issue at > > https://github.com/Raku/doc. Any help with the documentation would > > most certainly be appreciated as people working on the docs project > > are overloaded. > > Sorry I was late on this because I wasn't sure how to revamp the whole > thing. so i just simplified the 5to6 page this way: > > https://github.com/Raku/doc/commit/cd32380ab4e1c5ad2017d60a31def9189b54c80f > > Simple changes are better anyway. > > thanks. > marc > -- JJ
Looking for advent calendar authors
Hi, 'Tis the season for looking for Advent Calendar users, so if you've got any amusing story to tell that includes Raku, please add your name here: https://github.com/Raku/advent/blob/master/raku-advent-2021/authors.md This year I'd like to have the articles by Dec 1st. So please start writing as soon as you do the PR! Any question or anything you need to know, just let me know -- JJ
Re: Docs on docs.raku.org need automated build
Done also for the official site, https://docs.raku.org Check it out. El lun, 15 nov 2021 a las 19:17, JJ Merelo () escribió: > Testing the newly deployed docs here https://rakudocs.github.io/ > > I'll try and do a couple of updates and checks and if everything is OK, > will deploy to the official site. > > El dom, 14 nov 2021 a las 19:54, Tom Browder () > escribió: > >> Doc site i see is several weeks old and missing my last merged contrib >> on example of programmatic use of ‘require’. >> >> Any hope of a rebuild this month? >> >> -Tom >> > > > -- > JJ > -- JJ
Re: Docs on docs.raku.org need automated build
Testing the newly deployed docs here https://rakudocs.github.io/ I'll try and do a couple of updates and checks and if everything is OK, will deploy to the official site. El dom, 14 nov 2021 a las 19:54, Tom Browder () escribió: > Doc site i see is several weeks old and missing my last merged contrib on > example of programmatic use of ‘require’. > > Any hope of a rebuild this month? > > -Tom > -- JJ
Re: can u suggest a beginner book for perl6?
May I suggest my own "Perl 6 Quick Syntax Reference"? https://www.apress.com/gp/book/9781484249550 El mié, 29 sept 2021 a las 14:26, Elizabeth Mattijsen () escribió: > Perhaps Think Raku: https://greenteapress.com/wp/think-perl-6/ ? > > > On 29 Sep 2021, at 14:18, Walt CH wrote: > > > > I have some ruby programming experience, and some JS. > > can you suggest a book for newbie of perl6? > > > > Thanks > > -- JJ
Re: [naive] hash assingment
El mié, 14 jul 2021 a las 19:43, Aureliano Guedes (<
guedes.aureli...@gmail.com>) escribió:
> Hi all,
>
> Trying to knowing a little bit more about Raku lang, I decided to write a
> simple (as possible) lib to became similar to R/dplyr or Python/Pandas
> method to data wrangle.
>
> So, Raku gives us the possibility to deal with data in a functional way,
> given the native pipe operator, which is wonderful for newbies.
> > @a = 1..100
> > @a ==> map( { .sqrt } )
> > @a ==> HYPER( { .sqrt } ) # faster map
>
This is not going to be faster in the general case, only when the
operations done at every step take enough time, and the array is big
enough. In the general case, this might be even slower. Also, it's lower
case hyper, and it must go before the operation to be "hypered", like map.
> So I'm trying to decide the best way to abstract columns.
> First, I decide to use a hash where the key is the column name and the
> value is the oriented list ou array.
>
> > my %a = {'column1' => [1...5], 'column2' => ['a'...'e']}
> Potential difficulties:
> Useless use of hash composer on right side of hash assignment; did you
> mean := instead?
> at line 2
> --> ⏏
> {column1 => [1 2 3 4 5], column2 => [a b c d e]}
>
> It is a warning, not an error!
>
Yep, you can just write:
my %a = 'column1' => [1...5], 'column2' => ['a'...'e']
Raku knows it's a hash, it can figure out the two Pairs go there.
>
> But let's obey the warning.
> > my %a = {'column1' := [1...5], 'column2' := ['a'...'e']}
> ===SORRY!=== Error while compiling:
> Cannot use bind operator with this left-hand side
> --> n1' := [1...5], 'column2' := ['a'...'e']⏏}
>
> Now we got an error.
>
:= is for variable binding; you could do something like
my %a := {'column1' => [1...5], 'column2' => ['a'...'e']}
Which will bind lhs to rhs, saying: yes, I know that's a hash, that's
exactly what I want. No warning then. That's where you had to use binding.
> Someone may explain me why I got this error??
>
Hope that helps. You might want to have a look at the documentation, too:
https://docs.raku.org/routine/:=
Cheers
JJ
Re: too many file handles
Is it possible that is't got its origin in the operating system, and not in Raku itself? El mié, 17 mar 2021 a las 18:56, Elizabeth Mattijsen () escribió: > > On 17 Mar 2021, at 18:45, Richard Hainsworth > wrote: > > > > I have been running into this error: "Too many open files" > > > > Sorry for the lack of detail. The problem is that the error comes up in > odd places, so I have found it difficult to golf down into Raku program > that always fails with this error. > > > > When I separate out the code that leads to the error, and create another > program, Raku handles it without difficulty. It seems to occur when there > are a lot of moving parts, so to speak. > > > > I am not explicitly opening file handles, but the software I have > written is using the idiom > > > > "some-filename.html".IO.spurt( $an-accumulated-string ); > > > > Obviously, filehandles are being opened under the hood. Having written a > file, there is no need to reference it again, so I could close the > filehandle. > > > > I have been told that because of the way garbage handling is > implemented, there is a problem with file handles. > > That's should only happen if you specifically open a file to obtain an > IO::Handle: if you don't close it yourself (e.g. via a LEAVE block like: > LEAVE .close with $handle), *then* you run this risk, as the > IO::Handle.DESTROY method *will* close the handle, but you cannot be sure > as to when IO::Handle.DESTROY gets called. > > > > If so, what is a safer idiom to use in place of and IO on a string, so > that the handle can be closed immediately after use? > > The "filelame".IO.spurt($string)" is the exact idiom to ensure that file > handles are getting closed for you automatically. And I've just checked > the code: the OS file handle *is* specifically getting closed with an > nqp::closefh($!PIO). Specifically, the sequence is: > > my $PIO := nqp::open($path,$mode); > nqp::writefh($PIO,nqp::decont(data)); > nqp::closefh($PIO); > > Now, you can't get more succinct than that: it doesn't even open an > IO::Handle at all! > > The only thing I can think of at this moment, is that somehow > nqp::closefh() is leaking? Perhaps creating an issue for this, is in order! > > > Liz > > -- JJ
Re: Please create a Raku community channel
I don't think it's a duplication (or, as might be the case, triplication) of resources, or a waste of resources. I learned early on that the "resources" of the community is not, as in a company, a pool with a constant value from which you, as in yourself, can draw to push forward your favorite project. On the contrary, it falls on you to try and steer anyone's favorite project in a direction that could help *your* favorite project, and also to prop up your project so that it's open to contributions in a way that don't break or derail it. That's the best you can do. Also, a community with three or four projects in the same direction (documentation or whatever) is a great community; at the end of the day, you can profit from all three, even if it's in a tiny detail or simply on the effort put into implementing a standard. That said, the initial problem still stands: there's no way to make the whole community know something that might be important, such as the doc site dropping from some parts of the internet, or an adoption drive for some community module, really, whatever. Voting for the RSC... And that's got several sub-problems 1. We need to define community. If it's someone with a commit bit in every repo of the 5 (yes 5) Raku organizations, well, that's a tall order. There are myriad teams, some people have a commit bit just in one repo. And then this excludes people who contribute to the community in a different way, from organizing challenges to curating subreddits through answering questions in StackOverflow. 2. Even if you include all and everyone, you need to define what would go into that channel. As in a logging system, you need to define the severity of the issue to make the channel really relevant and actionnable. That, of course, goes against the fact that it needs to be open to everyone, and also interactive. 3. There's no single communication channel that's a) used by everyone and b) accessed by everyone on a hourly, or even daily, basis. So there's really no solution to your problem, other than try and tell everyone, many times, in different channels, whatever the heck you're interested on, and it will eventually grab the attention of the stakeholders (and don't have me defining stakeholders...). I really appreciate everyone's contributions, I really do. So heartfelt thanks to all :-) Cheers JJ El sáb, 13 mar 2021 a las 23:27, Vadim Belman () escribió: > > I would like to make an important note here. Up to my knowledge, the new > documentation site project is personal initiative of Alexander (Altai-man) > of which nobody of RSC members was informed about. For this reason it is > rather unlikely that any notification would be issued on any official > channel, would such one existed. I personally got to know about it the > moment Alexander posted his request for help on IRC. > > Apparently, the above paragraph doesn't say that we don't need an official > channel of a kind. I was asking a similar question ~1.5yr ago. As it is > with many other matters, this one needed some time to gain momentum. > Perhaps, the time has come to get it answered. > > 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. > > Best regards, > Vadim Belman > > > On Mar 13, 2021, at 2:21 AM, 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
Re: Please create a Raku community channel
This issue has been in the problem-solving repo for a long time https://github.com/Raku/problem-solving/issues/246 So yes, we need something like this, if only to avoid confusion about what plans/roadmaps there are, what's going to be done or simply to call for elections. El sáb, 13 mar 2021 a las 8:22, Richard Hainsworth () escribió: > 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 > > > -- JJ
Re: A problem case for the site documentation search: the "^methods" method.
This is a bug in Documentable. Generated an issue there https://github.com/Raku/Documentable/issues/149 Thanks for the report.
Re: A problem case for the site documentation search: the "^methods" method.
Yep, it's not totally clear to me if it's an error in how indices are generated or an error in where index marks are placed. I'll try to check it out anyway. Thanks El mié, 10 mar 2021 a las 4:35, Will Coleda () escribió: > Please open an issue for this at github.com/Raku/doc/issues > > On Tue, Mar 2, 2021 at 8:12 PM Joseph Brenner wrote: > > > > If you go to docs.raku.org and type "^methods" into the search > > window, you get a drop down looking something like this: > > > > class > > Method > > Submethod > > > > method > > methods > > > > Reference > > ^methods > > methods > > Submethods > > > > Routine > > method > > > > Site Search > > search entire site for ^methods > > > > There's a bunch of stuff in there I don't particularly want to > > see, but there's at least one entry that's definitely a hit: > > > > Reference > > ^methods > > > > That takes you to here: > > > > > https://docs.raku.org/language/classtut#index-entry-$CIRCUMFLEX_ACCENTmethods > > > > > > On this, my browser leaves me at the top of the page, it doesn't jump > > to the internal label-- it's presumably missing from the page: and > > $CIRCUMFLEX_ACCENT is a variable that was supposed to interpolate > > but got treated as a literal. > > > > But anyway, I can do a text search for "^methods" now, and that > > takes me to this section, where there's some good material about > > "^methods": > > > >https://docs.raku.org/language/classtut#Introspection > > > > Every other entry in that drop down menu is a red herring. > > Particularly bad is the "search entire site" because it uses > > Google, and they don't treat characters like '^' as significant > > (once upon a time they had a "code search" feature, but it's > > long gone). > > > > There *are* other place whether "^methods" is mentioned in the > > documentation, but to find them I needed to do a git clone of > > the project and grep the source files on my hard drive: > > > > language/5to6-perlvar > > Language/operators > > Language/rb-nutshell > > Language/structures > > Type/ForeignCode > > Type/Metamodel/MethodContainer > > Type/Signature > > Type/Stash > > > > And actually, just the fact that the main search interface for > > the raku docs is a drop-down is a bit of an annoyance for me-- it > > no doubt seems very modern to some people, but I had to do a > > screen shot of it just to get it to sit still so I could type up > > the copy I included above. > -- JJ
Re: We need you to propose projects for Google Summer of Code
https://github.com/perl-foundation-outreach/gsoc-2021-ideas/issues Here you go Cheers El dom, 31 ene 2021 a las 8:56, JJ Merelo () escribió: > Hi, > > El sáb, 30 ene 2021 a las 23:14, ToddAndMargo via perl6-users (< > perl6-us...@perl.org>) escribió: > >> On 1/30/21 9:11 AM, JJ Merelo wrote: >> > Anyway, my 2¢ is that in the grand scheme of things, compile time is >> not >> > that important. >> >> It drives me around the bend and wastes a lot of my >> time. It is also embarrassing to hand something like >> that over to a customer. >> > > You can shave time by spinning off all business logic to a module that the > customer can install. It will be precompiled when it does, and it will save > a lot of time next time it's loaded. Perl does not need that, although of > course modularizing will always allow you to use best practices like > testing and reuse. > > That said, it's always good to make things faster. Given Rakudo is written > to a large extent in Raku, and Raku is being continuously improved, up to > and including the new RakuAST, it will happen. The fact that such a project > would involve a deep dive into the different layers of the existing Raku, > as well as the new RakuAST, make it possibly a unsuitable candidate for > Google Summer of Code. > > Cheers > > > -- > JJ > -- JJ
Re: We need you to propose projects for Google Summer of Code
Hi, El sáb, 30 ene 2021 a las 23:14, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 1/30/21 9:11 AM, JJ Merelo wrote: > > Anyway, my 2¢ is that in the grand scheme of things, compile time is not > > that important. > > It drives me around the bend and wastes a lot of my > time. It is also embarrassing to hand something like > that over to a customer. > You can shave time by spinning off all business logic to a module that the customer can install. It will be precompiled when it does, and it will save a lot of time next time it's loaded. Perl does not need that, although of course modularizing will always allow you to use best practices like testing and reuse. That said, it's always good to make things faster. Given Rakudo is written to a large extent in Raku, and Raku is being continuously improved, up to and including the new RakuAST, it will happen. The fact that such a project would involve a deep dive into the different layers of the existing Raku, as well as the new RakuAST, make it possibly a unsuitable candidate for Google Summer of Code. Cheers -- JJ
We need you to propose projects for Google Summer of Code
Hi, You probably know that GSoC is an annual event where Google provides grants for students to help develop new stuff in open source organizations. https://summerofcode.withgoogle.com/ We participated a couple of years ago, and got a lot of help for the documentation and other stuff. Last year our application didn't get through, so let's try again this year. We participate under the umbrella of the Perl Foundation, so it's Perl or Raku projects, or any other open source project that's written in any of these languages. in this phase, where we prepare the application, we need project ideas. https://github.com/perl-foundation-outreach/gsoc-2021-ideas Follow the template in the main directory to propose something you'd be comfortable tutoring. Tutoring happens through summer, and it's ideally done by 2-3 people per project so that some can do the summer-y thing while the others help. What I want from you - Propose project ideas that can take a student (possibly with no prior idea of Raku) a summer to work on. It can be part of the core, but also modules you're working already with or some you want to work with. - Help as mentors. Mentors get their own T-Shirt and the appreciation from the whole community, and little in the way of monetary emoluments, but the Perl Foundation gets 2500€ (or $, don't remember exactly) per project, so you help not only further the goals of the project you're mentoring, but also the community at large. I've mentored in a couple of occasions, and it's an overall nice experience, plus you get to help Raku and also maybe yourself with some project you're familiar with. Getting involved is a win-win, for you and the community at large. Anything else you need to know, please ask. Cheers -- JJ
Re: I need help with ~~m/
El sáb, 30 ene 2021 a las 7:24, ToddAndMargo via perl6-users (<
perl6-us...@perl.org>) escribió:
> Hi All,
>
> rakudo-pkg-2020.12-01.x86_64
>
> Why does this work?
>
> > $x = "1.33.222.4";
> 1.33.222.4
> > $x ~~ m/ (<:N>+) [.] (<:N>+) [.] (<:N>+) [.] (<:N>+) /;
> ｢1.33.222.4｣
> 0 => ｢1｣
> 1 => ｢33｣
> 2 => ｢222｣
> 3 => ｢4｣
>
This works because you have the right amount of capturing groups (<:N>+) (
https://docs.raku.org/language/regexes#capturing )separated by the right
amount of single characters (. matches a single character, check
https://docs.raku.org/language/regexes#Wildcards) It also works because
<:N> matches the unicode property number (
https://docs.raku.org/language/regexes#Unicode_properties), which includes
all kinds of numbers. If you are not going to use Balinese or Roman
numerals, it's probably OK if you use \d instead. Then, the string you're
matching (shown above) matches precisely the 4 groups there are. So ti
works. You probably want this instead:
say "1.33.222.4" ~~ m/(\d+) "." (\d+) "." (\d+) "." (\d+) /
｢1.33.222.4｣
0 => ｢1｣
1 => ｢33｣
2 => ｢222｣
3 => ｢4｣
Or, even better,
say "1.33.222.4" ~~ m/(\d+) ** 4 % "." /
Which uses the modified quantifier (
https://docs.raku.org/language/regexes#Modified_quantifier:_%,_%%) together
with a general quantifier
https://docs.raku.org/language/regexes#General_quantifier:_**_min..max
saying "I want this (\d+) exactly four times (** 4 ) separated by (%) a
literal dot "."".
>
>
> But this does not?
> --> Why the wrong number in $2?
> --> Why no Nil for $3?
>
> > $x = "1.33.222";
> 1.33.222
> > $x ~~ m/ (<:N>+) [.] (<:N>+) [.] (<:N>+) [.] (<:N>+) /;
>
Because [.] is "a non-grouping class of characters that includes any
character". So <:N> is matching the first 2, then [.] is matching any
character, so matching and dropping (
https://docs.raku.org/language/regexes#Non-capturing_grouping) the second
one, and then the last group of <:N> is capturing the last one. It would
fail if you had had 2 digits, instead of three.
This works and matches both strings.
say $_ ~~ /(\d+) ** {3..4} % "\."/ for <1.33.222.4 1.33.222>
｢1.33.222.4｣
0 => ｢1｣
0 => ｢33｣
0 => ｢222｣
0 => ｢4｣
｢1.33.222｣
0 => ｢1｣
0 => ｢33｣
0 => ｢222｣
Once again, the regex tutorial is your friend
https://docs.raku.org/language/regexes, as well as the reference for Regex
or any of the other operators.
Cheers
--
JJ
Re: LTA documentation page
Yep, there are a couple of (known) issues here: https://github.com/Raku/problem-solving/issues/252 which request to remove it from the ecosystem (and I'll probably do it when I finish this email), and this one https://github.com/Raku/doc/issues/2896 Build.pm does not really work now, to it should probably be removed. And if it is, there's actually nothing to "install" so it should be removed. Maybe we should work first on releasing rakudoc. Let me see if we can do that soon-ish or it requires a lot of work. And in any case we will probably encourage people to use the online version of the documentation (or to build it themselves via Documentable) Thanks anyways for the checks, cheers El mar, 5 ene 2021 a las 18:02, Gianni Ceccarelli () escribió: > On 2021-01-05 William Michels via perl6-users > wrote: > > Raiph's suggestion works for me (on rakudo-2020.10). I mean, p6doc > > installs > > Oh, that points to new, different, problems. > > https://modules.raku.org/search/?q=p6doc links to > https://github.com/Raku/doc which does not contain a ``p6doc`` script, > which means that what I get with ``zef install p6doc`` is not the same > thing (this is a general problem with pointing at repositories instead > of distribution artifacts, it's not specific to p6doc) > > Then, ``zef install p6doc`` fails here, because:: > > Failed to create directory '/usr/share/perl6/site/doc' with mode > '0o777': Failed to mkdir: Permission denied > > AIUI, distributions should install to the CompUnit::Repository in my > home directory, not into the system-wide one. > > -- > Dakkar - > GPG public key fingerprint = A071 E618 DD2C 5901 9574 > 6FE2 40EA 9883 7519 3F88 > key id = 0x75193F88 > > -- JJ
Re: LTA documentation page
Gianni is basically right. rakudoc has not really been released yet into the ecosystem, and p6doc will get you the documentation itself, which you will have to build then. So LTA is true, and there's some work to be done. There's probably an issue already created, but it will pop up if you create another one, so please do raise the issue and focus it on the documentation part if it does not. We really encourage people to peruse the documentation online, though. https://docs.raku.org. If what you want is to check out the documentation of installed modules... Well, as said above, work needs to be done. El mar, 5 ene 2021 a las 14:10, Ralph Mellor () escribió: > I googled rakudoc and that led to: > > https://github.com/Raku/rakudoc > > which says it's forked from: > > https://github.com/noisegul/perl6-p6doc > > So I tried that in m.r.o and it's listed: > > https://modules.raku.org/search/?q=p6doc > > So, perhaps you can zef install p6doc? > > Maybe the doc you read mentioning rakudoc > is ahead of the situation in rakudo versions, or > at least yours, as well as being ahead of the > ecosystem? > > love, raiph > -- JJ
Re: Please take apart this stub line for me
El mié, 30 dic 2020 a las 11:40, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 12/30/20 2:21 AM, JJ Merelo wrote: > > It's "hosing me down". No, I'm not doing that. Veesh's answer was good > > enough for me; it probably should be for you. > > > > Cheers > > > > JJ > > Hi JJ, > > To Quote Veesh: > >No. I can't imagine that what you're doing >now is productive. What are you actually >trying to understand by reading the source. > > He most definitely did not answer my question. > Neither did you. In Veesh's case, I think he > knows but is just frustrated with the way I think. > Veesh is a really great guy. > Yes, he didn't answer the question and told you why. You seem to have an unique knack for turning what could have initially be productive questions into improductive rants about how bad is documentation, how you learn, or how the world at large is not built exactly the way you want it. I'm not answering either, although I'm not expecting you to learn the lesson. > > You, I suspect, don't actually know the answer > or you would have just answered me. Veesh told > me directly he did not want to answer, you > just hosed me. > So that's the point of the question? To try and find people that are punching above their weight like (possibly) me? Not going to fall into that either. Also, it's "hosed me _down_". I'm also requesting you to take these totally improductive questions (and subsequent discussions) elsewhere. I'm not participating in it any more. Cheers JJ
Re: Please take apart this stub line for me
It's "hosing me down". No, I'm not doing that. Veesh's answer was good enough for me; it probably should be for you. Cheers JJ
Re: Please take apart this stub line for me
El mié, 30 dic 2020 a las 10:14, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 12/30/20 12:18 AM, JJ Merelo wrote: > > > > > > El mié, 30 dic 2020 a las 8:02, Veesh Goldman ( > <mailto:rabbive...@gmail.com>>) escribió: > > > > No. > > I can't imagine that what you're doing now is productive. > > What are you actually trying to understand by reading the source. > > > > > > Probably proving his point that anything, up to and including looking at > > clouds and watching Turkish series in Netflix, is better than reading > > the documentation. > > > > So my answer will not surprise you: read the documentation > > https://docs.raku.org/type/Metamodel::ClassHOW > > <https://docs.raku.org/type/Metamodel::ClassHOW> Everything is in > there, > > and if it's not, it's probably an implementation detail you don't need > > to care about. > > > > Cheers > > > > JJ > > Hi JJ, > > Oh brother JJ. Did I accuse you of having patches on > your elbows and a beard to look older? What is with > the name calling? > > The link you gave me is worthless to the question > I asked. > > And please do not give me links to the documentation. > The documentation is written as a refresher for > advanced users that don't need it. It is a very > poor reference for me. > See what I mean? If you had bothered to look it up you would have seen it answers a part of your question. The rest has been answered by Veesh: Don't go there. For starters, if you had bothered to look at the name of the file you would have seen it's not even Raku, it's NQP, acronym for "DoN't Quite Peep here". You might be happy to know, however, there's barely any documentation for NQP, short of a reference and a couple of Power Points. Since you're apparently happier looking at source code than documentation, take a look at https://github.com/Raku/nqp and come back when you're done. All the answers for your question are there, if you look closely enough. Cheers JJ
Re: Please take apart this stub line for me
El mié, 30 dic 2020 a las 8:02, Veesh Goldman () escribió: > No. > I can't imagine that what you're doing now is productive. > What are you actually trying to understand by reading the source. > Probably proving his point that anything, up to and including looking at clouds and watching Turkish series in Netflix, is better than reading the documentation. So my answer will not surprise you: read the documentation https://docs.raku.org/type/Metamodel::ClassHOW Everything is in there, and if it's not, it's probably an implementation detail you don't need to care about. Cheers JJ
Re: Practical Raku projects
Yep, there's DBIish, which is fine and works pretty well. There's also a fabulous ORM, Red, very Rakuish, also working like a charm. Cheers El jue, 24 dic 2020 a las 12:24, Matthias Peng () escribió: > Do you know if there is any for Perl6’s DBIx::Class the ORM library? > Regards > > >> Hi, >> >> El jue, 24 dic 2020 a las 3:55, Matthias Peng () >> escribió: >> >>> May I ask if there is any practical perl6 project running? For example, >>> homebrew by ruby, k8s by go, flask by python etc. >>> >> >> I doubt there's any perl6 practical project _now_. There are a few >> practical Raku projects, however, and they are big. For instance, Cro is >> much better than Flask will ever be: its way of handling routes, templates, >> and the fact that it's concurrent, puts it in another level. There's no >> docker or k8s... yet. But just you wait.. >> >> Cheers >> -- >> JJ >> > -- JJ
Practical Raku projects
Hi, El jue, 24 dic 2020 a las 3:55, Matthias Peng () escribió: > May I ask if there is any practical perl6 project running? For example, > homebrew by ruby, k8s by go, flask by python etc. > I doubt there's any perl6 practical project _now_. There are a few practical Raku projects, however, and they are big. For instance, Cro is much better than Flask will ever be: its way of handling routes, templates, and the fact that it's concurrent, puts it in another level. There's no docker or k8s... yet. But just you wait.. Cheers -- JJ
Re: Continuous testing
You can probably use AppVeyor. It's got good support for Windows, although you'll have to write for it specifically. This one seems to use it, for instance https://github.com/MARTIMM/gnome-native El mié, 23 dic 2020 a las 16:35, Richard Hainsworth () escribió: > Hi to everyone. > > Hope you all have a happy holiday time at the end of the year - > different countries different celebrations, but good will to all. > > Hope 2021 is properous for you all too. > > About continuous testing. I have recently taken on the maintenance of > GTK::Simple. > > The Travis-CI setup was constructed a while ago and tested both OSX and > Linux, but not Windows. > > It was failing for OSX and for one of the Linux environments. > > So I have changed it to the minimal docker image provided by JJ - kudos > that man!!! > > However, that required a removal of OSX - bad. > > In addition, GTK::Simple is difficult to install on Windows, so I'll > need help there, but I would like to know how test a module for Windows > anyway. > > For clarity, I last used a Mac in the naughties, and stopped using > Windows as soon as I could get what I needed from Linux. So basically, I > have minimal recent knowledge of these environments. > > I have two questions: > > a) Could any one provide me with a CI scheme that would cover Linux / > OSX / Windows? > > Not necessarily on the same server environment. > > There is an issue in GTK::Simple to the effect that it would be better > to use github Actions instead of Travis-CI et al. A comment on this > theme would help. > > b) Is there a reasonable link to a blog/tutorial on CI ? > > I think that there should be some basic information on CI in the Raku > documentation on Modules. If anyone answers q1 for me, then I'll write > up the scheme I adopt for the Modules documentation together with a link > to better information. > > When I have asked this question before, I haven't had much response. > Either I have had answers that assume everyone know about CI, or most > often I get a response that the answerer just copies/pastes > configurations from other modules. > > Whilst CI is not a part of Raku, a basic CI scheme that could be adopted > by all Module writers would enhance the robustness of the Raku module > community. > > -- JJ
Two days to submit your talks to FOSDEM
Hi, https://news.perlfoundation.org/post/fosdem-2021-call-for-papers Any kind of talk is acceptable: from lightning talks to long talks (1 hour) Cheers -- JJ
Re: list of printers
El dom, 6 dic 2020 a las 10:09, ToddAndMargo via perl6-users (<
perl6-us...@perl.org>) escribió:
> On 12/4/20 8:55 PM, ToddAndMargo via perl6-users wrote:
> > On 2020-12-04 20:28, Curt Tilmes wrote:
> >> On Fri, Dec 4, 2020 at 10:52 PM ToddAndMargo via perl6-users
> >> wrote:
> >>
> >>> This is the C way, although it shows deleted printers as well:
> >>>
> >>> #include
> >>> #include
> >>>
> >>> int main() {
> >>> cups_dest_t* dests;
> >>> int nCount = cupsGetDests2(CUPS_HTTP_DEFAULT, );
> >>>
> >>> for (int i = 0; i < nCount; i++) {
> >>> cups_dest_t dest = dests[i];
> >>> std::cout << dest.name << std::endl;
> >>> }
> >>> }
> >>
> >> Roughly translating that into Raku Nativecall (my system has
> >> cupsGetDests(), but not cupsGetDests2() -- you'll have to update to
> >> that)
> >>
> >> use NativeCall;
> >> class CupsDest is repr('CStruct') {
> >> has Str $.name; # This is the first field in the struct --
> >> add more if you need them
> >> }
> >>
> >> sub cupsGetDests(Pointer is rw --> int32) is native('cups') {}
> >>
> >> my $ptr = Pointer.new;
> >> my $nCount = cupsGetDests($ptr);
> >>
> >> for ^$nCount -> $i {
> >> my $dest = nativecast(CupsDest, Pointer.new($ptr + $i *
> >> nativesizeof(Pointer)));
> >> say $dest.name;
> >> }
> >>
> >
> >
> >
> > Hi Curt,
> >
> > What am I doing wrong?
> >
> > #!/usr/bin/env raku
> >
> > use NativeCall;
> > class CupsDest is repr('CStruct') {
> > has Str $.name; # This is the first field in the struct --
> > add more if you need them
> > }
> >
> > sub cupsGetDests(Pointer is rw --> int32) is native('cups') {}
> >
> > my $ptr = Pointer.new;
> > my $nCount = cupsGetDests($ptr);
> >
> > for ^$nCount -> $i {
> > my $dest = nativecast(CupsDest, Pointer.new($ptr + $i *
> > nativesizeof(Pointer)));
> > say $dest.name;
> > }
> >
> > $ ListPrinters.pl6
> > Cannot locate native library 'libcups.so': libcups.so: cannot open
> > shared object file: No such file or directory
> >in method setup at
> >
> /opt/rakudo-pkg/share/perl6/core/sources/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B
>
> > (NativeCall) line 298
> >in block cupsGetDests at
> >
> /opt/rakudo-pkg/share/perl6/core/sources/947BDAB9F96E0E5FCCB383124F923A6BF6F8D76B
>
> > (NativeCall) line 587
> >
> >
> > $ locate libcups.so
> > /usr/lib/libcups.so.2
> > /usr/lib64/libcups.so.2
> >
> >
> > -T
>
> I did the following:
>
> # cd /usr/lib
> # gls libcups
> libcupsimage.so.2
> libcups.so.2
>
> # ln -s libcups.so.2 libcups.so
>
Why did you do so? ;-)
# ls -al libcups*
> -rwxr-xr-x. 1 root root 14612 Nov 10 06:07 libcupsimage.so.2
> lrwxrwxrwx. 1 root root 12 Dec 6 01:03 libcups.so -> libcups.so.2
> -rwxr-xr-x. 1 root root 710236 Nov 10 06:07 libcups.so.2
>
> # cd /usr/lib64
> # ln -s libcups.so.2 libcups.so
> # ls -al libcups*
> lrwxrwxrwx. 1 root root 23 Nov 23 22:09 libcupsfilters.so.1 ->
> libcupsfilters.so.1.0.0
> -rwxr-xr-x. 1 root root 264440 Nov 23 22:09 libcupsfilters.so.1.0.0
> -rwxr-xr-x. 1 root root 15256 Nov 10 06:08 libcupsimage.so.2
> lrwxrwxrwx. 1 root root 12 Dec 6 01:04 libcups.so -> libcups.so.2
> -rwxr-xr-x. 1 root root 686128 Nov 10 06:08 libcups.so.2
>
>
> Running the program now gives:
>
> $ ListPrinters.pl6
> B4350
> (Str)
> Segmentation fault (core dumped)
>
Well, the second $dest clearly has no value in "name". And in the next one
you are getting into a loop and casting pointers and stuff without actually
checking if they're good. It looks like it's pointing nowhere; either the
size is off, or there's any other problem.
Cheers
JJ
--
JJ
Get help for your projects during hacktoberfest
Hi, Hacktoberfest is coming, https://hacktoberfest.digitalocean.com/, and lots of people will be running around looking for PRs to get their tees. Let's try and help them by creating a page with specific issues that we have created specifically to be easy to PR for newcomers to Raku. Here's what you need to do 1. Look up or create newcomer-friendly issue(s) in the repos. By newcomer-friendly I don't only mean they need to be easy, also that they need to include all the context needed to solve them: links to the CONTRIBUTING.md file, pointers to module and language documentation, even pointers to tutorials or articles that might be useful. These can very well be *special* issues, that is, issues created only with that specific purpose. Possibly, also, issues that can be "solved" several times so that you don't need to close it when the first PR arrives. 2. Label it "hacktoberfest" 3. Send a PR here https://github.com/Raku/hacktoberfest to get it included into the webpage that we have created. 4. If you get a PR, react immediately and helpfully to it. Let's try to show, with this, how friendly and welcoming the Raku community is, and also attract interest and new coders to the language. Cheers -- JJ
Re: Reminder: Fill Raku's user survey!
El dom., 30 ago. 2020 a las 11:43, ToddAndMargo () escribió: > >> El dom., 30 ago. 2020 a las 11:34, ToddAndMargo ( >> <mailto:toddandma...@zoho.com>>) escribió: > >> > >> On 2020-08-30 02:26, JJ Merelo wrote: > >> > Hi, > >> > Here's the link > >> > > >> > https://docs.google.com/forms/d/e/1FAIpQLSdRPBdn1iRN_sT8BMNMOBhVbEY1u8ngZWVwLyM37sqsa4OLwQ/viewform > >> > > >> > It'll take you five minutes, top. Answers will be summarized and > >> > carefully considered. Thanks! > >> > > >> > -- > >> > JJ > >> > >> > >> Hi JJ, > >> > >> I missed one when I filled out the list: > >> > >> 8) The developers seriously need to fix the staging > >> compile times on par with Perl 5: > >> > >> $ raku -c --stagestats GetUpdates.pl6 > >> Stage start : 0.000 > >> Stage parse : 18.108 > >> Stage syntaxcheck: Syntax OK > >> > >> Any way you an get it into the fray? > >> > >> Many thnks, > >> -T > > On 2020-08-30 02:36, JJ Merelo wrote: > > In principle, answers are anonymous, so no way, sorry. Did you > > *actually* fill the form, though, or just answered the question here? We > > need them to be in the form, to consider them. > > Indeed I did. I just forgot to add the "staging" problem > to the fray. Then I started taklig about it on this forum. > > And I do not care if I am anonymous, especially if when you > get to mine, you will know immediately it is me. My views > are quite public. > There are 128 answers so far. I went so far as to actually look for 7., since that issue was 8. I didn't find anything there (only, unsurprisingly, some answers that mention Perl 7). Even if I had found it, you must understand that setting up and analyzing a survey is a good amount of work. Trying to find a specific answer and edit it is way beyond what is actually required, or actually needed. You've actually expressed your view, it's been noted. You want it to go into the survey, I'm afraid you'll have to fill it up again. Cheers -- JJ
Re: Reminder: Fill Raku's user survey!
In principle, answers are anonymous, so no way, sorry. Did you *actually* fill the form, though, or just answered the question here? We need them to be in the form, to consider them. El dom., 30 ago. 2020 a las 11:34, ToddAndMargo () escribió: > On 2020-08-30 02:26, JJ Merelo wrote: > > Hi, > > Here's the link > > > https://docs.google.com/forms/d/e/1FAIpQLSdRPBdn1iRN_sT8BMNMOBhVbEY1u8ngZWVwLyM37sqsa4OLwQ/viewform > > > > It'll take you five minutes, top. Answers will be summarized and > > carefully considered. Thanks! > > > > -- > > JJ > > > Hi JJ, > > I missed one when I filled out the list: > > 8) The developers seriously need to fix the staging > compile times on par with Perl 5: > > $ raku -c --stagestats GetUpdates.pl6 > Stage start : 0.000 > Stage parse : 18.108 > Stage syntaxcheck: Syntax OK > > Any way you an get it into the fray? > > Many thnks, > -T > -- JJ
Reminder: Fill Raku's user survey!
Hi, Here's the link https://docs.google.com/forms/d/e/1FAIpQLSdRPBdn1iRN_sT8BMNMOBhVbEY1u8ngZWVwLyM37sqsa4OLwQ/viewform It'll take you five minutes, top. Answers will be summarized and carefully considered. Thanks! -- JJ
Re: Place for examples in a Raku module?
Hi, El vie., 14 ago. 2020 a las 6:25, Stuart Hungerford (< stuart.hungerf...@gmail.com>) escribió: > 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 one of those is acceptable. The second way is a good one, for instance. "Idiomatic" Raku is never the one and only way of doing things; it's sometimes the most efficient way of doing something, compiler-wise, but we take pride in the TIMTOWDI slogan. In this case, I don't see any performance constraint or layout convention, so any, or both ways, are totally OK. Cheers JJ
Re: Baby steps to create a dataframe structure
Well, you can use it for commercial software as long as you distribute the
source with it...
El mié., 22 jul. 2020 a las 14:07, Fernando Santagata (<
nando.santag...@gmail.com>) escribió:
> Here https://www.gnu.org/software/gsl/ I see this note:
>
> The bottom line for commercial users:
>> GSL can be used internally ("in-house") without restriction, but only
>> redistributed in other software that is under the GNU GPL.
>>
>
> So yes, the license restricts the use to GNU GPL software; no other
> restriction that I noticed.
>
> On Wed, Jul 22, 2020 at 2:03 PM Tom Browder wrote:
>
>> On Wed, Jul 22, 2020 at 06:51 JJ Merelo wrote:
>>
>>> The Raku wrapper for GSL is ready, specifically all matrix operations,
>>> check it out. It's extremely fast, and could be the foundation for these
>>> data frames.
>>>
>>
>> Depending on your use of the GSL, as I recall the license restricts
>> commercial use.
>>
>> Best regards,
>>
>> -Tom
>>
>
>
> --
> Fernando Santagata
>
--
JJ
Re: Baby steps to create a dataframe structure
The Raku wrapper for GSL is ready, specifically all matrix operations, check it out. It's extremely fast, and could be the foundation for these data frames. El mié., 22 jul. 2020 a las 9:15, Tessa Plum () escribió: > Marc Chantreux wrote: > >> But the idea is to implement cooperatively those tools > > if you do that, i'll be a very suportive user (and casual contributor > > if i can). > > me second. :) > > Regards. > -- JJ
Re: Pod6 examples
El mar., 21 jul. 2020 a las 17:23, Richard Hainsworth (< rnhainswo...@gmail.com>) escribió: > How about: > > https://github.com/Raku/doc/tree/master/doc/Language/pod.pod6 > > which is the pod source of https://docs.raku.org/language/pod This page is also intended as a tutorial. If there's something you miss there, we'd be happy to get an issue about it (or a PR). Cheers JJ
Re: recent perl6 book
I would obviously suggest my own book https://www.apress.com/gp/book/9781484249550, Perl 6 Quick Syntax Reference, published last October. And we'll have to try and find a way to update that file... El mar., 21 jul. 2020 a las 4:02, Warren Pang () escribió: > Greetings, > > Would you suggest a recent release of perl6 book? > I took a look here: > https://perl6book.com/ > > They seem out of date, most were published before 2018. > > Thank you. > -- JJ
Re: recent perl6 book
OK, it's right there, at the bottom https://github.com/moritz/perl6book-web El mar., 21 jul. 2020 a las 9:11, JJ Merelo () escribió: > I would obviously suggest my own book > https://www.apress.com/gp/book/9781484249550, Perl 6 Quick Syntax > Reference, published last October. > And we'll have to try and find a way to update that file... > > El mar., 21 jul. 2020 a las 4:02, Warren Pang () > escribió: > >> Greetings, >> >> Would you suggest a recent release of perl6 book? >> I took a look here: >> https://perl6book.com/ >> >> They seem out of date, most were published before 2018. >> >> Thank you. >> > > > -- > JJ > -- JJ
Re: I cannot install any lib with Zef
El lun., 20 jul. 2020 a las 18:03, Aureliano Guedes (< guedes.aureli...@gmail.com>) escribió: > Hi all, > > I'm trying to figure out why I cannot install any package with zef. > > $ raku --version > This is Rakudo version 2020.06 built on MoarVM version 2020.06 > implementing Raku 6.d. > > zef install Acme::Insult::Lala > ===SORRY!=== > No candidate found for 'zef' that match your criteria. > Did you perhaps mean one of these? > Distribution | Author(ity) | Version >| | >| | >| | >| | > This error does not seem to correspond to the command line... It's as if you were looking for zef. That happens when you don't have an updated version of the tool and the repos and nothing downloaded locally. My hunch is that you might have an old version of zef; failing that, the repo index must be corrupted somehow. In any case, install zef (not using zef, but reinstalling it from repos or with rakudobrew) and you will fix it. > -- JJ
Re: NativeLibs not loading on Module testing
I've submitted now a PR to NativeLibs that fixes that issue. El mar., 14 jul. 2020 a las 11:03, Richard Hainsworth (< rnhainswo...@gmail.com>) escribió: > I'm adding a Module to the ecosystem, and the Build system failed, see > > https://travis-ci.com/github/Raku/ecosystem/builds/175326153 > > It doesn't seem that it is my Module that's failing, but NativeLibs. > > see line 165. > > As for my Module (raku-pod-render) it passes all tests, including > Test-Meta locally, so I don't think its my module. > > Richard aka finanalyst > -- JJ
Re: impact of compiling pod doc
It's going to be pretty much the same. If it's installed, it's going to be precompiled anyway. The overhead added by reading the file might even make it slower. Of course, you can always give it a try and measure. Measuring might always surprise you :-) El mar., 14 jul. 2020 a las 14:20, Marcel Timmerman () escribió: > Hi, > > I was wondering if pod documentation has a large impact on compiling > modules. I assume on small files it would be ignorable but I have some > modules which have grown big, one has 7153 lines of which the biggest > part is pod doc. Would it be useful to split such a file in two. one for > code and the other for doc to improve the install time? > > Regards, > Marcel > -- JJ
Re: perl streaming framework
Hi, El mar., 14 jul. 2020 a las 4:35, Warren Pang () escribió: > Hi > > Does perl have a stream computing framework? > I don't really know about Perl. It used to have Perl Data Language, but I don't know its current state. However, this mailing list is about Raku, or Perl 6 as it was called last year. Raku has enough capabilities to process data natively, so I don't think an external framework is really necessary. JJ
Re: Access violation when creating class instance
El mié., 24 jun. 2020 a las 10:05, WFB ()
escribió:
> Hi all,
>
> I have an access violation on Windows for one of my classes and think it
> is a bug, but not entirely sure about that.
>
> Every now and then creating a class instance ended my script with error:
> Process finished with exit code -1073741819 (0xC005)
>
> The class looks like that:
>
> class KnowledgeKeeper::Note {
> has $.title is required;
> has $.data is required;
> has @.tags;
> has @.attachments;
> has DateTime $.creation-date = DateTime.now;
> has DateTime $.modification-date = DateTime.now;
> }
>
> I first recognized it when a test just ended without dieing. That happens
> about in 50% of the test runs.
> But I could reproduce it with just a simple line in a script:
>
> #!/usr/bin/env perl6
> use KnowledgeKeeper::Note;
>
> my $note = KnowledgeKeeper::Note.new(title => "dasd", data => "adsad");
> say "OK";
>
> With this script it is not failing that much but at least reproducible:
>
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> OK
> PS C:\dev\repos\KnowledgeKeeper> raku -Ilib .\bin\test.p6
> PS C:\dev\repos\KnowledgeKeeper>
> $LastExitCode
>-1073741819
>
> OS: Windows 10 1909 x64
> Raku: This is Rakudo version 2020.01 built on MoarVM version 2020.01.1
> implementing Perl 6.d.
>
> Should I file a bug?
>
Definitely, yes. Please check first if it's still the same problem with the
latest released version. Also, try to golf it down to the minimal amount of
code that still produces the same result. Does the LastExitCode make any
sense?
--
JJ
Re: Is thre a way to do an "if" on "use lib"?
Also, you can simply issue different -I arguments when you invoke the
script; you can put that in a shell or whatever script
raku -Imy/lib script
for your own lib
raku -Iother/lib script
for other
(or Windows equivalent). No need to use Raku to change the path, actually.
El dom., 7 jun. 2020 a las 11:32, Peter Pentchev ()
escribió:
> On Sun, Jun 07, 2020 at 12:28:36AM -0700, ToddAndMargo via perl6-users
> wrote:
> > Hi All,
> >
> > Is there a way to do an "if" on "use lib", so
> > I do not have to keep commenting these back and forth?
> >
> > # use lib 'C:/NtUtil', '.';
> > use lib 'C:/NtUtil', '.', 'K:/NtUtil';
>
> "use lib" is evaluated quite early in the program's execution, so to do
> any interesting things with it, you will need to use a BEGIN phaser
> (similar to what you might know as a BEGIN block in Perl):
>
> =
> #!/usr/bin/env raku
>
> use v6.d;
>
> my $path;
>
> BEGIN {
> $path = 'lib1'.IO.d ?? 'lib1' !! 'lib2';
> }
>
> use lib $path;
>
> use Foo;
>
> Foo.new.hello;
> =
>
> Hope that helps!
>
> G'luck,
> Peter
>
> --
> Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com
> PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
> Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
>
--
JJ
Re: Is thre a way to do an "if" on "use lib"?
No, there's no else. This if is for using modules with different names. If you want to use modules in different paths, it's probably not a good idea to call them by the same name. You can call them different names (and do a use lib on all paths), or use other mechanisms to differentiate them, such as the :api module metadata Check everything about that here: https://docs.raku.org/language/typesystem#Versioning,_authorship,_and_API_version . El dom., 7 jun. 2020 a las 10:21, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2020-06-07 00:55, ToddAndMargo via perl6-users wrote: > >>> El dom., 7 jun. 2020 a las 9:29, ToddAndMargo via perl6-users > >>> (mailto:perl6-us...@perl.org>>) escribió: > >>> > >>> Hi All, > >>> > >>> Is there a way to do an "if" on "use lib", so > >>> I do not have to keep commenting these back and forth? > >>> > >>> # use lib 'C:/NtUtil', '.'; > >>> use lib 'C:/NtUtil', '.', 'K:/NtUtil'; > >>> > >>> Many thanks, > >>> -T > > > > On 2020-06-07 00:41, JJ Merelo wrote: > >> Unsurprisingly, there is "if": https://github.com/FROGGS/p6-if > >> Install it with zef install if > >> > >> And then... > >> > >> > >> use if;# activate the :if adverb on use statements > >> > >> use My::Linux::Backend:if($*KERNEL.name eq 'linux'); > >> use My::Fallback::Backend:if($*KERNEL.name ne 'linux'); > > > > Hi JJ, > > > > Thank you! > > > > Would show me an example of how to use it > > with "use lib"? > > > > -T > > Also, is there an "else" that goes with that? > -- JJ
Re: Is thre a way to do an "if" on "use lib"?
Unsurprisingly, there is "if": https://github.com/FROGGS/p6-if Install it with zef install if And then... use if; # activate the :if adverb on use statements use My::Linux::Backend:if($*KERNEL.name eq 'linux');use My::Fallback::Backend:if($*KERNEL.name ne 'linux'); El dom., 7 jun. 2020 a las 9:29, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > Is there a way to do an "if" on "use lib", so > I do not have to keep commenting these back and forth? > > # use lib 'C:/NtUtil', '.'; > use lib 'C:/NtUtil', '.', 'K:/NtUtil'; > > Many thanks, > -T > -- JJ
Re: Had a weird symptom calling raku
Since Raku is running CompUnits besides compiling them, it might be that there was some CompUnit creating a window in the path. Since you've been talking about GTK lately, something doing that might be left over and if it was used by something along the path, it might have been compiled, thus run, and popped up. It's probably not a good idea to open Windows in a CompUnit, as opposed to the main program. El vie., 5 jun. 2020 a las 22:32, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2020-06-05 13:06, Peter Pentchev wrote: > > On Fri, Jun 05, 2020 at 11:32:20AM -0700, ToddAndMargo via perl6-users > wrote: > >> Hi All, > >> > >> Windows 10 Pro > >> > >> raku -v > >> This is Rakudo version 2020.05.1 built on MoarVM version > >> 2020.05 implementing Raku 6.d. > >> > >> I had a weird symptom calling Raku from Cobian Backup. > >> A black box popped up, delayed about two seconds, > >> then died. The only writing was the flashing cursor. > >> > >> Running the program directly from a shell showed > >> that I had a directory in "lib" that did not > >> exist on the customer's machine: > >> > >> use lib 'K:/NtUtil', 'C:/NtUtil', '.'; > >> > >> Edited out the missing directory and happy camping returned. > > > > What is the window title of that "black box"? Is it possible that it is > > a command prompt that is actually your program, and that it took longer > > to run because of something like trying to access a network drive or > > something? (note: I have not run Windows in about ten years, I have no > > idea how it behaves when you try to access a drive letter that does not > > correspond to a currently mapped device or share). > > Hi Peter, > > It was "Raku". > > And I did check the result of what was suppose to have > happened and it did not. > > I had a little tiny panic attack as I had spend endless > hours on that program just to have it not interface > with Cobian. > > After correcting my "usr lib", all the text that > was suppose to show (as showed in a shell) did > show up i the Raku black box. > > Trivia: this is how Cobian calls my program: > > COMMANDLINE,"C:\rakudo\bin\raku.exe C:\NtUtil\CobianWrapper.pl6 > --rotates 20 --backup_path [BACKUP]\MyDocsBackup\backup1",true > > -T > -- JJ
Re: Accidentally closed an issue
Reopened El sáb., 30 may. 2020 a las 19:26, Joseph Brenner () escribió: > I was just trying to comment on an issue I opened the other day, and I > accidentally closed it. I don't see any way for me to re-open it, so > I would guess I don't have permissions to do so. Could someone > re-open this? > > https://github.com/rakudo/rakudo/issues/3728 > -- JJ
Re: star 2020.02 ?
OK, I missed that release then. The point stands, however, Rakudo star releases do not match exactly monthly releases. El dom., 22 mar. 2020 a las 10:28, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2020-03-22 02:19, ToddAndMargo via perl6-users wrote: > > > >> El dom., 22 mar. 2020 a las 9:50, ToddAndMargo via perl6-users > >> (mailto:perl6-us...@perl.org>>) escribió: > >> > >> I am not finding 2020.02 over on > >> > >> https://rakudo.org/downloads/star/ > >> > >> Am I missing something? > >> > >> > >> > >> -- > >> JJ > > > > On 2020-03-22 01:59, JJ Merelo wrote: > >> Hi, > >> There's no Star release for every monthly release; latest one was > >> 2020.01. It used to be done every four months, but not sure what's the > >> schedule now. > > > > https://rakudo.org/downloads > > $ sha256sum 'RakudoStar-2020.02.1.04-win-x86_64-(JIT).msi' > > 5a61c46ba05a5e360ca2b2433f2bdae1b9db99c32441c4dd53c0cfbfffa69798 > RakudoStar-2020.02.1.04-win-x86_64-(JIT).msi > -- JJ
Re: star 2020.02 ?
El dom., 22 mar. 2020 a las 10:20, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > > El dom., 22 mar. 2020 a las 9:50, ToddAndMargo via perl6-users (< > perl6-us...@perl.org>) escribió: > >> I am not finding 2020.02 over on >> >> https://rakudo.org/downloads/star/ >> >> Am I missing something? >> > > > -- > JJ > > > On 2020-03-22 01:59, JJ Merelo wrote: > > Hi, > There's no Star release for every monthly release; latest one was 2020.01. > It used to be done every four months, but not sure what's the schedule now. > > > https://rakudo.org/downloads > > > > -- > ~~ > Computers are like air conditioners. > They malfunction when you open windows > ~~ > > Those are the monthly releases, not the star releases, which are bundled separately and released in the same way. You were asking about those, right? -- JJ
Re: star 2020.02 ?
Hi, There's no Star release for every monthly release; latest one was 2020.01. It used to be done every four months, but not sure what's the schedule now. El dom., 22 mar. 2020 a las 9:50, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > I am not finding 2020.02 over on > > https://rakudo.org/downloads/star/ > > Am I missing something? > -- JJ
Re: problems with 2020.01
That would be probably a good candidate for raising it as a Rakudo Star issue at https://github.com/rakudo/star/issues Definitely, at least the documentation and much better the installation process should check for prior versions and ask them to be uninstalled. El vie., 28 feb. 2020 a las 21:59, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > I just installed rakudo-star-2020.01-01-win-x86_64-(JIT).msi > > Found out the hard way if you do not uninstall the prior version, the > current version will not uninstall it for you. > > -T > > raku -v > Unhandled exception: Missing or wrong version of dependency > 'C:\rakudo\bin\..\sh > are\nqp\lib\MAST\Nodes.nqp' (from 'src/Perl6/Pod.nqp') > at :1 > (C:\rakudo\bin\..\share\nqp\lib/Perl6/Pod.moarvm: s+deserialize>) > from src\vm\moar\ModuleLoader.nqp:47 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:) > from src\vm\moar\ModuleLoader.nqp:40 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:load_module) > from :1 > (C:\rakudo\bin\..\share\nqp\lib/Perl6/Actions.moarvm: ncies+deserialize>) > from src\vm\moar\ModuleLoader.nqp:47 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:) > from src\vm\moar\ModuleLoader.nqp:40 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:load_module) > from :1 > (C:\rakudo\bin\..\share\nqp\lib/Perl6/Grammar.moarvm: ncies+deserialize>) > from src\vm\moar\ModuleLoader.nqp:47 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:) > from src\vm\moar\ModuleLoader.nqp:40 > (C:\rakudo\bin\..\share\nqp\lib/ModuleLoa > der.moarvm:load_module) > from :1 > (C:\rakudo\bin\..\share\perl6\runtime\perl6.moarvm: ies+deserialize>) > -- JJ
Re: Rakudo Star v2020.01
Great work, and thanks, Patrick. El mié., 19 feb. 2020 a las 20:46, Patrick Spek via perl6-users (< perl6-us...@perl.org>) escribió: > Hi everyone! > > Just now I've sent an announcement to perl6-compil...@perl.org, to > notify people that I've made a first non-rc release of Rakudo Star. For > those of you that use Rakudo Star, this may be a good time to try out > the latest version! The files are available from https://dist.tyil.nl: > > - https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz > - https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz.asc > - > https://dist.tyil.nl/raku/rakudo-star/rakudo-star-2020.01.tar.gz.checksums.txt > > I've not had many people to test things, but the rakudo spectest > succeeds on all my machines, and I've been using it on my own machines > for a couple weeks now, so I have no reason not to believe this release > will work. > > Do note, however, that I only use, and therefore test, on GNU+Linux. > This release does *not* contain a .msi (for Windows users) or a .dmg > (for Mac users). If anyone would like to help out by building those > files, please do not hesitate to reach out! > > If you have any questions on how to install this (on GNU+Linux or > otherwise), please reply to the mailing list and I (or other people, > especially for Windows and Mac users) will do my (or our) best to help > you out. > > Any feedback on how to best communicate these releases is also very > much appreciated. > > Lastly, I do not have access to the sources of https://rakudo.org/ (as > far as I'm aware), and can therefore not update that website to mirror > the release files, nor update its documentation. If anyone knows who to > contact for this, please let me know. > > -- > With kind regards, > > Patrick Spek > > > www: https://www.tyil.nl/ > mail: p.s...@tyil.nl > pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 > > social: https://soc.fglt.nl/tyil > git:https://gitlab.com/tyil/ > -- JJ
Re: Question about Blob and Buf
You are using ~, which stringifies. Bufs are not strings: you need to decode them to concatenate it to a string. If what you want is to concatenate the buffer, probably ,= will work (not sure about this, would have to check), or any other operator that works on Positionals. JJ El mar., 11 feb. 2020 a las 10:56, David Santiago () escribió: > A 11 de fevereiro de 2020 10:47:34 CET, David Santiago > escreveu: > >A 11 de fevereiro de 2020 09:46:06 CET, David Santiago < > deman...@gmail.com> escreveu: > >> > >>Hi! > >> > >>Can someone explain me why this doesn't work: > >> > >>my Blob $read; > >>$read ~= $socket.read(1024); > >> > >>Dies with error: > >> > >>X::Buf::AsStr: Cannot use a Buf as a string, but you called the Stringy > method on it > >> > >>This also doesn't work: > >> > >>my Buf $read; > >>$read ~= $socket.read(1024); > >> > >>Dies with the same error as above. > >> > >> > >>But this works? > >> > >>my Blob $read = Buf.new; > >>$read ~= $socket.read(1024); > >> > >> > >>Best regards, > >>David Santiago > > > > > >Hi! > > > >Can someone explain me why this doesn't work: > > > >my Blob $read; > >$read ~= $socket.read(1024); > > > >Dies with error: > > > >X::Buf::AsStr: Cannot use a Buf as a string, but you called the Stringy > method on it > > > >This also doesn't work: > > > >my Buf $read; > >$read ~= $socket.read(1024); > > > >Dies with the same error as above. > > > > > >But this works? > > > >my Blob $read = Buf.new; > >$read ~= $socket.read(1024); > > > > > >Best regards, > >David Santiago > > > Hi! > > Can someone explain me why this doesn't work: > > my Blob $read; > $read ~= $socket.read(1024); > > Dies with error: > > X::Buf::AsStr: Cannot use a Buf as a string, but you called the Stringy > method on it > > This also doesn't work: > > my Buf $read; > $read ~= $socket.read(1024); > > Dies with the same error as above. > > > But this works? > > my Blob $read = Buf.new; > $read ~= $socket.read(1024); > > > Best regards, > David Santiago > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- JJ
Re: Ping JJ: string literals
El sáb., 18 ene. 2020 a las 13:55, Tobias Boege ()
escribió:
> On Sat, 18 Jan 2020, JJ Merelo wrote:
> > The example works perfectly, and it does because it's a string literal
> > which is already 0 terminated. Let's use this code instead of the one
> that
> > I used in my other mail about this (which you probably didn't read
> anyway):
> >
> > 8< 8< 8<
> >
> > What does this mean? It means that NativeCall does the right call
> > (badum-t) and converts a Raku string literal into a C string literal,
> > inserting the null termination even if we didn't. I actually don't care
> if
> > it was the NativeCall API or the encode method. It just works. It gets
> > allocated the right amount of memory, it gets passed correctly into the C
> > realm. Just works. Since @array.elems has 3 elements, well, it might be
> > rather the C part the one that does that. But I really don't care, and it
> > does not really matter, and thus the example is correct, no need to add
> > anything else to the documentation. Except maybe "get your C right"
> >
>
> What you say seems to be correct: if you have a string literal in your
> Raku code, this works for me, too. (Sometimes, see below.)
>
> BUT the terminating NUL character is not inserted by NativeCall and it
> isn't inserted by If you run this program which uses a much
> longer string that is not a literal on the face of it:
>
> use NativeCall;
> sub c-printf(CArray[uint8]) is native is symbol { * };
>
> my $string = "X" x 1994;
> my $array = CArray[uint8].new($string.encode.list);
> c-printf $array;
>
> through valgrind, it will warn you about a one-character invalid read,
> that is a byte accessed by printf() which is at offset 0 after a properly
> allocated block of size 1994:
>
> $ perl6-valgrind-m -MNativeCall -e 'sub c-printf(CArray[uint8]) is
> native is symbol { * }; my $string = "X" x 1994; my $array =
> CArray[uint8].new($string.encode.list); c-printf $array' >/dev/null
>
> ==325957== Invalid read of size 1
> ==325957==at 0x48401FC: strchrnul (vg_replace_strmem.c:1395)
> ==325957==by 0x50CD334: __vfprintf_internal (in /usr/lib/
> libc-2.30.so)
> ==325957==by 0x50BA26E: printf (in /usr/lib/libc-2.30.so)
> ==325957==by 0x4B58048: ??? (in $rakudo/install/lib/libmoar.so)
> ==325957==by 0x1FFEFFFB5F: ???
> ==325957==by 0x4B57F81: dc_callvm_call_x64 (in
> $rakudo/install/lib/libmoar.so)
> ==325957==by 0x50BA1BF: ??? (in /usr/lib/libc-2.30.so)
> ==325957==by 0xA275E3F: ???
> ==325957==by 0x990153F: ???
> ==325957==by 0xA275E3F: ???
> ==325957==by 0x1FFEFFFB7F: ???
> ==325957==by 0x4B578D1: dcCallVoid (in
> $rakudo/install/lib/libmoar.so)
> ==325957== Address 0xb5ebf1a is 0 bytes after a block of size 1,994
> alloc'd
> ==325957==at 0x483AD7B: realloc (vg_replace_malloc.c:836)
> ==325957==by 0x4A9DFDF: expand.isra.3 (in
> $rakudo/install/lib/libmoar.so)
> ==325957==by 0x4A9E6F4: bind_pos (in
> $rakudo/install/lib/libmoar.so)
> ==325957==by 0x4A2C9AF: MVM_interp_run (in
> $rakudo/install/lib/libmoar.so)
> ==325957==by 0x4B2CC24: MVM_vm_run_file (in
> $rakudo/install/lib/libmoar.so)
> ==325957==by 0x109500: main (in $rakudo/install/bin/perl6-m)
>
> This is the NUL byte that happens to be there and terminate our string
> correctly, but nothing in the moarvm process has allocated it, because
> knowing what is allocated and what isn't is valgrind's job. And if it's
> not allocated, then either moarvm routinely writes NULs to memory it
> doesn't own or it simply does not automatically insert a NUL after the
> storage of every CArray[uint8]. And why would it? I for one would not
> expect CArray[uint8] to have special precautions built in for when it's
> used to hold a C string.
>
> Why does it work with a string literal in the Raku code? I don't know,
> but consider the following variations of the code, with my oldish Rakudo:
>
> - with $string = "X" x 1994: valgrind sad
> - with $string = "X" x 4:valgrind sad
> - with $string = "X" x 3:valgrind happy
> - with $string = "X" x 2:valgrind happy
> - with $string a short literal
> like "FOO":valgrind happy
> - with $string a literal of
> sufficient length like "FOOO": valgrind sad
> - with $string = "FOO" x 2: valgrind happy
> - with $string = "FOO" x 200:valgrind sad
>
> My guess is that if it's sufficiently small and easy, t
Re: Ping JJ: string literals
I know this is utterly and absolutely absurd, but so it goes. El vie., 17 ene. 2020 a las 23:28, ToddAndMargo () escribió: > Hi JJ, > > Please be my hero. > > I won't call you any goofy names out of > affection and friendship, as others will get > their nickers in a twist. > > This is from a previous conversation we had concerning > the mistake in > > https://docs.raku.org/language/nativecall#index-entry-nativecall > > my $string = "FOO"; > ... > my $array = CArray[uint8].new($string.encode.list); > > > Todd: > By the way, "C String" REQUIRES a nul at the end: > an error in the NativeCall documentation. > > JJ: > No, it does not. And even if it did, it should better > go to the C, not Raku, documentation > A C string literal is a C string. It automatically gets null terminated. I already mentioned this link https://stackoverflow.com/questions/8202897/null-terminated-string-in-c, but you don't seem to like and read links, so I copy the good bits here; "Is it absolutely necessary? *No*, because when you call scanf, strcpy(except for strncpy where you need to manually put zero if it exceeds the size), it copies the null terminator for you. Is it good to do it anyways? *Not really*, it doesn't really help the problem of bufferoverflow since those function will go over the size of the buffer anyways. Then what's the best way? use c++ with std::string." And another answer: "Always be careful to allocate enough memory with strings, compare the effects of the following lines of code: char s1[3] = "abc";char s2[4] = "abc";char s3[] = "abc"; All three are considered legal lines of code ( http://c-faq.com/ansi/nonstrings.htmlhttp://c-faq.com/ansi/nonstrings.html), but in the first case, there isn't enough memory for the fourth null-terminated character. s1 will not behave like a normal string, but s2 and s3 will. The compiler automatically count for s3, and you get four bytes of allocated memory. If you try to write " > > > And that would be a "String Literal", which is NOT > a C String. And C's documentation is precise and > clear (n1570). It is not their problem. It > is a mistake in NativeCall's documentation. > Did you really read what you wrote? A string literal is not a C string? And you want to add that to NativeCall documentation? You really seem to be driven by your need to prove you're right, than by a genuine wish to improve the documentation. Which I insist, is for Raku, not for C. > > Without the nul at the end, the string is considered > "undefined". > No, it's not. Please read the answer in StackOverflow above. If you use string literals and don't assign enough memory for the null termination, it's going to be undefined. That's the case for s1 above. Again, C stuff. There's enough work as it is now to document the finer points of Raku. Only with the "new" ( = 1 year old) 6.d Raku behavior, there're still almost 100 items to document. Document the finer points of C is totally outside the scope. Just read (maybe implicitly) at the beginning of NativeCall "Get your C right" and that's it. I'm not gonna go further than that. > > The C guys have been helping me with definitions. Chapter and > verse would be : > > INTERNATIONAL STANDARD ©ISO/IEC ISO/IEC 9899:201x > Programming languages — C > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf > > 5.2.1 Character sets > 7.1.1 Definitions of terms > 6.7.9,p14 Semantics > > Here is your String Literal, which you are confusing > with a c string: > > 6.7.9,p14 states: > > An array of character type may be initialized by a > character string literal or UTF−8 string literal, > optionally enclosed in braces. Successive bytes > of the string literal (including the terminating > null character if there is room or if the array > is of unknown size) initialize the elements of > the array. > > So there is the unnecessary nul you speak of, except, > again, it is not a C String. So you do have a > Are you _really_ saying we should put parts of the C standard in the Raku documentation? Again, did you read what you wrote? somewhat of a point, although not a good one as > it will throw those trying to use the docs into > a state of confusion wondering what is going wrong, > as it did me. > They should have read the (implicit) notice at the beginning of NativeCall: "Get your C right" > It about killed me to figure it our myself. I > don't want others to go through the same pain > over a simple mistake in the documentation. > Well, an omission has suddenly be converted into a mistake. And an example which is totally correct (as proven several times) too. We do live in curious times. (Also, I didn't write that) > Now the C guys told me that the reason why I am not > getting anywhere with you is that I provided a bad > example. They proceeded to give me an example > that precisely shows the careening make by > the mistake in the documentation: > > > An example
Re: Bug in the documentation
I already did. It's a rather nasty bug in the graph generation module. Will take some time. El mar., 14 ene. 2020 a las 18:16, ToddAndMargo () escribió: > > >> El lun., 13 ene. 2020 22:33, ToddAndMargo via perl6-users > >> mailto:perl6-us...@perl.org>> escribió: > >> > >> Hi All, > >> > >> https://docs.raku.org/type/UInt > >> > >> Type Graph > >> Type relations for 404 > >> > >> The chart is 404 missing > >> > >> To fix this, Raku can use the chart from > >> https://docs.perl6.org/type/UInt > >> https://docs.perl6.org/images/type-graph-UInt.svg > >> > >> Picky, Picky, Picky > >> > >> :-) > >> > >> -T > > > > On 2020-01-14 01:15, JJ Merelo wrote: > > I'd be grateful if you (or someone) raised this issue in the doc repo. > > > > Hi JJ, > > Off list: > > I have a rule against posting to that repo. > > I am so far behind in office work that I > can not waste one extra minute on posting > to a form that will NOT-A-BUG me. > > Do I have you word that you won't shoot me > down if I post this? > > -T > > > > -- JJ
Re: Bug in the documentation
I'd be grateful if you (or someone) raised this issue in the doc repo. El lun., 13 ene. 2020 22:33, ToddAndMargo via perl6-users < perl6-us...@perl.org> escribió: > Hi All, > > https://docs.raku.org/type/UInt > > Type Graph > Type relations for 404 > > The chart is 404 missing > > To fix this, Raku can use the chart from > https://docs.perl6.org/type/UInt > https://docs.perl6.org/images/type-graph-UInt.svg > > Picky, Picky, Picky > > :-) > > -T >
Re: Bug to report: cardinal called an integer
El mar., 14 ene. 2020 1:24, ToddAndMargo via perl6-users < perl6-us...@perl.org> escribió: > On 2020-01-13 15:16, Laurent Rosenfeld via perl6-users wrote: > > Your own record over the last years shows that you very often don't > > understand documentation (and I actually sometimes wonder whether you're > > even really interested in trying to understand it). > > Actually, I go there a lot and I tear my hair out. > They are the antithesis of how Perl 5 wrote their > documentation (the only part of Perl 5 I like better > than Perl 6). > Never miss a good chance to bash documentation... > > > Your disdain for the documentation just confirms that. > > The documentation needs work. Several involved in > the documentation process have mentioned this in > several places. It is not like it is a secret. > I have tried to contribute to it before, but I > can't get past JJ. > I, the sole gatekeeper of documentation lore, banish you from ever entering my realm. Vade retro! I mean, really... > > And why do you think I am constantly find errors > in the documentation. Because I ignore them? > > By the way, "C String" REQUIRES a nul at the end: > an error in the NativeCall documentation. > No, it does not. And even if it did, it should better go to the C, not Raku, documentation > > > > But since you > > also explained very clearly times and again in the past that you don't > > want to read books or tutorials either, I also wonder whether you're > > interested in learning the language. I mean, *really* interested, to the > > point of making *real* efforts in that direction. > > You have no idea what I go through. You will if > you ever get to see my paper on NativeCall and > Win API. > > > > The way you consistently mixed up uint and Uint in the last hours, > > despite having been warned about this mistake, also shows a lack of > > proper consideration for the documentation. > > Now that is a mystery to me. The documentation for UInt > does not mention uint. But UInt and uint act exactly > the same and have exactly the same properties. But > somehow they are different. Since you know more than > I about Raku, please teach me the different. > > Maybe I presume too much thinking this is yet another > error/oversight in the documentation. Neither UInt > or uint even show up on > > https://docs.raku.org/images/type-graph-Numeric.svg > > > > > > The way you obstinately use the word "cardinal" these last days also > > shows it, since there is simply no such thing as cardinals in the Raku > > types, subsets, or whatever, and, even though some languages have used > > it in the past (and, yes, I have also used Modula-2 in a quite distant > > past), "cardinal" is certainly NOT a common IT concept (I mean in the > > way integer, unsigned integer, or float are common concepts, often > > defined by CPU manufacturers). Granted, most people here probably have a > > good understanding of the word "cardinal," but it's essentially a math > > concept, and has no precise definition in a programming language, unless > > of course the programming language in question does define it, which > > Raku doesn't. Yes, cardinals may be loosely described as integers equal > > to or larger than zero, but that doesn't make a definition and that > > tells us nothing about their range or maximal value, or about the > > methods that can be invoked on them, and so on. > > "cardinal" is a generic arithmetic and programming term. > It does not denote how many bit or bytes or whose CPU > calls what. And it is only uncommon if you have not > heard it before. And with your programming experience, > you should know the difference between generic > programming terms and language specific terms. > > > So, please, stop using the word "cardinal,", which is just improper, > > useless and essentially meaningless in the context of thee Raku > > language. Please use the types, subsets and other concept properly > > defined in Raku. > > Look at what I write closely. When I use a generic term like cardinal, > I always put the Raku term in parenthesis. If > this is not understandable to others, then it is a technical > writing issue on my part, not an ignorance of the > specifics any programming language. > > I have been doing a lot with NativeCall and WinAPI > functions the last several weeks, so I have been > using a lot of generic terms and have had to learn C++ > terms the hard way and how they map to Raku types. > (This is all in my paper.) NativeCalls documentation > is almost, but not completely, useless. > > By the way DWORD is a form of cardinal and are best > emulated as uint16. You run into trouble with int16. > Did you notice that I said "form of a"? > > I do the same thing with the generic term "Pointer", which > by the way can mean a lot of things. Not all pointers > are C Pointers, such as Perl 5's "references", which is > what the parenthesis are for. So when you use the term > "Pointer" you have to say what kind of pointer your >
Re: LocalFree?
Which is what I told you twice as an answer to your question: https://stackoverflow.com/questions/59630605/does-rakus-nativecall-run-localfree. Also, documentation: https://docs.raku.org/language/nativecall#index-entry-nativecall "Call into dynamic libraries that follow the C calling convention" >From where it follows: NativeCall does not call anything for you, WinApi calls or otherwise. If what you do is call into dynamic libraries that follow the C calling convention, it will help you do that. Nothing more (and nothing less). JJ El jue., 9 ene. 2020 a las 7:41, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2020-01-08 22:03, ToddAndMargo via perl6-users wrote: > > On 2020-01-08 21:05, ToddAndMargo via perl6-users wrote: > >> Hi All, > >> > >> Does Raku's NativeCall run WinAPI's "LocalFree( )" after it creates > >> buffers? Or do I need to do it myself? > >> > >> > https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-localfree > >> > >> > >> Many thanks, > >> -T > > > > > > I am doing it anyway. It is not throwing an error. > > This may be a bug in NativeCall, resulting in a memory > > leak > > > Follow up: > > NativeCall does not close any WinApi call buffers, so > you need to do it yourself. > -- JJ
Re: Working at FOSDEM
I'll be arriving on the Saturday afternoon, could spend some time there. El vie., 3 ene. 2020 a las 15:43, Andrew Shitov () escribió: > Hi, > > On 1-2 Feb, I have secured a table at the FOSDEM exhibition area. > Unfortunately, I found nobody who confirmed they can help at the > location for at least 1/2 day. What needs to be done there is to talk > to people passing by and tell them about Raku and its advantages. > Please let me know if somebody wants to join. > > Regards > > -- > Andrew Shitov > __ > a...@shitov.ru | http://shitov.ru > -- JJ
Re: NativeCall Doc booboo
El mié., 1 ene. 2020 a las 19:57, ToddAndMargo ()
escribió:
> On 2020-01-01 01:58, JJ Merelo wrote:
>
>
>
> El mar., 31 dic. 2019 a las 21:56, ToddAndMargo via perl6-users (<
> perl6-us...@perl.org>) escribió:
>
>> On 2019-12-31 09:17, JJ Merelo wrote:
>> > Hi,
>> >
>> > El mar., 31 dic. 2019 a las 5:54, Todd Chester via perl6-users
>> > (mailto:perl6-us...@perl.org>>) escribió:
>> >
>> > Hi All,
>> >
>> >
>> https://docs.raku.org/language/nativecall.html#Passing_and_returning_values
>> >
>> > Did anyone else discover the mistake, hopefully not the hard way
>> like I
>> > did. Anyone get weird gibberish printed out like I did?
>> >
>> > my$string="FOO";
>> >
>> # The lifetime of this variable must be equal to the required lifetime of
>> > # the data passed to the C function.
>> > my$array=CArray[uint8].new($string.encode.list);v
>> >
>> > The mistake is that "C" strings are terminated by a chr(0) -- in
>> > "C" terms chr(0) is called a nul or 0x00.
>> >
>> > If you don't terminate your C string, the reading functions keep
>> > careening
>> > until it finds a chr(0). You have to tack a chr(0) onto the end.
>> >
>> > my$array=CArray[uint8].new($string.encode.list);
>> > $array [$array.elems] = 0;
>> >
>> > $array should be 70 79 70 0 not 70 79 79
>> > You can test this with `say "$array"` (include the quotes).
>> >
>> > Maybe JJ will pick up on this and get it fixed.
>> >
>> >
>> >
>> > I don't always read this list, but I do read issues. If you put it
>> > there, it will be definitely get addressed when possible.
>> >
>> > --
>> > JJ
>>
>>
>> Hi JJ,
>>
>> I have a rule about not posting to that list, so maybe
>>
>
> I could answer that with I will not address issues that are not raised in
> the GitHub repo (which is not a list, BTW), but anyway, here you go. The
> thing is, first, that the example has little to do with the structure of
> the string itself; it focuses on the fact that the string has to be
> encoded. But anyway, let's check if that is true, with this little example:
>
> -- >8 -- const-char.c --
> #include
>
> void set_foo ( const char *foo) {
> printf("%s", foo);
> }
> - 8< --
>
> And this Raku script that uses it
>
> -- >8 --- null-terminated-or-not.p6
> --
> use NativeCall;
>
> my $string = "FOO";
> my $array = CArray[uint8].new($string.encode.list);
> sub set_foo(CArray[uint8]) is native('const-char') { * }
> set_foo( $array );
> - 8< --
>
> This works without a glitch, printing FOO to the terminal. As a matter of
> fact, $array.elems returns 3, so its "encode" is not actually adding any
> null-termination at the end. I'm no expert in C myself, and have not been
> for at least 25 years. But I know stackoverflow, which says (
> https://stackoverflow.com/a/1253336/891440)
>
> Why do C strings work this way? It's because the PDP-7 microprocessor, on
> which UNIX and the C programming language were invented, had an ASCIZ
> string type. ASCIZ meant "ASCII with a Z (zero) at the end."
>
> Is this the only way to store strings? No, in fact, it's one of the worst
> ways to store strings. For non-trivial programs, APIs, operating systems,
> class libraries, you should avoid ASCIZ strings like the plague.
>
>
> Plagues are bad. Let's avoid them for the upcoming year. Other than that,
> happy new year to every one.
>
> --
> JJ
>
>
> Hi JJ,
>
> Wow, you spent a lot of time on that. Thank you!
>
> You are of course correct.
>
> The example works and that is the end of it. So no
> mistake to be addressed.
>
Well, it doesn't work as such. It's a non-working, but syntactically
correct, example. It works as illustration.
>
> You are a teacher. Would you have wrote that example
> with out addressing the nature of a "C" string and why
> it requires a nul at the end?
>
... which it does not ...
>
> You are a teacher. Would you have given an example that
> only worked in the example?
>
Well, I would have given an example about how to work with strings in the
section where it would really be useful
Re: NativeCall Doc booboo
El mar., 31 dic. 2019 a las 21:56, ToddAndMargo via perl6-users (<
perl6-us...@perl.org>) escribió:
> On 2019-12-31 09:17, JJ Merelo wrote:
> > Hi,
> >
> > El mar., 31 dic. 2019 a las 5:54, Todd Chester via perl6-users
> > (mailto:perl6-us...@perl.org>>) escribió:
> >
> > Hi All,
> >
> >
> https://docs.raku.org/language/nativecall.html#Passing_and_returning_values
> >
> > Did anyone else discover the mistake, hopefully not the hard way
> like I
> > did. Anyone get weird gibberish printed out like I did?
> >
> > my$string="FOO";
> >
> # The lifetime of this variable must be equal to the required lifetime of
> > # the data passed to the C function.
> > my$array=CArray[uint8].new($string.encode.list);v
> >
> > The mistake is that "C" strings are terminated by a chr(0) -- in
> > "C" terms chr(0) is called a nul or 0x00.
> >
> > If you don't terminate your C string, the reading functions keep
> > careening
> > until it finds a chr(0). You have to tack a chr(0) onto the end.
> >
> > my$array=CArray[uint8].new($string.encode.list);
> > $array [$array.elems] = 0;
> >
> > $array should be 70 79 70 0 not 70 79 79
> > You can test this with `say "$array"` (include the quotes).
> >
> > Maybe JJ will pick up on this and get it fixed.
> >
> >
> >
> > I don't always read this list, but I do read issues. If you put it
> > there, it will be definitely get addressed when possible.
> >
> > --
> > JJ
>
>
> Hi JJ,
>
> I have a rule about not posting to that list, so maybe
>
I could answer that with I will not address issues that are not raised in
the GitHub repo (which is not a list, BTW), but anyway, here you go. The
thing is, first, that the example has little to do with the structure of
the string itself; it focuses on the fact that the string has to be
encoded. But anyway, let's check if that is true, with this little example:
-- >8 -- const-char.c --
#include
void set_foo ( const char *foo) {
printf("%s", foo);
}
- 8< --
And this Raku script that uses it
-- >8 --- null-terminated-or-not.p6
--
use NativeCall;
my $string = "FOO";
my $array = CArray[uint8].new($string.encode.list);
sub set_foo(CArray[uint8]) is native('const-char') { * }
set_foo( $array );
- 8< --
This works without a glitch, printing FOO to the terminal. As a matter of
fact, $array.elems returns 3, so its "encode" is not actually adding any
null-termination at the end. I'm no expert in C myself, and have not been
for at least 25 years. But I know stackoverflow, which says (
https://stackoverflow.com/a/1253336/891440)
Why do C strings work this way? It's because the PDP-7 microprocessor, on
which UNIX and the C programming language were invented, had an ASCIZ
string type. ASCIZ meant "ASCII with a Z (zero) at the end."
Is this the only way to store strings? No, in fact, it's one of the worst
ways to store strings. For non-trivial programs, APIs, operating systems,
class libraries, you should avoid ASCIZ strings like the plague.
Plagues are bad. Let's avoid them for the upcoming year. Other than that,
happy new year to every one.
--
JJ
Re: NativeCall Doc booboo
Hi, El mar., 31 dic. 2019 a las 5:54, Todd Chester via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > https://docs.raku.org/language/nativecall.html#Passing_and_returning_values > > Did anyone else discover the mistake, hopefully not the hard way like I > did. Anyone get weird gibberish printed out like I did? > > my $string = "FOO"; > # The lifetime of this variable must be equal to the required lifetime of > # the data passed to the C function. > my $array = CArray[uint8].new($string.encode.list);v > > The mistake is that "C" strings are terminated by a chr(0) -- in > "C" terms chr(0) is called a nul or 0x00. > > If you don't terminate your C string, the reading functions keep careening > until it finds a chr(0). You have to tack a chr(0) onto the end. > > my $array = CArray[uint8].new($string.encode.list); > $array [$array.elems] = 0; > > $array should be 70 79 70 0 not 70 79 79 > You can test this with `say "$array"` (include the quotes). > > Maybe JJ will pick up on this and get it fixed. > I don't always read this list, but I do read issues. If you put it there, it will be definitely get addressed when possible. -- JJ
Re: modules and subsets
El mié., 11 dic. 2019 a las 18:54, JJ Merelo () escribió: > Subsets follow pretty much the same rules as every other declared thing. > Change subset by "variable" or "class", if the answer is true, it's also > true for subsets. > > By default, the scope of anything (containers, classes, whatever) is > lexical to the scope they are in. > Sorry, that's not true. Classes have package scope, not lexical scope, by default; that is, they are "our": https://docs.perl6.org/language/classtut Subsets... well I don't know. I would say they are package scoped by default, same as classes. JJ
Re: modules and subsets
Subsets follow pretty much the same rules as every other declared thing. Change subset by "variable" or "class", if the answer is true, it's also true for subsets. By default, the scope of anything (containers, classes, whatever) is lexical to the scope they are in. El mié., 11 dic. 2019 a las 18:48, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > If I create a subset in the global section of a module > (not inside a sub), can the subset be seen by the > main program? > > Can a subset be declared on a sub's declaration line? > (Hope springs eternal.) > > Many thanks, > -T > -- JJ
Re: A grand idea on the documentation
El lun., 9 dic. 2019 a las 11:26, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2019-12-09 01:52, JJ Merelo wrote: > > > > > > El lun., 9 dic. 2019 a las 10:34, ToddAndMargo via perl6-users > > (mailto:perl6-us...@perl.org>>) escribió: > > > > On 2019-12-09 00:33, JJ Merelo wrote: > > > The Raku community has got a community documentation. It's called > > the > > > official documentation, and it's done by the community. You want > to > > > write your own and help yourself and maybe others, there're lots > lof > > > places you can do that: dev.to <http://dev.to> <http://dev.to>, > > Medium, your own blog. > > > Even the "official" Raku Advent Calendar or your very own. > > > > > > Spoken by a true guard dog! :-) > > > > > > If I'm a dog, I choose to be a Lab. Mr. Peanutbutter Lab, if anyone asks. > > > > > > I am speaking of a way to possibly get everyone in > > on the act. And make it official to the Raku site. > > > > > > You mean, as in an "official documentation"? Well, there's this thing > > unimaginatively called "official documentation" at > > https://docs.raku.org. Lots of people are volunteering to make it > better > > every single day. It's not everything to everyone, and it can't possibly > > be. But there are other places you can look at, like tutorials, and the > > whole wide Internet. To which you can contribute, if you so like. > > > > Cheers > > > > JJ > > > > > JJ, > > The "Community" you speak of it a collection of extremely > brilliant programmers. I will call them the "Community > of Developers". They are badly overworked and have > prioritized what they can volunteer for. Because > of this, the documentation takes are real hit: its > would make a cryptologist blush and the IEEE extremely > proud. > As an ACM member, I take offense at this. And I'm not really going to answer to the rest. It's simply not true. You don't understand lots of things that are there, fair enough. You don't need to. I always tell my students: "keep trying, and ask around when you're lost". They never, however, convert their inability in understanding something in a judgment on the quality of the material used for learning, which has probably been evolved through generations of other fellow students, so it's as good as it needs to be. You don't want to learn through the documentation, again, fair enough. Use StackOverflow, books, whatever. Your call. I get the documentation needs improvement. There are ~300 issues that need to be solved. We do what we can. But let's not throw the baby with the bathwater. Let's keep improving the official documentation, and let's try to make it as good as possible for the majority of developers out there. > Your job as a Peanutbutter Lab (junkyard dog) is to > protect them from frivolous input from the likes of, > well, me. > > No, it's not. I simply tried to direct you to raise an issue to where it would actually be heard by the people that maintain that. You don't want to listen, your call. But check if it's done any good in the first place you raised the issue, or where it was moved. You don't want to listen to what I said, you want stuff your way or the highway. Fair enough, I'll not try to help you again. But if nobody answers your issue which you want to do your own way (for instance, proposing "solutions" in a mailing list instead of raising issues in the specific places where they can be addressed), don't say we didn't warn you. The community I am speaking of is the the rest of us, > which I will call the Rakoons. This does include the > "Community of Developers" but mainly its includes all > Raku programmers interested in making Raku's documentation > better. > The rest of us (remember, we weren't born working with the documentation) do not want you to speak for, well, the rest of us. We all have a voice, and we also listen to everyone. We don't want anyone, however, to speak for us. So please don't do that. > And it included a request list, so things would be > prioritized by need. You might even have an automatic > mailing go our to Rakoon volunteers to pick up such > requests. > As in, say, the automatic email everyone in the Raku team gets when anyone raises an issue in any of the repositories? > My Grand Idea would be a real boom for us Rakoons. > No, it wouldn't, and it will not. You want to publish your "keepers" which are much better than the documentation, by all means do that. Speak for yourself, not for others. Cheers JJ
Re: Fwd: Raku, docs, help [was: Re: vulgar?]
El lun., 9 dic. 2019 a las 2:48, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2019-12-07 08:17, Philip Hazelden wrote: > > This is not IEEE-ese. Earlier, you defined IEEE-ese as > > > > Technical written material that uses so many obscure > > terms and unnecessary technical jargon mixed with > > deliberate obscurities that even a reader with > > intimate knowledge of the subject are confused. > > Example: read any published paper from IEEE. > > > > That is, IEEE-ese uses technical jargon *unnecessarily*. By contrast, > > what you quoted is simply using technical jargon *clearly and > > precisely*. (It does have a typo, the word "to" is missing between > > "invocant" and "Str"; and "Str.contains" links to the wrong anchor in > > the page.) It can probably be hard to tell the difference, if you aren't > > familiar with the technical jargon in question. But in this case, if you > > know what an "invocant" is, and what it means to "coerce" something, and > > to "call" a method, then the meaning is clear; and in fact, the way it > > was written seems like the obvious way to write it. > > > > If you don't know what those words mean, then the meaning won't be > > clear. (But even then, clicking the link on "Str.contains" and glancing > > down that page a little should give you some hints.) Perhaps, to make it > > easier for you to understand, the docs could stop using words like > > "invocant" and "coerce". But that makes it *harder* for people who do > > understand these words, because those people then have to read more > > words and translate them into their precise understanding. > > > > Perhaps it can be rewritten to make it clearer for people who don't know > > the jargon while not losing concision or expressiveness for people who > > do. But that's not necessarily an easy thing to do; and someone who > > doesn't know the jargon is unlikely to do it well. > > > > As for `|c`, that's part of the type signature. For people who can read > > type signatures, glancing at the type signature of a method can be much > > easier than reading a possible-imprecise description of how to use it. > > If you can't read type signatures, you're out of luck; but that's no > > reason to hide them from people who can. If you type `|` into the search > > box, there's an entry under "Reference" named "| (parameter)" (which > > admittedly also links to the wrong anchor in the page), and another > > under "Syntax" simply named "|", and either one of those will (with > > perhaps a bit more reading and following links) take you to > > https://docs.raku.org/type/Signature#Capture_parameters which describes > > what it does. > > Hi Phillip, > > Have you ever been to an IEEE seminar and attended a lecture > on a subject that you have intimate knowledge on hoping > to pick up some additional tips. In the lecture you keep > shaking your head saying to yourself "What, Huh? What > the Heck?". After the lecture you ask yourself why you > wasted both your time and your money? And here is the thing, > They are doing exactly what you stated are "cleanly and precisely" done. > These lecture are painstakingly peer > reviewed. So why can't you figure out what the heck is > going on and you KNOW THE SUBJECT? This is IEEE-eese. > > Now back to "contains". "method contains(Cool:D: |c)" > is not correct. It is missing the "$pos --> Bool" which > Those changes were made two months ago in this commit: https://github.com/rakudo/rakudo/commit/696eea2de6e67135b3b574ecb579ede16045ede6 We can't possible keep up with changes, even more so if those who notice the changes just keep it to themselves. We're still trying to reflect all changes that were made for the 6.d release a year ago. Other than that, it's clear from the context that it returns a Boolean, and concepts like signatures or the meaning of sigils can't be explained in every single place they appear. They can't even be linked, because they are not mentioned. In the definition of a method or sub, you're supposed to know a series of things: what's a method, what's a signature, and there are helpful reference and tutorial pages for that. Cheers JJ
Re: A grand idea on the documentation
El lun., 9 dic. 2019 a las 10:34, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2019-12-09 00:33, JJ Merelo wrote: > > The Raku community has got a community documentation. It's called the > > official documentation, and it's done by the community. You want to > > write your own and help yourself and maybe others, there're lots lof > > places you can do that: dev.to <http://dev.to>, Medium, your own blog. > > Even the "official" Raku Advent Calendar or your very own. > > > Spoken by a true guard dog! :-) > If I'm a dog, I choose to be a Lab. Mr. Peanutbutter Lab, if anyone asks. > > I am speaking of a way to possibly get everyone in > on the act. And make it official to the Raku site. > You mean, as in an "official documentation"? Well, there's this thing unimaginatively called "official documentation" at https://docs.raku.org. Lots of people are volunteering to make it better every single day. It's not everything to everyone, and it can't possibly be. But there are other places you can look at, like tutorials, and the whole wide Internet. To which you can contribute, if you so like. Cheers JJ
Re: A grand idea on the documentation
The Raku community has got a community documentation. It's called the official documentation, and it's done by the community. You want to write your own and help yourself and maybe others, there're lots lof places you can do that: dev.to, Medium, your own blog. Even the "official" Raku Advent Calendar or your very own. El lun., 9 dic. 2019 a las 3:16, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > I have a "grand idea" on how to fix up the documentation > I would like to pitch to the community: > > Raku's documentation is pretty much unusable for > newbies and regular users do to its culture: > IEEE-eese like "method contains(Cool:D: |c)" > and so on and so forth. Sometimes a usable > example sneaks through. It is targeted at > the wrong audience. > > It has been pointed out that the reason why Perl 5's > perldocs is so much better done that Raku's is that > Perl 5 has some industry funding behind it and > Raku is a volunteer effort. > > To cope with such, I write my own keepers on > various parts of Raku. I have posted a couple > of them here. I am up to 190 of them now. > > So here is my idea. Since this is a volunteer effort, > lets not loose the value of my own 190 notes and > everyone else's contributions as well. > > Lets create our own community documentation Wikipedia. > > Make it so any Raku user can wax eloquent on any > part of the documentation. Have it peer reviewed for > accuracy and content, and then published for all > to use. > > This would shut me up complaining about the IEEE-eese > and give me and other a chance to contribute on > a major scale. A true community effort. > > And, chuckle, keep the guard dog constructively > employed, instead of coming up his a bazillions > way to say (put to music) "no, No, NO, no no no, > NOT A BUG, NOT OUR PROBLEM, no no no, I don't > think this applies". > > Given time, we could have some awesome documentation! > And it would be all in one place, not spread out all > over the Internet. It would be something we could all > take pride in. > > And those versed in the IEEE-eese can still use > the original documentation. > > -T > -- JJ
Re: looking for good project to learn perl6
Spark is a platform for stream processing, mainly. Tensorflow is a framework for machine learning. It's now open source, although Google calls the shots. I don't think they're pulling the plug here. It's open source, you can always fork. El dom., 8 dic. 2019 a las 18:52, Tom Browder () escribió: > On Sun, Dec 8, 2019 at 10:38 AM Fernando Santagata > wrote: > > > > Hello, > > I started writing a raw interface to Tensorflow, but I stopped for > various reasons [¹]. If anyone wants to work on it I can help and/or share > what I've produced so far. > > > > [¹] three main reasons: > ... > > Fernando, I'm on board with you on all three! > > But doesn't the Apache Group have something similar that could be a > killer app without as much angst: Spark? > > See also: > > 1. > https://dzone.com/articles/the-complete-apache-spark-collection-tutorials-and?edition=549292_source=Weekly%20Digest_medium=email_campaign=Weekly%20Digest%202019-12-04 > > 2. https://www.educba.com/tensorflow-alternatives/ > > Best regards, > > -Tom > -- JJ
Re: Perl6 vs Julia
El dom., 8 dic. 2019 a las 12:10, Tom Blackwood () escribió: > Thanks JJ. > We know Perl has PDL for data science, > http://pdl.perl.org/ > > We are looking into it and see if it's possible to make a Perl6 version of > Scikit-learn based on PDL. > That would be really great. JJ
Advent Calendar
Hi, As you probably know, we're publishing a Raku-related article every single day until Christmas; https://rakuadventcalendar.wordpress.com. Check it out, spread the word. Also, the slot for the 23 of December is still free. Anyone willing to take it up? https://github.com/Raku/advent/blob/master/raku-advent-2019/schedule Cheers -- JJ
Re: Perl6 vs Julia
It might have been, but syntax is more Python-like to the point that in some cases it's exactly the same. It's got a very extensive macro systems, which enables it to work concurrently, for instance. It's more scientific-computing oriented, which means that there are all sort of mathematical modules for it, and not so many for web, databases, or things like that. El dom., 8 dic. 2019 a las 4:38, Tom Blackwood () escribió: > Hello > > How do you think of Julia language? > > https://en.wikipedia.org/wiki/Julia_(programming_language) > > It says it is also influenced by perl language. > > Regards > -- JJ
Re: looking for good project to learn perl6
As a matter of fact, there are very few data-processing libraries in Raku. Dealing with big files, stream processing, anything related to AI or machine learning would be great. There are very few neural nets implemented, for instance, and no convolutional or GAN or other popular algorithms like XGBOOST. Cheers El dom., 8 dic. 2019 a las 4:22, Tom Blackwood () escribió: > Hello William, > > We are actually a small team making the primary job for big data/machine > learning etc. > We know nothing about mailing list gateway and NNTP stuff. > But thanks for your suggestion, I will take a took at the references you > provided. > > Regards > Tom > > > On Sun, Dec 8, 2019 at 3:30 AM William Michels > wrote: > >> Hi Tom, >> >> My vote would be for someone to take on the task of writing >> "mailing-list" software in Raku/Perl6, and/or writing >> "mailing-list-archiving" software (e.g. an NNTP server) in Raku/Perl6. >> First of all, for your group this would be a relatively-high profile >> project, with the potential for hundreds or even thousands of >> companies adopting such a module for their own institutional or >> company needs. >> >> Regarding the "archiving" module in particular, you could see how the >> Perl mailing lists are archived, and easily imagine how they might be >> improved. There would be a need to access data from a database, filter >> out spam, organize the data by date and/or thread, and serve up the >> data in a web-accessible format. Selfishly, I would love to see a >> searchable archive of every Perl6/Raku email ever written. >> >> I've communicated with Ask Bjorn Hansen about the Perl software >> presently running the NNTP archive (www.nntp.perl.org), in particular >> the Perl6-Users mailing list. Ask Bjorn Hansen says the NNTP archive >> runs on Colobus which is written in Perl, with commits going all the >> way back to 2001. So why not rewrite it in Raku/Perl6?? In particular, >> I was hoping to see a better "subject threading" algorithm, since with >> Colobus (on occasion) emails from different "eras" are lumped together >> in the same thread (example: emails from 2010 showing up in Sept. 2019 >> threads). >> >> I don't know if your group has an interest in writing a full-blown >> NNTP server, but below are resources for Raku/Perl6, Python, and R. >> You can decide for yourself if the Raku/Perl6 resources need >> improving: >> >> Raku/Perl6: >> https://www.nntp.perl.org/group/ >> https://www.nntp.perl.org/group/perl.perl6.users/ >> https://trainedmonkey.com/projects/colobus/ >> https://github.com/abh/colobus >> >> Python: >> https://www.python.org/community/lists/ >> https://mail.python.org/archives/ >> https://mail.python.org/mailman/listinfo >> >> R: >> https://www.r-project.org/mail.html >> https://stat.ethz.ch/mailman/listinfo >> https://r.789695.n4.nabble.com >> >> >> HTH, Bill. >> >> >> >> On Fri, Dec 6, 2019 at 1:59 AM Tom Blackwood >> wrote: >> > >> > Thanks, I'll check it out! >> > >> > On Fri, Dec 6, 2019 at 5:50 PM JJ Merelo wrote: >> >> >> >> Try something in the most wanted repo: >> https://github.com/perl6/perl6-most-wanted/blob/master/most-wanted/modules.md >> That way you will learn _and_ help the community. >> >> >> >> El vie., 6 dic. 2019 a las 8:11, Tom Blackwood () >> escribió: >> >>> >> >>> Hello >> >>> >> >>> My team most time developed with ruby language. >> >>> These recent days we took time reading the book Learning Perl 6. >> >>> Then we consider to take an actual project to learn more deeply. >> >>> What project do you suggest for us to get involve into? >> >>> >> >>> Regards, >> >>> Tom >> >> >> >> >> >> >> >> -- >> >> JJ >> > -- JJ
Re: Fwd: Raku, docs, help [was: Re: vulgar?]
El sáb., 7 dic. 2019 a las 17:24, Philip Hazelden (< philip.hazel...@gmail.com>) escribió: > On Sat, Dec 7, 2019 at 12:04 PM ToddAndMargo via perl6-users < > perl6-us...@perl.org> wrote: > >> On 2019-12-07 03:00, Tom Browder wrote: >> > Forgot to reply to all. >> > >> > -- Forwarded message - >> > From: *Tom Browder* > tom.brow...@gmail.com>> >> > Date: Sat, Dec 7, 2019 at 04:58 >> > Subject: Raku, docs, help [was: Re: vulgar?] >> > To: ToddAndMargo mailto:toddandma...@zoho.com>> >> > >> > >> > On Fri, Dec 6, 2019 at 23:23 ToddAndMargo via perl6-users >> > mailto:perl6-us...@perl.org>> wrote: >> > >> > On 2019-12-06 18:34, Tom Browder wrote: >> > > On Fri, Dec 6, 2019 at 17:31 ToddAndMargo via perl6-users >> > > mailto:perl6-us...@perl.org>> wrote: >> > >> >> > >> On 2019-12-06 04:19, Tom Browder wrote: >> > >> > >> > Todd, I was a bit harsh in my last reply, but I do see a huge >> difference >> > between a bug report and a PR. In the PR, you have to show exactly what >> > the wording should be in its entire context, while in the bug report >> > your suggestions are less in context. To me, that automatically >> > increases the friction in the conversation. >> > >> > Some other points about help via comms other than email that are >> > valuable to me: >> > >> > 1. when using IRC, it is easy to put chunks of real code into a Github >> > gist. That way everyone can see it and discuss it by line number or >> > other reference >> > >> > 2. on the #raku channels, there is a built-in REPL so all can see your >> > code chunks in action >> > >> > Finally, I really don't have any more good arguments about your >> > discontent with the docs, but I leave you with these words about my >> > experience here: >> > >> > Any help you can contribute to the docs will usually be greatly >> > appreciated, but you are better off to start in small bits, correcting >> > typos, improving grammar, etc. >> > And I agree with you that much of the descriptions are in "IEEE-ese." >> To >> > help with that I have added several "cookbook" examples in such areas, >> > as much to help me as to help others. Given the way I've seen you >> > operate I think that adding better examples from your "keepers" would >> be >> > very useful. >> > > Merry Christmas! >> > >> > -Tom >> > >> > P.S. One more thing about Perl vs. Raku docs: I believe over the years >> > there has been much money applied to the Perl infrastructure by >> > commercial users of Perl, especially in the early days of the Internet. >> > On the other hand, I believe Raku has had comparatively little >> > commercial support and has had to rely on those unpaid people who love >> > the language and its community and who freely donate their time to its >> > improvement. It can only get better, but maybe not with quite as steep >> a >> > growth curve as Perl has had. >> >> Hi Tom, >> >> Seems I was a bit blunt with my criticism of the docs and >> hurt a lot of feelings. >> >> Perl 5's docs are a good example of Kaisen (constant change) >> as is the Linux kernel and Fedora. Raku itself is also >> a masterpiece of Kaisen too. The docs are not though, but >> maybe they will catch up in the future. Probably the >> developers are too busy doing their magic (that was >> a compliment -- not one get their nickers in a twist). >> >> What would be nice is if there was place to put suggestions >> as to improvements to the docs. >> >> Guys like me a perfect for such as we do not know what >> it is suppose to say and don't see what we expect to see. >> >> An example of IEEE-eese would be >> https://docs.raku.org/routine/contains >> >> method contains(Cool:D: |c) >> >> And >> >> Coerces the invocant Str, and calls Str.contains >> on it. Please refer to that version of the method >> for arguments and general syntax. >> >> Must win the IEEE-eese award for the week. I have no >> idea what was just said. What the dickens is `|c` >> anyway? >> > > This is not IEEE-ese. Earlier, you defined IEEE-ese as > > Technical written material that uses so many obscure > terms and unnecessary technical jargon mixed with > deliberate obscurities that even a reader with > intimate knowledge of the subject are confused. > Example: read any published paper from IEEE. > > That is, IEEE-ese uses technical jargon *unnecessarily*. By contrast, what > you quoted is simply using technical jargon *clearly and precisely*. (It > does have a typo, the word "to" is missing between "invocant" and "Str"; > and "Str.contains" links to the wrong anchor in the page.) It can probably > be hard to tell the difference, if you aren't familiar with the technical > Created issue 3112 https://github.com/Raku/doc/issues/3112, fixed and redeployed. Thanks for the report. https://docs.raku.org/routine/contains Cheers JJ
Re: My keeper on hashes
El vie., 6 dic. 2019 a las 11:46, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Hi All, > > My favorite variable is the associative array (hash). I finally updated > my keeper file on them. > > If anyone is interested, here goes! > > -T > > > Perl 6 Hashes (associative arrays): > > References: > https://docs.perl6.org/language/subscripts#Basics > https://docs.perl6.org/type/Hash#:exists > > > Please use the new URLs, those are deprecated, are no longer updated, and might stop working without prior notice: https://docs.raku.org/language/subscripts#Basics https://docs.raku.org/type/Hash#:exists Cheers JJ
Re: looking for good project to learn perl6
Try something in the most wanted repo: https://github.com/perl6/perl6-most-wanted/blob/master/most-wanted/modules.md That way you will learn _and_ help the community. El vie., 6 dic. 2019 a las 8:11, Tom Blackwood () escribió: > Hello > > My team most time developed with ruby language. > These recent days we took time reading the book Learning Perl 6. > Then we consider to take an actual project to learn more deeply. > What project do you suggest for us to get involve into? > > Regards, > Tom > -- JJ
Re: restricted value passed to a sub question
El mié., 4 dic. 2019 a las 11:06, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 2019-12-04 01:44, William Michels via perl6-users wrote: > > Hi Todd, > > > > Chapter 9 (Associatives) of "Learning Perl 6" by brian d foy has a > > section on Maps, "the immutable mapping of zero or more keys to > > values". In that section there are subsections entitled 'Checking > > Keys', 'Creating from a Positional' and 'Checking Allowed Values.' > > > > HTH, Bill. > > > > On Wed, Dec 4, 2019 at 12:41 AM ToddAndMargo via perl6-users > > wrote: > >> > >> Hi All, > >> > >> I am cooking up something where I want top pass a value to a sub, but I > >> want to restrict what those values are. > >> > >> For instance, things like > >> > >> AbortRetryIgnore > >> CancelRetryContinue > >> Help > >> YesNo > >> Maybe > >> > >> And so on and so forth. > >> > >> If the wrong value is passed, I want the checker to crash > >> the sub. > >> > >> What is the best way of going about this? > >> > >> Many thanks, > >> -T > > Hi Bill, > > I can't have books in my house. It is along story. > > But, based on what you said, I found this; > > https://docs.perl6.org/type/Map.html Please use this now: https://docs.raku.org/type/Map.html (also, we should probably move the deprecation notice from the footer to the header...) JJ
Re: Rakudo Star 2019.07.1
Thanks a lot, Patrick. El mar., 5 nov. 2019 a las 14:28, Patrick Spek via perl6-users (< perl6-us...@perl.org>) escribió: > Hello everyone, > > I've seen people ask about 2019.07.1 in multiple avenues, myself > included. Since there was little response, I've set out to build it > myself. The first results have been made, with a PR on the Rakudo Star > repository to fix a number of issues. > > Additionally, I've uploaded the 2019.07.1 tarball to my servers for > people to test[1]. Those looking for a newer version can download this > variant, and see if it works for them. If anyone spots any issues, > please let me know, either through this mailing list, the GitHub > repository[2] or the GitLab repository[3]. I'm trying to track all of > these places, and try to resolve all issues people find. > > I plan to also release a 2019.10 version of Rakudo Star before the end > of this year, but whether that's viable depends on the number of > severity of the issues people may find. > > I hope we can continue the Rakudo Star releases on a regular basis in > 2020! > > [1]: https://dist.tyil.nl/raku/rakudo-star/ > [2]: https://github.com/rakudo/star > [3]: https://gitlab.com/tyil/rakudo-star/ > > -- > With kind regards, > > Patrick Spek > > > www: https://www.tyil.nl/ > mail: p.s...@tyil.nl > pgp: 1660 F6A2 DFA7 5347 322A 4DC0 7A6A C285 E2D9 8827 > > social: https://soc.fglt.nl/tyil > git:https://gitlab.com/tyil/ > -- JJ
Re: FC31 can't find my module subs
El lun., 4 nov. 2019 a las 8:35, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > > Problem still occurs with selinux disabled > > selinux operates at a higher level. This is plain and simple not having the write bit set for your particular user. Anyway, try this (as a regular user) * Create a META6.json metadata file for every module, or a bunch of them, using the classic module layout (in a lib/ directory from root). That is /-- META6.json lib/ MyModule.pm6 Make sure that MyModule.p6 is actually declared that way. * zef test . (always a good idea too, including writing those self same tests) * zef install . (zef will run tests too, so you double check). That's the advised way to proceed always when you're developing a module. Once installed, you can use your modules from anywhere and, since they are in the default location, no need to use lib or -I. BTW, that's clearly specified in the official documentation for modules https://docs.raku.org/language/modules -- JJ
Re: FC31 can't find my module subs
El lun., 4 nov. 2019 a las 8:52, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > On 11/3/19 11:31 PM, JJ Merelo wrote: > > Again, running stuff and installing it as root is never a good idea > > > Most of my programs are for system administration and I have > no choice but to run them as root. > You don't have to _develop_ them as root, though. Development, and everything related to it, up to and including the version of the language you're using, should never be done with root privileges. -- JJ
Re: FC31 can't find my module subs
Again, running stuff and installing it as root is never a good idea. It's not a good idea either to dump your modules in a directory, the proper way to do that is through zef install, running as a non-privileged user. The privileges of the .precomp directory might be one thing, but there might be other at work here. El lun., 4 nov. 2019 a las 8:22, ToddAndMargo via perl6-users (< perl6-us...@perl.org>) escribió: > Oh and it does find and read the modules. If I > give it a bad module name, I get the finger wagged > at me: > > # perl6 -I/home/linuxutil/p6lib -e 'use BadName; ModuleTest; ModuleTst;' > ===SORRY!=== > Could not find BadName at line 1 in: > file#/home/linuxutil/p6lib > inst#/root/.perl6 > inst#/opt/rakudo-pkg/share/perl6/site > inst#/opt/rakudo-pkg/share/perl6/vendor > inst#/opt/rakudo-pkg/share/perl6/core > ap# > nqp# > perl5# > > > As opposed to something it can find: > > # perl6 -I/home/linuxutil/p6lib -e 'use ModuleTest; ModuleTest; > ModuleTst;' > ===SORRY!=== Error while compiling /home/linuxutil/p6lib/ModuleTest.pm6 > (ModuleTest) > Undeclared name: > ModuleTest used at line 4 > -- JJ
Re: FC31 can't find my module subs
The only thing I can think of is not having permission to write in that directory or in the directory you're running your program. In that case, perl6 will not be able to create a .precomp hidden directory, and that might result in what you're seeing. I see your modules are installed as root, which is probably not a good idea. if you're running your program as tony, you don't have write permission in /home/linuxutil/p6lib/ (as seen in the directory), and that might result in the eventual error you're seeing. Just chown -R tony /home/linuxutil/p6lib and that should work. JJ
Re: FC31 can't find my module subs
What's the content of /home/linuxutil/p6lib?
El lun., 4 nov. 2019 a las 6:48, ToddAndMargo via perl6-users (<
perl6-us...@perl.org>) escribió:
> On 11/3/19 6:56 PM, ToddAndMargo via perl6-users wrote:
> > On 11/3/19 3:15 PM, ToddAndMargo via perl6-users wrote:
> >> Hi All,
> >>
> >> Help!
> >>
> >> I just upgraded Fedora from 30 to 31.
> >>
> >> I upgraded to rakudo-pkg-Fedora31-2019.07.1-03.x86_64.rpm
> >> from https://github.com/nxadm/rakudo-pkg/releases
> >>
> >> Now P6 can not find my subs inside my modules:
> >>
> >> # perl6 -I/home/linuxutil/p6lib -MPrintColors -e 'PrintGreen( "Hi\n" );'
> >> ===SORRY!=== Error while compiling -e
> >> Undeclared name:
> >> PrintGreen used at line 1
> >>
> >> [editorial comment] HHH! [/editorial comment]
> >>
> >> The stock "rakudo" and "rakudo-zef" that resides in the
> >> Fedora repo's has the same issue.
> >>
> >> Many thanks,
> >> -T
> >
> >
> > I am hamstrung on so may fronts if I don't get this working!
> >
> > I gets uglier:
> >
> > # cat p6lib/ModuleTest.pm6
> > sub ModuleTest() is export( :ModuleTest ) { say "Hi"; }
> > sub ModuleTst() is export( :ModuleTst ) { say "Bye"; }
> >
> >
> > # perl6 -I./p6lib -e 'use ModuleTest :ModuleTest :ModuleTst; ModuleTest;
> > ModuleTst;'
> >
> > ===SORRY!=== Error while compiling -e
> > Undeclared name:
> > ModuleTst used at line 1
> >
> >
> > And way uglier. I removed the ":"
> > # cat p6lib/ModuleTest.pm6
> >
> > # sub ModuleTest() is export( :ModuleTest ) { say "Hi"; }
> > # sub ModuleTst() is export( :ModuleTst ) { say "Bye"; }
> > sub ModuleTest() is export( ModuleTest ) { say "Hi"; }
> > sub ModuleTst() is export( ModuleTst ) { say "Bye"; }
> >
> >
> > # perl6 -I/home/linuxutil/p6lib -e 'use ModuleTest; ModuleTest;
> > ModuleTst;'
> > ===SORRY!=== Error while compiling /home/linuxutil/p6lib/ModuleTest.pm6
> > (ModuleTest)
> > Undeclared name:
> > ModuleTest used at line 4
> >
> > And, And, depending on the position of the moon overhead,
> > sometimes it works.AAAHHH!
>
>
> I just reproduced this problem on a fresh Fedora 31
> virtual machine that has never before been touched by
> perl6 (rakudo)
>
--
JJ
Re: Perl6 -> Raku? whats the scope?
El mar., 15 oct. 2019 a las 17:49, Andrew Shitov () escribió: > > The coming weeks / months / years, the name "Perl 6" will be replaced by > "Raku". > > To my opinion, should be done before this year's Christmas. At least > everything that can be done by the "Perl 6 team" (whatever it is). > It's a bunch of volunteers doing stuff as fast as they possible can. Any help is obviously welcome. JJ
Re: Perl6 -> Raku? whats the scope?
There's no such thing as a Raku blog, so I am not sure where the official renaming should go. Closest thing is Liz's Raku weekly, I guess... El mar., 15 oct. 2019 a las 17:47, Andrew Shitov () escribió: > Hi, > > Here's what Larry Wall said: > > https://github.com/perl6/problem-solving/pull/89?fbclid=IwAR2rrjkuKJTWBPX6bobZTfeSj4VePT9HmEsunlLtD_XeP9g06RFsk-y0kHw#pullrequestreview-300789072 > > For me, there can be no other "official" announcement. The new name is > Raku. > > On Tue, Oct 15, 2019 at 5:43 PM N6Ghost wrote: > >> Starting to see posts, as if the decision was made already but have not >> see any offical >> post anywhere, i can find. everything seems to flow from a thread on >> github somehwere >> anyone know anything on the rename? is it "Raku" ? >> >> -N6Ghost >> > > > -- > Andrew Shitov > __ > a...@shitov.ru | http://shitov.ru > -- JJ
Re: perl6's new name?
Hi, El lun., 12 ago. 2019 a las 8:15, Eliza () escribió: > Hello perl6 world, > > I saw the perl6 github issue, just was confused will perl6 change its name? > Yes, it might. Perl 6 will still be the language, but the implementation (the stack including MoarVM, NQP and Rakudo) will be called Camelia. That's the proposal, needs to be approved (or rejected). Cheers JJ
Re: DEPRECATED routine
Thanks! El lun., 5 ago. 2019 a las 12:50, Marcel Timmerman () escribió: > @JJ Merelo, > > I filed an the issue: 'extending the documentation of DEPRECATED #2938' > > -- JJ
Re: DEPRECATED routine
Still, it's better to mention it in the documentation with all possible
caveats. I'd appreciate if you opened an issue, linking this question.
El dom., 4 ago. 2019 a las 14:20, Marcel Timmerman ()
escribió:
> Hi all,
>
> Studying GTK::Simple if found about the existence of a routine
> DEPRECATED which I couldn't find in the Perl6 documents. Reading from
> the code I see that it needs 3 arguments, start version of deprecation,
> version when it is removed and a string like in the 'is DEPRECATED()'
> trait.
>
> A use like
>
> sub gtk_builder_add_from_file ( ... ) {
>DEPRECATED(
> 'other multi version of gtk_builder_add_from_file', '0.17.10',
> '0.20.0'
>);
>...
> }
>
>
> Gives a result like;
>
> Saw 1 occurrence of deprecated code.
>
>
> Sub gtk_builder_add_from_file (from Gnome::Gtk3::Builder) seen at:
> /home/marcel/Languages/Perl6/Projects/perl6-gnome-gtk3/../perl6-gnome-native/lib/Gnome/N/X.pm6
>
> (Gnome::N::X), line 109
> Deprecated since v0.17.10, will be removed with release v0.20.0!
> Please use other version of gtk_builder_add_from_file instead.
>
> Perhaps it should be added to the docs (or I am look in the wrong spot :-)
>
> Thanks very much for the documentation as it is now
> Regards,
> Marcel
>
--
JJ
Re: module availability problem
Just the former is available:
ID|From |Package|Description
0 |Zef::Repository::Ecosystems|Gnome::Gdk3:ver<0.14.5>|Perl6 Gnome
gdk api, Please install Gnome::Gtk3
1 |Zef::Repository::Ecosystems|Gnome::Gdk3:ver<0.14.5>|Perl6 Gnome
gdk api, Please install Gnome::Gtk3
2 |Zef::Repository::Ecosystems|Gnome::Gdk3:ver<0.14.6>|Perl6 Gnome
gdk api, Please install Gnome::Gtk3
The one in modules.perl6.org is correctly listed with the 0.17.4
version.But there was a problem when indexing:
---
{
"authors": [
"Marcel Timmerman"
],
"build-depends": [
],
"depends": [
"Gnome::N",
"Gnome::Glib",
"Gnome::GObject"
],
"description": "Perl6 Gnome gdk api, Please install Gnome::Gtk3",
"license": "Artistic-2.0",
"name": "Gnome::Gdk3",
"perl": "6",
"provides": {
"Gnome::Gdk3::Device": "lib/Gnome/Gdk3/Device.pm6",
"Gnome::Gdk3::Display": "lib/Gnome/Gdk3/Display.pm6",
"Gnome::Gdk3::Events": "lib/Gnome/Gdk3/Events.pm6",
"Gnome::Gdk3::Keysyms": "lib/Gnome/Gdk3/Keysyms.pm6",
"Gnome::Gdk3::RGBA": "lib/Gnome/Gdk3/RGBA.pm6",
"Gnome::Gdk3::Screen": "lib/Gnome/Gdk3/Screen.pm6",
"Gnome::Gdk3::Types": "lib/Gnome/Gdk3/Types.pm6",
"Gnome::Gdk3::Window": "lib/Gnome/Gdk3/Window.pm6"
},
"resources": [
],
"source-url":
"http://www.cpan.org/authors/id/M/MA/MARTIMM/Perl6/perl6-gnome-gdk3-0.14.7.tar.gz;,
"tags": [
"gnome",
"gdk"
],
"test-depends": [
],
"version": "0.14.6"
}
---
As you see, the source version is OK, the version that was in
META6.json when packing it was not, apparently, as can be seen here
too: https://modules.perl6.org/dist/Gnome::Gdk3:cpan:MARTIMM
Since CPAN does not allow you to upload another package with the same
version, you'll have to bump both up to 0.14.8, I'm afraid...
El mié., 31 jul. 2019 a las 12:16, Marcel Timmerman ()
escribió:
> Hi JJ Merelo,
>
> Takes a couple of hours, in general. What module was it? You obviously
> bumped up the version number, right?
>
> Yes I did. Available is Gnome::Gdk3 version 0.14.6 but on CPAN there's
> already 0.14.7 uploaded on wed 24th of Juli.
>
>
> El mié., 31 jul. 2019 a las 11:19, Marcel Timmerman ()
> escribió:
>
>> Hi,
>>
>> I've a problem with zef that it is not installing the newest module in
>> town. I had uploaded a module a few days ago to CPAN to remove a bug but
>> zef does not notice it. On http://modules.perl6.org/ I also see that
>> there isn't the newest yet.
>>
>> How does the process work and how much time does it take to get available?
>>
>> I believe I've seen this answer before somewhere but can't remember
>> where and when.
>>
>> Regards,
>> Marcel
>>
>
>
> --
> JJ
>
>
>
--
JJ
