00:29 itz joined
lastofthe pew! pew! pew! see you, -Wpointer-sign 00:34
lastofthe may be dancing in front of the mirror before the party
But things are further along, at least 00:35
Dare I spectest? 00:38
TimToady Are you of clan Korval? 00:40
lastofthe I'm not, I'm a Hunter nee Brunton. 00:42
TimToady if your clan's slogan is not "I Dare" then you shall have to dare on your own :) 00:44
lastofthe Nice!, now I want to know clan Korval! 00:45
TimToady well, they're in the Liaden Universe, so you can only know them in books, alas, unless you are also in a book 00:48
in which case, you're still knowing them in a book, but might not be aware of that contingency :) 00:49
but they are good books, in any case 00:50
very much about knowing when to dare :)
lastofthe Some of my favorite folks are in a book, but I think I've only really been in a book once, and I had a fever, and was young. 00:52
I like the sounds of this place.
TimToady en.wikipedia.org/wiki/Liaden_universe 00:55
I recommend reading in publication order
the prequels are not spoiled by the originals :) 00:56
lastofthe Heh, good to know :) 00:57
I'm getting ready for a trip to see a brother and a sister-in-law of mine. I'll bet my bottom dollar between them they have "Agent of Change" on a shelf. Between turns throwing a pick (I'm gonna be out there digging a hole) I bet they'll let me turn a few pages. 01:00
01:03 itz_ joined
lastofthe Is there are version of 'make spectest' that does a parallel run? 01:17
timotimo you can set the environment variable TEST_JOBS 01:19
lastofthe Sweetness, thank you.
timotimo YW :)
lastofthe ps wwaux | grep perl6 | grep spec | wc -l 01:21
4
*ahhhhh*
01:33 JimmyZ joined
lastofthe Whew. pew! pew! pew! see you, -Wpointer-sign 01:46
lastofthe has his eyes on "gcc -Wall -Werror", and whatever becomes of clang thusly. 01:48
my dancing in front of the mirror before the party is hot. 01:50
01:56 FROGGS_ joined 02:04 itz joined 02:15 cognome joined 03:03 colomon joined 03:13 JimmyZ_ joined 03:26 itz_ joined 03:28 lastofthe joined 03:30 cognome joined 04:04 JimmyZ_ joined 04:30 itz joined
jnthn Very sleep... 04:33
04:46 itz_ joined 04:57 itz joined, JimmyZ_ joined 04:59 JimmyZ__ joined 05:02 JimmyZ__ joined 05:03 JimmyZ_ joined
jnthn FROGGS_: Did you spectest Rakudo on Windows after the libuv bump? 05:08
It seems many tests that spawn are exploding... 05:09
05:10 itz_ joined 05:54 JimmyZ_ joined 06:27 woolfy left 06:51 lastofthe joined
nwc10 jnthn: for me, if libuv is built with ASAN, it seems that all the tests that spawn end up hanging. 07:04
if libuv is built normally, ASAN build of the rest, and all is good
jnthn nwc10: OK. On Windows the result is a SEGV 07:06
nwc10 jnthn: PPC bug I described last night is at Moar 645e0ef3b2d5 NQP ba3354c330e5 rakudo deef0e308c80
which was the oldest version I could get to build (was trying to find the point where the bug was introduced) 07:07
I was assuming that it is the cause at HEAD but I realised after I went to bed that I don't know this for sure. So you might recognise it as "fixed" 07:08
07:13 lizmat joined 07:19 JimmyZ_ joined
dalek arVM: 97adcd6 | jonathan++ | src/io/procops.c:
Workaround for Windows explosions in spawn.
 07:30
jnthn files an issue since this needs a closer look 07:32
But at least now spectest isn't a huge mess on Windows
dalek arVM/moritz/debian: d03e1ea | moritz++ | debian/ (2 files):
do architecture amd64 for now
FROGGS_ jnthn: I've tested both on linux and windows 07:34
jnthn Urgh 07:35
So why is it so busted on my box...
FROGGS_ I think I've seen fails about progname.t and args.t, but I had the impression that they've always failed 07:37
nwc10 jnthn: the ASAN-built libuv fails on linux made me wonder if libuv has a race condition, and the different timings with ASAN find it. 07:38
but that's like "#11907 Looking for a compiler bug is the strategy of LAST resort. LAST resort."
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...l?id=11907
nwc10 dear synopsebot, the link you want is dave.org.uk/klortho/?n=11907 07:39
lizmat wouldn't be surprised if the rakudo thread load issues are in fact libuv issues under stress
FROGGS jnthn: I reported it upstream 07:59
I perhaps bisect libuv this weekend 08:00
jnthn FROGGS: Awesome, thanks! 08:08
FROGGS jnthn: shall I pass an argument to the --debug option on windows? 08:16
jnthn I jus do --debug
FROGGS k
last time I used the msvc debugger was when we had nqp-cc O.o
the debugger is telling me that it is exploding here: github.com/MoarVM/MoarVM/blob/mast...eam.c#L202 08:20
(without your patch) 08:21
jnthn Hmm 08:24
For args.t it was blowing up where I commented out the line 08:25
nwc10 confirm, SEGV bug is spesh of MVM_OP_getattrs_n on PPC 08:43
FROGGS that's weird 08:47
jnthn: your patch makes it exit with 0 in the debugger, but in the console I still do not get any TAP output 08:48
when running perl6-m t/spec/S29-os/system.t
nine just bought Agent of Change Kindle edition for EUR 0,00 on amazon.de 08:54
08:55 brrt joined
brrt \o 08:55
jnthn FROGGS: Urgh 08:56
FROGGS: Also, socket tests explode even with my patch
walk &
FROGGS :o(
the socket stuff might be due to api changes... 08:57
brrt oh, libuv change
annoying
FROGGS perhaps we have to pass another uv_buf_t where we pass a char*
will investigate in a bit
bbi1h
nwc10 so, as per irclog.perlgeek.de/moarvm/2014-09-05#i_9305662 why is a value being written to the .lit_i16, but read from the .lit_str_idx ? 09:09
brrt hang on 09:11
well
that'd be wrong in general
lit_str_idx is 32 bits
alignment issues may cause.. issues
i.e. will cause issues 09:13
nwc10 it is causing a SEGV
this is why I know about it
brrt but yeah
ok, hmm
where does this happen?
nwc10 t/spec/S32-trig/sin.t and likely othrs 09:14
I think I've answered most questions in the backlog
brrt okok i'm going to look for it
hey i recall seeing that argument :-) 09:15
nwc10 thanks for trying to take a look
specifically, here it's MVM_OP_getattrs_n
but I suspect that all of MVM_OP_getattrs_* might be "at risk" 09:16
this libuv is not as good as the old one. On PPC: 09:35
moar: 3rdparty/libuv/src/unix/signal.c:166: uv__signal_handler: Assertion `r == sizeof msg || (r == -1 && ((*__errno_location ()) == 11 || (*__errno_location ()) == 11))' failed.
Aborted (core dumped)
for 3 NQP regression tests
09:35 JimmyZ_ joined
brrt fuuuu 09:37
i'm wondering what would be making or dealing with MVM_OP_getattrs_n 09:51
hmm 10:10
i can't find any evidence of anybody writing lit_i16 where an lit_str_idx is expected 10:11
10:13 itz joined
brrt then again, that is basically the only explanation of what happens 10:13
oplist is basically correct 10:15
ok, nwc10: what happens in getattrs_n (basically from p6opaque, at any rate) is that MVM_spesh_get_string is /not/ called 10:17
oh, i see 10:23
i'm wrong 10:24
terribly wrong
dalek arVM: ed2227e | (Bart Wiegmans)++ | src/6model/reprs/P6opaque.c:
Use indirect name for slot in p6opaque getattrs_n

This caused issues on PPC because the value of the register is encoded in 16 bits while a string index is 32 bits wide. This should have caused more issues, I might add. nwc10++ for finding the bug.		 10:27
brrt basically, MVM_spesh_get_string isn't supposed to be called there, that's what the indirection throught spesh_attr_name is for 10:28
through
it is a lucky (or unlucky) coincidence this didn't cause as much problems as it should have
because you're basically looking into the slots table with a string that might or might not exist there 10:29
nwc10 I was wondering if it was something like that
something more wrong than my diagnosis
brrt anyway, should be fixed now 10:30
:-)
lizmat does this warrant a MOAR_REVISION bump ? 10:31
brrt eh
dunno
maybe :-)
lunch &
(maybe not because jnthn was looking into libuv issues still?)
lizmat trying build with master, master to see what happens 10:33
datapoint: master/master hangs when building the restricted settings 10:41
10:47 JimmyZ_ joined
jnthn lizmat: Ouch.. 10:53
Maybe time to go back to a working libuv in master, and work on the bump in a branch... 10:54
nwc10 brrt++ 11:02
FROGGS daxim: would it be possible for you to bundle libuv 0.11.18? 0.11.28 seems to be buggy in several ways
nwc10 With that fix (cherry picked onto the commit before the libuv bump) nearly everything passes on PPC
for some reason t/spec/S32-hash/delete-adverb.t seemed to go SEGV in the spectest
other failures are consistent with problems seen on x86_64 11:03
odd, malloc corruption in t/spec/S32-hash/delete-adverb.t on PPC 11:05
but valgrind can't spot it
11:21 lastofthe joined 11:25 brrt joined 11:37 daxim joined
FROGGS the on_write callback we pass has a wrong signature... 11:46
11:49 lastofthe left
FROGGS ohh, no, I am wrong 11:50
12:07 zakharyas joined 12:32 Ven joined 12:39 woolfy joined
FROGGS jnthn: with your patch system.t outputs stuff when run using the debugger, but there is nothing when run in cmd.exe 12:41
13:01 cognome joined 13:07 JimmyZ_ joined
JimmyZ github.com/joyent/libuv/compare/66...050a95R431 # looks like this change causes some lock, which spawn hangs on 13:25
qx// doesn't work on ubuntu 14.04 too, revert updating libuv and rebuild works 13:26
FROGGS jnthn: now, after doing a realclean again (I was about to automate a bisect), the system.t passes again 13:27
JimmyZ tries 13:28
FROGGS JimmyZ: do you have a one-liner that does not work? I am on 14.04 since like 20 hours...
JimmyZ perl6 -e 'qx/umask/' 13:29
FROGGS perl6 -e 'say qx/umask/' 13:30
0002
that was with jnthn's patch, now I build HEAD^ 13:31
JimmyZ: it still works with HEAD^ of MoarVM and libuv latest 13:32
JimmyZ hmm, doesn't works here :(
with HEAD of MoarVM 13:33
FROGGS JimmyZ: what happens?
JimmyZ don't know, reverting updating libuv and it works 13:34
FROGGS jnthn: even the socket tests now pass here 13:39
... on windows
13:39 brrt joined
brrt \o 13:41
FROGGS hi brrt
brrt hi FROGGS
anything broken still? :-)
FROGGS brrt: not on my boxes 13:42
brrt that is something at least
FROGGS for me a realclean in MoarVM helps on windows and linux
using MoarVM HEAD^, aka without jnthn's latest patch
spectest details and version summary for windows: gist.github.com/FROGGS/fa7a4a88317676fd36b9 13:45
(linux in the works)
JimmyZ FROGGS: still hangs 13:47
(gdb) bt
#0 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 0x00007ffff79ff21d in uv.epoll_wait () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
#2 0x00007ffff7a0a249 in uv.io_poll () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
#3 0x00007ffff7a00927 in uv_run () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so 13:48
#4 0x00007ffff79a49ca in read_to_buffer () from /home/jimmy/OpenSource/MoarVM/install/lib/libmoar.so
FROGGS hmmm
testing on an linux x86 now... 13:49
13:50 lastofthe joined
JimmyZ x86_64 :P 13:51
FROGGS my host is 64bits where all is fine... going to test on 32bit 13:53
jnthn: only a single spectest fail on my linux box: gist.github.com/FROGGS/fa7a4a88317676fd36b9 13:54
rakudo also compiles on a 32bit linux 14:04
spectesting now 14:05
nwc10 FROGGS: that failing spectest is unfortunately a known SEGV (or ASAN barf)
FROGGS: do the NQP tests pass on your box? 14:06
FROGGS nwc10: do you have anything that explodes due to the libuv upgrade?
nwc10 PowerPC fails assertions in libuv
FROGGS nwc10: and did you realclean in moarvm? 14:07
nwc10 x86_64 was fine once I didn't build libuv itself with ASAN
git clean -dxf
that may not be exactly the right answer
FROGGS nwc10: does that cleanup submodules?
nwc10 No. Which is why I repeatedly get annoyed about git submodules
or, amongst the reasons
FROGGS it would be very very awesome if you could realclean, make install, and test the failing test again 14:08
14:09 lastofthe joined
FROGGS I hope jnthn's patch does not do any harm, since I tested the revision before his patch fine on my boxes 14:09
nwc10: can I run that powerpc stuff in a virtual box on an intel laptop or do I need proper hardware? 14:10
JimmyZ ah.... git clean -xdf doesn't clean submodules! 14:11
FROGGS gah! I was talking about REALCLEAN! :P
JimmyZ after make reaclean and it works
FROGGS \o/
I have a good feeling now :D
JimmyZ I thought git clean -xdf cleans submodules
FROGGS well, submodules are something like repositories on its own, so... 14:12
nwc10 I thought that git clean -xdff did, but it doesn't seem to
dalek arVM: cf8088a | (Tobias Leich)++ | Configure.pl:
forcing a realclean to get rid of old libuv
 14:27
arVM: 78ab168 | (Tobias Leich)++ | src/io/procops.c:
Revert "Workaround for Windows explosions in spawn."

This workaraound is not needed when we remove old libuv files.		 14:28
FROGGS now I am eager to hear from jnthn
nwc10 I am more eager for him to have a good night's sleep :-) 14:32
FROGGS yes, of course :o)
it is just that I have no idea how late it is there 14:33
nwc10 Well, we know that the timezone is +08:00 but that's not actually that helpful
lizmat he's +6 hours from nwc10 and FROGGS and me :-) 14:36
22:36 or so
FROGGS k, thanks :o) 14:37
15:34 zakharyas joined 15:41 vendethiel joined 15:47 woolfy joined 15:48 woolfy left 16:07 Ven joined
jnthn FROGGS: Am trying cleaning things up now and rebuilding, will let you know soon 16:09
FROGGS: Yes, HEAD plus realclean works \o/ 16:13
16:13 brrt joined
FROGGS \o/ 16:15
jnthn: Configure.pl does that for you now since my last commit 16:16
so innocent ppl should be kinda safe
(that's a relief)
jnthn Yay, I qualify as an innocent person \o/ 16:17
TimToady you are guilty of being innocient
*cent 16:18
FROGGS *g* 16:20
jnthn: no, you're not :P
lastofthe Some time ago I was walking by a garden in Silver Lake (Los Angeles, CA, USA) and reached out to grab a prickly pear. I didn't think, I just reached and grabbed, it was ripe and pretty. 16:22
Some of the pricles have since decided I'm not a good host, and are working their ways out of me. 16:23
This is true, and remarkably similar to how I feel about the warnings I'm squashing. 16:24
I can't decide if prickly pear puss or a silenced warning is more exciting to me right now, so I'm giving them both play. 16:26
Relatedly, is github the only convenient way to share patches? Or is a branch that is available to the public also convenient? 16:28
(or patch files, or ...)
TimToady we often use branches
lastofthe Oh, that's kind. 16:29
TimToady and pull requests for people who haven't got a commit bit yet
lastofthe You may have heard me correctly, in which case I apologize for shouting, but I meant to say: "Can I submit a branch for review from outside github's purview" 16:31
TimToady I don't know how to do that, other than with a diff 16:32
TimToady heard no SHOUTING... :) 16:33
lastofthe Someone should write a utility to patch those into an existing codebase.
:)
[Coke] if you're already working with git, then the easiest thing for us is for you to use github's pull request mechanism. 16:34
TimToady yeah, why hasn't anyone thought of that before now? :)
lastofthe Sometimes I think I'm old and inflexible for thinking that I shouldn't have to become a member of something in order to submit code to a project 16:35
[Coke] Amnesiator? I think I'd remember inventing something THAT useful.
yes, but it's not about you. it's about the project. :)
lastofthe It is, you're totally right.
[Coke] it raises the barrier of entry for us to look at your code.
lastofthe It raises the barrier of entry to submit code to look at. 16:36
[Coke] Yes. and from our standpoint, that's probably a good thing, right?
lastofthe Sometimes that's a barrier that folks aren't ready to cross, for many reasons. Sometimes completely unrelated to quality.
TimToady it's slightly intentional in this case, since the earlier <mmmph mmmph> had the opposite failure mode
[Coke] Note: I'm just a dude, I'm not the patch police. 16:37
lastofthe We're all just dudes, even the patch police :)
And I mean "dude" as a multi there. 16:38
TimToady hopefully in the west coast genderless sense, yes :)
Dude!
lastofthe Heh, yes indeed.
[Coke] as an east coaster, I'm getting sick and tired of your west coast high and might stuff. :P
*y 16:39
lastofthe Heh
TimToady nah, it's low and sneaky
jnthn I thought the west coast was sliding into the sea?
TimToady insidious surfers
lastofthe hah!, low and sneaky, yes.
TimToady jnthn: strike/slip faults go sideways, not up and down
lastofthe jnthn: but we don't even care
jnthn TimToady: Ah, right. So if you're on the right side of it, and a little patient, you get to be in Alaska... ) 16:40
lastofthe Left side of it, methinks. 16:41
jnthn lastofthe: Generally, those submitting a sequence of patches that Do The Right Thing find themselves landed with a commit bit... :)
TimToady much of the US can be explained in terms of older, middle, and younger child dynamics :)
jnthn Yes, I meant "correct" by that :)
TimToady lastofthe: only if you're facing north
TimToady is facing south currently 16:42
lastofthe begins to wonder about his feng shui
TimToady worries more about his zanshin 16:43
lastofthe jnthn: re patches: rockin'. If I'm to be completely honest, I was looking for an excuse to cry about the centralization that github has imposed (on a decentralized protocol) to modern open source projects. It rubs me wrong, but I'll get used to it. 16:44
And to be completely honest, that wasn't completely honest. Just an approximation.
recur() 16:45
And when I say "protocol" I mean "git", but I also mean "emergent social behaviour" :) 16:48
TimToady well, perhaps you'll be a part of the eventual decentralization after this swing of that pendulum :) 16:49
16:50 timotimo joined
TimToady that one always goes back and forth every half-generation or so 16:50
lastofthe TimToady: Until then, I for one, ... 16:51
It sure does seem to wobble. It's hard for me to forget that the whole idea was about making it easy to share information. 16:53
But I most certainly digress
TimToady nah, that's just half the idea; since information only flows easily downhill, you also need economic drivers for information to flow uphill 16:54
we wouldn't have google without ads 16:55
lastofthe I've never been a fan of dams. 16:56
And now that DoubleClick owns search, I'm less of a fan of it 16:57
(both)it
TimToady nonetheless, you probably turn on the light switch, and do other things to enforce the laws of thermodynamics :) 16:58
jnthn Yowser, the dynamic gen2 tuning from timotimo++ makes some good difference to CORE.setting build time...
And also a "read a million lines" benchmark 16:59
TimToady yes, we noticed that at the beginning when you were distracted
jnthn Since we end up with .lines keeping all the darn lines it ready around somehow :/
Another issue we need to solve in the list refactor.
TimToady: Hopefully the improvemnet is just as good with my re-worked version of the patch. :) 17:00
lastofthe TimToady: I knew Woodie Guthrie before I knew I missed salmon, for sure :)
lastofthe sings *Roll on Columbia* and gets back to silencing warnings
TimToady will be driving from younger child to older child for most of the next two weeks, but will continue thinking about the list refactor 17:02
TimToady really wants Perl 6 to run fast, for some unfathomable reason
timotimo huh, you mean you *still* didn't give up on Perl 6??
clearly you must be Stark Raving Mad 17:03
TimToady indubitably
up till now, I've been the only person who is not allowed to give up on Perl 6, but jnthn++ is in grave danger of falling into that category now :) 17:04
timotimo i'm not sure if i understand what that's supposed to mean 17:05
lastofthe Moar and friends are close, and getting closer 17:06
lastofthe thinks
dalek arVM: 7e8304d | jonathan++ | src/ (4 files):
Base full collections of promotion rate.

There's no point doing a full GC every N collects if we're promoting very little data each time. This patch, largely from timotimo++, uses tracking of the number of bytes promoted to gen2 to decide when to do it. This version of the patch correctly copes with blocked threads by moving where we clear and contribute the promoted bytes.		 17:07
jnthn *of, d'oh... 17:08
timotimo ah, very good
i wasn't entirely sure i did the per-thread stuff correctly
decrement_total_promoted_by is now a dead variable fwiw 17:09
jnthn oh, darn, I thought I removed that...
timotimo and you're saying this improves the timing of the core setting compilation? :)
maybe we need the pruning of excessive call graphs soon for the profiler 17:10
jnthn Yeah
timotimo did you see avuserow and me try to get a profile of the core setting compilation up? :D
jnthn Also
The profiler lies.
timotimo AHA!
jnthn Not on execution times 17:11
But on allocations
timotimo oh
that's interesting
jnthn It doesn't know about some of our allocate-y extops
timotimo oh, so we're actually allocating even more than it already shows?
jnthn Potentitially yes
Well 17:12
The GC numbes are always correct
But the Allocations tab mises some things.
timotimo right, makes sense 17:13
so ... the html file avuserow pried out of the profiler's smoldering remains was 1.1gb big. it took "only" 22 hours and 59 minutes to finish up ...
jnthn o.O 17:14
timotimo how do you feel about we directly print out the data into the file instead of concatenating strings together?
jnthn Did anybody have a web browser that could load a 1.1GB file? :)
timotimo that may improve things
i tried it with firefox and chrome, both didn't want to
firefox seemed to just ignore the script outright
chrome very quickly said "oops, this tab has crashed. want to try again?"
jnthn So much for web scale... :P 17:15
timotimo no, this is already Big Data
jnthn Quick! To the cloud! 17:16
timotimo it ballooned up to 40 gig of maxrss i believe
jnthn o.O
timotimo anyway, gotta BBL :)
it == the profile dumping thingie
jnthn Nice box avuserow++ has...
timotimo aye
jnthn And that he set it on this
timotimo we shouldn't require that kind of box to profile the core setting compilation, though :)
jnthn Yes. 17:17
I think I need to look at pruning the graph
timotimo hah! i managed to convince you! ;))
jnthn The million lines thing goes from 52.165s to 43.998s with the gen2 tuning :) 17:18
It was 71.016s at the start of the day, before my take patches, then lizmat++'s many patches. 17:20
timotimo sweet! 17:33
jnthn Another 1.5s off with local patches 17:35
timotimo it's kind of sad, that we can't benefit from our ropes for doing the chomp thing 17:37
lastofthe Y'all here might be the folks to ask this question of, and it's one that's been on my oatmeal lately... 17:42
I came here via Julia, because it has multimethods. I wondered, "who else" 17:43
timotimo i recently attended a little presentation of julia by a friend, who's a physicist 17:44
lastofthe and found lisp (CLOS) and ocaml and a couple others, but perl 6's multis seem special to me in that parameter values can be used for dispatch
timotimo i need to finally get off my lazy butt and do the ipython protocol thing, god damn it.
lastofthe And I thought, "that must be hard to optimize", but when I thought about that some more, I couldn't figure out why I thought that. 17:45
timotimo heh. 17:46
we're quite fortunate that we are allowed to assume multi subs are "fixed" at the time we encounter them in the optimizer
but multi methods are, of course, virtual
lastofthe Are they fixed because the parameters are unboxed and inspected before they are passed along? 17:47
timotimo oh, no, not like that
lastofthe realizes he might just be using words, here
timotimo i meant the list of candidates cannot be changed "afterwards"
so if we see an 1 + 1 we can already go ahead and look for the right candidate of &infix:<+> and we even inline small subs like that 17:48
lastofthe Oh. Can multis not be punched into the symbol table at runtime?
timotimo they can, but then you get zero guarantees for runtime behavior
lastofthe behavior or performance? 17:49
timotimo if you invoke the multi sub indirectly, it'll likely be fine
TimToady lexical scopes are officially immutable once finished compiling
timotimo right, was just about to correct my claim there
lastofthe Cool, I dig it.
And can thusly be passed around, I imagene. 17:50
TimToady and we make a very careful separation between things that belong to the current language, and are fixed in the current lexical scope, vs things that belong to the objects, which are virtual by default
lastofthe even imagines
TimToady operators belong to the current language, methods belong to the objects
timotimo you can probably dig deep into VM internals to F with a multi sub's candidate list, but at that point, any given call to that sub may already have been inlined or candidate-decisioned (o_O) at that time and may not even know what multi they'd *have* to look at
TimToady at the end of compilation, the compiler is also allowed to close and finalize classes that haven't been pried open or already derived from 17:52
but we don't do that optimization yet
in fact, we don't even implement the LINK phaser yet, which is when that would happen
lastofthe TimToady: okay. When one multifies an operator, does that push it over a boundary?
lastofthe needs to read some specs, probably 17:53
timotimo no, it does not
TimToady only the boundary that it is legally a double dispatch, first to the proto, and then the proto redispatches to the multis
but that's almost always optimized away
timotimo the operator has to be declared "multi" or a "proto" has to be created on the first definition for that operator
(or you can override a previously multi operator with a non-multi operator in a lexically "inner" scope with the "only" keyword)
(or by providing a new proto, i believe) 17:54
TimToady
.oO(if you cannot afford a proto attorney, one will be provided for you)
lastofthe That's fantastic. 17:55
TimToady well, we think so, but we're known to be prejudiced in the matter
timotimo i don't think i can provide an outsider's view on perl 6 any more, even though i've only been involved some 2 years 17:56
(has it been that long already? wow.)
TimToady we have been thinking about this a goodly long time now, so we'd like to think we've got a few things right by now :)
and still have a few things wrong we want to fix
17:57 zakharyas joined
lastofthe By all rights, you all have! Multimethods seem to be a bit of a tough thing for folks outside of a world that intersects with ML/CLOS to get right, I'm sure I didn't get the right in my head until I instersected with those worlds. 17:58
s/right/Mu/
(..you all have!): got some things right, that is 18:00
18:01 brrt joined
TimToady well, and we don't think CLOS got multis right either :) 18:03
our rules are agnostic to parameter order, unlike CLOS
lastofthe No, but one could make them right :) 18:04
TimToady (Int,Num) and (Num,Int) are both considered the same distance from any (X,X)
so formally ambiguous 18:05
timotimo ah, that. of course.
TimToady whereas CLOS, iiuc, would pick the left one over the right one
well, Int and Num are a bad example maybe 18:06
since they are only cousins
but yeah, CLOS does more cascading decisions left-to-right, and we don't 18:07
lastofthe That's also fantastic. 18:08
TimToady but that's sort of the historical FP bias coming through of priviledging the car over the cdr
lastofthe Which makes not having syntax easy, which is maybe an odd thing to optimize. 18:10
TimToady if we all optimized for the same things, life would be kinda boring :) 18:11
lastofthe Can I get an ...
TimToady m: say 0,1,*+* ... * 18:12
camelia rakudo-moar 4a7429: OUTPUT«0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765 10946 17711 28657 46368 75025 121393 196418 317811 514229 832040 1346269 2178309 3524578 5702887 9227465 14930352 24157817 39088169 63245986 102334155 165580141 267914296 433494437 701408…»
lastofthe Show off :) 18:13
TimToady ayah... 18:14
18:14 teodozjan joined
timotimo m: say 1 , *.rand ... 0.0001 18:16
camelia rakudo-moar 4a7429: OUTPUT«1 0.185797766360854 0.134341292914885 0.0126081342347814 0.00654983537965583 0.00357668111091382 0.00240665709688171 0.00113202482912126 5.32329151742171e-05 3.44407453064244e-05 9.11938041984839e-06 7.08717585672882e-06 8.48999551213041e-07 4.502952053892…»
lastofthe My new seed for everything 18:17
timotimo m: say (1, 1 , *.rand + *.rand ... 0.0001) 18:19
camelia rakudo-moar 4a7429: OUTPUT«1 1 1.28732767501881 0.712114840272033 1.32522605348956 0.904939122185709 0.885580364714935 0.912687391448989 1.11714281386194 0.805584158737667 1.41191989868245 1.03590889369564 0.310556727034583 0.362401945299584 0.270688460496896 0.334274831310506 0.443…»
timotimo pretty <3
18:30 FROGGS joined
brrt ugh, i'm into java distributed systems middleware land tonight, wish me luck 19:00
19:21 lastofthe joined 19:29 vendethiel joined, xiaomiao joined 20:11 brrt left 20:17 lastofthe joined 20:32 lizmat joined 20:33 woolfy joined 20:50 lastofthe joined
avuserow timotimo: it's might be worth mentioning that "my" machine (at $dayjob) with lots of memory is fairly old so it's not very fast, at least CPU-wise. I think it's 2009-vintage. Plus it's actually a VM, so I figure it might be up to ~10% slower for CPU/memory 21:47
timotimo oh, hm 21:55
fair enough
but we *still* need to make it faster :D
did it swap memory out, btw?
avuserow I think it swapped out some of the base system but not moar
since it had a few MB of swap used when I came back, but the time output didn't say any swaps happened 21:56
I've noticed Linux does that as a precaution when memory gets used a bunch (for certain values of "a bunch")
[Coke] had to skip a a few commits doing this rakudo-jvm bisect, another weird build failure showed up. 22:10
timotimo :< 22:12
22:55 nebuchadnezzar joined 23:55 colomon joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!