00:02 softmoth left, patrickz left 00:09 patrickb left 00:25 leont left 01:51 squashable6 left, squashable6 joined 02:42 softmoth joined 07:21 sena_kun joined 07:37 MasterDuke joined 07:51 leont joined 08:12 softmoth left
lizmat Files=1306, Tests=111378, 216 wallclock secs (28.78 usr 8.43 sys + 3020.06 cusr 277.27 csys = 3334.54 CPU) 08:47
09:00 patrickb joined 09:22 Altai-man_ joined
[Tux] Rakudo version 2020.05.1-272-g7bace1bef - MoarVM version 2020.05-60-g852576e7d
csv-ip5xs0.827 - 0.830
csv-ip5xs-207.922 - 8.055
csv-parser25.933 - 26.793
csv-test-xs-200.387 - 0.393
test7.933 - 8.107
test-t1.893 - 2.131
test-t --race0.847 - 1.077
test-t-2032.051 - 32.430
test-t-20 --race9.195 - 10.698
 09:23
09:25 sena_kun left
lizmat jnthn: reprepare-raku-list in bootstrap, is there a reason for that? or was it just convenient to cat-license "prepare-list" 09:42
*re
Geth rakudo: 0b48651ccf | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Simplify multi/single capture handling

  - don't special case a single name on split		 09:50
jnthn lizmat: See commit message of 992f1b83 for background 09:55
linkable6 (2020-02-21) github.com/rakudo/rakudo/commit/992f1b83f8 Fix mixing in Raku-level code to the grammar
lizmat jnthn: ok, so moving that logic to HLL would not be a bad thing then 09:56
for the raku case, I mean
jnthn Hm, but why? 10:03
lizmat because then I could merge it with the other logic building the Match object 10:20
I think we're running over things at least twice
afaics, the only thing we really need, is a check for producing empty lists for unmatched captures with + or * 10:21
as in "a" ~~ /(z)*/
jnthn My recollection (hazy) is that there's a pass over the static captures data to set up empty lists for +/* captures, and then a pass over the capture stack to populate things 10:22
lizmat right, so why could they not be merged ?
for the Raku case 10:23
jnthn e.g. I *think* they're over two different things, and you can't get away with not doing the first, because you still need the empty array if there's no captures
m: "" ~~ /(a)*/; dd $0
camelia Array element = []
jnthn So if you only go over the cstack then you'd never find a capture to tell you to set up the empty array 10:25
lizmat hmmmm
jnthn I think I remember this because I tried what you're trying too :)
lizmat hehe... challenge accepted :-)
jnthn And I think it was after that, that I started pondering not building the list/hash at all unless actually asked to 10:26
lizmat I might wind up there as well... 10:27
jnthn (e.g. doing it on AT-POS/AT-KEY)
lizmat yeah, gotcha
the thing is, when people want to capture stuff, they usually also want to use it 10:28
so the chance of capturing something unneeded, would be small I think
so the overhead of making things lazy, could make things worse ?
10:29 squashable6 left
jnthn It's not so much aimed at them not using it, just not having to have a hash/array allocated and populated 10:30
Trouble is that it probably depends on how many captures, etc. 10:31
I guess in many cases you have rules/tokens that capture 2 named things 10:32
10:32 squashable6 joined
jnthn And in that case the work of just finding them on access is probably lower than the cost of building a hash of them 10:32
lizmat ah... hhmmm 10:33
that *is* a good point
ok, lemme see if I can work out that avenue :-) 10:35
jnthn Good luck :)
lizmat thanks!
nine Hm...solving the precompilation and code navigation issues around the generate-and-export pattern give wonderful opportunities for over-engineering for the enterprising architecture astronaut.
After all wouldn't it be good if we automatically invalidated precomp files that contain symbols generated from some RDBMS or result from fetching some web page? 10:36
lizmat
.oO( but can the first stage be re-used? )
nine I mean, really, files are just boring...
lizmat nine: that was the whole idea of the pluggability of $*REPO ? 10:37
nine Close, but not exactly the same problem. $*REPO is for finding code. github.com/Raku/problem-solving/issues/159 is about plain code generated from some other source. 10:39
lizmat finding code / generating code potato / potato :-) 10:40
nine Though it's still an interesting point. At least for my case of invalidating precomp files when some used Perl 5 module gets changed could be handled by CompUnit::Repository::Perl5. 10:41
Also intriguing that I've never had the idea of generating actual Raku code, but instead only create objects in memory. 10:43
jnthn I guess at some point, generating it from RakuAST instead will be nice :) 10:48
nine Yes, RakuAST will give much greater control and thus better opportunities to make things faster 10:50
lizmat yeah, that will be the time I can look at my sprintf work again :-) 10:52
patrickb .tell tony-o I'm still interested in creating a more robust p6c ecosystem. But I'm currently kind of blocked by you spearheading a similar effort. Is there anything I can do to speed things up on your side? 10:58
tellable6 patrickb, I'll pass your message to tony-o
10:58 MasterDuke left 11:12 patrickb left 11:23 sena_kun joined 11:25 Altai-man_ left
lizmat jnthn: what exactly is the rationale of making Match a subclass of Capture ? 11:44
other than having both a Positional / Associative interface ?
11:57 JJMerelo joined
JJMerelo What do you think would be the best way to proceed if your tests need admin privileges? 11:58
tellable6 2020-06-10T03:55:23Z #raku <softmoth> JJMerelo, I figured out the Travis CI display problem; I needed to use travis-ci.com instead of .org. Sorry for the noise. travis-ci.com/github/Raku/rakudoc
JJMerelo .tell softmoth no problem.
tellable6 JJMerelo, I'll pass your message to softmoth
lizmat JJMerelo: make those tests depend on an env variable ? 11:59
JJMerelo So that they don't run if it's not root?
So essentially turn them into author tests
lizmat that would be my suggestion, right 12:00
Geth rakudo: 537a6e4170 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Simplify Match.clone

Seems like something was leftover from a debugging session
JJMerelo lizmat they can be run anyway in environments where you can sudo, like Travis... So that might be, after all, the most sensible solution 12:01
lizmat I've lost the best part of the morning thinking about using namespaces to do to that... Or system "sudo" calls. Simplest thing, best thing, after all... 12:02
lizmat thanks!
lizmat yw!
ShimmerFairy lizmat: What comes to my mind is that, with a method my-rule($/) { } in an actions class, the Match acts kinda sorta takes the place of a Capture for a normal method? 12:11
Not that that's a reason to subclass, but there's a similarity if you squint at least.
lizmat well, that's what I meant with t performing the Associative and Positional roles 12:12
nine JJMerelo: why do they need privileges anyway?
JJMerelo nine in my case, to use chown in a non-trivial way
nine you could mock chown in the tests
JJMerelo nine but I could think about other uses, like using port 80 12:13
nine yep, that's the other option, but imagine that what I want to test is a higher-level chown...
nine That would be very bad form. 1. ports should be configurable, not hard coded 2. if your tests use hard coded ports you can't run tests files in parallel
JJMerelo nine OK, just imagine I want to run in any privileged port 12:14
nine or kill any process
in general, any system call with privileges
nine lizmat: the speculations described Match as class Match is Cool does Positional does Associative 12:16
lizmat yeah, feels to me the Capture business is quick hack :-)
JJMerelo I don't think we have a mock framework for Raku. Or do we?
lizmat Test::Mock comes to mind, JJMerelo 12:17
JJMerelo lizmat Just found out... Thanks.
nine JJMerelo: literally everything in me, most of all the software developer and the system administrator cry out against tests needing evelated privileges. That's usually a case of "if you need it, you went the wrong way"
JJMerelo nine so you think mocking is better than running them as author tests with sudo? 12:18
nine You can kill any process belonging to the same user which ought to be enough for any tests. Tests shouldn't go around killing other user's processes.
What is the non trivial way you'd like to use chown? 12:20
JJMerelo I'm checking out jnthn's Test::Mock, and it's not exactly a mock the way it's used in Python, for instance. Mocks the API of a class, but not the response 12:21
nine well, chown to a different user, for instance.
jnthn JJMerelo: You have like 3 different ways in Test::Mock to deal with responses... :) 12:22
JJMerelo as long as a user belongs to different groups, I guess changing troup can be tested...
nine JJMerelo: why would you need that in a test?
jnthn fixed value, computed value without regard to incoming arguments, computed value with access to incoming arguments
JJMerelo nine Well, to check that the lower-level primitives that are being used actually work...
JJMerelo checks Test::Mock more carefully
jnthn But yes, it assumes there's a class and you want to mock the methods of it 12:24
nine JJMerelo: unless you're writing tests for the Linux kernel (which would be cool) or libc (ditto) I don't think you really need to test every case chown supports. Once you've established that any call works, you can assume that it will behave as documented.
JJMerelo jnthn OK, great... Thanks!
nine By mocking you can then test your higher layer much easier as it's trivial e.g. to have the mock function return different error codes. 12:25
JJMerelo nine right
nine another option mentioned around was to use fakeroot... 12:26
nine seems overly complicated, however. It's like using sudo, only without some of the risks. 12:27
So, mocking. Thanks!
nine actually, that's what's suggested here too stackoverflow.com/questions/755024...ctionality 12:28
12:34 cognomin_ left 12:52 JJMerelo left 12:53 Altai-man_ joined 12:55 sena_kun left 12:57 MasterDuke joined
Geth roast: c288a89a8f | (Elizabeth Mattijsen)++ | 2 files
Make Match.list tests more general

  - it should really test if the result is a Positional
  - it should *not* necessarily be an Array		 14:08
nine The most generic way to support arbitrary dependencies for precomp files is of course - code. There could be a PRECOMPCHECK phaser that gets run and upon returning false causes us to unload the comp unit again and re-compile. 14:17
Of course if we have that, we may as well replace the EVAL of a dependency specification in the current precomp header by reading an object from the bytecode file. 14:20
lizmat distributed is good :-)
nine The dependency checking code could even be written as a separate comp unit preceeding the actual byte code. This way we wouldn't have to unload and it would fit better with the existing architecture. 14:26
Doing this would pretty much require the ability for in-process precompilation, even if we don't use it for the main byte code. We'd still need to be able to while we're in the active compiler, compile and serialize a separate comp unit which can include data generated by the outer compiler (i.e. DependencySpecification object) 14:29
MasterDuke sounds like you have an exciting and fruitful weekend planned 14:30
nine MasterDuke: my weekend is going to be exciting as the next two days the weather will be very good for gliding. As to implementing any of these speculations, that sounds like another can of worms that can keep me busy for weeks or months... 14:33
In-process precompilation has so far been the only endeavour I've given up on instead of pushing through.
When working on rakudo that is 14:34
Of course in the years since I've learned a lot and stepped up my debugging game considerably. I'd just hoped that my next project will be somewhat more manageable :) The BEGIN time EVAL stuff was exhausting 14:37
Geth rakudo: f627d2c859 | (Elizabeth Mattijsen)++ | 2 files
Make reifying captures about 3% faster

  - Match.list now returns a List rather than an Array
  - this saves 1 Scalar container allocation per capture
  - allows use of nqp::push rather than Array.push		 14:43
lizmat another exhausting bit ^^
worth it for regex heavy applications 14:44
14:52 lichtkind joined 14:55 sena_kun joined 14:56 Altai-man_ left
MasterDuke nine: hang gliding? i've never been, but it looks fun 15:15
nine MasterDuke: -> segelflieger-linz.at/linz-ost/flug...index.html 15:16
Btw. this is the aircraft for which I do the maintenance and which I also like to fly: segelflieger-linz.at/static/1/7/8/...D-KFMF.jpg 15:17
jdv79 nine: what was so hard about in proc precomp? 15:18
MasterDuke nice, never done that either. how do you take off? towed by a powered plane?
nine MasterDuke: mostly towed by a winch on the ground segelflieger-linz.at/linz-ost/gale...index.html segelflieger-linz.at/linz-ost/gale...index.html but also towed by a plane 15:21
jdv79: keeping symbols belonging to the outer compiler out of the precomp file (otherwise you'd get errors about missing dependencies) and IIRC I got stuck on some repossession issue - at a time when I didn't fully understand what repossession even was about 15:22
15:26 softmoth joined
MasterDuke nine: looks fun 15:28
jdv79 cool. the first thing that comes to mind for the word repossession is when a bank takes back something after a default 15:53
16:18 softmoth left 16:31 softmoth joined 16:36 leont left 16:45 leont joined 16:46 dogbert11 left 16:54 Altai-man_ joined 16:56 sena_kun left
nine An open question that remains is how this would work together with a solution to the code navigation problem? 16:58
17:36 JJMerelo joined 17:56 [Tux] left 18:01 [Tux] joined
Geth rakudo: fbb0abc1d5 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Remove dead code
 18:17
18:29 JJMerelo left 18:55 sena_kun joined 18:57 Altai-man_ left 19:30 softmoth left
[Coke] need to change the install dir from ...\perl6\bin to ...\raku\bin 19:39
20:08 lichtkind left 20:10 lichtkind joined 20:18 lichtkind left 20:54 Altai-man_ joined 20:56 sena_kun left
Geth rakudo: 87e91defd5 | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6
Make Match.caps about 35% faster

  - 20% fewer allocations, so much less memory churn
  - built list of captures in nqp
  - sort list directly
  - add private method to determine key to sort on
  - allows use of Whatevercode for mapper		 20:57
lizmat also: Match.caps feels awkwardly named 20:58
this concludes my frustratingly hacking for today& 20:59
timotimo ooooh
but 35% is really nice
jnthn It's just short for captures, no? 21:12
Nice speedups; lizmat++
sjn quick question; what's the canonical way to define a method alias? 21:24
e.g. I have a method (or multi method) named "caps" and would like also to call it with the name "captures" (same signatures &c.) 21:25
timotimo i think we have an "is aka" trait in the ecosystem 21:28
sjn can't seem to find it 21:30
in roast there's an aliasing test; it does this: our &baz ::= &bar; 21:32
(found in S13/Syntax)
I'll play around with that
timotimo that's why i said ecosystm :) 21:37
oh
i read something that wasn't there
modules.raku.org/dist/Method::Also...:ELIZABETH misremembered the name
[Coke] sjn: also not bad to have a method that takes a capture for a signature and calls the canonical version
jdv79 counldn't it just be: method captures(|c) { $.caps: |c } 21:45
timotimo sure, but then introspection won't give you details :( 21:46
jdv79 i do like that your can alias a sub succicntly like: &captures = &caps;
yeah
timotimo you can probably BEGIN TheClass.^add_method("new-name", TheClass.^lookup("other-method")) inside the class body? 21:47
21:52 softmoth joined
jdv79 i employed both ways recently to alias stuff 21:53
i personally have no need for introspection but that'd be nice i guess
timotimo that's fair 21:57
22:02 dogbert11 joined 22:55 sena_kun joined 22:56 Altai-man_ left 23:04 softmoth left 23:48 maggotbrain 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!