[00:44] *** squashable6 left [00:46] *** squashable6 joined [00:47] *** squashable6 left [00:50] *** squashable6 joined [00:54] *** Altai-man_ joined [00:56] *** sena_kun left [00:58] *** oddp left [00:59] *** MilkmanDan left [01:00] *** MilkmanDan joined [01:08] *** MilkmanDan left [01:11] *** molaf left [01:13] *** marcusr left [01:18] Altai-man_ : I can’t wait for jnthn++ to release RakuAST. It’s going to really help out with some of the Intl stuff (specifically with the formatters) [01:18] *** marcusr joined [01:19] * guifa feels a little weird giving his talk on internationalization because by next year things will be 10x better and cooler than this year [01:23] *** molaf joined [01:33] *** MilkmanDan joined [02:10] *** Cabanossi left [02:12] *** Cabanossi joined [02:55] *** sena_kun joined [02:56] *** Altai-man_ left [03:00] *** acw left [03:41] *** _jrjsmrtn joined [03:42] *** __jrjsmrtn__ left [03:53] *** brtastic joined [04:53] *** committable6 left [04:53] *** nativecallable6 left [04:53] *** quotable6 left [04:53] *** coverable6 left [04:53] *** unicodable6 left [04:53] *** squashable6 left [04:53] *** bloatable6 left [04:53] *** sourceable6 left [04:53] *** linkable6 left [04:53] *** tellable6 left [04:53] *** notable6_ left [04:53] *** greppable6 left [04:53] *** statisfiable6 left [04:53] *** reportable6 left [04:53] *** evalable6 left [04:53] *** shareable6 left [04:53] *** releasable6 left [04:53] *** bisectable6 left [04:53] *** evalable6 joined [04:53] *** bloatable6 joined [04:53] *** linkable6 joined [04:53] *** shareable6 joined [04:54] *** reportable6 joined [04:54] *** committable6 joined [04:54] *** tellable6 joined [04:54] *** Altai-man_ joined [04:54] *** statisfiable6 joined [04:55] *** nativecallable6 joined [04:55] *** squashable6 joined [04:55] *** bisectable6 joined [04:55] *** greppable6 joined [04:55] *** releasable6 joined [04:56] *** unicodable6 joined [04:56] *** quotable6 joined [04:56] *** notable6 joined [04:56] *** coverable6 joined [04:56] *** sourceable6 joined [04:56] *** sena_kun left [05:01] *** OpenZen left [05:02] *** tejr left [05:02] *** tejr joined [05:16] *** sauvin joined [05:29] *** wamba joined [05:30] *** brtastic left [05:35] *** aborazmeh joined [05:35] *** aborazmeh left [05:35] *** aborazmeh joined [05:47] *** ponbiki joined [05:47] *** ponbiki left [05:48] *** ponbiki joined [05:49] *** ponbiki left [06:09] *** cpan-raku left [06:10] *** cpan-raku joined [06:10] *** cpan-raku left [06:10] *** cpan-raku joined [06:12] *** andrzejku joined [06:20] *** stoned75 joined [06:28] *** brtastic joined [06:33] *** andrzejku left [06:34] hi, i'm currently strugging with react/supplies: i have an application with a main react block that should handle messages from a websocket supply (Cro::WebSocket::Client::Connection). whenever the connection closes i need to reopen it, which returns a new connection object with a new message supply. however then the main react block still has the original - now stale - supply. how do i pass the new supply to the main react block? afaict there are method [06:34] merge multiple suppies - but they always return a new supply instead of altering an existing supply. [06:55] *** sena_kun joined [06:55] *** stoned75 left [06:57] *** Altai-man_ left [06:58] *** stoned75 joined [07:05] *** dakkar joined [07:19] *** kst` left [07:27] *** Black_Ribbon left [07:57] *** aborazmeh left [08:06] *** stoned75 left [08:14] perlmaros, that's a problem i've dealt with before [08:15] the way i handle it is to use a supply block instead of react for the connection, emit connection supplies to a Supplier, and use react with Supply.migrate on the connection supplier [08:17] *** stoned75 joined [08:19] *** Sgeo left [08:22] *** sarna joined [08:29] *** pecastro joined [08:30] *** Guest43 joined [08:32] *** gdonald left [08:39] *** leont_ joined [08:39] *** leont joined [08:39] *** JJMerelo joined [08:39] releasable6: status [08:39] JJMerelo, Next release in ≈2 days and ≈10 hours. 1 blocker. 143 out of 292 commits logged (⚠ 4 warnings) [08:39] JJMerelo, Details: https://gist.github.com/946f43e555e7bb0b07a15dbbe28e5292 [08:40] *** Guest436 joined [08:40] *** Guest436 is now known as dry [08:40] *** dry is now known as Dry [08:40] *** Dry is now known as hungrydonkey [08:41] *** Guest43 left [08:48] *** gdonald joined [08:53] *** neheist2 joined [08:53] *** gdonald left [08:54] *** Altai-man_ joined [08:55] Altai-man_ did you see my comment about IO::Glob? [08:56] *** sena_kun left [08:59] *** gdonald joined [09:03] JJMerelo, yup, and replied. Blin is not for knowing what module in the ecosystem were broken so we could fix them, it's primary use is to know what in Rakudo was broken so that we could fix Rakudo. Yes, you may fixed the module, but the code it uses just became non-working for someone without a really great reason behind this. [09:03] s/module/modules/ [09:03] s/it's/its/ [09:04] Gh, need breakfast. [09:04] Altai-man_ not sure about that. It might have been coincidental. Or it might actually have fixed something that was used broken. [09:06] JJMerelo, I still have not seen any real investigation of this proving what it is. Patching the tests to got it working again and releasing without knowing the real explanation is shooting in the dark hoping you won't kill someone. Maybe it concidentally won't. [09:07] Check out my comments to the issue and the related fixes. One of the tests that was failing was due to a patch that fixed something for Windows. [09:07] The other tests that were failing were actually incompatible with other tests that didn't fail. You fixed some, you broke some others. [09:09] Here is my take on the stuff https://github.com/zostay/raku-IO-Glob/issues/22 [09:09] *** hungrydonkey left [09:12] The module worked just fine on 2020.05. If we release it right now, 2020.06 suddenly breaks it unless you do patching manually somewhere somehow. This is not how it should be. [09:14] I wonder if we can kindly ask lizmat to just look at the b63976a8f19e650fe3533562a5fa040d84535de8 results. I truly adore those efforts on making Rakudo faster. Yet it would be awesome to have both a speedup and no compat issues. [09:14] (2020-05-21) https://github.com/rakudo/rakudo/commit/b63976a8f1 Make IO::Path.dir between 1.5x and 2.2x as fast [09:14] But the IO::Path.dir code that's affected by that change is actually in tests, not in the code. [09:14] Anyway, time for breakfast now. [09:15] *** bdju left [09:17] JJMerelo, enjoy! By the way, I'd like to ping you about docs UI later, there are some questions around. [09:18] *** JJMerelo left [09:21] I don't think it matters that the change is in the test rather than the code; it's still a change of behavior... [09:25] *** rindolf joined [09:30] fwiw, I've looked at the IO::Glob issue for many hours already, and I'm starting to think the bisect is a red herring [09:31] JJ's work will help me get to the bottom of this today [09:31] lizmat, does it pass if you revert? [09:32] a simple revert is not an option... already tried that [09:32] Not suggesting, just wondering to check this way is a culprit. [09:32] no, if it had been a simple revert, I'd done it already [09:32] :/ [09:36] *** xelxebar left [09:37] *** wamba left [09:37] *** xelxebar joined [09:39] *** JJMerelo joined [09:41] Is this the List -> Array in Match thing, or something else? [09:44] nope, that has been reverted already [09:44] this is about "." and ".." appearing (or not) in directory listings [09:45] complicating factor in this is that the JVM backend never produces "." and ".." [09:45] whereas MoarVM does, but they'r filtered out by default [09:46] but if you have an explicit test, the MoarVM needs to add "." and "..", because they are presented to the test on the MoarVM backend as well [09:47] lizmat: Ah, I see. What was the Array -> List resolution, btw? [09:47] IO::Glob's test fail because somehow the "." and ".." appear in the result tested against when they aren't expected [09:47] It occurred to me that while things may commit to Array, they probably don't depend on elements having been assigned rather than bound... [09:47] jnthn: I reverted the opt [09:47] Meaning you could mostly keep the opt [09:47] *** oddp joined [09:48] yeah, but since I'm reworking Match anyway, I didn't want to put any work in that anymore [09:48] in the rewrite, it *will* be an Array with bound values [09:49] unfortunately, the dir opts cannot be easily reverted [10:02] *** literal_ is now known as literal [10:52] *** brtastic left [10:55] *** sena_kun joined [10:57] *** Altai-man_ left [10:59] *** dakkar left [11:10] *** brtastic joined [11:12] *** JJMerelo left [11:30] *** stoned75 left [11:32] *** vike left [11:32] *** stoned75 joined [11:37] *** JJMerelo joined [11:58] *** vike joined [12:12] *** Maylay left [12:13] *** Maylay joined [12:13] *** molaf left [12:17] *** JJMerelo left [12:34] *** wamba joined [12:45] *** team\andinus is now known as notandinus [12:54] *** Altai-man_ joined [12:54] *** wamba left [12:57] *** sena_kun left [12:58] weekly: https://news.ycombinator.com/item?id=23560339 [12:58] lizmat, Noted! (weekly) [13:03] *** soursBot joined [13:05] I must say, that like rurban, I've always felt that “the first postmodern computer language” was an insult [13:06] 2020-06-17T21:29:48Z #raku El_Che - fyi - https://www.reddit.com/r/azuredevops/comments/hb0kds/azure_devops_toolset_to_automate_crud_operations/ [13:06] 2020-06-17T22:09:37Z #raku El_Che - I've create home project and call it Spazure - Sparrow automation for Azure DevOps ))) - https://github.com/melezhik/Spazure [13:08] "This is not beauty, beauty is Lisp or Forth" -- As someone who's worked with common lisp, various scheme and racket, lisp is definitely not pretty. Maybe on a superficial level, when looking at the base syntax alone. Everything beyound that is the same convoluted and smelly horsecrap as in any other language. [13:12] *** bdju joined [13:12] *** vrurg left [13:12] *** vrurg joined [13:26] *** dataange` left [13:31] *** lucasb joined [13:32] Lisp is beautiful in its uniformity, but that also comes with major downsides. Sometimes different things should look different. (I still don't think I fully get how macros differ from functions in Lisp, because their defns look so similar) [13:36] I think that downside is mainly a matter of what you're used to :) [13:40] *** sarna left [13:51] *** oddp left [13:53] I guess Raku has a similar thing wrt to public attributes and methods [13:53] *** oddp joined [13:53] $.foo doesn't tell you whether it is an attribute accessor or simply an instance method called "foo" [13:54] I know it's a bland and meaningless statement, but beauty is in the eye of the beholder. I like twigils, but there's plenty of people to whom even regular sigils are an affront. [13:56] *** rindolf left [13:59] *** oddp left [14:01] *** rindolf joined [14:09] *** molaf joined [14:27] That's the main thing; talking about it like there's an objective truth to aesthetics is wrong in the first place. [14:27] *** soursBot left [14:30] *** JJMerelo joined [14:31] *** soursBot joined [14:33] *** klapperl_ left [14:35] side note, the difference between functions and macros is quite simple. if you pass a function an argument, it gets evaluated. if you pass a macro something, you get the unevaluated expression as a "data structure" [14:39] *** JJMerelo left [14:50] *** greppable6 left [14:52] *** greppable6 joined [14:53] *** eseyman left [14:54] *** klapperl joined [14:55] *** sena_kun joined [14:55] *** brtastic left [14:56] *** Altai-man_ left [15:06] I think my confusion with macros comes from when docs use examples that don't really *need* macros, so I end up asking "couldn't this just be a function? what's the point of macros?" [15:09] *** wamba joined [15:09] *** soursBot left [15:12] *** skids joined [15:18] *** wamba left [15:23] *** brtastic joined [15:29] *** soursBot joined [15:32] *** wamba joined [15:34] *** OpenZen joined [15:40] *** soursBot left [15:43] *** soursBot joined [15:46] *** soursBot_ joined [15:47] *** soursBot left [15:53] *** brtastic1 joined [15:53] *** brtastic left [15:53] *** brtastic1 is now known as brtastic [16:05] *** soursBot_ left [16:08] *** sno left [16:09] Hi all, I need a test reader or two for a chapter of Raku Fundamentals on web services with Cro (and declarative APIs), about 8 pages [16:10] anybody interested? please /msg me your email address [16:11] (more like 10 pages actually) [16:12] *** soursBot joined [16:15] yo ustill have mine? :3 [16:17] *** MasterDuke joined [16:19] that's the wakelift address? [16:20] sent [16:20] yes the one [16:20] thank you very much [16:20] moritz: i can [16:20] it's my turn to thank you (and the other two volunteers so far; wait, three! :D ) [16:21] *** Sgeo joined [16:23] big fan of tiemstamps [16:23] moritz, you can find my email on github profile (Altai-man) if interested. :) [16:25] sena_kun: thanks, sent! [16:25] timotimo: heh, just got there [16:26] for context; an earlier chapter already develops a command line application for the same task (converting between ISO datetimes and POSIX/UNIX timestamps) [16:26] "start service" - start serving? [16:26] zef + modules, higher-order functions, regexes, grammars, dynamic variables have all been discussed in previous chapters [16:27] timotimo: yes, good catch [16:30] *** brtastic left [16:30] *** brtastic joined [16:31] *** leont_ left [16:33] i tend to forget which of is where it's wrong, but "in it's block form" shouldn't have an apostrophe? [16:34] *** MilkmanDan left [16:34] and i'd perhaps also state that "all subscribed streams have finished" or error conditions to be cases where a react block finishes [16:40] *** MilkmanDan joined [16:46] *** soursBot left [16:47] *** soursBot joined [16:48] *** guifa left [16:48] *** MilkmanDan left [16:54] *** Altai-man_ joined [16:57] *** sena_kun left [16:59] *** MilkmanDan joined [17:28] *** zacts joined [17:30] *** oddp joined [17:33] *** rainmanjam joined [17:34] *** zacts left [17:43] *** Sgeo left [17:44] *** Sgeo joined [17:58] *** sno joined [18:00] yes, the ' is wrong [18:01] and good catch, re react [18:04] *** Maylay left [18:07] *** Maylay joined [18:13] *** soursBot left [18:18] *** soursBot joined [18:21] wasn't there a thing in cro for dockerifying stuff? or does it already generate it for you when you "cro stub" a service? [18:21] *** vrurg left [18:22] *** brtastic left [18:22] *** vrurg joined [18:22] It does. [18:24] "everything stays the same" + else [18:24] i've gotten sidetracked, maybe everything i'd point out now is already known [18:24] Kaeipi: thank you for the migrate hint [18:25] timotimo: so far, the feedback has been very orthogonal :D [18:26] *** sauvin left [18:26] *** vrurg left [18:26] "add second get call" + a [18:27] *** Black_Ribbon joined [18:27] ✓ [18:28] "a bit of pain" + a (i believe) [18:28] "and tore it down" -> "and tear it down" [18:30] there was some document i forgot the name about that suggested making most things configurable via env vars, rather than commandline args; if i can find it again, maybe it'd make sense to point that out in your example, too [18:31] *** vrurg joined [18:32] very slightly confused by the unix timestamps having a space before the comma in the test example [18:33] "block with our tests" + a [18:33] fixing [18:34] timotimo: the whole 12 factor app thingy? not sure I want to go into that in the context of that chapter [18:34] that's the one, yeah [18:34] no problem [18:35] *** natrys joined [18:35] think on page 17 at the start you've confused request and response in the prose [18:35] you're testing that the response matches your expectations, not the request [18:35] there's page 17? [18:36] ah [18:36] x) [18:36] and somehow the output of the test is in blockquote once and regular text another time [18:36] *** vrurg left [18:39] looks like "File index.htmlshould be placed" lacks a space [18:40] looking forward to the release. Thx to everyone working on it! [18:40] releasable6, status [18:40] Altai-man_, Next release in ≈2 days and ≈0 hours. 1 blocker. 143 out of 300 commits logged (⚠ 4 warnings) [18:40] Altai-man_, Details: https://gist.github.com/b612b98c7bd449224806fde582962985 [18:40] end of page 18 has "a pretty [..] api endpoints" [18:41] .oO ( still a massive blocker ahead ) [18:41] *** wamba left [18:42] "we could have written just as well:" isn't right, but not sure what to suggest instead [18:44] lower middle of p20 has "just like get is a function [...], so is route {} just a function", which sounds odd [18:46] timotimo: "we could have written instead" sounds better, ya? [18:47] I'll rephrase that [18:48] "...written this instead:" ? [18:49] page 21 seems to have very strange formatting issues? [18:49] if you want to keep the "just as well", then "we could just as well have written:" would work [18:49] ah, i think some code lbock wasn't terminated before putting more prose [18:55] *** sena_kun joined [18:55] "t ## Summary" probably accidentally prevented Summary from becoming a headline [18:57] *** Altai-man_ left [18:57] not sure if it's worth mentioning in this context, but not only json can be automatically serialized by cro [18:57] you can extend that mechanism [18:59] the code example on page 14, why does it have the `+` before `$timestamp` in the `Date.new` call? [18:59] MasterDuke: a left-over from sub MAIN() where it's actually an IntStr [18:59] I've removed it from the latest version [19:00] ok, i just reloaded [19:00] i can't reload the pdf, it was a mail attachment %) [19:01] "replace signal(SIGIINT) by" has an extra "I" [19:02] and `signal(SIGINT).merge(signal(SIGTERM)` is missing a final `)` [19:04] `my ($date_str, $time_str)` doesn't have padding spaces inside the parens, but `my ( $hour, $minute, $second )` does [19:05] and the subsequent DateTime.new call has one at the opening, but not the closing [19:06] what's next? Trailing whitespace? x) [19:06] just kidding, yeah, it's good when the snippet doesn't look sloppy [19:07] at least trailing whitespace don't show up in print :D [19:08] some of the code blocks aren't syntax highlighted [19:08] yeah, I actually like when even things that are within the text are highlighted [19:10] *** soursBot_ joined [19:10] *** soursBot left [19:10] page 17: "to he the" [19:11] moritz: speaking of the small stuff, you can also put a comma after `:$application` (it's the last arg in the call) because you did after `application => routes(),` [19:12] +1 [19:13] I like it, nameds are often changed so it can look good in git diff if you're not packing a lot of stuff on the same line [19:14] the iso input and result don't look the same (not sure if that's ok, but it seems a little weird) [19:14] *** vrurg joined [19:15] `+$timestamp` on page 20 [19:15] and `where $date-re` instead of `where &date-re` [19:19] "expects an block" should be "a block" [19:24] *** zacts joined [19:24] roger [19:26] it's amazing how many small errors, inconsistencies and suboptimal wording one can make in just 10 pages... :-) [19:26] (but then, the rest of the book has undergone 5+ review phases already, and this chapter hasn't) [19:32] *** soursBot_ left [19:36] *** soursBot joined [19:38] looks good, made sense, i could follow the code [19:38] *** sno left [19:39] thanks! [19:43] New module released to CPAN! LibXML (0.5.1) by 03WARRINGD [19:45] *** MilkmanDan left [19:46] *** MilkmanDan joined [19:46] *** vrurg left [19:54] *** wamba joined [20:16] *** zacts left [20:25] *** mowcat joined [20:37] *** kensanata joined [20:45] *** natrys left [20:46] *** vrurg joined [20:47] *** patrickb joined [20:48] *** patrickb left [20:50] *** vrurg left [20:51] *** brtastic joined [20:54] *** Altai-man_ joined [20:57] *** sena_kun left [20:58] *** rindolf left [20:59] *** aborazmeh joined [20:59] *** aborazmeh left [20:59] *** aborazmeh joined [21:00] *** brtastic left [21:01] *** skids left [21:03] *** vrurg joined [21:17] *** soursBot left [21:20] *** wamba left [21:40] I can do that in just one sentence :) [21:41] *** clarjon1 joined [21:42] *** kensanata left [21:46] *** sno joined [21:52] New module released to CPAN! LibXML (0.5.2) by 03WARRINGD [21:52] *** aborazmeh left [22:17] *** dataangel joined [22:55] *** sena_kun joined [22:56] *** skids joined [22:57] *** Altai-man_ left [23:00] *** leont left [23:12] *** pecastro left [23:31] *** mowcat left [23:37] New module released to CPAN! Red (0.1.8) by 03FCO