weekly meeting at 18:30 UTC, Tuesday
Set by moderator on 3 September 2008.
01:25 particle1 joined 03:13 particle joined 13:43 rdice joined 13:58 clinton joined, clinton left 14:09 DietCoke_ joined
DietCoke_ KJS's report: 14:09
* many cleanups and code refactoring for pirc/new
* linking to libparrot is now possible (after figuring out link flags); see README for details for windows (no access to linux; and parrot on cygwin doesn't build). This is a huge step forward.
* this means that all Parrot functions are now accessible, allowing for checking whether an identifier is an op
* also implemented .loadlib, which can be used to load a dynamic oplib: this works as well.
14:13 davidfetter joined 15:16 pmichaud joined 15:25 rdice joined 15:56 rurban joined 16:35 NotFound joined 17:04 paco joined 17:14 rurban_ joined 18:20 dmknopp joined 18:22 jhorwitz joined
Tene * More work on Cardinal 18:26
18:26 chromatic joined
Tene * I want to get a commit bit for dmknopp. He has a CLA ready to send in. What does everyone else think? 18:26
cotto_work I think you're a little early ;) 18:27
Tene * A few experiments on HLL compatibility for P6object and HLLcompiler, but nothing good enough to commit
NotFound Say hello at least ;)
Tene * EOR, now I run away to drive in to work 18:28
Tene is a bit late getting in to the office.
pmichaud notes that Tene also added 'hll_map' to the interpreter object, which is *hugely* important.
(and was committed)
moritz DietCoke pre-posted KJS' report earlier 18:30
jhorwitz materializes
chromatic aloha
rurban hello 18:31
NotFound H
cotto_work i
18:32 allison joined
chromatic Alphabetical order? 18:32
moritz that would be allison first
*hilight* 18:33
allison - Mostly working on the multiple dispatch branch, for code consistency and fixing failing tests.
- Migrated the 'infix' virtual opcodes over to real opcodes.
- Deprecated 'cmodulus' vtable functions.
- The old 'n_*' versions of the opcodes are gone, and the regular versions now create a new PMC for the result by default. 18:34
- Made it possible for new pcc_invoke function to invoke PIR subs as well as NCI subs.
EOR 18:35
chromatic I fixed a bunch of bugs, some in the MMD branch but most in trunk.
18:35 rdice joined
chromatic cotto_work? 18:35
cotto_work *not much specific, mostly just tickets necromancy
*found several to close, some to raise for discussion and a couple I can work on 18:36
eor
chromatic japhb?
18:37 barney joined
chromatic jhorwitz? 18:37
jhorwitz submitted mod_perl6 talk for pittsburgh next month.
due to a design flaw in mod_parrot, i increasingly found myself writing code to provide functionality that Apache already has. sparing the details, i'm now refactoring all HLL layers into their own Apache modules. this eases the burden on mod_parrot by forcing HLLs to manage their own configuration data and Apache hook registration. but it's difficult work and is taking some time.
(that was a mouthful) 18:38
EOR
chromatic barney?
barney nothing to report.
.eor 18:39
chromatic moritz?
moritz * usual testing/patching work
* hacked the PGE tests into Perl 6 tests, with help from Larry got us a few hundred more tests, another 250 depend on infix:<where> and parsing q/.../
* hacked a bit on nqp and rakudo NCI examples (NotFound++ for them)
KTHXBY
chromatic NotFound? 18:40
NotFound * Some work in debugger
* Created Xlib and Mysql modules and test programs in examples/nci/
* Fix some nci and UnManagedStruct problems in the process
* Applied patch from mhelix that solves several parameter passing problems
* Some others patches applied
* Renamed PMC attributes structs, RT#48014, pdd17
Three questions
EOR
chromatic particle?
pmichaud? 18:41
pmichaud PCT: 18:42
* Fixed 'loadinit' attribute for PAST::Block in PCT
* Discussions on dynamic HLL type mapping
Rakudo:
* Removed ':immediate' blocks from Rakudo code generation
* ./parrot perl6.pbc --target=pir now generates standalone executable PIR
* Updated Failure type to generate warnings when used as a value
* Added '!FAIL' and 'fail' builtin functions
* Fixed bug in Code.REJECTS
* Figured out a way to do inline PIR in Perl 6 source, so we can write builtins in Perl 6.
Misc:
* Working on my Mozilla Foundation grant final report
* Answered lots of questions here, there, and on the mailing list
* Reminder that Parrot release is next Tuesday
* Please update NEWS, CREDITS, PLATFORMS, etc.
eor
chromatic rurban?
rurban * particle gave me a commit bit, thanks. Need a mentor. For jvm I need jonathan. dotnet will get something back hopefully.
* Worked with allison on pdd30_install.
* Updated cygwin070patches with more make install tuning and cleanup: make installable creates now runtime/parrot/library/$HLLNAME.pbc for HLL interop.
* "make languages" works now also with already installed shared libparrot, just win32 not yet.
* A few langs need a runtime/parrot/library/$HLLNAME subdir: WMLScript and forth
* Change: "make all" is for all, "make build" is for the default target only.
* cygwin070patches should be ready to merge.
* Added a new language to my branch: jvm (20%) and a new perl5 lib lib/SRM, moved over from dotnet. SRM is for stack-bytecode => register mapping. It is now generalized and can be used for dotnet + jvm; later probably WMLScript also.
two questions
EOR
moritz Tene posted his report earlier 18:44
pmichaud tewk? 18:45
chromatic Did we miss anyone? 18:46
Alright, rurban. Question time.
rurban * runtime/parrot/library/$HLLNAME.pbc and subdir ? For me this sounds most natural and needs no additional libpath entry. See forth and WMLScript in the cygwin070patches branch. 18:47
2nd: * Should I try to be jvm cleanroom compatible or with Sun's recent GPL step should I not care? I need some simple external classreader sources in C, like KAFFE or Hotspot.
KAFFE is good enough IMHO, but I want to compare it to the original. Google's new v8 is in C++, so I guess Hotspot is also in C++. They have a Sun License, which looks good to me.
chromatic As long as you don't include code directly, any OSI-approved license should be fine as source material for ideas. 18:48
pmichaud runtime/parrot/library/$HLLNAME.pbc works good for me. It might be good to explore how we decide the values of HLLNAME (perhaps on list is better)
allison runtime/parrot/library/$HLLNAME.pbc and runtime/parrot/library/$HLLNAME/... is a fine place to start
rurban ok, that's in my branch now.
pmichaud for example, is it "Perl6", "perl6", or "rakudo"?
allison and, as chromatic said, linking is fine, copying is not 18:49
rurban perl6 is different :) the existing p6 pbc's just
pmichaud "Ruby", "ruby", "cardinal", ...?
rurban cardinal.pbc
the HLLNAMEis the name of the languages dir
moritz whatever the current directory name under languages/ is?
rurban exactly
pmichaud I ask because it might also impact the names we use for 'compreg' and 'load_bytecode' 18:50
rurban that will also be the name which is registered with compreg and the pbc name
and load_bytecode of course, thanks
allison eventually we will need to allow languages to register and be used under multiple names
pmichaud so, it would be load_bytecode 'cardinal.pbc' and $P0 = compreg 'cardinal' ?
rurban yes. different from that are the various frontend executables, like net2pbc
allison but, that can be later
pmichaud well, languages can already register under multiple names for compreg 18:51
rurban ok, like an alias
pmichaud it's the load_bytecode one that is tricky :-)
allison rurban: yes language aliasing
pmichaud although if compreg could also automatically load the corresponding bytecode, that would be cool too
rurban please not too much magic
I'm only worried about HLLNAME changes as with pipp lately 18:52
pmichaud we know there needs to be some magic if "parrot --prog=cardinal" is to work
allison I don't see much need to monkey with the name of the bytecode file, at least not now (maybe Parrot 2.0)
rurban this coudl work via symlink and $0 resolution 18:53
allison on platforms that support symlinks, yes
pmichaud would it be fair to say then that "parrot --prog=foo" automatically grabs foo.pbc from runtime/parrot/library ?
chromatic Not all platforms or filesystems support symlinks.
jhorwitz and we need to consider embedded apps
allison pmichaud: yes, but --language=foo instead of --prog
rurban --language++ 18:54
pmichaud we'll treat all symlinked applications as languages, then?
parrot -language=apache ... ?
jhorwitz that doesn't seem right...
pmichaud or, more likely
parrot --language=httpd ... ?
allison you mean a case of making parrot pretend to be apache or httpd? 18:55
pmichaud yes
i.e., something other than a language translator
rurban but note that the pbc is mainly a HLL lib, not a language
allison if it's ever used for something other than languages, we can introduce another flag
pmichaud i.e., we have $0 set to run a program from parrot
allison How about "parrot --language=foo" automatically grabs foo.pbc from runtime/parrot/library/language 18:56
(note the added subdirectory)
rurban also not bad.
pmichaud with runtime/parrot/library/language/$HLLNAME ?
chromatic Why not runtime/parrot/language ?
NotFound One can even imagine a minmalistic linux distribution whith parrot where most commands are parrot symlinks.
pmichaud yes, I think I like runtime/parrot/language
rurban that woudl need a library.c and libpatch change
jhorwitz +1 18:57
rurban libpath
allison and then, if at some point we need to add some other semantics besides languages, then we have a sensible hook for a different location
yes runtime/parrot/language is sensible
pmichaud but I agree with NotFound -- if we think along the lines of busybox type stuff (very reasonable with Parrot), then --language may be a bit too narrow in scope
I like having runtime/parrot/language... except then we'd want load_bytecode to be able to easily get to stuff from there as well
Tene queue one question from me 18:58
pmichaud although perhaps load_bytecode "language/perl6.pbc" might work
(with current implementation)
allison too much magic, better is load_language "perl6"
which could do the compreg bit too
pmichaud well, that already happens. :-)
load_bytecode 'perl6.pbc' causes the :load subs to execute (which register the compiler) 18:59
rurban I like the load_language "perl6" idea
pmichaud I do have some qualms about introducing a separate opcode, though
it's nicer if we think of languages as being libraries (which, in a sense, they really are)
rurban then we need no addiitonal libpath entry, which would slow the other load_bytecode calls down
pmichaud otherwise when I say "use Python;" there has to be something that knows whether to call "load_bytecode" or "load_language" 19:00
allison languages are more than libraries, and down the road they're likely to diverge further
NotFound load_bytecode time is mainly disk access, a little cpu time will never be noticed.
pmichaud and, going back to our discussion at YAPC::EU, we're also looking at "run_bytecode" and "load_bytecode" ops
which means we'd want "run_language" and "load_language"? 19:01
allison pmichaud: saying "use Python;" to load a language library is a pretty uniquely Perl6-ish thing
pmichaud allison: fair enough. 19:02
rurban well for now the languages occupy the general lib namespace in library. let's see how crowded it will get there I would suggest.
allison and, you're already doing magic, because Python.pbc /Python.pir doesn't actually exist in the Perl 6 namespace
pmichaud I still think it's better if we treat languages as libraries, but I'll not push it.
allison didn't we decide we didn't need 'run_bytecode'?
well, they'll still be libraries
pmichaud I said I could work around it.
NotFound We can have a minimal lib that loads the language in his init, if some language need that. 19:03
allison and, you can still load them with load_bytecode "path/to/wherever/foo.pbc"
rurban note the analogue to compilers. nqp was formerly a language, now it's library, and now even one without installed pbc 19:04
pmichaud (run_bytecode) it's still the case that we'd like to be able to specify functions that run after everything else is loaded
currently the only way to do that is to put the function at the end with a :load flag
allison pmichaud: okay, we should probably start a ticket for 'run_ bytecode', then
chromatic Tene had a question (and rurban still has one queued)
pmichaud which gets complicated if it has any nested lexical blocks (which would have to be after that)
NotFound Don't forget my questions! 19:05
Tene I want to get a commit bit for dmknopp to help him work on cardinal.
NotFound They are short, I promise X-)
chromatic Tene, can you mentor him?
allison pmichaud: (a separate :flag that marks subs to be run after everything else has been loaded might also be a possibility)
Tene Yes.
chromatic Any objections? 19:06
pmichaud allison: yes -- this is effectively what :main does now for running from command line
no objection
(and yes, if we had such a flag we don't need run_bytecode) 19:07
(assuming we always wanted it run with load_bytecode)
allison re: dmknopp: no objections 19:08
pmichaud: yes, I like having one load function, and leaving the decision of what routines to run when to the module author
pmichaud allison: meaning the caller never gets to decide, except by some agreed-upon out-of-band convention 19:09
(which is okay, just pointing it out. Sometimes we want to load-but-not-run)
Tene dmknopp: You have the address to mail the CLA? 19:11
dmknopp 7456 SW Baseline Road #220
Hillsboro, OR 97123
USA
is listed on the form
allison dmknopp: that's correct
dmknopp ill send it off then. :-) 19:12
pmichaud allison: I'll send a description of the current workaround that Rakudo is having to use to the mailing list so you can think about it there.
allison pmichaud: sounds good
rurban My 2nd question was answered I guess, if I may look at the Hotspot source. 19:13
(Because to paste the structs from the pdf specs is awful)
NotFound My first question: some languages have docs/ and some have doc/. Shall we open a TODO to standarize on docs/? 19:14
allison rurban: yes you can look at the source, but you can't copy from it
Tene NotFound: why standardize on docs instead of on doc?
rurban May I copy from KAFFE? This is GPL.
NotFound Tene: because the root tree has docs/ 19:15
allison rurban: no, Parrot is Artistic, not GPL
moritz unix as doc/
rurban ok.
moritz *has
rurban I'm for doc
moritz rurban: maybe you can ask the KAFEE folks if they can release the headers also under Artistic
NotFound If not docs, add rename the base docs to whatever. 19:16
allison rurban: It's unlikely we'll be able to use anyone else's source directly anyway, they're all stack-based
rurban ok, I'll do. What I really want is to copy the classfile reader source (because of the stupid zip uncompression)
moritz allison: for parsing jvm bytecode, I think
rurban yes.
allison rurban: we can link to an external library 19:17
we just can't copy it into the source tree
rurban ok.
moritz any comments on NotFound's question? 19:19
pmichaud is consistency of doc/ vs. docs/ terribly important?
I'd hate to rename the source tree and break a number of (external) links
NotFound pmichaud: that is the question, precisely.
allison standardizing on one (doc/docs) for languages in the parrot repository seems sensible
not critical
rurban I would only rename the languages docs to doc 19:20
allison and for languages outside the parrot repository we won't impose any standard
rurban make it easier to podlink L<> to other langs (as I do from jvm to dotnet e.g.)
pmichaud rakudo went with "docs/" because that's what parrot trunk was using.
allison rurban: you can't assume any one standard across all languages 19:21
pmichaud and there are links in various articles and blog posts directly into the svn repository
rurban it's just a nice to have if done early enough
NotFound We can put a recommendation for new languages, no ticket for anow.
rurban good point
pmichaud so renaming docs/ to doc/ would break all of those links
moritz does tools/dev/mk_language_shell.pl generate doc/ or docs/ 19:22
?
pmichaud (and yes, they'll break *anyway* when rakudo moves out of the parrot repo, but that's a different sort of breakage.)
particle moritz: neither iirc
moritz pmichaud: is that planned?
allison docs/ is the parrot standard, I can't think of any particular other standard we're trying to meet
moritz then it might be a good idea to generate a stub directory with the "right" name
pmichaud moritz: is what planned? 19:23
rurban I want a docs/running.pod for every language which has no good man page.
allison mortiz: yes, all the languages will be moving out of trunk at some point
moritz: or, at least all HLLs
NotFound Second questions: integer overflows: we have some guide about what to do, throw an exception or something? Both for int registers and for pmc.
particle "all" except examples like abc
rurban which point? in 2008?
pmichaud not likely in 2008.
moritz allison: before 1.0?
particle yes, before 1.0 19:24
allison moritz: at some point soon after we get a language install process that works
particle heard rurban is working on that ;)
pmichaud ...and (hopefully) when Parrot is a bit more stable?
the primary reason for having languages in the trunk is to keep close coordination between Parrot changes and languages 19:25
allison pmichaud: that too, which will also be quite soon
rurban I did no install lib for all the langs. I copied the same for all langs.
Tene rurban: is there a doc in parrot that specifies what pod files a language should have?
allison rurban: come again?
Tene rurban: all I have is you mentioning some pod file names on IRC a few times. Can you write up what you want, what each pod file needs, etc and add it as a doc somewhere? 19:26
rurban I thought about a make install framework to make it easier an consistent. For now the same steps are just copied to all makefiles.
barney MAINTAINER should be there for all HLLs as well
rurban this pod is pdd30_install.pod
in pdds/draft
pmichaud since languages are eventually moving out of trunk, I would expect individual languages to maintain their own 'make install' target. 19:27
particle yep, languages must be self-contained
rurban But to make future installations easier for external libs and langs we need a lib as perl5 MM
particle their own configure (if needed), build, test, and install
rurban Or Module::Build (shudder)
allison rurban: a manual copy between makefiles is fine for now (the makefiles are all generated anyway), but yes, they will all need their own ability to install 19:28
rurban: we may need to go that far eventually, but to start with all we need is to define what steps the language will need to take to install 19:29
rurban That's defined in my draft. Almost
allison rurban: and include that in the default makefile template generated for new languages
rurban the wanted pods and the name of the docs dir are not defined yet
ok, will do.
particle we've just hit the 1h mark. anything else that can't be disussed in #parrot or via email? 19:30
pmichaud did we decide on parrot/runtime/languages ?
allison pmichaud: yes
pmichaud okay.
NotFound Repeat second question: integer overflows: we have some guide about what to do, throw an exception or something? Both for int registers and for pmc.
particle wait. is that runtime/parrot/languages? 19:31
pmichaud particle: yes, I had it backwards.
allison for PMCs, integer overflows go to BigInts
particle r/p/l++
allison well, it should be parrot/runtime/languages :)
pmichaud and --language=foo automatically runs parrot/runtime/languages/foo.pbc ?
allison runtime/parrot was designed with the intention of runtime/perl runtime/python 19:32
particle it can be runtime/languages/. we don't need parrot/ in the source tree
rurban parrot/runtime/languages makes no sense. runtime will be dropped when installed
runtime/parrot => lib/parrot
allison so, maybe, instead of whatever/runtime/languages, it should just be runtime/mylanguage/mylanguage.pbc
pmichaud keep in mind that I expect nqp.pbc and perl6grammar.pbc to follow suit 19:33
particle allison: that's how runtime/ was originally designed
rurban uh. pollution
NotFound Last question: must I move Xlib and Mysql from examples to runtime library?
particle parrot is just another hll name
allison let's move the path conversation to further discussion on the list and in pdd30
rurban parrot should be the base of all. perl6 is just a HLL imho
pmichaud (on list)++ 19:34
rurban :)
allison NotFound: why would you need to?
particle notfound: if you intend to make full libraries out of them, it makes sense
NotFound allison: easier to test
rurban I would like to see a mysql and Xlib library as OpenGL and Pg
particle if they're intended not to grow beyond their current state, they're fine as examples
pmichaud (because load_bytecode doesn't look in examples/)
allison seems more like a problem with load_bytecode than anything else 19:35
NotFound To test for other people interested, not by me, of course.
allison we don't currently have a way of adding to the parrot equivalent of @INC, but need one
rurban @INC hook++
allison (it will not be called @INC :) 19:36
rurban pushlib <dir>
NotFound The intention is to grow both, but they are big things, don't know how fast will be the process, or how many people will help.
allison NotFound: move them out if they grow big enough to be part of the "standard" library, but don't move them out just to make testing easier 19:37
particle push_library_path/unshift_library_path
NotFound allison: ok
pmichaud NotFound: Note that Rakudo *does* have @*INC, and you can use that. 19:38
allison mostly, I'll like the core install to grow smaller, not larger, and work out the installation process for other modules
NotFound particle: as methods for the interpreter pmc? 19:39
allison steer clear of "push" and "pop", use more general words like "add_library_path"
NotFound: as opcodes
pmichaud speaking as a HLL implementer, opcodes are evil. 19:40
methods are much easier to work with.
allison they may modify the interpreter, or they may bodify a sandbox
except that methods on the interpreter mean you're modifying the interpreter directly, which is also evil 19:41
pmichaud fair enough.
allison and if opcodes are evil, we have a serious problem
pmichaud opcodes aren't modifying the interpreter, then?
chromatic The search paths *are* attributes of the interpreter.
allison the opcode is an interface, it can do anything behind the scenes 19:42
rurban sidenote - I'll make 2nd branch with the 2nd path suggestion, language libs parallel to parrot. runtime/HLLNAME/library/HLLNAME.pbc runtime/HLLNAME/dynext/HLLNAME_group.dll and such. This will need library.c changes and a new opcode/method
pmichaud that sounds to me like a method :-)
chromatic That's fine, but these opcodes are going to modify interpreter attributes behind the scenes.
allison it may modify the interpreter, but it may also run it through security filters, or capture it in a sandbox
pmichaud "a method is an interface, it can do anything behind the scenes"
allison yes, but a method is an interface where you've already selected what object to modify 19:43
pmichaud anyway, the only "evil" part is that HLLs end up having to wrap opcodes with subroutines or method calls anyway
allison an opcode gets to select the object too
NotFound The pmc method can just call the same function than the opcode, as a helper to hll
chromatic That object is going to be the interpreter.
allison not necessarily, it may be a sandboxed COW interpreter
particle moos 19:44
chromatic It's not going to be an interpreter, it may be an interpreter!
allison or, it may be a thread
NotFound allison: in that case, getinterpreter will return the same, it isn't?
pmichaud even if it's a sandboxed COW interp, I would expect getinter..... right
particle anyway, we need a way of adding paths (or code objects) to the list of library search paths both at beginning and end 19:45
allison yes, but getinterpreter is just an opcode
particle *getinterp
allison so, you'd rather call an opcode and a method than just an opcode?
chromatic Yes.
pmichaud from a HLL perspective, it ends up being a Parrot sub that calls an opcode.
chromatic I might not want to change the library paths on the current interpreter.
pmichaud it's never "just an opcode".
(except for opcodes that tend to map directly to hll operations) 19:46
NotFound The question for integer overflow on registers is pending. 19:47
pmichaud so, my choice is either (1) fetch an interpreter object and call a method on it, or (2) call a wrapper sub that invokes the opcode.
allison we're getting too tied up in the small details, especially considering we don't even know what the proposed method/opcode will do yet
pmichaud yes, but I'm speaking somewhat in generalized terms. From an HLL perspective, having lots of specialized opcodes isn't as useful as having methods. 19:48
Use that for whatever it's worth. :-)
rurban load_language
allison pmichaud: okay, that's useful information
chromatic It modifies the array stored in IGLOBALS_LIB_PATHS.
NotFound We can start by adding a function, and a command line option to set it.
A C function, I mean.
pmichaud a good example of the principal is in the compiler objects we're creating (and registering with compreg).... calling methods on those objects is much more useful than specialized opcodes for it 19:49
allison NotFound: good potential starting point
pmichaud another example is ParrotIO -- methods on an object are much more useful than specialized opcodes
allison ParrotIO is moving in that direction
pmichaud yes
rurban but other HLLs need to load this language at first somehow. 19:50
allison NotFound: on overflowing integers, if they can't be converted to BigInt PMCs (the context doesn't allow for that kind of change), then it's an exception
particle of course, it's probably an exception of type Inf or NaN, which isn't really specced 19:52
pmichaud I would think it's a range exception
particle pmichaud: does your expectation change if we substitute num for int? 19:53
NotFound Is useful to not mix integer overflow with float or bigint ones, I think.
Some languages may need to catch it to do whay their standard mandates.
particle ok, so int overflow is a range exception, and the maxint value is dependent on configuration parameters 19:54
pmichaud particle: if the question is "are we generating values that can't be stored in the available types", that sounds like a range exception to me
allison how about an integer overflow exception
NotFound ++ 19:55
pmichaud the canonical examples are probably: add $I2, $I0, $I1 and add $N2, $N0, $N1
particle yes, but with NREG, Inf and NaN representations are built in to the data type 19:56
we may differentiate between NaN and NaNQ
where the former throws an exception as well as sets the value in the NREG 19:57
pmichaud Inf doesn't sound right to me -- I think of that as being fundamentally different than simply "out of range"
particle the latter just sets the value
pmichaud but we're at the edge of my expertise on the issue, so I'll shut up now. :-)
particle well, it doesn't need to be settled today anyway 19:58
allison I think we've generally run to the end of what can be done in IRC discussion on these topics, any further questions before we wrap up?
moritz counts that as a "no" 19:59
allison Sounds like a no. Thanks for joining us, tty next week!
rurban bye 20:00
moritz bye
NotFound B
20:00 chromatic left 20:01 NotFound left, rurban left 20:04 dmknopp left 20:58 jhorwitz left 21:34 paco left 22:00 particle joined 23:05 davidfetter joined 23:52 wknight8111 joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!