00:19 lizmat joined 01:38 TimToady1 joined 03:54 TimToady joined 04:23 vendethiel joined
dalek arVM: 1cf923b | TimToady++ | src/strings/ops.c:
ordbaseat should handle synthetics, it would seem
 06:00
TimToady diakopter++ too
diakopter timotimo: good morning! 06:34
06:49 domidumont joined 07:14 domidumont joined
nine timotimo: the tests you mention fail regularily here. Your branch is not at fault. 07:40
09:21 zakharyas joined 09:28 leont joined 09:52 donaldh joined 10:01 zakharyas joined 10:02 leont joined 10:15 brrrt joined
brrrt good * #moarvm 10:17
lizmat brrrt o/
nwc10 good *, brrrt 10:24
blog.pyston.org/2015/11/24/pyston-t...recording/ is updated with a link to slides at www.slideshare.net/KevinModzelewski...alk-111015
brrrt hi lizmat, nwc10 10:31
i'm still puzzling over the decision linked list / linear array
linear array, because i might want random access 10:32
linked list, because i might want splicing
i know of a way to work arround splicing, but it isn't exactly elegant
or maybe it is, depending on your point of view
so as you know, for design questions i come to you :-) 10:33
it's funny how pyston started out as a greenfield implementation that gradually merged in stuff from cpython 10:34
its like if we had started with parrot and had copied all the difficult stuff from perl5 10:35
it is of course quite a luxury to even be in such a position 10:37
JimmyZ so do you plan merge even-moar-jit before 6.c, brrrt ? 11:10
brrrt JimmyZ: no 11:12
i may be able to do that after tiler linearisation, inner-basic-blocks, and offline-register-allocation 11:13
the big three for even-moar-jit
maybe I should call them
TL, IBB, ORA 11:14
JimmyZ yeah, all looks like hard
brrrt just so you know what i'm talking about
TL touches again a lot of things, but it is mostly a mechanical transformation
i.e. i already give my tiles a number
so why not put them in a list while you're at it?
the difficulty is then in all the things that happen between emitting bytecode from a tile, those also need to be added to the list, or handled outside of it 11:15
JimmyZ integration is hard :P
brrrt in fact, having these things in a linear-list which can be scanned and of which it is easy to assert certain things, *specificially* 'which basic block is the last user of this value', is the whole point of TL 11:16
lizmat brrrt: wrt to linked list vs linear array: if you *might* want splicing, it feels like making a decision on a feature you may not need
brrrt: and hence a linear array seems like a more logical choice to me 11:17
brrrt well, let's say it this way
lizmat brrrt: otoh, if you are sure you need a *lot* of splicing, then linked list :-)
brrrt i *do* need to be able to conceptually insert loads, stores, etc into the 'linear' array
lizmat between is a grey area :-)
brrrt but, it is not actually required that i splice them directly in there
lizmat are you suggesting a mix of array and linked list ? 11:18
brrrt i.e. i can maintain a second array that holds all the spliced-in-things, along with the indexes where they should be spliced, and iterate them together
lizmat aka a linked list of arrays ?
brrrt also a possibility, yes
but i kind of like to reduce my data structure complexity as much as possible
lizmat well, a lot of re-allocs are not something you would want from an execution point of view 11:20
brrrt true
in case you want to reduce reallocs, linked lists are of course ideal
you know what 11:21
i just try the linear array first; and if that doesn't work like it should, it'll be easy enough to change to linked lists
lizmat MIW before MIF :-) 11:22
brrrt right :-) 11:24
11:50 pyrimidi_ joined 13:36 zakharyas joined 15:42 zakharyas joined
TimToady so RT #126771 is basically about running off the end of a string with nqp::ordbaseat and getting an exception 15:56
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=126771
TimToady I have a patch that makes it return -1 instead, but should we instead be forcing all usage of the instruction to check bounds more tightly? 15:57
jnthn: ^^^ Q for you, mostly
(the dicey calling code is the $im case of INTERPOLATE) 15:59
about the only downside to the -1 approach is that you might compare two -1 results and think you have a match 16:01
nwc10 there's need for a -1 but NaN ? 16:02
TimToady so I guess the question is one of philosophy and maybe consistency: how much failsoft do we allow ourselves in the instruction set where? 16:03
nwc10 I'm really not competant to answer this
TimToady nwc10: it's expecting to return an integer codepoint (non-synthetic), so -1 is not a valid return already, so we wouldn't need NaN to fight semipredicateness 16:14
nwc10 it was more the NaN != NaN thing 16:15
TimToady plus you'd have to change the return type to a floater, which is ugh
nwc10 a -1 that behaved like that
yes, that's ugh
TimToady ah
hoelzro o/ #moarvm 16:24
TimToady well, I'll probably just check in this patch, and get on with it, since it'd be a no-brainer to back it out if we decide to do it the other way
well, maybe I'd better test first :) 16:25
dalek arVM: 6da907f | TimToady++ | src/strings/ops.c:
less cowbell with ordbaseat off end of string

We now return a failsofter -1 instead of throwing.		 17:11
diakopter m: nqp::ordbaseat("",0)
camelia rakudo-moar 09a3e3: OUTPUTĀ«Invalid string index: max -1, got 0ā¤ in block <unit> at /tmp/BroV_mmcNe:1ā¤ā¤Ā»
diakopter m: nqp::ordbaseat("",-1) 17:12
camelia rakudo-moar 09a3e3: OUTPUTĀ«Invalid string index: max -1, got -1ā¤ in block <unit> at /tmp/vWHQUKUctO:1ā¤ā¤Ā»
diakopter heh
dalek arVM: 0ada249 | TimToady++ | src/strings/ops.c:
fix off-by-one noticed by diakopter++

also check for negative offset		 17:35
jnthn m: nqp::substr('x', 1, 1) 17:36
camelia ( no output )
jnthn m: nqp::ordat('x', 1)
camelia rakudo-moar 34b87d: OUTPUTĀ«Invalid string index: max 0, got 1ā¤ in block <unit> at /tmp/eW9Rrf1x0h:1ā¤ā¤Ā»
jnthn Perhaps that one wants consistentizing too
TimToady nod 17:39
jnthn ponders dinner 17:40
nwc10 it's usually better to eat dinner than merely to ponder it 17:52
jnthn well, more "what to do" 17:53
But think I've decided
bbl :)
diakopter mmm dinner 18:01
dalek arVM: 0670e3d | TimToady++ | src/ (3 files):
make ordfirst and ordat consistent with ordbaseat
 18:06
18:06 JimmyZ_ joined
JimmyZ_ jnthn: what's your plan about sync io branch? 18:07
jnthn: I want to merge my backlog branch before 6.c, because it changes the op api 18:09
TimToady m: say(nqp::ordat('x', 1)) 18:11
camelia rakudo-moar 3f8566: OUTPUTĀ«-1ā¤Ā»
TimToady m: say(nqp::ordfirst('x')) 18:12
camelia rakudo-moar 3f8566: OUTPUTĀ«120ā¤Ā»
TimToady m: say(nqp::ordfirst(''))
camelia rakudo-moar 3f8566: OUTPUTĀ«-1ā¤Ā»
TimToady m: say ord ""
camelia rakudo-moar 3f8566: OUTPUTĀ«(Int)ā¤Ā»
TimToady hmm, should probably be Nil
in fact, I need to take an audit pass on all the places that return type objects to mean Nil 18:29
jnthn JimmyZ: What op API does it change? 18:45
Ah, foudn it 18:46
I don't think it should be on sync sockets. 18:47
18:48 vendethiel joined
jnthn ah, maybe it can be 18:48
Yeah, it's more portable than I realized. :)
JimmyZ: Are there NQP and Rakudo patches too? 18:49
jnthn doesn't see an NQP one 18:50
And I fear we break async sockets on JVM without that
Could you submit a PR for that, and then an updated Rakudo one? And I'll be fine to merge the three. 18:51
18:57 JimmyZ__ joined
JimmyZ__ jnthn: there is a backlog nqp branch 18:58
you can merge it directly ;) 18:59
jnthn Oh, it's a branch
JimmyZ__ and a rakudo pr there too.
so only need to bump version 19:03
19:03 zakharyas joined
JimmyZ__ the nqp backlog branch cantains the jvm patch 19:04
03:05 am here, good night
19:10 leont joined 19:20 Peter_R joined 19:29 vendethiel joined
leont I've got rakudo-moar hanging in epoll while trying to load a module, any idea what could be going on? 20:49
This isn't making sense to me :-s 20:50
jnthn Me either :S
Any threads involved at all?
leont Yes
Erm, no?! 20:51
jnthn
.oO( Schrodingers thread )
Got a backtrace?
leont (was confusing my bugs, dealing with a two regressions at the same time)
paste.scsys.co.uk/502339 20:52
One thread
jnthn o.O
Can you MVM_dump_backtrace(tc);
timotimo perhaps it's waiting for data to be available on a file descriptor? 20:53
leont In what frame?
jnthn Maybe not 'cus you don't seem to have debugging symbols
Any MVM_ one
timotimo this is for th synchronous file read case, so that could be
jnthn MVM_io_syncstream_read_line will do
leont Nope, lack of debugging probably
jnthn aye
timotimo in that case --debug=3 in your moar's configure.pl would do it 20:54
leont I guess --moar-option in rakudo is my friend for that one 20:55
timotimo yeah 20:57
leont It wants to reuse the existing moarā€¦
timotimo hasn't used rakudos configure.pl for building nqp and moar in a long time
oh, that makes sense i suppose
nothing keeps you from just cd-ing into the oar directory, though
just make sure you give it the right --prefix
leont Which one? 20:58
leont goes nuke his install dir, seems easier 20:59
timotimo um ... just the install dir 21:02
21:17 vendethiel- joined
leont Now running with a debugging moar, getting a SIGTTOU, not sure what to make of thatā€¦ 21:44
(wait, I'm not doing exactly the same anyway, retrying) 21:45
Forget what I said about SIGTTOU, I'm now getting a SIGTTIN when calling MVM_dump_backtrace 21:48
jnthn o.O 21:49
leont Yeahā€¦ 21:50
jnthn And I'm guessing it refuses to actually dump the backtrace?
leont Yes 21:51
jnthn Joy. That was the easiest hope of figuring out exactly what readline it's trying to do.
And on what handle
leont I've just pushed to my harness branch 21:52
It should be reproducable by adding a Foo.pm that contains Ā«use TAP;Ā», and then doing ./perl6 -I. -Ilib -MFoo -e0 21:53
(haven't tried minimizing TAP.pm to the point where it no longer does this yet, may be possible)
jnthn Hmm. On Windows that explodes like this: 21:58
===SORRY!===
Missing or wrong version of dependency 'C:\consulting\rakudo\Foo.pm6' (from 'C:\consulting\rakudo\Foo.pm6')
oh, that may be leftover stuffs 21:59
hm, no
Yeah, something's wrong 22:00
And certainly depends on the content of TAP.pm 22:07
But it reports that it's Foo that is to blame
my &colored = try { EVAL q{ use Terminal::ANSIColor; &colored } } // sub ($text, $) { $text } 22:10
That line seems to be to blame
leont Interesting 22:11
Specially because loading TAP directly works fine, but indirectly apparently not 22:12
jnthn Yes
if you golf TAP.pm to the line
my &colored = try { EVAL q{ use Terminal::ANSIColor; &colored } } // sub ($text, $) { $text }
Then it still produces an identical bug here 22:13
Don't know if it gives you the same hang.
I need to go sleep now...teaching tomorrow then flight after it... :S
(Teachig is fine, but grmbl airport...plane...Friday...) 22:14
*Teaching
leont jnthn++ # doing magic
jnthn nine++, if awake, may have further ideas what's going on
But at least this reduces the surface area a good bit :) 22:15
leont Yes, quite
jnthn :)
'night
nine what's up? 22:16
leont Two one lines .pm files can make moar hang, and it really shouldn't
nine hang as in 100 % CPU or as in sleeping? 22:17
jnthn nine: A module TAP.pm with the line I posted above placed in lib, a module Foo that uses that placed in ., perl6 -Ilib -I. -e "use Foo" = hang on...Linux?...and on Windows you get "Missing or wrong version of dependency 'C:\consulting\rakudo\CertainlyNot.pm6' (from 'C:\consulting\rakudo\CertainlyNot.pm6')"
leont With your one line version in its own module, I also get "Missing or wrong version of dependency" on Linux now 22:18
jnthn Curious 22:19
nine Would use Terminal::ANSIColor be successful?
jnthn Certainly not for me
Don't have it in lib or . or anything installed
Really should sleep... o/
nine jnthn: then good night :0
:)
leont: do you have Terminal::ANSIColor? 22:20
leont No, working from rakudo checkout, though I think I saw the same problem on a rakudo that did have it installed
nine I could very well imagine that we don't unlock the .precomp/lock if module loading fails. It's a not very well tested code path. 22:21
Oh yes, I see the bug in the code 22:22
leont That may explain what I'm observing
nine What's your "finally" equivalent?
s/your/our/
leont LEAVE? 22:23
nine Trying 22:24
Now I'm getting a "Missing or wrong version of dependency"... 22:29
Pushed a fix 22:34
leont nine++ \o/
nine At least a fix for the obvious mistake. There may be more... 22:35
22:47 Peter_R joined
diakopter nine: into which repo did you push a fix 23:05
leont rakudo, github.com/rakudo/rakudo/commit/446ea7b8d8 23:07
diakopter ah, dalek must've died 23:09
leont exterminated, obviously
diakopter oh there it is 23:10
duhh
didn't look high enough

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!