00:54 tokuhirom joined 02:27 tokuhirom joined 06:00 domidumont joined 06:06 domidumont joined 06:12 domidumont joined 06:17 ggoebel joined 06:34 Ven joined 06:50 FROGGS joined 07:40 ShimmerFairy joined 07:47 leont joined 08:02 zakharyas joined 08:33 zakharyas joined 08:50 donaldh joined 08:58 Ven joined 09:16 lizmat joined 09:34 brrt joined
brrt \o #moarvm 09:34
FROGGS o/
jnthn o/ brrt 09:35
nwc10 \o/
brrt ohai jnthn nwc10 09:37
i have news
i've finally gotten around to looking at the dynvar bug under gdb
turns out, sometimes the jit return label is zeroed 09:38
even when it is in the call stack
somehow, that never yields the segv that i expect
jnthn yowser
brrt at any rate, just one of the possible causes would be trying to load a label which didn't really exist 09:39
that would give me a good excuse to redo that labelling properly
jnthn :)
brrt++ for hunting it down further
brrt on the other hand, i kind of suspect something like OSR, since this problem happens after a very specific number of iterations 09:40
however, iirc, it wasn't actually sensitive to OSR
so you may disregard that suggestion
dalek arVM: 6aecd2a | jnthn++ | / (8 files):
Stub in fc (fold case) op.

Just as an alias for lc at present.		 09:44
brrt supposes a watchpoint might help
hmmm, or there are more creative solutions 09:47
nwc10 hangon - foldcase is something Perl 5 does better than Perl 6? 09:48
the future is not evenly distributed yet
jnthn nwc10: Working on correcting that ;) 09:49
brrt what is foldcase, actually 09:50
ShimmerFairy jnthn: if/when you get to full case mapping, do you intend to make the simple variants readily available? (I thought of Stringy.suc, .slc, etc.) Or would one need to go through the appropriate unicode properties for that (which wouldn't be so terrible)? 09:52
jnthn brrt: www.w3.org/International/wiki/Case_folding 09:54
ShimmerFairy: No, wasn't going to make the simple ones so readily available
ShimmerFairy: If we find there's a pressing need for it we can in the future.
ShimmerFairy jnthn: in doing that draft of S32::Stringy a bit ago, the only place in core I recall possibly wanting it would be .samecase , if you didn't want .samecase to change string length. 09:55
brrt oh wow, that is... awefully complex 09:57
arnsholt brrt: Welcome to natural language =) 10:00
nwc10 Greek trailing sigma 10:01
ShimmerFairy brrt: that wiki page is a bit misleading. Actual case folding amounts to just using the list provided in the UCD, ignoring the stuff that's considered tailoring (e.g. the Turkish i thing should be just in Turkish contexts)
10:02 travis-ci joined
travis-ci MoarVM build passed. jnthn 'Stub in fc (fold case) op. 10:02
travis-ci.org/MoarVM/MoarVM/builds/84058955 github.com/MoarVM/MoarVM/compare/f...ecd2a70ee6
10:02 travis-ci left
brrt wonders if it'd be sensible to have, above the 'String' abstraction, a 'Text' abstraction, which also has a language / locale tag attached to it 10:02
ShimmerFairy brrt: I imagine modules would probably subclass Str to add locale stuff. I think the CLDR is probably important in how that plays out, but (understandably) Perl 6 hasn't touched it so far :) 10:03
brrt i gues we shall see :-) 10:04
brrt afk
10:04 brrt left 10:08 Ven joined
dalek arVM: 0026f25 | jnthn++ | src/strings/ops.c:
Refactor to get rid of a macro.

To make it easier to do further refactors to case changes.		 10:09
_itz stackoverflow.com/questions/445643...me-to-a-so 10:18
(from another channel)
jnthn *lol* 10:19
_itz++ 10:20
dalek arVM: e8c972f | jnthn++ | src/strings/ (4 files):
Preparatory refactor for length-changing case ops.
 10:34
arVM: e1d59e6 | jnthn++ | src/strings/ (3 files):
Get simple case folding using case fold data.
 10:58
10:59 Ven joined
jnthn Lunch, then I gotta work on some not-6 stuff for several hours this afternoon; bbl 11:00
11:08 Ven_ joined 12:31 Ven_ joined 12:46 brrt joined
brrt speaking of HN topics, did anybody see the one about the demise of JITs? 12:48
arnsholt Yeah, that one was interesting
Although given the title, I thought it was about jitter, not JITs =)
jnthn Didn't see that one...link? 12:49
brrt original topic: blog.metaobject.com/2015/10/jitterdammerung.html
hn discussion: news.ycombinator.com/item?id=10344601
needless to say i disagree
'when you need predictable performance, a JIT is not for you' - is the summary 12:50
but you know, that's hardly the universe of possible programs 12:51
jnthn You could sorta say the same of GCs 12:58
Except giving time bounds on JITs doing their work and returning control to the program seems a lesser problem than doing it with GCs, and there's already been plenty of research into hard real-time GC 12:59
brrt you would say the same of gcs
hmmm
yeah
that is actually very much possible
jnthn Well, that's my sorta. You can say it, but it only makes sense if you ignore recent developments :)
brrt what recent development would you be thinking of? 13:03
jnthn brrt: Well, if you said 20 years ago GC was incompatible with hard real time, then there probably wasn't so much research to point to that would refute the claim. Today, afaik, there is. 13:05
brrt oh, yes, in that way :-) 13:08
gcs are still a minor hobby of mine
13:17 kjs_ joined 13:32 TimToady joined 13:39 zakharyas joined 14:14 FROGGS joined 14:44 Ven_ joined
_itz I'm getting warnings with moar and VS2015 .. some docs refer to VS2010 .. should I be using that? 15:06
jnthn _itz: I get a handful of warnings at the moment on 2013 15:07
_itz: They're harmless afaict
(Though will still be nice to clear up) 15:08
_itz srcjitemit_x64.dasc(2103): warning C4293: '>>': shift count negative or too big, undefined behavior 15:09
linking moar.dll
jnthn ooh, I ain't seen that one before 15:11
Very shifty
15:19 nbiiebbiih joined
[Coke] camelia, Perl 5's shifty little sister. (alt: Perl 5's little shifter) 15:48
_itz ) 15:53
:)
15:53 tokuhirom joined
TimToady misread shifty :) 15:54
15:56 pyrimidine joined 16:01 pyrimidine joined 16:05 kjs_ joined 16:07 donaldh joined 16:24 donaldh joined
dalek arVM: b7283d6 | brrt++ | src/core/frame.c:
Spaces, no tabs
 17:14
17:18 pyrimidine joined 17:23 FROGGS joined
timotimo a tremendous fix! :) 17:50
(yeah, yeah, i haven't had a proper commit in O(weeks) )
[Coke] tabs are evil and must be eradicated. I approve this commit. 17:53
17:55 tokuhirom joined 18:24 Peter_R joined 18:52 lizmat joined
jnthn
.oO( TabToady )
 18:54
18:54 lizmat_ joined 19:25 dalek joined
FROGGS jnthn: btw, I'm ready when you are :o) 19:46
dalek arVM: 5affc05 | jnthn++ | src/strings/unicode_ops.c:
Handle growing case of foldcase operation.

Only for fc; uc/lc/tc still to come.		 19:57
arVM: 01bd7d9 | jnthn++ | src/strings/ops.c:
Basic handling of strings growing on case change.

Needs integrating properly with NFG yet, however; some of these are cases where a case change will need to produce a synthetic.
jnthn > say(nqp::fc('Scheiße!')) 19:58
scheisse
FROGGS that bang goes missing :o(
jnthn Yeah, wtf
FROGGS haha
I thought that was intention :D
jnthn ohhh 19:59
I'ts not *intended* to go missing
FROGGS but "scheisse" hints on something going wrong :o) 20:00
jnthn Indeed
It's the first German word I could think of with a ß in it
But I thought of maß soon after
oh, duh 20:02
FROGGS Straße
jnthn It wasn't using the grapheme iterator properly 20:03
And got away with it before
FROGGS you have to think out of the bottle :P
jnthn scheisse!
Better.
dalek arVM: bf60b13 | jnthn++ | src/strings/ops.c:
Fix a couple of growing case change thinkos.
 20:04
jnthn OK, enough Unicode crazy today. Let's look at the serialization thing. 20:07
FROGGS \o/ 20:08
jnthn What do I need to do? Grab the repo you gave me a couple of days back? 20:09
FROGGS aye
git clone [email@hidden.address]
jnthn got it
FROGGS perl6 t\01-basic.t
jnthn 6 passes, 7th fails? 20:10
FROGGS aye
when you look at the test, the failing test fails because $a does not get modified
my first question: is this about lazy deserialization? 20:11
jnthn Lemme build a Moar without lazy deserialization and try it :) 20:13
FROGGS hmm, how?
I tried to do that but did not find the right spot
jnthn #define MVM_SERIALIZATION_LAZY 0 20:14
FROGGS duh
jnthn Well, it's 1 normally
Top of src/6model/serialization
FROGGS I grepped for /:i lazy/ :o(
jnthn Anyway, the answer is no
It still fails with lazy deserialization turned on
oh 20:15
With it turned off
FROGGS :/
jnthn Which is kinda a relief 'cus that coulda been quite the debugging "fun"
20:15 travis-ci joined
travis-ci MoarVM build errored. jnthn 'Basic handling of strings growing on case change. 20:15
travis-ci.org/MoarVM/MoarVM/builds/84170844 github.com/MoarVM/MoarVM/compare/b...bd7d990783
20:15 travis-ci left
FROGGS depends, it could just be that the scdisclaim op does not do enough 20:15
jnthn More likely, yeah 20:18
FROGGS but anyway, it seems (again), that hitting a write barrier helps...
and I forgot why
(you explained it months ago)
jnthn wonders if this is one of those awkward dusty corners of serialization
FROGGS jnthn: because, if you change push to unshift, it fails too 20:20
and that's because only the push_o op has a MVM_SC_WB_OBJ 20:21
FROGGS gets another cuppa 20:22
jnthn But wait, what actually fails? 20:26
20:27 travis-ci joined
travis-ci MoarVM build errored. jnthn 'Fix a couple of growing case change thinkos.' 20:27
travis-ci.org/MoarVM/MoarVM/builds/84172055 github.com/MoarVM/MoarVM/compare/0...60b1331a4b
20:27 travis-ci left
jnthn omg, you won't believe this 20:27
[Coke] YOU WON'T BELIEVE WHAT HAPPENED NEXT
jnthn FROGGS: So, the constant 42 20:28
FROGGS: It's in the SC of the program (thus -e)
The serialization context ID is computed by the source
FROGGS when we deserialize, do nothing, and serialize, the string heap seems broken
jnthn No no 20:29
Try this
Take any of the tests
Say, the third
Add a single space before the closing quote
So instead of
serialize($a)'
It's
serialize($a) '
Note that it now fails at *that* point
The 42 is in the SC of the program (-e) 20:30
And when you have identical programs then they get the same SC hash
And so it finds the program it was linked against with the 42 and resolves it
But as soon as you have a different program, it can't find that constant 42 any more 20:31
*That's* why it fails
Nothing to do with the push
FROGGS ahh!
damn it
bloody hell
jnthn :/
But yeah, can see how you got yourself chasing dwon the wrong rabbit hole
FROGGS but what can I do? 20:32
I *want* to able to change my script
without invalidating the serialized thing
I thought I "chown" that 42 when serializing it? 20:34
jnthn It's bounded serialization, so it works up to the point you encounter an already owned object
The 42 is never unowned though; it's owned as a result of being in the program's constants table.
FROGGS so Ser.pm:8 does not do what I think it does? 20:35
hmmm
jnthn It sets the SC of $obj - which is actually (due to is copy) a Scalar container, I guess
But yeah, it's not a deep operation 20:36
20:36 colomon joined
jnthn It means "this exact object" 20:36
Nothing recursive.
FROGGS yeah
jnthn [A::Class::From::Another::CompUnit, And::From::A::Second] # this array needs to be linked against the objects owned by the two other comp units, for example
FROGGS: I need to go rest now, but can you write me up your actual use case for this, so I can ponder a solution? 20:38
I wonder if we can "re-bound" or some such...
FROGGS jnthn: will do
jnthn: gnight :o)
jnthn 'night
20:48 tokuhirom joined 21:03 kjs_ joined 21:06 japhb joined
masak 'night, jnthn 21:09
21:37 colomon joined 21:41 donaldh joined
dalek arVM: 656358f | (Tokuhiro Matsuno)++ | src/io/syncsocket.c:
Check return value of uv_listen().
 22:34
arVM: 08ded20 | lizmat++ | src/io/syncsocket.c:
Merge pull request #279 from tokuhirom/check-uv_listen-retval

Check return value of uv_listen(). Throw AdHoc exception if it's failed.
arVM: bf2f733 | cygx++ | src/core/interp.c:
Add missing const
 22:36
arVM: 1cbbb2b | lizmat++ | src/core/interp.c:
Merge pull request #280 from cygx/patch-1

Add missing const
lizmat jnthn: hope this will save you some work 22:37
22:54 tokuhirom joined 23:05 travis-ci joined
travis-ci MoarVM build passed. lizmat 'Merge pull request #280 from cygx/patch-1 23:05
travis-ci.org/MoarVM/MoarVM/builds/84199423 github.com/MoarVM/MoarVM/compare/0...bbb2b693ab
23:05 travis-ci left

Powered by Cro and the Raku® Programming Language.

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

Thank you!