[Tux] This is Rakudo version 2016.05-6-g2c45068 built on MoarVM version 2016.05 06:11
test 20.440
test-t 13.533
csv-parser 35.139
nine AlexDaniel: please don't 06:21
AlexDaniel nine: ok, but what's your reasoning? 09:05
llfourn I think it's not worth it because git blame etc is less clear if there's a bunch of lines changed with "whitespace removal" as the commit 09:21
brrt also, very difficult to check all these files by hand if there are no sudden and unexpected changes of semantics 09:25
which would be bad
AlexDaniel llfourn: git blame -w 09:33
llfourn AlexDaniel: cool didn't know about that thx! 09:34
AlexDaniel brrt: you mean when whitespace is part of the test? I've checked the diffs. 09:35
brrt i know. but i haven't
and neither has anyone else
llfourn wonders if he can do git blame -w with magit 09:36
brrt probably an emacs variable you can define
llfourn actually it's built into magit magit-blame-popup lets you enable it :) 09:39
AlexDaniel llfourn: also, if you're using github, then just add ?w=1 to the url
llfourn nice. 09:40
brrt i'm no authority AlexDaniel, it may be worth it 09:45
but i wouldn't be able to tell you
AlexDaniel my problem with it is that a lot of people have their editors set up in such a way that trailing whitespace is shown in red. When you open a file that has a lot of that, it shines up like a christmas tree and makes you cringeā€¦ It looks a bit unprofessional, IMO 10:13
another point is that people tend to delete trailing whitespace anyway, e.g. see github.com/perl6/roast/commit/25c4...36a9e96R52
so it pollutes the diffs anyway, it is just spread across many commits 10:14
.oO( bikeshedding againā€¦ )
stmuk I don't understand why anyone would care about trailing whitespace 10:30
RabidGravy I've worked with people who get quite agitated about it 10:35
jnthn Some quite widely used editors will also put whitespace characters on an "empty" line that correspond to the indent of code lines above/below. 10:36
stmuk I've worked with people who wouldn't eat different coloured vegetables which touched as well :) 10:37
jnthn And that is often counted as "trailing whitespace" too. :/
stmuk I'd be annoyed by trailing whitespace at the end of a file (more common with emacs users than vim) 10:38
RabidGravy stmuk, I think I recall the person in question 10:39
AlexDaniel stmuk: why? 10:42
stmuk: I mean, why is it worse than 5 extra spaces at the end of some line
no newline at the end of a file ā€“ I get that, some tools freak out because of that 10:43
RabidGravy I keep meaning to go through the moar source to fix that, there's quite a few files that a C compiler of a certain vintage moans about 10:58
brrt the same c compiler that complains about %ld not being the right thing for $lld 11:03
long long decimal
stmuk AlexDaniel: I think you have to go out of your way with config to see trailing whitespace at the end of the line whereas trailing lines at eol are visible in some default editor configs 11:16
brrt whitespace-mode shows it directly in emacs
i think whitespace-mode is very useful
AlexDaniel it is, yes 11:18
stmuk but its not a default mode in emacs whereas vim does show trailing lines by default
AlexDaniel but I think that spacemacs displays trailing whitespace even when whitespace-mode is off
[Coke] it's possible to write a script to do blame that skips whitespace if we need it. 12:27
I find that non-conforming code still bugs me these days, but not enough to keep it fixed like I've had on other projects. 12:28
(esp. when I'm not the one who decides what "conform" means.)
oh. git blame -w, even better. 12:31
hoelzro o/ #perl6 13:03
[Coke] hio 13:10
AlexDaniel OK so I'll submit it as a pull request tomorrow. Those who are against are welcome to downvote it :)
hoelzro I think I may have found a rakudo bug, but it may be a misunderstanding of how nextsame works 13:15
multi sub foo { bar }; sub bar { nextsame }; foo() 13:16
should that nextsame dispatch to other &foo candidates (if there were any)?
jnthn No 13:18
If it does it's a bug
(Does it? :))
The nextsame has to appear lexically within the multi, though
hoelzro jnthn: it seems to; at the very least, it doesn't throw a "no dispatcher" error 13:19
jnthn Are you sure? 13:20
nextsame is designed to be quiet if there's nowhere for it to dispatch to
m: sub foo() { nextsame() }; say foo()
camelia rakudo-moar 2c4506: OUTPUTĀ«nextsame is not in the dynamic scope of a dispatcherā¤ in sub foo at /tmp/ewT5vCAlHr line 1ā¤ in block <unit> at /tmp/ewT5vCAlHr line 1ā¤ā¤Ā»
jnthn Oh... 13:21
Hmm
I thought an only would clobber the dispatcher. Hmmmm.
hoelzro m: multi sub outer(Any $) { say 'any way you want it' }; multi sub outer(Str $) { inner() }; sub inner() { nextsame }; outer('foo')
camelia rakudo-moar 2c4506: OUTPUTĀ«any way you want itā¤Ā»
jnthn Curious.
hoelzro my thoughts too
jnthn: should I RT that?
jnthn Yeah, I mean it may be OK but I'm not really sure it is :)
hoelzro well, I dug into this because of a problem we had with Test::subtest just before the release 13:23
it was changed to a multi, which interestingly enough broke a test using nextsame 13:24
nine AlexDaniel: yes, there's probably a solution for every way one can do a git blame. But every user will have to know and use them. 13:33
dalek p: d0b3b6e | brrt++ | t/moar/50-jit-register-alloc.t:
Add test for even-moar-jit register allocator

The current register allocator can't spill registers, so it may run out of them and die.		 13:34
nine AlexDaniel: for example, I've no idea how to tell vim to ignore whitespace for :Gblame
AlexDaniel nine: what about :Gblame w 13:43
[Coke] nine - you ever run the perl6 doc site builder, htmlify?
getting warnings on " $handle = $precomp.load($id);", where precomp isa my $precomp = CompUnit::PrecompilationRepository::Default.new(store => $precomp-store); 13:44
AlexDaniel nine: ā€œYou can give any of ltfnsewMC as flags and they will be passed along to git-blame.ā€
[Coke] (issue might have nothing to do with precomp, digging more...) 13:45
AlexDaniel or maybe it is :Gblame -w 13:46
[Coke] nine: looks like the uninitialize value in str contet warning is coming from inside CompUnit::PrecompilationRepository's precompile method. 13:57
is there a way to get ll-exception to work with warnings? 14:09
if my diagnosis is right (that the warning is coming from the compunit code), then --ll-exception isn't changing the reporting. 14:10
nine [Coke]: no, haven't tried it. 15:45
[Coke] nine: doing a special run with a locally modified perl6 to see if I can figure out where it's coming from. 16:30
tadzik++ for making GIT_PROTOCOL work everywhere. 16:32
nine: do you think it's OK for a non core script to be using the CompUnit::* stuff directly? 16:36
nine [Coke]: it's slowly becoming ok. There's still one open PR that will change interfaces to be much closer to S22. 16:37
[Coke]: which parts would you like to use? 16:38
[Coke] ok. Takes a few dozen seconds for me to add debug prints here and narrow it down, but I'm guessing the problem is the run() of perl6 in the precompile(). 16:39
nine: I'm just looking at github.com/perl6/doc/blob/master/h...fy.p6#L160
nine [Coke]: maybe $source-name? 16:40
Ah yes, there's no $source-name: github.com/perl6/doc/blob/master/h...fy.p6#L171
[Coke] yup, github.com/rakudo/rakudo/blob/nom/...ry.pm#L204 is what's warning. 16:41
is source-name required?
(but not marked as such?)
nine Without it backtraces of the precompiled files will be useless but should otherwise work
[Coke] should it default to "", perhaps? or something like "<unspecified>" ? 16:42
I mean, I can just update htmlify.pl to pass it in for now, obv.
nine $path.Str should be a good default 16:43
source-name is really a workaround for the unreadable sha-1 file names. It's basically "$path ($module's-short-name)"
[Coke] trying a patch with that. 16:47
nine++ for finding it in 3 seconds. :) 16:48
nine Well there weren't that many candidates :) 16:49
[Coke] IWBNI this worked in rakudo: GIT_PROTOCOL=ssh make stresstest 16:50
(but it's fine that it doesn't) 16:51
nine: ok. that fixes htmlify (adding the default to rakudo) - doing a test run to make sure nothing else explodes. 16:52
[Coke] goes for lunch/walks 17:01
dalek kudo/nom: 7a98505 | coke++ | / (2 files):
Provide default for precompile()'s 'source-name'

We use this value in a Str context, so warnings will be emitted. Pick a sane default (nine++).
Avoids many warnings for perl6/doc's htmlify		 18:47
[Coke] crap. s/will be/would otherwise be/
ah well
nine [Coke]++ # thanks for fixing my mishaps :) 18:48
[Coke] is anyone hacking on the html profiler? I'd like to improve the responsiveness. 19:19
a 65928890 byte file is really show to load (chrome is actually OH, SNAP dying on it)
just didn't want to step on anyone's toes.
timotimo the only thing i know about is someone working on making the json dump code faster 19:22
nine It's amazing how modern software stacks can make sheer unlimited computing power unbearingly slow 19:25
[Coke] spare run of htmlify is still unusably slow in the profiler in chrome. ah well. 19:26
*sparse
timotimo yeah, you're right 19:27
the best way to make it work is still to try to build limiting the depth of the emitted call graph in moar, IMO
i mean, i suppose you could do the work in nqp, too. as a post-processing step
or even build a program that does that to the already-written .json file 19:28
jdv79 i think its the json parse that's the, at least initial issue. 19:48
i almost feel like its november again when i was complaining about the profiler perf. or around november at least. 19:49
nine thinks the profiler's UI should be a locally running client/server application with profile data deserialized on-demand and the browser being fed what's necessary for display 20:12
dalek kudo/nom: b348f2f | coke++ | .travis.yml:
Track channel rename
 20:17
[Coke] maybe that'll get the travis comments to come here. 20:18
I see that rakudo-jvm is failing. that a result of my commit, or a holdover? 20:20
travis-ci Rakudo build failed. Will "Coke" Coleda 'Track channel rename' 21:20
travis-ci.org/rakudo/rakudo/builds/132380962 github.com/rakudo/rakudo/compare/7...48f2f02147

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!