02:48
ilbot3 joined
03:52
vendethiel joined
04:48
sivoais joined
07:10
vendethiel joined
07:39
kjs_ joined
08:11
FROGGS joined
08:15
vendethiel joined
08:57
zakharyas joined,
brrt joined
09:29
kjs_ joined
09:35
vendethiel joined
09:44
kjs_ joined
10:44
vendethiel joined
11:05
brrt joined
11:07
rurban_ joined
11:08
vendethiel joined
12:02
kjs_ joined
12:21
brrt joined
|
|||
jnthn | Maybe p6invokeunder is something we should not inline... | 12:30 | |
13:03
btyler joined
13:43
brrt joined
|
|||
brrt | jnthn - fwiw, the issue seems to be that the spesh candidate is supposed to have a two-args-callsite, and the second of these args is really an integer | 14:09 | |
now that i'm talking about it, it seems plausible that that second argument may not be an integer at all | 14:10 | ||
just some random value | |||
and that the args buffer is really smaller than this | |||
18:40
rurban_ joined
19:03
brrt joined,
FROGGS joined
19:30
muraiki joined
|
|||
muraiki | hi all. I'm getting an error trying to build moar on (an admittedly old) freebsd using rakudobrew | 19:30 | |
oh wait, I see | 19:31 | ||
it wants clang, and I only have gcc | |||
probing whether your compiler thinks that it is gcc clang: not found | 19:32 | ||
Can't compile simple gcc probe, so something is badly wrong at build/probe.pm line 92. | |||
nwc10 | muraiki: try running Configure.pl as | 19:33 | |
Configure.pl --cc=gcc -ld=gcc | |||
(plus any other options you had) | |||
jnthn | I think --compiler=gcc is enough to get it to set the cc, ld, etc. | ||
nwc10 | ah OK. | 19:34 | |
I was searching back through command line history on a FreeBSD box | |||
anyway, unambiguous conclusion is "it should work, but you'll have to tell it not to default to clang" | |||
sigh, build system. We ought to fix it so that ... and then I think "step back, maybe there's a bigger set of things to improve" | 19:36 | ||
no, more like "step back, maybe it's more effective in the long term fixing the bigger picture problems" | |||
muraiki | thanks, I'll try that | ||
nwc10 | anyway, sorry that it doesn't just work right first time with the defaults | ||
muraiki | it's ok. I'm not a freebsd kind of person, but it's what I have at work | ||
and this is an ancient version, too | |||
nwc10 | oooh that's an interesting work | ||
most places I've worked that go open source OS are some or other linux | 19:37 | ||
even the place where the CTO likes FreeBSD on his personal machines | |||
muraiki | yeah, this place has a long history of freebsd usage, although perhaps now 10-20% are linux | ||
nwc10 | the gcc that certainly did built OK at one point is "gcc (GCC) 4.2.1 20070719 [FreeBSD]" | 19:38 | |
muraiki | nice, I have the same oen :) | 19:39 | |
ok, I got "Configuration SUCCESS." but then I also got two errors: ""Makefile", line 30: Missing dependency operator "Makefile", line 35: Need an operator make: fatal errors encountered -- cannot continue" | 19:50 | ||
oh, I wonder if I have to use gmake | |||
ok, it worked with --compiler=gcc --make=gmake --optimize | 20:26 | ||
21:07
avarab joined
|
|||
timotimo | moarvm likes --optimize=3 | 21:14 | |
i think --optimize is the same as --optimize=1 and no --optimize is the same as --optimize=2 nowadays | 21:15 | ||
jnthn | I bumped the default to 2 | ||
Let's give that some time to make sure there's no fallout, then do 3. | 21:16 | ||
Otherwise if there is fallout we won't know which is to blame. | |||
timotimo | i have been compiling and running and spectesting with -O3 for a long time :) | 21:17 | |
i saw we are waaaaayyy slower than rakudo-jvm and rakudo-parrot on one of the benchmarks | |||
deep_scan_for_string_literal or something | |||
400x slower or 500x | |||
(parrot is only 3x or 4x slower than jvm here) | 21:18 | ||
haven't had the opportunity to look more closely | |||
jnthn | Wow | ||
That's gotta be some algorithmic mis-fortune... | |||
deep_scan_for_interpolated_string_var ? | 21:19 | ||
timotimo | i think so, yes | ||
i'm getting impatient WRT perl6 performance :\ | 21:26 | ||
but i suppose most of it is still GLR-related | |||
muraiki | what's the timeline for GLR? | 21:31 | |
FROGGS | muraiki: '2015' | 21:40 | |
muraiki | that's the timeline for everything! :) | ||
FROGGS | muraiki: but pmichaud++ said that he is going to work on it mid February, so, we'll see | ||
muraiki | ok, I'm still learning about this stuff -- I was just curious | 21:41 | |
timotimo | mid february? i like that | 21:44 | |
now that i have an actual time frame, i should be able to keep my impatience under control | 21:45 | ||
FROGGS | :o) | 21:49 | |
japhb | FROGGS: But he keeps bumping the "I should be able to work on it in this window" date. Encouragingly, he said this time that if he misses the window, someone else can pick up the task. So hopefully he will be able to, but if not, Rakudo isn't blocked. | 21:51 | |
FROGGS | japhb: true | 21:53 | |
but who wants to pick up *that* task? | |||
I mean, jnthn++ can't do all three big TLA :S | |||
lizmat | I guess if we must, then we must | ||
I've been digging in all of the xxIter stuff lately, to familiarize myself with that | 21:54 | ||
just in case | |||
timotimo | brave | 21:55 | |
lizmat | perhaps, but I would hope not to have to do that by myself | 21:56 | |
timotimo | agreed, it's a big chunk of work | ||
22:13
woolfy1 joined,
woolfy1 left
22:15
woolfy1 joined
|
|||
jnthn | I don't mind too much if it falls to me, but I'm doing native arrays and NFG first. | 22:40 | |
And I still think pmichaud++ would make a far better job of it. | 22:41 | ||
I mostly just have the advantage of being a more stubborn debugger than most :P | 22:42 | ||
FROGGS | I also don't tend to give up early, but I clearly lack a CS study and a lot of knowledge | 22:44 | |
jnthn | CS studies taught me how knowledge I don't have... :) | 22:47 | |
FROGGS | the what? :D | ||
jnthn | You have to know some fields exist before you can know you don't know about them :) | 22:48 | |
FROGGS | gotcha | ||
vendethiel | *g* | 23:41 |