[00:13] *** lichtkind left [00:13] *** MasterDuke91 joined [00:15] *** monkey_ joined [00:24] *** monkey_ left [01:24] *** evalable6 left [01:24] *** linkable6 left [01:27] *** linkable6 joined [01:42] *** monkey_ joined [01:55] *** kjp left [01:56] *** kjp joined [02:27] *** monkey_ left [02:57] *** sftp left [02:57] *** sftp_ joined [02:58] *** sftp_ is now known as sftp [03:25] *** evalable6 joined [03:53] ¦ doc: codesections++ created pull request #3962: Explain "list" vs "destructuring" assignment [03:53] ¦ doc: review: https://github.com/Raku/doc/pull/3962 [04:00] *** MasterDuke91 left [04:05] *** reportable6 joined [04:25] *** Xliff left [04:33] *** keutoi joined [05:33] *** committable6 left [05:33] *** statisfiable6 left [05:33] *** greppable6 left [05:33] *** sourceable6 left [05:33] *** releasable6 left [05:33] *** linkable6 left [05:33] *** evalable6 left [05:33] *** squashable6 left [05:33] *** bisectable6 left [05:33] *** shareable6 left [05:33] *** bloatable6 left [05:33] *** nativecallable6 left [05:33] *** unicodable6 left [05:33] *** benchable6 left [05:33] *** notable6 left [05:33] *** coverable6 left [05:33] *** quotable6 left [05:33] *** tellable6 left [05:33] *** reportable6 left [05:33] *** unicodable6 joined [05:34] *** evalable6 joined [05:34] *** nativecallable6 joined [05:34] *** coverable6 joined [05:34] *** tellable6 joined [05:35] *** greppable6 joined [05:36] *** committable6 joined [05:36] *** shareable6 joined [05:39] *** Altai-man left [06:03] *** reportable6 joined [06:34] *** sourceable6 joined [06:34] *** linkable6 joined [06:35] *** quotable6 joined [06:36] *** benchable6 joined [06:36] *** notable6 joined [06:36] *** bloatable6 joined [06:36] *** squashable6 joined [06:56] *** frost joined [06:57] *** codesections left [07:36] *** bisectable6 joined [07:36] *** statisfiable6 joined [07:42] *** Sgeo left [08:10] *** dakkar joined [08:36] *** releasable6 joined [09:10] *** clarkema joined [09:23] *** lichtkind joined [09:33] *** lizmat_ joined [09:37] *** lizmat left [09:37] *** lizmat_ is now known as lizmat [09:37] *** lizmat left [09:37] *** lizmat joined [10:35] *** xinming left [10:59] *** squashable6 left [11:05] *** lizmat left [11:08] *** TempIRCLogger left [11:09] *** lizmat joined [11:10] *** TempIRCLogger joined [12:00] *** squashable6 joined [12:03] *** reportable6 left [12:15] *** C0l0mb0 joined [12:18] newb question from long-time Perl programmer. I want to convert a Perl5 script into raku to learn raku. So my first issue is the perl code "while (<>) { etc }". what are the best resources to learn what the raku equivalent of <> is? [12:20] I have looked at https://docs.raku.org/language/5to6-nutshell but its not that detailed [12:26] C0l0mb0: ok? would you mind sharing with us what you feel is missing from the 5to6-nutshell page? [12:27] it covers quite a bit, but if something important is missing, that's worth fixing :-) [12:28] I'm trying to find how to write a cli that can take in piped lines or use the first parameter as a filename to read in and execute line by line [12:30] C0l0mb0: it's `lines()` [12:30] it would be handy if 5to6 showed some example programs like that to use as a skeleton [12:30] Ok, you may want to also look at the MAIN method, for command line flags... [12:31] s/flags/parameters/ [12:31] CIAvash: yes - I found "lines()" from the raku error message when I tried just running the old Perl 5 code, I'm impressed with the error messages in raku [12:31] The section named "Getopt::Long" shows a short example [12:32] sjn: ah yes, that is useful, didnt see that earlier [12:32] (Yeah, some of these topics could probably be improved with some better keywords and descriptions) [12:34] I'm keen to convert some of my scripts to Raku and learn that way. It does seem like an awesome language [12:34] converting scripts is a good way of exploring the language :) [12:35] yeah, I've been doing the REPL examples but I really want to make my first proper .raku script and start using it for real work [13:05] *** reportable6 joined [13:24] *** frost left [13:24] *** C0l0mb0 left [13:27] does Red provide something like a to-hash on its models? [13:32] Altreus: do you mean to get a row (an object) as a hash? [13:33] SmokeMachine__: we do, I have an object ^load has given me like this; `Character.new(id => 35383842, tier => 1, comment => "test", date-added => DateTime.new(2016,5,10,17,20,18.674), author => 496805464491687949)` and apparently to-json doesn't like it. :( [13:39] aye, just a naive conversion to a column => value hash [13:40] if you want json, you can just do something like: https://usercontent.irccloud-cdn.com/file/4dZSZ4lu/image.png [13:41] JSON::Class! [13:41] I still think to-json is an antipattern and I'm waiting for history to agree with me, but at least it makes a prototype quick [13:44] But if you want this to make Red objects accessible throw JSON:API interface... I've been playing with this that could be useful (but still far from completed and help needed): https://github.com/FCO/CroX-Red-JsonAPI [13:47] but if you don't want JSON:API but just want to jsonify a ResultSeq,Jonathan Stowe has done this: https://twitter.com/gellyfish/status/1417866847882563590 [13:48] https://gist.github.com/jonathanstowe/7d2ec8d499ddb058e62669cac0792cbb [14:24] *** xinming joined [14:39] *** xinming left [14:40] *** xinming joined [14:48] That's interesting how things pop up close to what I was doing recently... I have a good experience JSONifying Red models with JSON::Marshall. [14:51] I don't like the implication that every object only has one possible representation in JSON [14:51] nor do I like the danger of accidentally outputting a password column in JSON because the computer is doing as it was told! [14:52] to-json is a procedure that should be owned by the view class: the controller, or an adapter, or something [14:52] *** lichtkind left [14:52] Altreus: has Str $.password is password handles is json-skip; [14:52] There's no reason a Red class should know how a Cro webapp wants to represent it [14:52] You don't put to-html on it [14:52] I don't know why JSON is so special that rendering things as JSON goes on the things and not the renderer [14:53] It's very bad! [14:53] It couples your JSON API to your database schema, which is already naughty [14:53] cos it means you can't change the schema without changing the API [14:53] and you can't change an API [14:53] In my use JSON goes almost nowhere close to rendering. The only thing I need it for is to simplify JSON-RPC communication with the frontend. [14:54] outputting JSON /is/ rendering [14:54] Database models should not be directly connected to an API [14:55] that's why MVC was so popular [14:55] where did it go :( [14:55] Things like user account entries are hardly something to be changed. [14:55] How long does software engineering have to be a discipline before people realise that what they think the future holds is rarely what the future holds? [14:55] I've been at this company for 2 years now and most of that time has been removing assumptions like that from the code [14:56] All for the sake of putting to-json(User) in the right place [14:57] There are exceptions. What if your frontend is actually managing the database? Then your API is bound to it anyway. [14:57] the problem is, of course, not that you call $user.to-json in the controller: rather, it's the fact that if to-json changes, you break your API by accident [14:57] Telling me there are exceptions implies you agree with the rule in general, so that's enough for me [14:59] It's hard to argue, I'd say. :) [15:00] good cos I have citations to back me up :D [15:00] specifically in the "Don't couple your API to your database" regard [15:00] if only I could find the book... [15:00] Altreus: you could `($model but JSON::Class).to-json` on your view, no? [15:01] SmokeMachine__: that's correct, and that is where you would do that [15:01] But then the point is you have the opportunity to amend that line without breaking the controller [15:01] The case of user account is the kind where direct mapping of a user record to API is acceptable if you want to provide basic user info to the frontend. The other thing is when you want to provide more extended account info like personal information (kind of meta-info) as this is something more mutable and should even be kept in a separate DB table. Just as an example. [15:01] because now if you put a password on that model, how could you possibly put json-skip on it? [15:02] direct mapping is never appropriate because it means you can't change your mind about *anything* in the future [15:02] What if you got the memo that "first_name" and "last_name" shouldn't be separate fields? [15:02] now you want to update your model to live in the future by dropping those columns and just using a name field [15:03] But you can't because that's a breaking change to the API [15:03] If you'd just implemented a view at the start you could do a "best guess" for the old API and implement a new API with just name [15:03] Nothing is immune to the "I did it wrong" bug [15:04] Assuming it was written right is probably the main problem with software in the first place :P [15:04] I recognise this applies to the very argument I'm making [15:04] Altreus: Full name is meta. My example is about a user record which consists of: id, username, group flag (account is a goup), and password. The rest is locate somewhere else. Now, what would you change in this table? ;) [15:04] I don't know. What changes in the future? [15:04] I've not been there so I can't tell you [15:05] Maybe you add a 2fa secret [15:05] forget to put json-skip on it [15:05] Altreus: 2fa goes as a separate service with it's own data. Miss. [15:05] JSON::Class uses a blacklist for sensitive data, which is a bug waiting to happen [15:06] I mean, that table is the core. It is proclaimed immutable. Period. There're things not changing ever. Ask Microsoft, they know alot about these. :D [15:06] You're asking me to invent a future reason why your arbitrary specific instance might be bad in the future [15:06] *** lichtkind joined [15:06] Why? [15:06] Assume it will go wrong, and protect against it [15:06] This discussion is already pages and pages longer than the code required to protect yourself against data leaks in future [15:07] You're arguing against defensive coding [15:07] Don't :P [15:07] You fall into another trap. It's too hard to hold swampy ground. You need axioms to build theorems. [15:08] Saying something isn't going to happen just because you don't have enough imagination to see why it might happen is not sustainable [15:08] If there's one thing software is great at it's undermining those assumptions [15:08] What I'm arguing against is that I'm often loose too much time considering making code less vulnerable to future changes. Sometimes it doesn't worth time spent. [15:09] well sure, we all come up against time constraints [15:09] That's why it's helpful to have design patterns [15:09] And you're discussing this with someone who is too often blamed for saying "what if this goes wrong?" :D [15:09] So you can pre-solve this issue by always passing your models through a view adapter, even if it's thin [15:10] on that case you should do something like`to-json %( name => "{ .first-name } { .last-name }", password => "***" ) given $model` or something like that [15:10] * vrurg will be away for a while [15:10] and then to-json might as well be to-hash [15:10] Which is another thing!!!! [15:10] It doesn't return JSON! [15:10] Why is it called to-json when it doesn't return JSON? [15:10] SmokeMachine__: right, but then someone adds more sensitive data and suddenly it's popping out on the API, even though nobody updated the API spec to include it [15:11] no, you should ALWAYS get data via whitelist [15:11] cos you never know what is going to show up! [15:12] that IS a white list, isn't it? if someone change the model, it won't change anything on the generated answer... [15:12] *** Sgeo joined [15:12] sub for-json(MyModel:D $model) { $model.to-hash:kv } [15:12] oh ... I totally misread your use of to-json, sorry [15:12] yes, like that [15:12] got a bit carried away ^^; [15:14] BTW, I the white list is a good thing. Wish it be how JSON::Marshall do things, use `is json-use` instead of `is json-skip`. [15:15] s/I// [15:15] maybe fork it and do that :) [15:15] I think a combination is perfectly reasonable [15:15] (except don't call it JSON because it's not JSON) [15:16] ToHash::Simple, which provides to-hash and is hash-use [15:16] or something [15:17] now you can add the role to literally any class and make selected properties come out in to-hash [15:17] I bet you can even do does ToHash::Simple[:everything] [15:17] personally I'm always keeping in mind that not all my data models come from databases, so I want a solution that works generally [15:17] Oh, no. I just've done sufficiently featureful Config::BINDish and need to focus on other things [15:17] API::Discord, for example, already uses a JSON API as its data source [15:18] So to-json means something different when I'm communicating with Discord compared to if I were to put a web API on that [15:27] *** xinming_ joined [15:29] *** xinming left [15:30] *** abraxxa left [15:43] Altreus: maybe something like this? https://usercontent.irccloud-cdn.com/file/jL9b212f/image.png [15:44] actually that's quite useful, being able to specify certain values and also have the others filled in [15:45] SmokeMachine__: hey, you could error if it asked for an attr that isn't on the obj, even if it's given a value [15:46] that way you're sure you're not just leaving legacy code lying around [15:46] Say you completely removed password auth for some reason, then it would say, not gonna give you password, even though you specified a value for it [15:47] but what id you want to change the name of it? or create a completely new one (as the :name one?) [15:48] ah hrm, but then &value would fail if it asked for a nonexistent thing [15:49] you could change the name of it with password => *.pass [15:49] or such [15:49] eh, IDK, you might be right [15:49] Feels like overkill [15:49] now it's almost a format-hash method :D [15:50] also it doesn't have to be on the object, which is nice [16:30] *** evalable6 left [16:30] *** linkable6 left [16:32] *** evalable6 joined [16:42] Altreus: my last version, if someone is interested: https://usercontent.irccloud-cdn.com/file/lc5Zu9w3/image.png [16:43] hey I like lens [16:44] SmokeMachine__: this is a fun algo but my brain is refusing to process it [16:44] I'm gonna leave it open for later [16:46] *** melezhik joined [16:46] . [16:48] *** dakkar left [16:50] ! [17:06] *** xinming_ is now known as xinming [17:07] how can I get a source code of Raku program when run `raku -e ' ...' `? [17:09] What is the official dbmopen implementation for rakudo ? [17:10] Today, I thought that, can we have a database where all keys are in memory, but all data are on the disk? [17:10] Hmm, I know it's doable, What I mean is, wether we already have the module for this. ;-) [17:20] melezhik: there is no official interface for that [17:21] unofficially, there is Rakudo::Internals.PROGRAM [17:21] maybe we should expose that somehow [17:24] lizmat++ [17:29] *** jess joined [17:43] * lizmat clickbaits https://rakudoweekly.blog/2021/09/13/2021-37-receding/ [17:48] melezhik: %*COMPILING<%?OPTIONS> might be a less brittle thing to depend on [17:52] although that also appears to be an implementation detail [17:54] maybe I should just make a module for it [17:55] *** immediate joined [17:57] m: say [5, 12, 13]>>.WHAT [17:57] rakudo-moar 10b327292: OUTPUT: «(Array)␤» [17:57] m: say [5, 12, 13]>>.&WHAT [17:57] rakudo-moar 10b327292: OUTPUT: «[(Int) (Int) (Int)]␤» [17:58] Hello, why we need &? and what does it do when we don't use &? [17:58] *** melezhik left [18:03] *** reportable6 left [18:04] immediate: intriguing, I guess it's because .WHAT is basically a macro [18:05] but it feels incorrect indeed... [18:05] *** patrickb joined [18:23] *** keutoi left [18:30] *** linkable6 joined [19:05] *** reportable6 joined [19:12] thank you [19:15] immediate: seems like a bug [19:18] Is it specific to WHAT? WHICH gives a different result [19:18] m: say [5, 12, 13]>>.WHICH [19:18] rakudo-moar 10b327292: OUTPUT: «[Int|5 Int|12 Int|13]␤» [19:19] m: say [5, 12, 13]>>.&WHICH [19:19] rakudo-moar 10b327292: OUTPUT: «5===SORRY!5=== Error while compiling ␤Undeclared name:␤ WHICH used at line 1␤␤» [19:22] m: dd WHICH 42 [19:22] rakudo-moar 10b327292: OUTPUT: «5===SORRY!5=== Error while compiling ␤Undeclared name:␤ WHICH used at line 1␤␤» [19:22] *** patrickb left [19:24] that's because there is no sub WHICH in the core, but there not a sub WHICH [19:24] that's because there is no sub WHICH in the core, but there *is* a sub WHAT [19:51] *** cognominal left [19:54] *** Manifest0 left [20:12] *** Manifest0 joined [20:17] *** Manifest0 left [20:32] *** Manifest0 joined [20:42] *** abraxxa-home joined [20:45] *** abraxxa-home left [20:51] *** Manifest0 left [20:54] i see thank you [20:55] does it not make sense to have WHICH as a sub [21:01] I'm not entirely sure why *WHAT* is a sub ... [21:03] probably so you can .map(&WHAT)? [21:08] immediate: many month ago I asked that question in #perl6-dev (many many months ago) and this is by design. In some places it's the only way to find out what a thing is. [21:13] gfldex: Did you mean WHICH question? and "it" in your second sentence refers to "by design"? [21:14] The bahaviour of .WHAT is by design. [21:14] moritz_: I'd write that as .map(*.WHAT) anyway I think [21:15] but then .WHAT needs to be a real method as well, not a macro [21:15] m: class A { method WHAT() { 'X' }; say A.WHAT [21:15] rakudo-moar 10b327292: OUTPUT: «5===SORRY!5=== Error while compiling ␤Missing block␤at :1␤------> 3ss A { method WHAT() { 'X' }; say A.WHAT7⏏5␤ expecting any of:␤ postfix␤ statement end␤ statement modifier␤ stat…» [21:16] m: class A { method WHAT() { 'X' }}; say A.WHAT [21:16] rakudo-moar 10b327292: OUTPUT: «(A)␤» [21:16] if that were the case, the line above should return X, not A [21:17] moritz_: Why would we support override of WHAT? [21:18] *** Manifest0 joined [21:18] m: .say for (3, "b").map(*.WHAT) [21:18] rakudo-moar 10b327292: OUTPUT: «Cannot map a List using 'Whatever'␤Did a * (Whatever) get absorbed by a list?␤ in block at line 1␤␤» [21:18] Oh interesting [21:18] I don't think we have a name for the things that are like .WHAT . [21:19] I figured that it would macroize the WhateverCode, but I guess not. [21:19] `$foo.do-stuff` <-- what kind of thing is `.`? [21:21] I link to think about those things as grammar- or AST-level operators. So `.WHAT` is a "postfix at compile time". [21:21] s/link/like/ [21:25] *** immediate left [21:26] isn't that the gist of a macro? [21:27] The macros we have right now are written like a sub. Is a sub an operator? [21:29] gfldex: Are you asking that in the type-theoretic sense or the Raku practical sense? [21:31] In a natural language sense. Because we are talking about it and have difficulty to name the catigory. [21:34] Actually, natural language is hard. Let's stick with Raku. :D [21:38] *** melezhik joined [21:38] is raku `dir()` function keeps it state? [21:38] https://github.com/melezhik/topsdevops/blob/master/app.raku#L18-L20 [21:39] this 2 lines returns the same results even though content of directories change across requests [21:39] melezhik: the function itself doesn't but the c-level stuff it uses does [21:39] they only give another result when I restart my cro app [21:40] so, how can I "flush" dir state? [21:40] however, keeping that state around for to long might result in strange errors [21:40] I don't need to keep state, here is the thing )) [21:40] dir returns a list. The state is bound to that list. If you call dir() again you get a fresh list with it's own state [21:41] I expect dir() is called per every cro request ... [21:41] oh, it is not ... [21:42] only now noticed it is not under a certain router [21:42] that explains the behavior )))) [21:42] thanks for thinking with me gfldex )))) [21:52] *** melezhik left [21:53] gfldex: it's still a macro, syntax doesn't preclude something from being a macro [22:52] *** linkable6 left [22:52] *** evalable6 left [22:54] *** RakuIRCLogger left [22:55] *** TempIRCLogger left [22:55] *** evalable6 joined [22:56] *** linkable6 joined [22:56] *** Geth left [22:56] *** lizmat left [23:00] *** lizmat joined [23:00] *** TempIRCLogger joined [23:01] *** Geth joined [23:37] *** bronco_creek joined [23:38] *** bronco_creek joined [23:40] *** bronco_creek left [23:42] *** bronco_creek left