00:14 benabik joined 00:54 benabik joined 01:21 sergot_ joined 01:22 yawnt` joined 01:34 FROGGS_ joined 02:00 bcode_ joined 02:25 donaldh joined 02:26 bcode joined 02:37 bcode_ joined 03:49 FROGGS_ joined 07:08 zakharyas joined 07:21 FROGGS joined 07:56 yawnt joined 08:35 FROGGS joined 08:42 FROGGS joined 08:59 FROGGS joined 10:54 FROGGS joined
jnthn just realized that he didn't cut the Moar release yet. :) 11:19
Which masak will soon need for the Rakudo release :)
FROGGS /o\ 11:23
panic now?
11:29 yawnt left
jnthn working on it 11:37
No panic
I had the day's meeting
And the release process ain't much work :) 11:38
dalek arVM: 1859883 | jonathan++ | docs/ChangeLog:
ChangeLog for 2014.04.
 11:39
lizmat an impressive list :-)
jnthn :)
lizmat " Main thread has ID 1 now" 11:40
jnthn It used to have 0 :)
Also that's the VM-internal ID
Not the OS one
It got to be 1 because I wanted 0 as a sentinel value elsewhere :)
lizmat yes, I understand 11:41
dalek arVM: a5bc46f | jonathan++ | VERSION:
Update VERSION.
lizmat I just seem to remember either a spec or a piece of code using !thread.id as a way to find out if you're running in the main thread 11:42
jnthn hmm 11:44
lizmat can't find anything in the spec
jnthn I suspect some MoarVM code may have done it
I tweaked at least one place
lizmat m: say $*THREAD.id 11:45
camelia rakudo-moar a4e5ca: OUTPUTĀ«140303077705536ā¤Ā»
lizmat is that expected ?
jnthn Well, it's not unexpected :P
But "seems not quite legit" :)
Looks more like a junk value than an OS-provided ID
lizmat it's not 1, which one would expect, no? 11:47
jnthn no, .id returns the OS's idea of thread ID, at least on Moar, not the internal one.
But maybe that's not a sane thing to ask for on the main thread of a program? 11:48
m: say $*THREAD.id; Thread.start({ say $*THREAD.id }) 11:49
camelia rakudo-moar a4e5ca: OUTPUTĀ«140497208452928ā¤140497145652992ā¤Ā»
jnthn Maybe they are somehow legit...
lizmat S17:778: "This should be treated as an opaque number. It can not be assumed to map to any particular operating system's idea of thread ID"
synopsebot Link: perlcabal.org/syn/S17.html#line_778
jnthn Yeah. Partly 'cus that's all JVM can promise. 11:50
Anyway, above are certainly opaque numbers :P
lizmat so how would you determine that you're running in the main thread ?
jnthn But I'm surprised they don't look more like the kinda number you'd see in, say, top.
OK, anybody has any release blockers? 11:52
jnthn sure hopes not :)
dalek arVM: cd6a21f | jonathan++ | README.markdown:
Update README.
 11:57
jnthn tries out the tarball 11:59
www.moarvm.org/releases/MoarVM-2014.04.tar.gz 12:03
and tagged as 2014.04 12:04
cognominal what is the meaning of repossession in the context of GC?
FROGGS jnthn++
jnthn cognominal: I dunno :) 12:05
cognominal: We mostly use that word in the context of serialization
cognominal oops
jnthn augment is the most obvious thing that needs it
I update the moarvm.org site later on. 12:06
timotimo "positoin arguments" 13:26
13:53 btyler joined
jnthn timotimo: where? 13:53
oh, change log 13:54
dalek arVM: dcbd3fc | jonathan++ | docs/ChangeLog:
Fix typo; timotimo++.
 13:55
jnthn Not cutting a new release for it, but at least will get correct spelling on le site. :)
timotimo :) 13:57
14:25 donaldh joined 15:39 cognominal joined
TimToady ven, lizmat: wrt "is readonly", that's why we have ::= instead, which markes readonly after binding 16:02
*marks 16:04
oops, wrong channel 16:12
FROGGS .oO( yeah, indentation is mandatory... oops, wrong channel! ) 16:13
TimToady hopes a third cup of coffee will fix his brane 16:14
16:18 FROGGS[mobile] joined
retupmoca just found a spesh bug 16:19
(that I can only reproduce in the REPL so far)
looks like obj is null in OP(sp_findmeth), but only after/inside a OP(forceouterctx) 16:20
FROGGS[mobile] Uhh, that does not sound nice
retupmoca (reproduce: run perl6, enter 1 RET s/\$// REG 16:21
results in a segfault
s/REG$/RET
looks like the nqp code line it segfaults on is rakudo/src/core/Str.pm:649 (in method subst) 16:25
(will die on any s/// code, s/\$// is just what I spotted it with) 16:32
17:01 raiph joined 17:18 FROGGS joined 18:05 brrt joined
brrt hi #moarvm 18:05
timotimo heyo brrt :) 18:06
how are things?
brrt tired as hell :-) 18:07
18:07 btyler joined
brrt doing my bachelors project, so lot of mucking about with rats, papers, presentations 18:07
timotimo i've been more tired than usual recently; maybe it's the hayfever medication?
brrt doesn't have hayfever, thankfully 18:08
timotimo aye, it's thoroughly annoying
brrt i can imagine 18:12
next morning we'll know (or i'll know) whether my proposal has been accepted 18:14
retupmoca Fixed my segfault! github.com/MoarVM/MoarVM/pull/93 18:16
timotimo \o/ 18:17
brrt seems legit 18:18
see you tomorrow :-) 18:20
18:20 brrt left
retupmoca hrm...that wasn't the root cause of the issue however 18:22
$/ should be getting set, but it isn't in the repl 18:23
timotimo hm, it may need the same treatment as $!
retupmoca I still think spesh was wrong (it shouldn't segfault), but the actual problem here isn't spesh-related 18:24
what treatment did $! get?
timotimo well, the way we handle the repl is kinda ... weird
for example, you'll end up with a crapton of OUTER:: nested
er, i think i meant $_? or maybe $!. i don't remember :P 18:25
FROGGS the OUTER:: stuff is because every line is EVALed 18:37
timotimo every line is eval'd with the previous line as its outer :)
20:53 LLamaRider joined 22:41 colomon joined
timotimo it would be a good idea to change the link on moarvm.org for the new release (and the bit of text on what's new) before the release announcement goes out ... 23:34

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!