🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 00:03 reportable6 joined
lizmat raydiak: which test? 04:50
there's a test for drawing randomly from a mix with 100000 of one value, and 1 of another value, and the test draws a significant amount of values (like 1000 or so) with a very small but non-zero chance of hitting that one other value 04:52
I've not been able to come up with a way that would not cause a potential flapper (other than just not testing) 04:53
ah, nvm, other test 05:06
raydiak yes not that one, the one I linked :) github.com/Raku/roast/blob/0a32868...mix.t#L284 05:59
but looks like the same principal applies
I didn't read it too close originally, because it made little sense to me, and the description is completely uninformative 06:00
doing tests with statistical chances of failure seems like a bad idea, doesn't it?
06:02 reportable6 left
raydiak especially that one and the one above it, I haven't done the math to work out the chance of failure, but it's not less than 1 in four digits I'd wager. it could at least be astronomical. and what is that "+ 2" doing in there? 06:05
06:05 reportable6 joined
raydiak seems more sane to me to just check that each of the two possible characters occured at least once 06:06
afk
lizmat raydiak: but that wouldn't be statistically sure either ? 06:20
raydiak no, but it'd be a ton less likely to fail. if we can push it to a couple orders of magnitude past the number of times we expect the test to be run for the rest of raku's existence, it'd at least be a good start 06:40
lizmat well, I'm not particularly attached to those tests... so please fix them as you see fit :-) 06:41
raydiak kinda like how solar power isn't free energy, only lasts until the sun dies...which for most purposes, would be good enough :)
I'll give it some thought
afk
06:56 discord-raku-bot left 06:58 squashable6 left 07:00 squashable6 joined 07:09 discord-raku-bot joined
raydiak okay, I'm actually back for a few hours 07:10
if I just changed those two tests to check that each of the two elements exists at all, the chances of "a" failing would be (2/3)**100, and "b" would be (1/3)**100 07:17
m: say ((1,2) »/» 3) »**» 100
camelia (1.9403252174826328e-48 2.4596544265798292e-18)
raydiak now let's say the spectests were to be run worldwide 1000 times a day for the next century 07:20
m: say 1e3*365.2425*1e2
camelia 36524250
raydiak m: say (1 »-» (1.9403252174826328e-48, 2.4596544265798292e-18)) »**» 36524250 07:22
camelia Lists on either side of non-dwimmy hyperop of infix:<-> are not of the same length while recursing
left: 1 elements, right: 2 elements
in block <unit> at <tmp> line 1
raydiak m: say (1 «-« (1.9403252174826328e-48, 2.4596544265798292e-18)) »**» 36524250
camelia (1 1)
raydiak right. rounding erros. I'll work it out another way without further spamming the dev chat 07:24
07:31 discord-raku-bot left 07:32 discord-raku-bot joined
gfldex raydiak: at least your rounded errors don't have sharp corners that could hurt ppl who bump into them :-> 07:51
raydiak I've always said I shouldn't be trusted with anything sharp, hot, or electrified :D 07:57
lizmat
.oO( don't run with unrounded errors )
 07:58
raydiak been a year or so since I cleaned the dust out of this used laptop. wonder if I should be throwing giant arbitrary-precision float exponentiation at it. at the onset of an historic record-breaking heat wave, no less 08:03
they're forecasting 112 F (over 44 C) on Tuesday 08:07
lizmat yeah, has been *very* hot in central europe the past weeks, with actual tornados happening in Czechia and Poland 08:12
that was a first, afaik
raydiak oh wow, I didn't think about that. extreme tempuratures making extreme pressure differentials could cause all kinds of fun things, huh? 08:15
nine raydiak: when it's about really big numbers, I just use bc for calulations - it does give answers instantaneously. Right tool for the job :) 08:18
gfldex We did have tornados in the past. But the where shored lifed and as such usually just hit forrests. Some deroofing did happen every couple years here in germany. That will become more common tho. 08:19
raydiak I was about to start looking for another tool, forgot all about bc. thanks nine++ 08:20
moon-child nars2000 has 'floating ball' arithmetic. I don't quite understand it, but it's an arbitrary-precision format that lets it figure out the magnitude of error
lizmat I don't recall 300km+ wind speeds in my lifetime
in europe I mean
breakfast&
nine Running just the @a.grep(* eq 'a') + 2 < @a.grep(* eq 'b') test in a loop it fails pretty reliably within a few hundred iterations. Changing the 100 to 1000 I haven't seen a failure yet. 150000 iterations and still going. 08:25
Sadly my math is too bad to calculate the chances though
raydiak yeah, calculating the chances of the test as it is now would be a bit more tricky. I'm just trying to calculate the chances if we changed it to just test that both a and b occur at least once, if it were ran 1k times per day for 100 years (36,524,250 iterations) 08:33
nine Even with just 200 elements in the array the test made it through a million iterations without failing. And is still running 08:34
Clearly a heavily exponential growth :) 08:35
raydiak just to 10 digits, bc takes 1 minutes and a half. I should probably just see if I can rearrange it to something sane symbolically on paper. or look up some statistics formulas. I never took statistics, so I only know the most crude fundamentals 08:38
nine Took 2421452 iterations to see the version with 200 elements fail 08:42
raydiak seems like 1000 would probably do the trick, then. though I'd advocate for bumping it up to 1e4 or 1e5, just to be safe, if the performance remains tolerable 08:47
is this lazy? that might mean it runs a lot longer for very unlucky people :) 08:48
though, even making sure the whole list is reified by doing .join.say before the grep, it runs at a totally acceptable speed on my machine, and gives very stable 1:2 ratio of a and b. less than 1% deviation in a couple hundred iterations I've tried so far 08:57
as in, *always* within 1%. the test is exponentially more forgiving than that 08:58
lizmat just pushed github.com/rakudo/rakudo/commit/db...ef078a5d0e # Make $() work properly on scalar values 09:02
raydiak nice 09:03
what exactly is our approval/merging process/frequency for PRs to rakudo? I want to align my expectations of expediency with reality. I've been trying to get started with some minor things to spool up, but seems like they tend to end up in "no negative feedback but nobody's hitting merge" limbo, but maybe I'm just too impatient 09:07
lizmat well, personally I'd like to see a PR appear in the Weekly :-) 09:08
to get more eyes on it
so suppose you submit a PR on Tue, it will appear on the next Mon, and if nobody disagrees, I generally merge it after the next RWN 09:09
unless someone beats me to it
nine raydiak: I've generated some data, running that thing in a loop with varying array sizes, fed it into LibreOffice and let it create an exponential trend line. This fits the data pretty well, crosses the 1 in a million mark at around a length of 200 and just goes through the roof after that.
MasterDuke so possibly two weeks? that seems long 09:10
raydiak so expect at least a week or more, regardless of what it is? or just don't submit PRs unless it's almost monday? :)
lizmat well... unless somebody beats *me* to it
or it is such a no-brainer that it could be immediately merged 09:11
raydiak: you could also apply to get a commit bit
so you could do the merges yourself ?
nine If the extrapolation holds, at an array length of 1000, we're at a probability of failure of about 1/1e30 09:15
raydiak the two I have open currently, I would merge with confidence. the first one I just stumbled over forgetting to spectest because it was my first in well over half a decade (and nobody thought to suggest it when I asked for careful review and suggestions). the problem wasn't even my code, it was the bogus test. thanks again for expediting the corrections on that, btw 09:16
putting aside for a moment the question of whether or not I'm qualified to have a commit bit, doesn't that seem like a kinda resistant-feeling process for new contributors? a few days to a couple weeks, regardless of complexity or lack thereof? if people can't be bothered to check out the new PRs until the weekly tells them to, should we really wait for their input? "yes" is a totally valid answer, it's an 09:20
honest question not rhetorical
lizmat well, I'm afraid in the past a lot of PRs got completely warnocked, so the 2 week window I sorta impose on myself looking at PRs feels like an improvement to me 09:24
although admittedly, the bar was really low
raydiak nine: for one iteration? or many? remember that the chance of a single failure goes up exponentially with the number of iterations. so if it's (1e30-1)/1e30 chance of success for 1 iteration, it's ((1e30-1)/1e30) ** many millions over the next century, idk if that still leaves it really high or not, because I can't calculate it well 09:25
nine 1e30 falls into the category of "ridiculously large number" already. Remember, that's: 1,000,000,000,000,000,000,000,000,000,000 09:27
If you do a billion tests per second for the next 1000 years, you still have only a chance of 1/31709791983 of seeing a failure 09:28
raydiak I don't think so, the chance of *every* iteration being successful falls *exponentially* with the number of iterations. how did you calculate that? 09:30
chance of all successes at 1e9 per second for 1e3 years should be ((1e30-1)/1e30) ** (1e9*86400*365242.5) I think. that's why I'm having a hard time calculating these things :) 09:33
by all means use whatever number you like if you're offering to contrib the commit, I appreciate that I'm not going down this rabbit hole myself. I just like to add lots of extra because I can't calculate the actual probability atm, kinda makes me feel like I'm flying blind and want extra safety 09:36
lizmat: circling back to your suggestion, what are the general criteria for a commit bit and how does one apply? is there more involved than the license agreement? 09:41
lizmat nope, basically sending in the license agreement 09:42
.oO( we haz the power of git to blame and revert )
I mean, the core devs must have the idea that it is not somebody who doesn't know anything about rakudo 09:43
applying for a commit bit
nine raydiak: you are right and I think your formula is correct. According to WolframAlpha the chance of failure in my example is then 3.15 × 10^-14
raydiak I have no idea what anybody thinks I know or don't know :D 09:44
lizmat raydiak: I think you've already shown interest and capability
raydiak nine: nice, then we're good. I didn't even think of wolframalpha. you're just all over the "right tool for the right job" thing
nine So I think it's still fair to say, that even if we throw all of humanity's ressources onto this, we still won't see a failure :D
raydiak this reminds me of a discussion I had with a former boss once, back when fancy boxes in html involved corner images. he wanted the box color to be fully customizable in our CMS, and so I should generate a few different styles of corner images of every possible foreground/background color combination in 24-bit RGB, instead of dynamically generating and caching just the ones that were actually requested... 09:49
lizmat: thanks for the vote of confidence! I'll look it over
moon-child o.o
raydiak m: say 256**6 # number of images for a single corner style 09:53
camelia 281474976710656
raydiak then you mulitply that by the number of styles, and figure a *minimum* of one disk sector each... 09:54
nine I think the past year has firmly established that humans don't crok exponential growth :)
moon-child not 256**3?
256 colours per channel and 3 channels 09:55
raydiak the background color also has to be matched, he wanted to be able to do both "inside" and "outside" corners 09:56
moon-child ahh
no transparency yet, of course :D 09:57
raydiak yeah I think there was some wrinkle in transparency support in those days, I don't exactly recall. it was around 02-03 or something, we were still supporting like ie5 or something 09:58
and he didn't trust new things. I eventually had to drag him kicking and screaming into the CSS world 09:59
[TuxCM] Rakudo v2021.06-21-gdba9f56af (v6.d) on MoarVM 2021.06-6-g6977d0591
csv-ip5xs0.842 - 0.868
csv-ip5xs-209.094 - 9.452
csv-parser27.509 - 27.956
csv-test-xs-200.372 - 0.375
test8.040 - 8.194
test-t1.988 - 2.094
test-t --race0.882 - 0.924
test-t-2033.749 - 35.109
test-t-20 --race9.892 - 10.183
 10:00
raydiak web dev for too long makes you feel sketched out like that, no control over what browser or OS people use and standards weren't as strong as vendor implementation back then. so you don't really trust anything besides what you've already been using successfully for years 10:03
stop using frames! quit laying stuff out with tables! if you had used a stylesheet I could change that font style without a massive search and replace with hand verification of each instance. where's the doctype? IE is in quirks mode messing with my box sizes! fun times. 10:07
just hearing "javascript" still gives me PTSD-like flashbacks, even though standardization is much better these days 10:09
lizmat yeah, fortunately I haven't had to really deal with Javascript since 2004 10:14
when an Apple-like interface for an availability system would not work in many browsers 10:15
raydiak it's more standardized, but I still hate how it happily passes undef and NaN through weird places, doesn't catch undefined variables, it has classes too now but they still don't complain if you mistype a property name. guess I should try typescript or something like that 10:17
thankfully my engagement with it is rare and voluntary these days. still, I tried something a month or two ago, and burned out before I finished it 10:19
and then there's dorey.github.io/JavaScript-Equality-Table/ which is on par with PHP's level of screwery 10:20
and variable hoisting (although at least it has lexicals now) 10:24
if you leave out semicolons it "guesses" where you meant them to be, even in ambiguous cases 10:26
gfldex lizmat: script has been updated to show descriptions of new modules gist.github.com/gfldex/d4162178db9...ebca9c17df 10:55
The data was there already, so why not to show it? 10:56
That's for --html=wordpress only. The text version stays the same to keep it parseable.
raydiak g'night everyone. thanks for chatting o/ 11:01
lizmat gfldex++ 11:05
11:11 frost joined 12:02 reportable6 left 12:03 reportable6 joined 14:20 Altai-man_ joined 14:39 frost left 16:20 notna joined 16:57 Altai-man_ left 17:52 notna left 18:02 reportable6 left 18:05 reportable6 joined 18:20 Altai-man left 19:33 evalable6 left, linkable6 left 19:35 linkable6 joined 19:36 evalable6 joined 20:22 sena_kun joined 21:39 linkable6 left, evalable6 left 21:40 Xliff joined
Xliff \o 21:40
tellable6 2021-06-24T07:53:16Z #raku-dev <MasterDuke> Xliff: i'm not sure, but i think samcv did some stuff for Atom support
Xliff MasterDuke++ 21:41
21:42 evalable6 joined, linkable6 joined 22:28 [Coke] left

Powered by Cro and the Raku® Programming Language.

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

Thank you!