| [Coke] | * [new tag] Zürich -> Zürich .... did something change the encoding on that string recently? just got it updating a checkout that was recent enough to only get 2016.10 | 01:54 | |
| is someone looking at #130043 ? kicking off a bisect now... | 01:55 | ||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130043 | ||
| travis-ci | Rakudo build errored. Zoffix Znet 'Merge pull request #913 from Xliff/patch-3 | ||
| travis-ci.org/rakudo/rakudo/builds/174025059 github.com/rakudo/rakudo/compare/6...ef3d9f8531 | |||
| buggable | [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. | ||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Mark native shaped str arrays as NYI' | 03:09 | |
| travis-ci.org/rakudo/rakudo/builds/174061716 github.com/rakudo/rakudo/compare/2...0061432d7d | |||
| buggable | [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. | ||
| lizmat | .tell jnthn is there a reason to not mixin the $!descriptor for TypedArrays only, and leave it off for Arrays ? | 13:54 | |
| yoleaux2 | lizmat: I'll pass your message to jnthn. | ||
| FROGGS | o/ | 13:55 | |
| nine: wrt lexical module loading: does it make sense to make re-exporting symbols work like synopsed, before merging your branch? | 13:59 | ||
| (depends on the ecosystem fallout clearly, which I dont know how it will look like) | |||
| dalek | kudo/nom: f6d9232 | lizmat++ | src/core/Shaped (5 files): ShapedxArray don't need parameterization |
14:20 | |
| [Coke] wonders if getting a Perl 6 app running on GE's predix would be a good thing. | 14:24 | ||
| dalek | p: 396a679 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js: [js] Store a Null instead of undefined for the type in VMArray. |
14:59 | |
| nqp: 066c6a7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files): | |||
| nqp: [js] Fix style violations found by js-lint. | |||
| ast: 734c19d | (Zoffix Znet)++ | S32-temporal/DateTime.t: Test DateTime.hh-mm-ss |
15:02 | ||
| kudo/nom: 35bd063 | (Zoffix Znet)++ | src/core/DateTime.pm: Use consistent code style |
15:07 | ||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'ShapedxArray don't need parameterization' | 15:45 | |
| travis-ci.org/rakudo/rakudo/builds/174219989 github.com/rakudo/rakudo/compare/c...d92328a656 | |||
| buggable | [travis build above] ☠ Did not recognize some failures. Check results manually. All failures are on JVM only. | ||
| viki | travis, bruh. | 15:46 | |
| dalek | kudo/nom: a581bf4 | (Zoffix Znet)++ | .travis.yml: Add missing space in JVM travis ignore options The current setting doesn't see to work; replicate exact strings set up in the `env` field |
15:50 | |
| viki | Was there a thing that lets me check if I'm compiling the setting? I'm trying to add a few debug nqp::say()s into World.nqp, but it hangs when I try to compile rakudo | 18:54 | |
| oh... maybe it's just 'cause this box is slow as hell :} | 18:56 | ||
| viki tries using ... if %*ENV<WAHTEVER> | 18:57 | ||
| jnthn | I think there's a $*IN_CORE_SETTING | ||
| viki | oh $*COMPILING_CORE_SETTING | 18:58 | |
| jnthn | :) | 18:59 | |
| "Close enough" | |||
| [Coke] | ACHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO | 19:32 | |
| lizmat | boom | ||
| [Coke] | ... since most of you probably heard that one anyway. Ow. | ||
| TimToady | I sensed a disturbance in the farce... | 19:33 | |
| lizmat | .oO( those Americans, always using euphemisms :-) |
19:42 | |
.oO( especially on a day like today ) |
|||
| [Coke] | ooof, my isms! | 19:48 | |
| lizmat | jnthn: is there a way to find out whether the result from a ^mixin is from a cache, or from a newly created type ? | 20:51 | |
| dalek | rakudo/nom: 729d7e3 | (Zoffix Znet)++ | src/Perl6/Actions.nqp: | 20:56 | |
| rakudo/nom: Prevent overflow when creating large Num literals | |||
| rakudo/nom: | |||
| rakudo/nom: The current calculation converts the "base" number to one without fractional | |||
| rakudo/nom: parts, raises it to "e" power, and then divides it by however many powers of | |||
| rakudo/nom: 10 it took to make it fractionless. So 1.23e10 gets converted to 123, multiplied | |||
| rakudo/nom: by 10**10 and then divided by 100. This causes the calculation to blow through | |||
| rakudo/nom: the limit and get an Inf before the final division happens, even though we do have | |||
| rakudo/nom: enough space to represent the final number. | |||
| rakudo/nom: | |||
| rakudo/nom: Fix by dividing *before* multiplying by the powers of 10. | |||
| rakudo/nom: | |||
| viki | ENOTIMETOTEST | ||
| github.com/rakudo/rakudo/commit/72...cf911dd7cf | |||
| viki rushes to catch the bus | |||
| I mean to write a test for the bug.... I did run stresstest :) | 21:00 | ||
| lizmat | m: sub a(\self) { dd self } # I guess this is a case of DIHWIDT | 21:35 | |
| camelia | rakudo-moar 729d7e: OUTPUT«===SORRY!=== Error while compiling <tmp>'self' used where no object is availableat <tmp>:1------> sub a(\self) { dd ⏏self } # I guess this is a case of DIHWI expecting any of: argument list term» | ||
| dalek | ast: 8737580 | (Zoffix Znet)++ | S02-types/num.t: Test literal Nums close to upper limit do not end up being Inf RT#130039: rt.perl.org/Public/Bug/Display.html?id=130039 |
22:13 | |
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=130039 | ||
| jnthn | lizmat: I can go with it being that. :) I think we lifted the checking logic straight out of STD... | 22:14 | |
| lizmat: I don't think you can check on the mixin cache being used without sticking logging in the code | |||
| lizmat: But you can mix in twice and do nqp::objectid on the .HOW of the two and it should be identical | |||
| lizmat | yeah, but that's defeating the purpose | 22:15 | |
| I wanted to prevent ^set_name being called when it needn't be | |||
| as that was still taking 4% of CPU in a loop | |||
| jnthn | Hmm | ||
| Doesn't that go away if we pre-fab the types though? :) | 22:16 | ||
| lizmat | I now check whether the name is already right, and that saves a lot already | ||
| eh, no | |||
| well, yes, if we can actually create the array and .clone it for a scope | |||
| brb | |||
| jnthn | Mebbe I'll take a look tomorrow when I'm better rested | 22:17 | |
| (Got Perl 6 tuits all day tomorrow) | |||
| japhb | \o/ Perl 6 tuits | 22:20 | |
| lizmat | whee! | ||
| :-) | |||
| jnthn | I really need to deal with the rest of the flatten string bug though :/ | 22:21 | |
| japhb | jnthn: Which bug is that? | 22:25 | |
| lizmat | jnthn: to get the .clone ing behaviour like my @a, i would probably only need some pointer as to where to look in Grammar/Action/World | ||
| Array+{Array::Shaped1Array}+{Array::Shaped1Array} # that looks like a ^mixin snafu, no/ | 22:26 | ||
| ? | |||
| jnthn | japhb: A .substr or a string made with infix:<x> or infix:<~> don't actually copy string data | 22:27 | |
| japhb: Instead, they reference the original string(s), and have extent or repetition count as needed. | 22:28 | ||
| japhb: Back in the early days of MoarVM, we chose not to write our own hash data structure, and so used uthash instead. This wants a flat buffer of memory to hash and compare. | 22:29 | ||
| This was meant to be a workaround "for now", and so the rest of the VM assumes strings are truly immutable. | 22:30 | ||
| Except they end up doing this thing in place, which occasionally goes boom 'cus it breaks the immutability contract | 22:31 | ||
| tl;dr re-use was a dumb idea | |||
| Shoulda just written a hash impl for us in the first place. | |||
| lizmat | .oO( but there are so many to choose from ) |
22:32 | |
| jnthn | I'm not talking about the hash *function*, to be clear. | 22:33 | |
| Just the data structure itself. | |||
| I'd kinda put this off because I wanted to do VM-level object hash support too | |||
| japhb | Fair enough. | ||
| jnthn | But by this point it's basically concurrency enemy #1. | 22:34 | |
| (Because so many of the other issues have been addressed.) | |||
| We've a few other nasties (phasers, of note) | 22:37 | ||
| The phaser over-sharing issue and the string flattening one were the two I stubbed my toe on while prototyping a concurrent system at work recently. | 22:39 | ||
| japhb | And whatever it is that makes code objects sometimes fail precompilation .... That one bugs me personally, but it also makes me very nervous in general because I have no idea what might be causing it, and it feels pretty deep. Which is to say, it makes me wonder what else is broken based on the same root cause. | ||
| Yuck. | |||
| ab5tract and I agreed to start heavily adding concurrency to Terminal-Print as our next push, so stability there will no doubt save a world of headaches. | 22:40 | ||
| (So far we've just been avoiding making the APIs concurrency-hostile, but now we want to go to async events and supplies and such pretty heavily.) | |||
| travis-ci | Rakudo build errored. Zoffix Znet 'Use consistent code style' | 22:43 | |
| travis-ci.org/rakudo/rakudo/builds/174234057 github.com/rakudo/rakudo/compare/f...bd063f1350 | |||
| buggable | [travis build above] ✓ All failures are due to timeout (0), missing build log (6), or GitHub connectivity (0). | ||
| japhb | .oO( Consistent style: no style at all ) |
22:46 | |
| jnthn | Yup, I'm glad to have a prototype to do where Perl 6 is genuinely a really nice thing to turn to for its mix of whipuptitude and concurrrency features. | 22:47 | |
| I've no doubt it'll show up a couple more issues along the way. | |||
| Real life use-cases are good at that. | 22:49 | ||
| japhb | nodnod | ||
| dalek | kudo/nom: b7e632e | lizmat++ | src/core/ (4 files): Mix in shapedness in the class, rather than instance This means we only have 1 global deopt for creating a shaped array of a given number of dimensions and type. - fix .of on shaped typed arrays - fix the .perl of shaped typed arrays This gives a 10% gain on a simple "for ^10000 { my @a[10] }" loop, but for larger programs it should be much more because it would no longer do a global deopt for every iteration. fb56768 | lizmat++ | src/core/native_array.pm: Streamline shapedarray.shape |
23:01 | |
| lizmat | rakudo/nom: review: github.com/rakudo/rakudo/commit/b7e632e | 23:02 | |
| MasterDuke | jnthn: method lineof() in src/HLL/Compiler.nqp isn't ever called during a rakudo compile. were you thinking i just needed to get it to know the right file/line? or get it to be called at all (with the right file/line)? | 23:21 | |
| jnthn | MasterDuke: Um, I thought that's what was called o.O | 23:26 | |
| MasterDuke | heh. i added a print, it shows up when building nqp, but not when building rakudo | 23:27 | |
| jnthn | You did `make install` NQP after the change? | ||
| MasterDuke | hmm, i (usually) always do, but now my bash history might be making a fool of me | ||
| MasterDuke rages at /me | 23:30 | ||
| jnthn | Mystery solved? :) | ||
| MasterDuke looks around for some(thing|one) to blame, but sees only /me | 23:32 | ||
| yeah. rakudo doesn't like the print, but at least it's happening | |||
| jnthn | nqp::printfh(nqp::stderr(), 'foo') or similar may be less build-explosive | 23:34 | |
| MasterDuke | it is, thanks | 23:39 |