babydrop | m: use nqp; class Z { method z (Mu \SELF:) { dd [ nqp::iscont(SELF), nqp::iscont(self) ] } }; my $z = Z.new; $z.z | 00:43 | |
camelia | rakudo-moar 0c75e5: OUTPUT«[1, 0]» | ||
babydrop | Is there any case where self would be nqp::iscont()? I see nqp::decont(self) in Mu.clone which I think isn't needed, based on the above | ||
dalek | rakudo/nom: 9a161fa | (Zoffix Znet)++ | src/core/Mu.pm: | 01:36 | |
rakudo/nom: Prevent Mu.clone from incorrectly marking all attrs as inited | |||
rakudo/nom: | |||
rakudo/nom: Fixes RT#130271: rt.perl.org/Ticket/Display.html?id=130271 | |||
rakudo/nom: | |||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130271 | ||
dalek | rakudo/nom: Using nqp::getattr() or nqp::bindattr() on an attribute makes | ||
rakudo/nom: nqp::attrinited return true. This made cloned Baggies lose their | |||
rakudo/nom: .WHICH value, since its method uses nqp::attrinted to decide whether | |||
rakudo/nom: to give its $!WHICH attribute. And in the ticket we have a cloned | |||
rakudo/nom: Baggy, since the infix:<but> operator clones under the hood. And | |||
rakudo/nom: this is the reason for the error in the ticket, since the .WHICH value | |||
rakudo/nom: is unboxed into a native str at one point. | |||
rakudo/nom: | |||
rakudo/nom: Fix by checking whether an attribute is nqp::attrinted before to | |||
babydrop | rakudo/nom: decide whether to call getattr/bindattr. | 01:37 | |
review: github.com/rakudo/rakudo/commit/9a...d97ba81a50 | |||
dalek | ast: ebfab26 | (Zoffix Znet)++ | S02-types/WHICH.t: Test cloned Baggies have defined WHICH RT#130271: rt.perl.org/Ticket/Display.html?id=130271 Rakudo fix: github.com/rakudo/rakudo/commit/9a161fa0c92ea7 |
01:38 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130271 | ||
babydrop | samcv: BTW, to get a commit bit for rakudo, one has to sign the CLA and (e)mail it to The Perl Foundation: www.perlfoundation.org/contributor_..._agreement | 01:57 | |
samcv: just mentioning it, 'cause it took me months to find out that was a requirement :P | |||
samcv | ah | ||
but why don't other pull requests make you agree? | 01:58 | ||
babydrop | No idea. | 01:59 | |
dalek | kudo/nom: f9d34a9 | (Fernando Correa de Oliveira)++ | src/core/Int.pm: Fix UInt not smartmatching undefined Int |
02:04 | |
kudo/nom: d21d8ab | (Zoffix Znet)++ | src/core/Int.pm: Merge pull request #947 from FCO/uint-match-unsigned-int Fix UInt not smartmatching undefined Int |
|||
ast: c506ea5 | (Fernando Correa de Oliveira)++ | S32-num/int.t: Add test for smatmatch UInt with undefined Int (#194) |
|||
samcv | babydrop, the Linguist repo makes you do such a thing | 02:10 | |
for people who have not gotten a pull accepted before | |||
it's one of the checks | |||
wait did you actually have to mail it there | 02:11 | ||
babydrop | samcv: I'm pretty sure email is fine. When I mailed mine, I somehow managed to mail it to the wrong address and it got returned to me and then lizmat hooked me up with a contact whom I just emailed a digital version | 02:12 | |
samcv | ah | 02:13 | |
would we want to have somebody look at the CLA ( could be on our project they read it) and click accept? | |||
babydrop | Just for PRs? | ||
samcv | yeah. or nobody cares? lol | 02:14 | |
babydrop | I rather not add barriers to contribution. | ||
samcv | yeah. i thought that too | ||
it wasn't the easiest. it just said "1 check failed" or whatever when you hadn't signed it | |||
though courts have said that if you contribute source code, and they have a license it implies that you are submitting the code under that license unless you specify otherwise. | 02:15 | ||
babydrop | Makes sense. | 02:16 | |
geekosaur | ...courts where though? | 02:21 | |
samcv | oh USA i think? | 02:41 | |
maybe others. not sure | |||
kalkin- | who do I have to please to get github.com/rakudo/rakudo/pull/948 merged? (It passed all checks) | 04:06 | |
:) | 04:07 | ||
samcv | kalkin-, readline is initialized here already github.com/kalkin/rakudo/blob/9043...EPL.pm#L58 | 05:51 | |
does it work if you remove that line? | 05:52 | ||
actually hold on. just don't initialize readline inside that method | |||
> my $read = $Readline.new; that will make it lexical | |||
will be a nice feature to have | 05:53 | ||
kalkin-, also see how it loads github.com/kalkin/rakudo/blob/9043...EPL.pm#L60 files here | |||
make sure it doesn't read the history until after this | 05:54 | ||
nine | samcv: I emailed my CLA, too. If you don't get a reply in a reasonable time, Coke++ can help. | 07:58 | |
samcv | oh i didn't fill out a CLA yet ;P | 07:59 | |
but will remember for in the future | |||
brrt | btw, nine, i've resolved the issue with rakudo building on even-moar-jit | ||
thanks for pointing it out :-) | 08:00 | ||
nine | brrt++ | 08:03 | |
dalek | kudo/nom: e9ce28a | samcv++ | src/core/io_operators.pm: Make routines say, note and put 25% faster to stdout |
08:16 | |
kudo/nom: 99f04e0 | niner++ | src/core/io_operators.pm: Merge pull request #949 from samcv/say Make routines say, note and put 25% faster to stdout. |
|||
nine | lizmat: this ^^^ looks like something our static optimizer may be able to do automatically | 08:21 | |
[Tux] | This is Rakudo version 2016.11-194-gd21d8abbd built on MoarVM version 2016.11-44-g8e24145d | 08:26 | |
csv-ip5xs 3.205 | |||
test 14.206 | |||
test-t 6.335 | |||
csv-parser 14.092 | |||
dalek | nqp: 7fed81d | samcv++ | src/HLL/Grammar.nqp: | 09:02 | |
nqp: Add four new pairs of matched delimiters brackets/parens (#330) | |||
nqp: | |||
nqp: These are the only four pairs in Unicode that we don't have | |||
nqp: added. | |||
lizmat | samcv++ # good catch on say and friends! | 10:06 | |
jnthn is a bit surprised it makes such a difference | 10:08 | ||
The static optimizer should be able to lower such a lexical to a local at some point, though | |||
Oh, I bet I can guess why it was costly... It probably created a nativeref 'cus it can't prove statically that .print doesn't want an "is rw" thing | 10:10 | ||
And spesh can't strip them out in that case yet either | |||
timotimo | yup, native refs are a big reason our code isn't optimal | 10:12 | |
... IMHO | |||
jnthn | Yes, I need to spend a good chunk of time on spesh at some point | 10:14 | |
But I'm so burried in concurrency stuff it's hard to find the itme. | 10:15 | ||
*time | |||
dalek | kudo/nom: 64b5c2f | samcv++ | src/core/Cool.pm: Make uniprop return Bool or Str, also make it 15% faster and fix… a bug in MoarVM where canonical Unicode shortnames return the incorrect property. It is 15% faster now, and adds these two fixes as well. |
10:16 | |
kudo/nom: 71821dd | samcv++ | / (2 files): Add the script used to generate the uniprop code. Also make a comment saying the code was generated and where to find the file that generated it. 9043f58 | (Bahtiar `kalkin-` Gadimov)++ | src/core/REPL.pm: Add Historyfile support for Readline |
|||
kudo/nom: 1582e93 | lizmat++ | src/core/REPL.pm: Merge pull request #948 from kalkin/readline-history Add Historyfile support for Readline |
|||
rakudo/nom: 8965145 | samcv++ | tools/build/NQP_REVISION: | |||
rakudo/nom: Bump nqp: Add 4 new sets of matching brackets | |||
rakudo/nom: | |||
rakudo/nom: For use in q [], #`[ and other things such as this. | |||
rakudo/nom: | |||
timotimo | to be honest, it'd probably be worth more in the medium term to fix that nativeref problem in our static optimizer | 10:18 | |
jnthn | We can't. | ||
Methods are late bound. | 10:19 | ||
We can handle more cases than we do today of course, but the general case needs handling in spesh | 10:20 | ||
timotimo | oh | ||
of course | |||
arnsholt | And statically proving anything about $*ERR doesn't sound too plausible to me | ||
timotimo | we do have the same problem with operators, though | ||
makes native ints and such not very fun to use | |||
jnthn | True. Question is if we really want to maintain such an opt twice :) | ||
Well, we static inline a bunch of operators | |||
And get away with it on those | 10:21 | ||
timotimo | are we going to turn rakudo into javac? ;) | 10:22 | |
jnthn | What, does very few opts and leaves them to the VM? | 10:23 | |
timotimo | right | 10:24 | |
jnthn | It's an interesting question. For very short-lived scripts, it's usually a waste of time. | ||
samcv | thanks lizmat | ||
timotimo | so only turn on the optimizer for the core setting, then ;) | ||
jnthn | Well, we have levels too. "We're pre-compiling this" could push it up a level. | 10:25 | |
Though that only really helps if you get to skip analyses too | |||
timotimo | aye. we'll likely want to put a few more level checks into the optimizer | 10:26 | |
dalek | ast: 425011c | lizmat++ | S15-unicode-information/uniprop.t: Unfudge now passing test, samcv++ |
10:36 | |
babydrop | say was 25% slower just 'cause it saved into a variable? 0.o | 11:06 | |
dalek | kudo/nom: f4479d2 | dogbert17++ | CREDITS: Added myself |
11:09 | |
kudo/nom: e25a708 | (Zoffix Znet)++ | CREDITS: Merge pull request #946 from dogbert17/update-credits Added myself |
|||
nine | So, hands up please! Merge lexical_module_load before the release, i.e. ~ today? | 11:11 | |
o/ | |||
babydrop | +1 | ||
jnthn | Umm | 11:13 | |
Surely immediately *after* a release is more sensible? | |||
lizmat | I think we already skipped 2 releases where we could have done that | 11:14 | |
if we say now: immediately merge after the next release, I can live with that also | 11:15 | ||
jnthn | Yes, but this time we've got (a) data showing the impact, and (b) it's documented | ||
lizmat | but please let's not skip another one :-) | ||
jnthn | Yes, I can very easily agree with "merge right after next release" | ||
lizmat | 👍 | 11:16 | |
jnthn | Full +1 on that. I'm just a tad more wary on sneaking it in 4-5 days beforehand. | ||
nine | I'd be fine with right after the release, too. The "before release" plan certainly provoked responses faster though ;) | 11:17 | |
Also now that emmentaler is up and running again, we should use it more extensively. Thinking about jnthn++'s release plan from January. | 11:18 | ||
jnthn | Yes, we really should take advantage of that better to catch ecosystem-breaking changes sooner. | 11:19 | |
And perhaps even start doing the automatic release branch thing I proposed. | |||
(Where we use an automated process of spectest + selected module smoke pass = fast-foward branch we relesae from) | 11:20 | ||
babydrop | Is that proposal written down somewhere I could read the details? | 11:33 | |
.oO( we need a place for RFCs.... ) |
11:35 | ||
jnthn | babydrop: github.com/rakudo/rakudo/blob/nom/...ersions.md | 11:36 | |
babydrop | .oO( we have a place for RFCs.... ) |
||
thanks | |||
Well, with that naming scheme I just can see myself doing a checkout for a quick fix and accidentally forgetting to switch branches and ending up pushing to master :/ | 11:39 | ||
dalek | kudo/nom: e1d92e5 | (Zoffix Znet)++ | docs/language_versions.md: Fix typo |
11:41 | |
babydrop | And I guess most PRs will be made off master and not nom and requested to be merged to master and not nom? | 11:43 | |
babydrop isn't sure how that's works outs | |||
jnthn | Hm | ||
I think github may have some branch-level protection at these days? | 11:44 | ||
help.github.com/articles/about-bra...trictions/ | |||
timotimo | we can make an orphaned master branch with only a single commit that says "this isn't the branch you're looking for" | ||
jnthn | We could leave nom as the default | 11:45 | |
timotimo | then pushing will basically always tell you it's not a fast-forward | ||
oh, wait | |||
we're talking about making master only pushable by the automated thing | |||
jnthn | Right | ||
babydrop | But if I'm a random dude walking through decided to submit a fix, I'll just do it off master 'cause that's what everyone uses and I never heard of this `nom` | ||
jnthn | Right | ||
Yeah, we should probably then stick with not having a master. | |||
To avoid such confusion | 11:46 | ||
And call the release target one something else | |||
babydrop | +1 | ||
timotimo | release-target-one | ||
jnthn | At the time the doc was written, people using rakudobrew to obtain a Rakudo build was a more important use-case than it is now; now it seems we discourage that. | 11:47 | |
nine | But we already have a massively outdated master and there hasn't been a PR for master ever? | ||
jnthn | And people who want stability are pushed towards releases, packages, etc. Which is a good thing. | ||
nine: We don't have a master afaik | |||
Anyway, if there are users who want to be sort-of-bleeding-edge but not-so-rare-you-see-it-bleeds then I guess they can choose to track the release branch. | 11:49 | ||
nine | Oh, indeed. | ||
jnthn | I figure that will be an increasingly small group however. | ||
timotimo | we might have a master that's been created by accident | ||
i think i've done that once? | |||
nine | Seems like I have a master in my fork | 11:51 | |
jnthn goes to put a fork in his lunch :) | 11:57 | ||
arnsholt | jnthn: Is lunch return of revenge of the son of pulao mountain, or are you done with that now? =) | 11:58 | |
kalkin- | samcv: ohh i see, double initialization of my read | 11:59 | |
why did you guys merged it? should i make another pr fixing this? | |||
babydrop | kalkin-: if something's broken, yeah, please submit another PR fixing the issue. | 12:00 | |
kalkin- | babydrop: ok | 12:01 | |
nine | kalkin-: we usually operate in a "when in doubt, merge it" mode | 12:06 | |
kalkin- | i see | 12:07 | |
masak | we do? exactly how much doubt to we allow? :P | 12:11 | |
masak .oO( "I'm really not sure about this PR! let's merge it!" ) | |||
nine | "Wait, why would rakudo need to open an IRC connection and fork into background? And I have never read this account name. But the commit message explains that the patches just fix some indentation, so let's merge it!" | 12:13 | |
babydrop | Ummm... no, we don't? | 12:27 | |
babydrop doesn't want to start rumours that Perl 6 core devs will merge just any old thing | |||
lucasb | github.com/rakudo-acceptanything | 12:30 | |
babydrop | heh | ||
lizmat | m: my $a <== join(",") <== <a b c>; dd $a # this seems wrong ? | 12:33 | |
camelia | rakudo-moar e1d92e: OUTPUT«Array $a = $["a,b,c"]» | ||
lizmat | sorta expected to see "a,b,c" there ? | ||
psch | m: my $x <== 1; say $x | ||
camelia | rakudo-moar e1d92e: OUTPUT«[1]» | ||
psch | i always assumed feed operators to implictly always leave arrays behind | 12:34 | |
potentially lazy i wanna say, but i'm not sure about that | |||
kalkin- | Am I right that only rakudo/rakudo uses the nom branch as the current development branch while MoarVM/MoarVM and perl6/nqp use master branch? | ||
lizmat | kalkin-: yes | 12:35 | |
nine | kalkin-: correct | ||
lucasb | on nom nom | 12:36 | |
kalkin- | thanks | ||
pmurias | masak: isn't Angular 2 supposed to be faster? I have used only Angular 1 (and had performance problems with it) | 12:37 | |
pmurias meant to say that in #perl6 :( | 12:38 | ||
masak | pmurias: you switch channels for the Angular 2 discussion? | ||
ah :) | |||
please do. | |||
Woodi | m: my @a = |<| / - \ | / - \ > xx *; say @a[0]; say @a[0]; | 12:41 | |
camelia | rakudo-moar e1d92e: OUTPUT«||» | ||
Woodi | @a[0] do not shift Slip ? | ||
babydrop | What does that mean? | 12:44 | |
Why not use .rotate instead of that? | 12:45 | ||
Woodi | babydrop: it's another way, not circular but infinite! ;) | ||
babydrop | ummmmm | 12:46 | |
Well, don't let me stop you.. | |||
psch | that just wastes RAM, and you still need to either $++ or shift | ||
...if we can shift from lazy lists? | |||
Woodi | babydrop: and I should stil have that blogpost open, for closer reread :) | ||
psch | well, or overwrite AT-POS(0) of course vOv | 12:47 | |
that's probably gonna be perfectly fine and usable | |||
babydrop | I've no idea what blog post you mean :/ | ||
Woodi | psch: it is just short example, just put lazy there ? | ||
psch | Woodi: sure | ||
Woodi | m: my @b = |<| / - \ | / - \ > xx *; say shift @b; say shift @b; # shift shifts ? | 12:48 | |
camelia | rakudo-moar e1d92e: OUTPUT«|/» | ||
Woodi | but it is Slip, not Array... | ||
psch | m: my @b = |<| / - \ | / - \ > xx *; say @a.WHAT | 12:49 | |
camelia | rakudo-moar e1d92e: OUTPUT«===SORRY!=== Error while compiling <tmp>Variable '@a' is not declaredat <tmp>:1------> my @b = |<| / - \ | / - \ > xx *; say ⏏@a.WHAT» | ||
psch | m: my @b = |<| / - \ | / - \ > xx *; say @b.WHAT | ||
camelia | rakudo-moar e1d92e: OUTPUT«(Array)» | ||
psch | yeah | ||
Woodi is afk; Perl6 is hard. let's deliver some cakes for kids ;) | 12:50 | ||
jnthn | arnsholt: Thankfully, I finished that up by the end of last week. :-) | 13:01 | |
kalkin- | samcv: i fixed the double initialization of Readline you mentioned github.com/rakudo/rakudo/pull/951/...679435cf6b | 13:02 | |
MasterDuke_ | hopefully nobody minds if i ask about this again. i'm trying to get -n to codegen 'while ($_ := get()).DEFINITE { $code }' instead of 'for lines() { $code }' | 13:05 | |
dalek | kudo/nom: 0c6d142 | kalkin++ | src/core/REPL.pm: REPL fix readline double initialization |
||
kudo/nom: e296a14 | kalkin++ | CREDITS: Add myself to CREADITS file |
|||
kudo/nom: af2ff23 | niner++ | / (2 files): Merge pull request #951 from kalkin/readline-history REPL fix readline double initialization |
|||
babydrop doesn't mind but doesn't know the answer either :( | |||
MasterDuke_ | the AST i get looks reasonable, but depending on different tweaks to it, i get no output, or the error "Cannot call method 'sink' on a null object in block <unit> at -e line 1" | ||
here's a gist with some diffs gist.github.com/MasterDuke17/6e09e...2a0348ef7b | |||
kalkin- | ups typo | 13:07 | |
too late :) | |||
lizmat thinks it's creative :-)_ | 13:14 | ||
m: my @a = ^10; say -« @a # works fine | 13:18 | ||
camelia | rakudo-moar af2ff2: OUTPUT«[0 -1 -2 -3 -4 -5 -6 -7 -8 -9]» | ||
lizmat | m: my @a = ^10; say -<< @a # doesn't parse | ||
camelia | rakudo-moar af2ff2: OUTPUT«[0 -1 -2 -3 -4 -5 -6 -7 -8 -9]» | ||
lizmat | huh? | ||
oops, seen the error of my ways :-) | |||
babydrop | m: my @a = 0e0..9e0; say -« @a | 13:41 | |
camelia | rakudo-moar af2ff2: OUTPUT«[-0 -1 -2 -3 -4 -5 -6 -7 -8 -9]» | ||
babydrop | m: my @a = 0e0..9e0; dd -« @a | ||
camelia | rakudo-moar af2ff2: OUTPUT«[-0e0, -1e0, -2e0, -3e0, -4e0, -5e0, -6e0, -7e0, -8e0, -9e0]» | ||
babydrop | (good, negative zero works) | ||
A ton of failures in make j-test on nqp.... I guess I'm learning Java today. | 13:44 | ||
psch | babydrop: irclog.perlgeek.de/perl6-dev/2016-...i_13713553 and the next two or so pages will probably be helpful | 13:46 | |
babydrop: i'm assuming the contextual.t additions suffer from a similar problem, which is completely-different-codegen-architecture | 13:47 | ||
babydrop: so, yes, you probably have to learn some Java, but most of it is like in src/vm/jvm/QAST/Compiler.nqp | |||
*likely | |||
travis-ci | Rakudo build passed. Bahtiar `kalkin-` Gadimov 'Add Historyfile support for Readline' | 13:48 | |
travis-ci.org/kalkin/rakudo/builds/183241465 github.com/kalkin/rakudo/compare/1...43f5897a75 | |||
babydrop | ummm | ||
I don't undertstand any of it. | 13:49 | ||
I guess I'm too optimistic about my ability to fix those tests :) | |||
I just didn't want to fudge anything 3rd release in a row... | 13:50 | ||
psch | understandable, and maybe sufficient grounds to park r-j | ||
i mean, considering it's probably mostly new tests that test previously-assumed-correct behavior... | 13:51 | ||
babydrop | So would I release nqp with those failing tests unfudged or should I fudge them? | 13:52 | |
where by "fudge" I mean skipping them for both moarvm and jvm | |||
psch | i don't have a strong opinion on that, but it seems justifiable to not release nqp-j or r-j is what i wanted to say before | 13:53 | |
babydrop | OK. | ||
psch | like, it's new tests, but we should've been passing them all along | 13:54 | |
if people really want an nqp-j that we cannot confidently say fits notably relevant semantics -- like closure cloning and lexical references -- they probably can build it themselves | |||
and in turn take note of the failing tests | 13:55 | ||
but afaik releases should pass all the fudged tests, and it feels a bit weird to me at least to fudge tests that at time of release are only a few days old but pass on the other backend | |||
especially in nqp | |||
on the other hand that's previously been policy, so you could also fudge and release both | |||
as i said, i don't really have a strong opinion either way, and i'm sadly not capable of fixing anything in the lexrel and closure cloning area quickly | 13:56 | ||
babydrop | I think I'll fudge them just so if someone's packaging this downstream they don't stop and think there's some new breakage | 13:58 | |
pmurias suspects he should run make j-test more often to avoid failing tests on nqp-j | 13:59 | ||
psch | pmurias: honestly, i'm not sure. if they're passing on moar and nobody notices bad semantics it's better to have failing tests than no tests | 14:00 | |
pmurias: if you're fixing nqp-j in the process... well great, i've troubles getting into some of the deeper parts of the compiler | |||
pmurias | wouldn't fudging my having a list of tests that nqp-j fails rather then modifing tests on release and reverting that be saner? | 14:01 | |
s/my/by/ | 14:02 | ||
psch | well, sure, we can bring the fudger into nqp tests too | ||
but currently we're just straight running them through -exec nqp ... | |||
pmurias | I just meant having a list of whole test files that we fail | 14:03 | |
Woodi | hmm, Slip is just "kind of List that automatically flattens into an outer container" so what was that kind of list that do not keep used values ? Seq ? | 14:09 | |
babydrop | Woodi: FWIW, there are more users in #perl6 channel | 14:13 | |
Woodi | damn, wrong channel... sorry | 14:15 | |
pmurias | psch: 104-method-cache, 01-qast and serialization/01-basic fail? | 14:17 | |
lunch& | |||
babydrop | yeah, those look like the ones that fail to me: gist.github.com/zoffixznet/f4e1e1c...8defd3eb38 | 14:19 | |
psch | right | ||
01-qast is the one affected by the closure model differences | |||
babydrop | But I'm unsure what you mean by "make a list" of files that fail. To what end? To just keep them in a directory that's not tested on j-test? | 14:20 | |
psch | ah, 01-qast also has the bit where we don't look for the right boxing type for some reason | 14:23 | |
i don't remember offhand what's going on with the other two | |||
dogbert17_ | babydrop: I'm getting quite a few fails when running 'make spectest' normally. Is something up? | ||
babydrop | dogbert17_: what are the failures? | 14:24 | |
dogbert17_ | bizarre to say the least, I even nuked my rakuda install and started from scratch. Let me pu up a gist. | 14:25 | |
babydrop: gist.github.com/dogbert17/5916d833...06ac49e278 | 14:26 | ||
babydrop | Just one file fails? | 14:27 | |
dogbert17_ | babydrop: sry, was afk, no several failures | 14:36 | |
five or six files: t/spec/S17-promise/basic.t, t/spec/S17-supply/syntax.t, t/spec/S29-context/sleep.t, t/spec/S05-substitution/subst.rakudo.moar, t/spec/S16-io/handles-between-threads.rakudo.moar, t/spec/S17-promise/basic.t | 14:38 | ||
babydrop | No idea. Doesn't look like anything I could've broken :} | 14:40 | |
jnthn | dogbert17_: Still got extra debug checks turned on, perhaps? | 14:43 | |
pmurias | I'll look into those nqp-j failures | 14:48 | |
babydrop | pmurias++ | 14:49 | |
dalek | kudo/nom: e5e81e4 | (Zoffix Znet)++ | src/core/Rakudo/Internals/VMBackedDecoder.pm: Re-instate comment about why the `with` is in the code And expand on why it was removed/re-added |
14:51 | |
p: 069d9ea | (Pawel Murias)++ | t/qast/01-qast.t: [jvm] Add a takeclosure op needed for JVM's old closure handling. |
14:52 | ||
pmurias | when is nqp-j release planned? | 14:59 | |
babydrop | This Saturday. | 15:01 | |
NeuralAnomaly: status | |||
NeuralAnomaly | babydrop, [✘] Next release will be in 4 days and 14 hours. Since last release, there are 48 new still-open tickets (2 unreviewed and 0 blockers) and 28 unreviewed commits. See perl6.fail/release/stats for details | ||
dogbert17_ | jnthn: no, I started from scratch | 15:02 | |
dogbert17_ hopes he's made some stupid mistake | 15:03 | ||
MasterDuke_ | dogbert17_: pretty sure i've seen some failures in some of those files also | 15:05 | |
dogbert17_ | MasterDuke to the rescue :) | ||
bizarre: # Failed test 'huge values to sleep() work' | 15:06 | ||
# at /home/dogbert/repos/rakudo/t/spec/packages/Test/Util.pm (Test::Util) line 76 | |||
# got err: "Thread 3 bound to a hash key of an object (BOOTHash) allocated by thread 1\n at <unknown>:1 (./CORE.setting.moarvm:BIND-KEY)\n from SETTING::src/core/hash_slice.pm:12 | |||
babydrop | I'm not getting any failures in the entire stresstest. In fact the opposite: | 15:11 | |
t/spec/S17-procasync/kill.rakudo.moar (Wstat: 0 Tests: 9 Failed: 0) | |||
TODO passed: 9 | |||
Files=1204, Tests=130277, 139 wallclock secs (21.52 usr 3.56 sys + 2945.33 cusr 287.87 csys = 3258.28 CPU) | |||
Result: PASS | |||
dalek | kudo/nom: aa27d5c | (Zoffix Znet)++ | src/core/Date.pm: Make all Date constructors check validity of dates Fixes RT#130313: rt.perl.org/Ticket/Display.html?id=130313 |
15:13 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130313 | ||
dalek | ast: fecfa65 | (Zoffix Znet)++ | S32-temporal/Date.t: Test all Date contructors check validity of dates RT#130313: rt.perl.org/Ticket/Display.html?id=130313 Rakudo fix: github.com/rakudo/rakudo/commit/aa27d5ce94 |
||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130313 | ||
pmurias | babydrop: I'll try fixing the failures later today/tommorow, the don't look like they require a closure handling refactor or anything that serious | 15:18 | |
babydrop | cool | ||
lizmat | babydrop: are you sure you didn't break the subclassability of Date ? | ||
ah, read the commit wrong | 15:19 | ||
dogbert17_ | babydrop: it's very strange, for me the following code spits out lots of strange output: await ^30 .map: { start { S/.+/{$/.chars.print}/ given "abc"; } } | ||
m: await ^30 .map: { start { S/.+/{$/.chars.print}/ given "abc"; } } | |||
camelia | rakudo-moar e5e81e: OUTPUT«333333333333333333333333333333» | ||
dogbert17_ | odd | ||
lizmat | babydrop: but I do think you've severely slowed down Date.new(y,m,d) creation :-( | 15:20 | |
dogbert17_ | babydrop: if it's no to much trouble, are you close to your 32-bit dev machine? | 15:21 | |
ilmari | s: Range, 'in-range', \(Int, Str) | ||
SourceBaby | ilmari, Something's wrong: ERR: Unhandled exception: Missing or wrong version of dependency 'src/Perl6/Grammar.nqp' (from 'gen/moar/main.nqp') at <unknown>:1 (/home/zoffix/services/sourceable/building-perl6/perl6.moarvm:<dependencies+deserialize>) | ||
lizmat | since that now has to go through the (much slower) named variant :-( | ||
babydrop | dogbert17_: it's kinda of "trouble" tho, beucase I don't use it to dev Perl 6. So any time you ask me for something I have to rebuild Perl 6 which takes ages. | 15:22 | |
ilmari resorts to ag | |||
dogbert17_ | babydrop: that's cool just wanted to check. will try with slightly older releases | 15:23 | |
babydrop | lizmat: it's slower just due to named args? | 15:24 | |
I see it's now 3 times slower :o | |||
lizmat | oh, yes | ||
babydrop makes changes | |||
lizmat | named parameters are *way* slower than positionals | ||
that's the whole point of not using BUILD in the core setting, but custom SET-SELF methods instead | 15:25 | ||
babydrop | s: Range, 'in-range', \(Int, Str) | 15:28 | |
SourceBaby | babydrop, Sauce is at github.com/rakudo/rakudo/blob/aa27...ge.pm#L629 | ||
babydrop | ilmari: you just caught it in the middle of building a new commit | ||
ilmari | ah | ||
jnthn | m: class C { method m($a, $b) { } }; C.m(1, 2) for ^100000; say now - INIT now | 15:30 | |
camelia | rakudo-moar e5e81e: OUTPUT«0.21150674» | ||
jnthn | m: class C { method m($a, $b) { } }; C.m(1, 2) for ^1000000; say now - INIT now | ||
camelia | rakudo-moar e5e81e: OUTPUT«2.0623987» | ||
jnthn | m: class C { method m(:$a!, :$b!) { } }; C.m(:1a, :2b) for ^1000000; say now - INIT now | 15:31 | |
camelia | rakudo-moar aa27d5: OUTPUT«2.0579070» | ||
jnthn | lizmat: Really? :) | ||
babydrop | m: class C { method m(:$a, :$b) { } }; C.m(:1a, :2b) for ^1000000; say now - INIT now | ||
camelia | rakudo-moar aa27d5: OUTPUT«2.22023755» | ||
lizmat | well, :$a! is essentially the same as a positional | ||
jnthn | Uh | 15:32 | |
No, it's passed as a named :) | |||
Spesh rewrites it into a positional | |||
But it does that in the optinal case too | |||
lizmat | well, as babydrop showed, it's clearly slower | ||
if you don't use ! | |||
jnthn | m: class C { method m($a?, $b?) { } }; C.m(1, 2) for ^1000000; say now - INIT now | ||
camelia | rakudo-moar aa27d5: OUTPUT«1.8460138» | ||
jnthn | huh, how come that one is a bunch faster... | 15:33 | |
m: class C { method m($a?, $b?) { } }; C.m(1, 2) for ^1000000; say now - INIT now | |||
camelia | rakudo-moar aa27d5: OUTPUT«2.10225324» | ||
jnthn | Oh, just noise :) | ||
ilmari | .oO( dumbbench? ) |
||
jnthn | I suspect that if it boils down to "if you don't use !" then it's not too much to do with nameds and much more to do with optional, anyways. |