00:02 ShimmerFairy left, ShimmerFairy joined 00:03 sena_kun joined 00:05 Altai-man_ left 01:28 Xliff joined 02:02 Altai-man_ joined 02:05 sena_kun left 02:32 lizmat joined
timotimo so my thinking about lembark's code is that we need to teach Proc::Async's pipes to permit the process to emit the "right" amount so we hover around a reasonable pipe buffer size, like maybe 128 megabytes? it should be big enough that in many cases you wouldn't even hit the permit limit, but if you've got a program that spits out multiple gigabytes, then it'll pause before that point is reached 03:29
so the pipe would have to issue permits when the buffer gets drained so that the process can continue writing and set the permits back to 0 when the buffer is full, maybe 03:30
and it'd be cool to have manual control over the permit process, too, but i'm not sure what the api should look like, what it should be called, etc.
if i see correctly, the IO::Pipe uses a Channel coercer on the stdout/stderr/merged supply, which is usually a way to prevent backpressure from affecting a supply's source 03:31
this might be food for a problem-solving issue 03:34
m: my Channel $c .= new; say $c.elems; $c.send($_) for ^100; say $c.elems
camelia Cannot determine number of elements on a Channel
in block <unit> at <tmp> line 1
timotimo i *think* you can nqp::elems a ConcBlockingQueue (but not .elems, because it's unreliable and prone to races and should never be used by users who don't know exactly which foot they're holding the gun to) 03:35
04:03 sena_kun joined 04:05 Altai-man_ left 04:42 Xliff left 06:02 Altai-man_ joined 06:05 sena_kun left 07:34 tobs joined 08:03 sena_kun joined 08:05 Altai-man_ left
lizmat Files=1307, Tests=113021, 216 wallclock secs (29.46 usr 8.63 sys + 3025.89 cusr 287.78 csys = 3351.76 CPU) 09:15
09:22 squashable6 left 09:24 squashable6 joined
MasterDuke timotimo: there is an elems() in src/6model/reprs/ConcBlockingQueue.c 09:55
10:02 Altai-man_ joined 10:05 sena_kun left 10:50 patrickb joined 11:45 AlexDaniel joined, AlexDaniel left, AlexDaniel joined 12:03 sena_kun joined 12:05 Altai-man_ left 12:57 MasterDuke left 13:01 stoned75 joined
sena_kun Blin shows `1481 out of 1484 modules processed (left: Font::FreeType PDF::Font::Loader PDF::ISO_32000)` for some hours now, I wonder if it hung... 13:04
13:08 MasterDuke joined
AlexDaniel sena_kun: I think these three are just slow 13:16
also, it's possible that blin is bisecting them…
which is slow times 11
sena_kun Let's wait until tomorrow and see. 13:17
AlexDaniel x)
I was about to suggest to kill the individual processes, but then they'd be started again if it's bisecting them… 13:18
timotimo: you seem to like nice tools. Let me tell you about alacritty :) 13:27
timotimo: fast gpu-based terminal, no unneeded features, seems to work natively on wayland, supports bitmap fonts 13:28
I'm switching from urxvt :)
now I need a file manager that works on wayland. Suggestions? 13:31
MasterDuke AlexDaniel: you're using wayland on debian? how's the support? 13:32
AlexDaniel MasterDuke: yeah, well…
MasterDuke: so transition from i3 to sway is kinda easy, it can read the same config file
so out of the box it kinda works. You do need to add something extra for keyboard layouts and stuff, but it's relatively easy 13:33
now, all apps work just find through xwayland
but what's the point of using wayland if you're not running apps natively on wayland, right? :)
so, firefox needs an ENV variable to be set in order to work natively on wayland 13:34
and let me tell you, it's very noticeable!
something about the scrolling just feels so nice
MasterDuke ah, so noticeable in a good way?
AlexDaniel yes
MasterDuke i've thought about giving wayland a try 13:35
AlexDaniel it depends on the window manager that you use
MasterDuke but i have an nvidia gpu, and i think the support isn't quite as good
AlexDaniel for i3 → sway transition it's extremely easy 13:36
MasterDuke i use kde
AlexDaniel MasterDuke: are you using proprietary or open-source drivers?
MasterDuke proprietary
AlexDaniel well… yeah…
MasterDuke: this rant is kinda relevant to understand the situation with nvidia: drewdevault.com/2017/10/26/Fuck-you-nvidia.html 13:37
MasterDuke yeah, that's one reason i've been hesitant. but i believe the situation has improved a bit since then
AlexDaniel in what way? 13:38
MasterDuke i also need to upgrade my video card, so am considering amd
AlexDaniel all wm devs bent over and added separate code paths for nvidia's proprietary stuff? Maybe…
if so then indeed it should be unnoticable to users
MasterDuke i think a little of that and a little of nvidia supporting some more of the other standards 13:39
AlexDaniel so, to summarize, I just had to install xwayland to make sure most programs keep working, then configure the keyboard layout stuff separately for sway, then switch to alacritty because urxvt doesn't run natively on wayland and alacritty should, add an env variable for firefox (btw chromium has no such thing I think, so firefox ftw)… 13:41
that's about it, it's not too much
two issues I still have: nm-applet doesn't work (it just doesn't, that's it, no solution for now), spacefm segfaults
so I have no file manager and no gui for the network manager… 13:42
and everything else is working absolutely fine
timotimo just use iwd instead of NetworkManager ;)
AlexDaniel timotimo: use what? 13:43
timotimo iwd
just kidding
i only just heard of iwd's existence :D
AlexDaniel thing is, network manager itself is working just fine, you can still control it with nmtui and stuff like that 13:44
timotimo right
AlexDaniel it's the tray applet that doesn't
timotimo and nmcli :)
AlexDaniel and I can live with that, I think… but file manager?
timotimo media.ccc.de/v/ASG2019-127-gnu-pok...inary-data - possibly quite interesting to look at for the design of binary rules in raku 13:46
AlexDaniel that logo tho x) 13:49
13:55 Kaiepi left 13:56 Kaiepi joined
timotimo kaitai.io/ - did we know about this yet? 13:57
AlexDaniel timotimo: I don't really know what you want to achieve with binary parsing in Raku. Even basic text parsing is slow as hell, why would it be useful to do anything with stuff that requires binary parsing? 13:59
timotimo text parsing won't stay slow forever 14:00
AlexDaniel why?
timotimo because we have smart people!
AlexDaniel we've had smart people for 20 years
timotimo there's a complex web of requirements to make stuff possible 14:01
AlexDaniel and they didn't come up with a way to parse text without polluting everything with match objects
even though you don't even need match objects in the majority of the cases, you just need the text itself that matched 14:02
14:02 Altai-man_ joined
nine Our text parsing certainly isn't fast. But it's fast enough for many use cases. Same could be true for handling binary data 14:03
AlexDaniel the key to performance is to not do stuff at all. Instead we do everything that anyone may possibly want, and then expect the compiler to figure out that nothing needs to be done 14:04
timotimo true, on the other hand we're currently doing barely any smarts at the level where we still have the QRegex QAST datastructure
14:04 sena_kun left
AlexDaniel what kind of smarts do you expect to be implemented to stop creating objects when we don't need them? 14:05
jnthn EA. 14:06
AlexDaniel nine: colabti.org/irclogger/irclogger_lo...07-07#l539
timotimo we already only guarantee that {} makes a $/ usable, there's probably more spots we can use that let us signal "no need to do anything yet"
AlexDaniel timotimo: {} makes a $/ usable? What does that mean? 14:07
timotimo and yeah, when we have match objects just for storing positions and such inside a part of the generated code, EA can make no match object exist at all yet
i'm not speaking coherently 14:08
m: say "ahaha" ~~ / (a) .* $0 / 14:09
camelia 「ahaha」
0 => 「a」
timotimo i'm possibly misremembering
AlexDaniel I don't think escape analysis will ever undo the generation of all the bloat during regex matching 14:10
you are free to believe though
timotimo the generation of that bloat is actually exactly what EA would be for 14:11
AlexDaniel language-wise the solution is very simple – let people populate their stuff with matched strings. Zero match objects created.
timotimo we could totally have a "use NoMatchForMe" that changes regex compilation and matching to do that 14:12
jnthn In principle, the entire subrule call graph can not even be traversed in first place when there's no capturing and it's entirely declarative.
Meaning you could avoid the cursor creation too
timotimo as far as signaling to the compiler that it is supposed to change how things work, i mean
nine We've had smart people woring for 20 years, but 15 of those were to get stuff up and running
And so far only 5 years to get stuff faster that was created over 15 years 14:13
AlexDaniel so 15 years of adding bloated features and 5 of trying to undo it with the compiler. See you in 10 years? 14:15
you can also make a fast language right from the start, other languages do it somehow 14:16
timotimo java was crawling for the first X years, and now it's pretty widespread 14:17
they somehow didn't care about being fast from the start and turned out well, i mean
AlexDaniel yeah, feel free to not care. I'll go try Julia for my next project 14:18
timotimo i do care about making rakudo and moarvm faster, i don't think i'm the right person to attempt sweeping architecture changes, though 14:19
raku-bridge <Vendethiel> jnthn: don't you need to create a cursor still, because it's often used i.e. in error reporting? 14:23
jnthn Vendethiel: If it's reporting an error then it's got imperative parts, not purely declarative ones. 14:24
raku-bridge <Vendethiel> ah, right
timotimo which might mean that imperative parts are very common in grammars that have any error reporting, perhaps?
jnthn I think those are common common in tokens than rules 14:25
uh, other way around :)
raku-bridge <Vendethiel> that's severely limiting the scope of grammars that can be optimized that way, but for simple regexes, that sounds incredible
timotimo for simple regexes we still have to do more than "nothing" in terms of skipping regex entirely
like going for ends-with, starts-with, contains
raku-bridge <Vendethiel> right 14:26
timotimo extracting dominating substrings up front
jnthn AlexDaniel: I hope you'll find the enjoyment in doing that, that you once found with Raku. 14:27
AlexDaniel raku is fun when you start learning it. And much less fun once you know enough, attempt to use it and then immediately see all of the ugly 14:28
to fix it you'd need to revert the mindset that you all seem to share 14:29
which I obviously won't be able to do, so yeah, let's hope I find something else
timotimo i'm not sure i'm clear on what that is, exactly 14:31
raku-bridge <Vendethiel> timotimo: "maybe someone will be smart enough to figure out how to clone jnthn++", surely :)
timotimo is it more of a priorization thing, or that we need to more aggressively toss out stuff that's not optimizable, at least at the moment? 14:32
jnthn At the end of the day, languages all make different trade-offs, and people differ on which ones they consider more trade-off-able.
If they didn't, there wouldn't be so many languages, I guess.
raku-bridge <Vendethiel> insert Bjarne quote here 14:33
AlexDaniel timotimo: I'd say it's more about not admitting that we ended up with something that is just plainly bad. You say it's OK-ish for now and maybe it will get better, jnthn says it's just tradeoffs. I say it's just bad. You decide which one of these allows to plan how to get things fixed as soon as possible. 14:37
raku-bridge <Vendethiel> are we still talking about performance?
AlexDaniel performance is not something that is isolated
we're talking about Raku 14:38
I am, at least
raku-bridge <Vendethiel> I just wanted to make sure.
AlexDaniel although people will disagree, I think, which is how Raku was really created. Performance as an afterthought 14:39
speaking of undoing, I hope it's clear that it's always much harder (and more time-consuming) to fix design mistakes than to implement them wrongly in the first place 14:43
Altai-man_ AlexDaniel, I think this suddenly became too polarized, maybe that's just me. It is not about black and white, utter shit and software masterpiece. It is a bit unfair to lump "performance" / "language" into a single thing and slap a label at it. Raku is rather fast compared to others in some things, it is rather slow compared to others in some things. IT industry is full of pain in general and "Language X is pure joy 100% of the time" is usually a
wrong first impression.
AlexDaniel so the 10-year estimate is rather optimistic, actually :)
Altai-man_ AlexDaniel, good luck looking at Julia, a nice break and a change of pace is always great. 14:45
AlexDaniel Altai-man_: for any real life code, which language you think is slower?
lizmat AlexDaniel: I wish you you a better experience with another programming language than you've appear to have had with Raku
timotimo and thanks for all your contributions so far, of course
lizmat as in any relationship, at some point the infatuation either turns into love, or the relationship ends 14:46
AlexDaniel except that I keep maintaining the stuff I made, unless anyone wants to take over :)
timotimo \o/
glad to hear it
Altai-man_ As for 10 years, it is not like people here have a deadline to be successful kings of the programming world and unless it's done you're a complete failure. At the end of the day, nothing actually matters and we are here a bunch of folks with conciousness who try to entertain themselves somewhat. Maybe I am lecturing, though, dunno. 14:47
timotimo that's an easy stance to take when your food is taken care of, at least
AlexDaniel Altai-man_: no, you're right, it's an optimistic way of looking at things, very refreshing compared to my messages :)
but I do have a feeling that there's a bit of conflict between optimism and realism in this case 14:48
timotimo: I actually sorta left quite some time ago, tried to stay away from IRC because you see how it ends :P 14:49
timotimo: I actually reworked statisfiable, it has more stats and is just better now, but I didn't commit it yet
I'll try to get back to my break once it's live 14:50
timotimo i thought that happened when i saw an amount of issues you had opened were closed
14:50 patrickb left
AlexDaniel yeah. Though I didn't close anything that mattered? It was mostly about my own personal tickets that I used for myself 14:50
14:51 patrickb joined
timotimo surely, how slow it was to grab all the annotations from moar's dump output was not a great experience :) 14:51
AlexDaniel haha
timotimo oh hey nine can you find that gist again where you wrote a moar bytecode parser in raku? i kind of couldn't find it any more
AlexDaniel but was it? Once I switched to nqp ops I think it became really fast on my side? 14:52
it's usually the speed of my own code that I care about, for what it's worth the moar output I'd consider an external utility :)
Altai-man_ The point is, if you can be satisfied with what you have, you're a happy lucky one. If you are not and want more X, no amount of "more" can satisfy you, even if your X is 10x best in the world. 14:54
I mean, it does sound like a lame excuse, but I found a bit of stoic approach in this, which allows to care about what you can change and don't be sad over things you can't change. 14:55
Namely, IT is about tools, so it something does the job better - please do use it. There is no need to be sad with the hammer seeming wrong because it can't screw something. 14:57
timotimo actually
i saw a super cool video where a hammer helped screw something
Altai-man_ More so, being extensive contributor you INDEED see much more horrible stuff about the language than the "average" user... And thus comes the bias "Oh, this thing is so horrible" while in fact it is not SO horrible. Maybe somewhat, true. 14:58
timotimo i have not the slightest clue how to find that again
essentially used an extra screw on top of a plank to give the hammer leverage against another plank that was misaligned, then screwing the two together from "the front" 14:59
jdv79 i saw someone hammering screws in one day. did a double take. 15:00
Altai-man_ timotimo, well, in some conditions you can hammer a screw, it's just not how it works in general and no warranty given or implied. :P 15:01
timotimo oof, the heaptrack record is almost a gigabyte big 15:02
AlexDaniel well, impact drivers are essentially hammers
timotimo what are you, the god of hammers?
AlexDaniel and they are much more efficient than regular powered drills, for screwing screws that is
they strike to rotate the bit though, not to punch the screw through
that is, they don't push the screw, they just rotate the bit in rapid kicks 15:03
nine timotimo: gist.github.com/niner/63a718023aba...c1ccd84e32 15:04
AlexDaniel youtu.be/f0gSJa3L_7c?t=141 15:06
jdv79 they are also very noisy. i prefer a non-impactful screw gun. 15:07
AlexDaniel jdv79: I'd take hearing loss over cam out any day xD 15:08
jdv79 i like music though 15:09
AlexDaniel the first time you use it it's really loud indeed, but later it feels like you clench or something and it no longer bothers
btw, here's a positive observation 15:10
julia's startup time for scripts is a bit higher. By 10-20ms or so
statisfiable6 will be able to graph startup time now, after I commit my stuff 15:11
so you'll be able to see where it's going
jdv79 a friend of mine was raving about julia a few years ago 15:12
something about being able to get the asm and manip it or something
AlexDaniel well, any time I compared something I didn't like in the raku language to julia I always liked what julia was offering. I have no idea if it really works in practice, hard to tell without doing a real project in it. 15:13
15:14 patrickb left
AlexDaniel the way it is printing stacktraces is very interesting. It's really really slow, like it has to redo something in order to figure out what happened? 15:14
vrurg Talking about performance, /me remembers the times when inlining assembler into C code was common because people were dissatisfied with performance... 15:15
tellable6 2020-07-08T12:03:15Z #raku <SmokeMachine> vrurg thanks! my irc client is out, I've haven't seen that! Thanks!
timotimo vrurg: i'm looking forward to trying vigna when new-disp is mainline 15:34
though honestly, i think i'd really love something simple where you can have an input line at the bottom and scrolling output above, perhaps split side-by-side, maybe multiple independent ones on top of each other 15:35
for simpler tools like the debugger commandline, the heap analyzer commandline, stuff like that
maybe my idea to "do this with just the simplest escape sequences" is dumb 15:37
like how you can set an area of the terminal to be scrolling and everything else to stand still 15:38
15:38 MasterDuke left
timotimo but then if you want to support resizing of the terminal you would probably have to keep everything in memory as well, so you can redraw what should be on screen 15:39
AlexDaniel “Stack Overflow is currently offline for maintenance” 15:42
:)
timotimo and i've got to think of something with regards to completion and line editing
AlexDaniel: the sound of a million coffee machines screaming in agony and suddenly being silenced by energy grids all over the world collapsing
15:59 MasterDuke joined 16:03 sena_kun joined 16:04 Altai-man_ left 16:05 stoned75 left 16:07 stoned75 joined 16:13 Kaiepi left 16:14 Kaiepi joined
[Tux] Rakudo version 2020.06-58-g16d24a212 - MoarVM version 2020.06-20-g187b4564e
csv-ip5xs0.812 - 0.824
csv-ip5xs-207.862 - 8.039
csv-parser25.286 - 25.845
csv-test-xs-200.395 - 0.400
test7.600 - 7.651
test-t1.841 - 2.085
test-t --race0.827 - 0.830
test-t-2032.261 - 33.218
test-t-20 --race8.738 - 9.513
16:22
dogbert17 AlexDaniel: out of curiosity, why Julia specifically? I mean there are lots of hyped languages out there :) 16:29
AlexDaniel jdv79: hey remember that silly-ish benchmark you showed yesterday? 16:30
jdv79: I tried writing it in Julia. Now, I don't speak julia is it's potentially ugly, but here: gist.github.com/AlexDaniel/cbac99a...c35436528f
it's faster in julia!
that is, faster than perl
perl5
I tried doing something with one of the vars thinking it optimizes too much away, but I don't think that's the case
dogbert17: they seem to be doing a lot of things right, or at least have ways of doing things right (and all of that is pretty fast at the same time) 16:32
dogbert17: it is weirdly similar to Raku actually, rats, channels, atomic ints, last expression is returned, etc. 16:33
a lot of that not by default, but if you want a rat you can have a rat 16:34
jdv79: s/is/so/
dogbert17 interesting, seems to have lots of math/scientific stuff
here's something for timotimo: julialang.org/blog/2020/05/rr/ 16:35
AlexDaniel dogbert17: any time I found something debatable in Raku it was curious to find that in Julia it is almost always done in a more meaningful way
dogbert17: but look, no big ints by default. Weird. 16:37
dogbert17 but there's multiple dispatch and optional typing
AlexDaniel yep 16:38
dogbert17 goes out for a quick walk &
Geth rakudo/rakuast: cef320b06d | (Jonathan Worthington)++ | 3 files
RakuAST support for various regex assertion forms
16:46
jdv79 AlexDaniel: my box is loaded at the moment but i see perl beating julia a bit at ~6.6s vs 8.25s on my file "4496744 17986976 610247801 s3-pica9-logs-ls-r" 16:52
AlexDaniel jdv79: in my case it's Julia 1.4.1 vs Perl 5.30 16:53
jdv79 ditto 16:54
AlexDaniel interesting. It's faster by about 10% for me, but it's not a real file so who knows
jdv79 maybe julia is more sensitive to a cpu bound box
i'll try after the loading is over
wow. raku with hyper i guess is very cpu load sensitive. with hyper it takes 59s and without it takes 12s 16:56
that's with the "next unless .contains($str)" cheat
AlexDaniel in my experience hyper didn't do anything faster ever, unless you have some sleepy tasks
vrurg timotimo: I was away... A simple tool for simple tasks – yes. But as soon as complexity of an application grows, the requirements for a framework skyrocket.
jdv79 yeah
AlexDaniel jdv79: oh, are you benchmarking with the cheat or not? :) 16:57
jdv79 with cheat
AlexDaniel that's why then
ah no
ok I got very confused
time for a break I guess x) nevermind
vrurg timotimo: BTW, I was wondering about profiling. I tried to use moarperf with vikna once. The flamegraph happened to be occupied with await because this is where most of the time is spent after all. But is there a way to exclude it from the output? 16:59
AlexDaniel jdv79: so I created a file with 2100000 lines and it's 3.4s for julia and 4.4s for perl. The difference seems to grow if I make the file larger 17:00
but no idea what kind of tricks it has up its sleeve
jdv79 idk. the big load is over and they both are still relatively the same 17:01
perl is 5.8s and julia is 8s
meh
maybe its less uniformness of my data file? 17:02
s/its/its teh/
AlexDaniel maybe!
trying a simple loop over the lines seems to indicate that perl is indeed faster, 0.6s vs 1.2s 17:03
vrurg AlexDaniel: sorry if I'm out of the context and missed something, but with hyper I got really huge speed up in producing an HTML from a sqlite via Template::Mustache. Though the latter needed a patch to actually support concurrent sequences.
AlexDaniel vrurg: I guess it can be helpful if you have very “fat” tasks 17:04
but for small code pieces like iterating over lines and doing simple matches, hyper just makes things worse 17:05
vrurg Evidently. Otherwise the cost of spawning threads is too hight.
AlexDaniel: if there're many such short-living tasks then pre-spawning of the kind what my Async::Workers does is more helpful. 17:07
AlexDaniel jdv79: another thing to try is gist.github.com/AlexDaniel/7317971...6aea12c617
a bit fairer comparison :)
vrurg is afk 17:08
jdv79 7s
AlexDaniel still, I kinda hoped that it'd be able to populate existing variables. They're using pcre so maybe that makes it harder, but Raku has all the freedom to do that 17:09
something like my $foo; … /$foo=[\S+]/ 17:10
just save the string and whizz by
in the past I supported the idea of making a fast .contains that simply returns a Bool (which actually got implemented…), but now I feel like that's wrong too 17:14
it's .match and friends that should not return anything at all unless you ask for it 17:15
basically, $/ should be gone 17:16
sena_kun Is it just me or this regex can be replaced with just `.words` call and unpacking assignment? 17:17
AlexDaniel sena_kun: correct, yes, but it's a benchmark for a simple regex
sena_kun Fair enough. 17:18
AlexDaniel sena_kun: perl5 and Julia are sorta exchanging blows on that one, IIRC Raku is 25 times slower 17:19
$/ was already changed to no longer by dynamic, I think? Or something like that 17:20
be*
performance was cited as one of the reasons if I remember it right
too bad it wasn't thrown away completely instead :P 17:21
jnthn AlexDaniel: No, it was $_ that was changed to no longer be dynamic. A lot of things rely on $/ being. 17:31
AlexDaniel I see 17:40
timotimo vrurg: i don't have a clever idea for that yet :| 17:56
18:02 Altai-man_ joined 18:05 sena_kun left 18:12 lichtkind joined
MasterDuke re the implementation being optimized later rather than up front, i know TimToady has mentioned something about "it" (i don't know if he was talking about the language design itself or the particular implementations) being "optimizable". i think a valid question would be whether in practice that meant people made sub-optimal (from a performance 18:30
viewpoint) decisions with the thought that a "sufficient smart compiler" would be developed eventually? or was the design such that there was/is a clear path to optimizing what we had then/now?
MasterDuke isn't trying to cast blame on anybody, but figure out whether performance issues have a pre-planned path to improvement, or do we need to come up with those plans? 18:34
18:34 Kaiepi left, Kaiepi joined
AlexDaniel MasterDuke: well, if you read the old design docs then they sometimes mention how something can be hopefully optimized 18:45
18:45 squashable6 left
AlexDaniel MasterDuke: but that's really not enough 18:46
basically, as I understand it, the design process was pretty much done in the dark wrt optimizability 18:47
even though the principles of making fast code are very well understood 18:48
18:49 squashable6 joined
AlexDaniel so basically the docs say “ok this bit maybe will be optimized like that, fingers crossed” 18:51
when what should be happening is “ok this will map exactly to these operations, and that's why it will be fast”
you see, it is possible to design a language that does exactly what the users commands, which is fast by itself, and then you can spend all the time in the world in figuring out how to make the compiler ignore that and not do anything at all, making it even faster 18:53
instead, Raku does a bunch of stuff you didn't even ask it to do, and now the devs are trying to figure out how to get back to the base performance 18:54
18:56 [Coke] left 18:57 [Coke] joined, [Coke] left, [Coke] joined
AlexDaniel and you can see that in all recent discussions. For example, let's say you take a Seq and want to skip a value. You do $s.skip(3) and get a new Seq object 18:57
well hold did I ask it to create a new object? I just wanted it to skip a certain amount of values
which I guess you can do if you play with the underlying iterator, but that's like playing with guts when you have a .skip that was sort of designed to do that? 18:58
or, another example is the last regex benchmark
all you need in that benchmark is to take a string and destructure it into a few variables 18:59
sounds simple, and it is simple, but you can't do it
instead it creates a bunch of match objects. Well, hold on, I didn't ask for match objects, I didn't even necessarily ask for anything really
of course you can argue all day that returning a match tree is the most versatile solution, sure, whatever, but it is not designed to be fast for sure 19:00
[Coke] So at this point, do you think there's a path forward that will satisfy what you're looking for? 19:04
AlexDaniel yes
lizmat drumroll....
AlexDaniel admit that we ended up with crap, dismantle the language into pieces and redo them right, release a much better Raku 7 19:05
lizmat well volunteered!
Altai-man_ This is probably the worst time ever for this, but... Apparently, Blin hung, so here is the overview for Seq-related branch clbin.com/0Ov4J <- and around ~60 modules are broken. 19:06
AlexDaniel oh that's not too many
lizmat Altai-man_: I am *not* surprised
Altai-man_: of *all* modules tried, or just the ones before it hung ? 19:07
AlexDaniel lizmat: of all modules
lizmat: 3 modules were hanging I think
Altai-man_ Yes 19:08
AlexDaniel lizmat: it didn't generate the dependency tree because it was killed, but it's possible that out of just 60 there are some failures caused by parents
jdv79 i would say this sort of frustration isn't uncommon. others have expressed simliar sentiments. 19:09
lizmat well, I guess you have your work cut out for you: a. fix those modules, b. start working on fixing roast
AlexDaniel it's not that easy
lizmat jdv79: I too have my frustrations
having spent quite an amount of time on: val processing, ..., printf and lately Match 19:10
jdv79 yup. some others flamed out. some just disappeared.
lizmat in my case, it has led me to understand the complexity of the situation
AlexDaniel complexity can be reduced by deleting stuff 19:11
lizmat in the case of printf: RakuAST will allow us to revisit that *without* having to resort to EVAL
jdv79 curious if there are some underlying root causes that might be addressed...?
lizmat some internals that rely on EVAL and which are slow because of that, will also be fixable with RakuAST
the underlying root cause, in my opinion, is that nobody knew how to implement a language as radical as Raku 19:12
AlexDaniel it's not very radical
the biggest value is in some nice syntactic sugar, that's what makes it feel like Raku 19:13
lizmat AlexDaniel: how many languages can change their grammar with a single statement ?
AlexDaniel lizmat: and how many languages like to talk about features that nobody is using? :P 19:14
I get it, changing the language sounds like a wonderful idea
but others get away with just macros, and it's fine 19:15
lizmat AlexDaniel: you should talk to the people who would like to remove "format" from Perl 5
Altai-man_ AlexDaniel, there is some fallacy... Some of those "nobody using" features are key points of raku. People are suggesting to strip them off to speed up the compiler and what this gives us? Python with braces and `sub` instead of `def`? Please no. 19:16
AlexDaniel that's not the point. Many languages have macros and custom operators, changing the whole syntax in just a single statement is not as amazing as you make it sound 19:17
19:17 go|dfish left
AlexDaniel if I had to choose between fast parsing of Raku code and a sophisticated grammar-changing monstrosity, I'd choose the former in a heartbeat 19:17
lizmat then by all means, join the Perl 7 effort
AlexDaniel right, so you say well-volunteered and then make it clear that this is definitely not something you want for Raku feature 19:18
future*
which is why nobody will ever make things right
any idea of simplifying Raku will be shot down 19:19
Altai-man_ Apparently, there are people who won't choose the former and they went and did some implementation of Raku. People have opinions about what they want and if it differs from yours, then hm.
AlexDaniel so what is Raku for, exactly? Playing around with fun ideas and fun one-liners? 19:20
because that's what it is right now, with very little applicability for real world problems
ShimmerFairy For the record, anybody who has ever defined their own operator has changed the grammar.
Altai-man_ What's the meaning of life? Erm, almost exactly the same question. If it is for playing around with fun ideas and fun one-liners, then what? 19:21
AlexDaniel Altai-man_: I don't blame you, I defended raku exactly like that before
Altai-man_ AlexDaniel, being blunt, I don't really care about future, because one won't predict it. You do things which sound kind of worthy (while having to pay the bills, of course) to do and that's all. You don't like it anymore and search for another thing to do. 19:23
AlexDaniel but that's not very useful. You're basically saying that whatever Raku does is OK. I'm saying that it can be much much better 19:25
where did the LTA mindset go? :)
Altai-man_ My bad, I am broading the subject and expressing my kind of opinion on everything. 19:26
ShimmerFairy I use Raku all the time, especially when I need to parse some text (it's invaluable for that). Just because *you* don't find it useful doesn't mean nobody does. 19:27
AlexDaniel [Coke]: if I had to poorly summarize it, I'd say we need a somewhat coordinated effort at decluttering the language
Altai-man_ AlexDaniel, something like 6.e-level language breakage? 19:28
AlexDaniel Altai-man_: not sure I understand?
I'm proposing Raku 7, which can be significantly reworked 19:29
timotimo seven does what rakudon't
AlexDaniel it'll break stuff, yeah. Luckily nobody is really using Raku so there's that. 19:30
Altai-man_ AlexDaniel, oh, sorry. I mean, we don't suddenly release a decluttered compiler breaking stuff in production. This sounds like something suitable for a language revision.
>nobody is really using Raku
AlexDaniel sure sure you can go “but I use it”, and yes, I used it in production too
Altai-man_ This is just ridiculous right now.
AlexDaniel no it's not. The amount of people who actually use Raku is *extremely* small
Altai-man_: but yes, I mean the next version 19:31
you see, there's a real problem of admitting stuff in this community :)
lizmat like admitting it should have a different name ? 19:32
19:32 SmokeMachine joined
AlexDaniel yeah 19:32
lizmat is getting angry and steps away from this discussion
AlexDaniel many many years to do that obvious change
remember how the proposals to do that were shot down?
all of that to finally admit that yeah, we'd be better off with a different name 19:33
19:33 kawaii joined
ShimmerFairy AlexDaniel: honest question, do you even like Raku, at all? All you ever do is complain about it, and not in a way that seems like someone noticing bits that could be improved, but as someone who's upset it doesn't match their personal ideal for a language. It really just seems like you want a completely different language. 19:36
AlexDaniel ShimmerFairy: I liked it a lot, yeah. I'm not sure if I do anymore 19:37
it's really hard to use
Altai-man_ ShimmerFairy, "all done is complaining" is a bit of underestimation of how much amazing level of work AlexDaniel put into all this.
s/underestimation/misrepresentation/ 19:38
ShimmerFairy All I know is what I've seen since I came back.
Altai-man_ Fair enough, just noting. Honestly, I am always amazed seeing this. 19:39
AlexDaniel ShimmerFairy: I think I felt similarly when I saw brrt's rant 19:40
can't really find it now, I think it was on #moarvm
it was something about unpredictable performance, I don't remember now as I didn't comprehend it back then
all I thought was “why is this guy complaining about this awesome language” 19:41
there was also Zoffix who craved relatively massive changes, which always felt to me like he was trying to make raku not raku 19:42
ShimmerFairy Of course we should improve the language, and make it more attractive to other people (and I think it's fair to say very few people use it relative to other languages). But I don't think we can make Raku more appealing to others without honest-to-goodness studies to figure out what exactly is keeping people. 19:43
The reasons could range anywhere from "Most programmers are deathly allergic to anything remotely like Perl" to "The language is fine, it just doesn't get 'marketed' enough". 19:44
Altai-man_ The brrt rant mentioned is probably colabti.org/irclogger/irclogger_lo...-09-21#l99 19:46