MasterDuke interesting. if i remove $!filename and $!lineno from here github.com/perl6/nqp/blob/master/s...p#L34-L51, everything builds and passes spectest. are they actually meant for something NYI? 00:52
jnthn: git blames you for ^^^ almost exactly 3 years ago (6c1c6f3e). any reason not to get rid of them now? 01:08
moritz MasterDuke: do you still get line numbers in error messages? :-) 05:51
lizmat Files=1150, Tests=53706, 210 wallclock secs (12.58 usr 3.61 sys + 1281.51 cusr 120.77 csys = 1418.47 CPU) 07:51
jnthn: is there a way to "flatten" a n-dimmed shaped array at the nqp level? 09:01
jnthn: reason I'm asking is that it would make a .values iterator on such a beast so much easier :-) 09:02
jnthn lizmat: No 09:19
And values should work lazily anyway :)
Rather than producing a duplicated view
We may be able to do some other smart thing though 09:20
Once we implement the partially dimensioned views thingy we could hijack it for quick values iteration
By "lying" about the dimensionality
morning, #perl6-dev 09:21
lizmat morning jnthn :-) 09:22
jnthn: but it feels like such a waste to have to generate n-dimensional AT-POS values to be able to get to the next value? 09:23
jnthn We can live with it for now, I think. 09:24
lizmat ok
jnthn And solve it when we solve the partial dimensions problem
lizmat anyway, partially dimensioned slices is on my menu
jnthn OH
OK
Well, ready to write some C? :)
(It wants doing at VM level.) 09:25
lizmat ok, then it is *not* on my menu :-)
at least not yet
jnthn My overall plan is to have a REPR that offers a "view" into some other one.
That is, another array one
lizmat I see.... ok 09:26
jnthn So you can curry dimensions, for example
lizmat cool
jnthn But if it's flexible enough to let you pretend a 3*3 array is actually a 1*9 then yeah, we can use it to much more efficiently write an iterator :) 09:27
(The memory layout of MultiDimArray should already be right for that)
lizmat right :-)
jnthn My other thought on it was that it could offer, for example, a way to view bytes of a int32 array or vice versa 09:28
lizmat nibbles? 09:29
jnthn MasterDuke: I think the file and lineno there are fossils
MasterDuke: It's done using an explicit MAST::Annotated
MasterDuke: Probably they are leftovers from early development
lizmat: Hm? :) 09:30
Oh, the computing meaning, not the food one :P 09:31
Yeah, potentially that :)
lizmat yeah, 1, 2 4 bit ?
jnthn Yeah, though we don't support those at all yet 09:32
lizmat I guess my Apple ][ heritage is showing :-) 09:33
nine jnthn: I wonder what your thoughts are on how to move forward with lexical_module_loading?
jnthn nine: Is there a write-up of it somewhere for me to look at? 09:34
(What it changes, estimated fallout, etc.)
nine Not yet. 09:35
Though it's probably short and simple: it no longer merges the globals of a loaded module into the current comp unit's globals but into the lexpad. That means that you need to explicitly use or need the modules you depend on instead of expecting your dependencies to take care of it. 09:36
Task::Star needed fixes in 2 or 3 modules. Fixes were adding use statements and fixing overly clever (but almost useless) tests in DBIish. 09:37
lizmat jnthn: it is a pre-requisite to allowing multi-version modules to be loaded at the same time
fitness& 09:38
nine Fixed modules are fully backwards compatible with older rakudos.
Reverting back to the old behavior could be done by replacing a single line in Perl6::World. So we could for example merge the branch now, deal with the fallout and revert the behavior before doing a release if we deem the ecosystem not ready yet. 09:42
gfldex is prefix & a real operator or a macroy-thing like .WHAT? 09:52
jnthn gfldex: Example of its usage? 09:53
nine: Got a $other-job distraction, will read carefully in a moment :)
nine jnthn: take your time :0 09:54
gfldex m: sub f {}; say &f.WHAT
camelia rakudo-moar 839e52: OUTPUT«(Sub)␤»
nine :)
jnthn Oh
That's a sigil
Not an operator
It's parsed by the variable rule :)
gfldex sigils feel macroish. Maybe a good way to explain them to new disciples. 09:59
nine They are really part of the name though 10:00
jnthn nine: If it's a case of a single line, what are our changes of making code that declares itself as needing 6.c get the current semantics? 10:05
*chances
nine I now realize the single line message is not actually true. We'd need to change the 3 callers of load_module back to pass $*GLOBALish instead of the lexpad. If we need easy switching, we could make them pass both easily. 10:08
jnthn: then a switch on Perl 6 version should be trivial.
jnthn OK, it is one option 10:09
To ease the pain. Depending on if people have actually been good about declaring version dependencies.
nine That would however mean that we'd have to wait almost a year for a potentially very useful feature :/ It's for example blocking Inline::Perl5 from allowing access to all loaded Perl 5 modules instead of the explicitly use'd one. Hurts especially when a module file contains several packages. 10:10
jnthn Which...I'm not sure is the case :P
nine breakfast&
jnthn Oh, wow. It turns out that LEAVE handlers already do get scoping stuff right on Moar through a...slightly interesting...mechanism. 10:18
Which may mean I have a solution to the nasty Lock.protect + control exceptions bug 10:19
Without having to do a ton of work
masak what's the slightly interesting mechanism? :) 10:22
jnthn masak: Essentially a "invoke this as if its outer is the nearest callee on the callstack that matches what it wants" 10:24
Which is...somewhat deplorable
It's actually the mechanism we use to get where clauses right too
Passes spectest and solves the problem I found, anyways :) 10:25
Sadly, I higher numbers of iterations seem to hit a JIT bug, of all things 10:26
masak messing with outers, eh?
well, that's something I'm familiar with in dealing with macros :)
(although I've since realized it's not enough)
it doesn't sound so deplorable to me, fwiw
since LEAVE, just like exception handlers, do things without unwinding the call stack 10:27
dalek kudo/nom: 48c2af6 | jnthn++ | src/core/Lock.pm:
Use LEAVE to unlock a lock in `protect`.

This means we do the right thing when we unwind the stack due to a control exception.		 10:28
nine jnthn: thought some more. Making it dependant on Perl 6 version won't buy us much, since you're usually not hurting yourself by merging globally, but hurting your users. 10:32
dalek ast: c074558 | jnthn++ | S17-supply/return-in-tap.t:
Add test for returning from Supply quit handler.
kudo/nom: b5780f0 | jnthn++ | t/spectest.data:
Run S17-supply/return-in-tap.t.
 10:33
jnthn nine: Yes, true. 11:16
nine: One other question: have you been able to actually have two versions of a module loaded using this work?
nine: It'd be bad to cause two sets of upheavel because we didn't think the first one through enough.
nine jnthn: indeed I have :) 11:20
jnthn: gist.github.com/niner/02f1d23a928c...b9e6388df8 11:29
dalek kudo/nom: b623210 | lizmat++ | src/core/Lock.pm:
No need for intermediary now we have LEAVE

Also, we don't need a block for LEAVE either.		 11:45
lizmat jnthn: ^^^ :-)
jnthn Phew, think I found/fixed the JIT bug I was hunting 12:02
lunch; will read stuff here afterwards :)
dalek p: f0b8e81 | jnthn++ | tools/build/MOAR_REVISION:
Bump MOAR_REVISION for JIT fix, other fixes.
 12:41
jnthn lizmat: It's thunked anyway so the block made no difference :) 12:42
lizmat: Other tweak is nice though 12:43
dalek kudo/nom: b4dfed2 | jnthn++ | tools/build/NQP_REVISION:
Bump for various MoarVM fixes.
ast: 6265575 | jnthn++ | S17-supply/return-in-tap.t:
Bump number of iterations in test.

This means it also will nicely cover a JIT bug we had.		 12:44
jnthn nine: I assume missing in gist.github.com/niner/02f1d23a928c...b9e6388df8 is where you installed the two versions of A? 12:47
(Into an installation repo)?
|Tux| This is Rakudo version 2016.10-132-gb4dfed2 built on MoarVM version 2016.10-33-ga4c0a84 13:02
csv-ip5xs 3.151
test 14.199
test-t 6.826
csv-parser 14.777
lizmat m: my int @a = ^10; dd @a.rotate # strange omission ? 13:33
camelia rakudo-moar b4dfed: OUTPUT«No such method 'rotate' for invocant of type 'array[int]'␤ in block <unit> at <tmp> line 1␤␤»
dalek ast: 12ccb11 | jnthn++ | S17-channel/stress.t:
Add a test covering RT #129949.
 13:47
lizmat commute to Amsterdam.PM meeting& 13:56
dalek p: c1b2cb9 | jnthn++ | tools/build/MOAR_REVISION:
Get MoarVM channel GC fix.
 14:38
kudo/nom: 6dc5074 | jnthn++ | tools/build/NQP_REVISION:
Get MoarVM with channel GC fix.
 14:39
kudo/nom: 7b4a55d | jnthn++ | t/spectest.data:
Run S17-channel/stress.t as a stress test.
[Coke] jnthn++ 14:53
japhb star: use LWP::Simple; my @recent = LWP::Simple.get('tux.nl/Talks/CSV6/speed.log').lines...rds[*-1]); my ($min, $max) = @recent.min, @recent.max; my $range = max($max - $min, .1 * $min, .25); my @bar = (^8 + 0x2581)>>.chr; my $spark = @recent.map({ @bar[(($_ - $min) / $range * (@bar - 1)).round] }).join; say $spark; 15:03
camelia star-m 2016.04: OUTPUT«▆▃▂▂▃▃▂▂▃▃▆▂▂▇▂█▃▂▃▂▁▁▁▂▃▄▄▃▄▁␤»
japhb Looks like it got slow for a week and then sped up again today
Well, slow*er*
dalek kudo/nom: 41a9804 | lizmat++ | src/core/Rakudo/Internals.pm:
Introduce R:I:RotateListToList(from,n,to)

Rotate objects with $!reified for given number of positions. This is basically the functionality of List.rotate abstracted away, but without using push/pop, so that we can also use it on shaped arrays.		 15:06
kudo/nom: bd62142 | lizmat++ | src/core/List.pm:
Let List.rotate use R:I:RotateListToList

Also fix rotating an empty list without $!reified
lizmat sorry dalek 15:07
Use R:I:RotateListToList for 1dimmed shaped arrays
All other shapes will now just throw an exception.
github.com/rakudo/rakudo/commit/e2...54dc576a29 15:08
and one more unimportant sig fix
dalek kudo/nom: 052bc01 | lizmat++ | src/core/Rakudo/Internals.pm:
Introduce R:I:ReverseListToList

Basically abstracted the functionality of List.reverse, so that we can also use it for 1dimmed shaped arrays.		 15:37
jnthn lizmat: Think we might need to audit CORE.setting for once usages 15:38
And look out for those that lead to race conditions
lizmat ok, yes, I've used it a few times
so what should I look for specifically? I mean, is once not threadsafe ?
jnthn (Or decide we're going to fix "once" in that regard by making it be more than just a state var)
No
Because it's just a state var
method EmptyIterator() { 15:39
- once class :: does Iterator {
+ BEGIN class :: does Iterator {
Is the patch I've got here that fixes things 15:40
The problem I was getting was that .iterator occasionally returned Mu on an empty List
When two threads both tried to iterate an empty list at the same time
And it was a race in setting up the once 15:41
The first invocation of a frame sets a "this was already invoked" flag
So the second invocation doesn't run the once (which is fine)
(We only want it once) 15:42
But since the first call is still in the once computing the value, then it reads Mu
dalek kudo/nom: ddfcaa7 | lizmat++ | src/core/List.pm:
List.reverse now uses R:I:ReverseListToList
kudo/nom: a6eeaa0 | lizmat++ | src/core/Shaped (2 files):
@a[10].reverse now uses R:I:ReverseListToList

Also, other dimmed arrays now always fail for .reverse
lizmat ok, will try that
jnthn Well, I'm spectesting that particular patch now 15:44
lizmat fwiw, I'm still not used to BEGIN really being reliable in the setting
jnthn *nod*
Yeah, it needs care, but in this case - just making an instance of a simple class - it seems fine 15:45
I'm wondering a bit if we can do anything about this... 15:46
We can't really about state vars in general, I don't think
otoh, maybe "once per closure" *and* "threadsafe" isn't such a common combination to want 15:47
INIT would also work fine
If BEGIN doesn't 15:48
lizmat ok
jnthn can do the once audit; there's not loads of them 15:49
dalek kudo/nom: ed2631c | lizmat++ | src/core/Rakudo/Internals.pm:
Prevent race condition for the EmptyIterator

  jnthn++ for pointing out		 15:51
lizmat jnthn: arriving in Amsterdam, will be offline for the next couple of hours 15:52
jnthn OK
Oh, I'd committed that locally :P
lizmat oops, sorry :-)
jnthn np :)
lizmat it tested ok here 15:53
later&
nine jnthn: yes, installed both versions of A 16:04
jnthn .tell literal Seems that various occurences of once in Version, Process, Kernel, and Backtrace are vulnerable. 16:31
yoleaux2 jnthn: I'll pass your message to literal.
jnthn oops
.tell lizmat Seems that various occurences of once in Version, Process, Kernel, and Backtrace are vulnerable.
yoleaux2 jnthn: I'll pass your message to lizmat.
jnthn .tell literal disregard that, tab-o :) 16:32
yoleaux2 jnthn: I'll pass your message to literal.
FROGGS o/ 16:44
lizmat m: class A { method a() { INIT dd self } }; A.a # I sorta expected "self" to be (A) here 18:54
yoleaux2 16:31Z <jnthn> lizmat: Seems that various occurences of once in Version, Process, Kernel, and Backtrace are vulnerable.
camelia rakudo-moar ed2631: OUTPUT«Mu␤»
lizmat .tell jnthn looking at it, but INIT doesn't work :-(
yoleaux2 lizmat: I'll pass your message to jnthn.
lizmat m: class A { method a(\SELF:) { INIT dd SELF } }; A.a # making it specific doesn't help :-( 18:56
camelia rakudo-moar ed2631: OUTPUT«Mu␤»
viki m: class A { method a(\SELF:) { INIT "dd SELF".EVAL } }; A.a 19:00
camelia rakudo-moar ed2631: OUTPUT«No such method 'dispatch:<.?>' for invocant of type 'NQPMu'␤ in block <unit> at EVAL_0 line 1␤ in block <unit> at <tmp> line 1␤␤»
viki 0.o 19:01
jnthn Surely that won't work; SELF isn't bound until a method is called
yoleaux2 18:54Z <lizmat> jnthn: looking at it, but INIT doesn't work :-(
jnthn Or self, for that matter
viki ah
lizmat ah, duh
jnthn Can the type not be used? 19:02
viki :)
jnthn Only thing with INIT is we do the work even if it's not used...
lizmat jnthn: checking
fg
jnthn: looks like that will work 19:03
jnthn When I was pondering how to get the "initialized on first use" + "threadsafe" behavior, I realized it's not trivial to do it right, and that it's also fairly common to want it.
Which suggests we should torture ourselves rather than everyone :)
The question is whether to try and find a way to fold it into once 19:04
Or if it should be something else
(Like a "deferred" - a kind of Promise-y thing that triggers the work on first await)
lizmat feels to me it should be folded into "once", whatever the underlying mechanism 19:05
I mean, that's how I (and probably other people) expected it to work anyway 19:06
jnthn *nod* 19:08
Let's leave things as once for now then 19:09
And I'll look into if we can do that
lizmat ok, I'll make sure we don't use once in the core in the meantime 19:10
jnthn Well, I'll have tuits for it tomorrow 19:12
So maybe wait until then, and do it if I don't find an easy way :) 19:13
lizmat it's already mostly done... 19:15
dalek kudo/nom: 94d19e9 | lizmat++ | src/core/Version.pm:
Change once to INIT until we fix once
lizmat hmmm... the once's in Kernel are harder to fix :-( 19:19
jnthn Yeah, those are what made me think it might be better to fix once or something :) 19:20
viki
.oO( fix once once and for all )
 19:22
lizmat m: my $x₁ = 42 # what was the reason again why we don't allow this? 20:17
camelia rakudo-moar 94d19e: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Bogus postfix␤at <tmp>:1␤------> my $x⏏₁ = 42 # what was the reason again why␤ expecting any of:␤ constraint␤ infix␤ infix stopper␤ postfix␤ …»
lizmat m: my $x1 = 42
camelia ( no output )
viki 'cause subscript isn't an accepted uniprop 20:18
Isn't it No or somethinm
Wound be nifty to have it allowed though :)
lizmat .u \x2081 20:19
yoleaux2 U+0030 DIGIT ZERO [Nd] (0)
U+0031 DIGIT ONE [Nd] (1)
U+0032 DIGIT TWO [Nd] (2)
lizmat m: say "\x2081".uniprop
camelia rakudo-moar 94d19e: OUTPUT«No␤»
lizmat it *is* No
viki \o/ I guessed right
lizmat it's not Nd
dalek kudo/nom: a1347ca | lizmat++ | src/core/Shaped (3 files):
Put the containerizing in a private sub

This at least makes the 1dim AT-POS just as fast as List.AT-POS		 20:54
lizmat decommute& 21:27

Powered by Cro and the Raku® Programming Language.

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

Thank you!