🦋 Welcome to the MAIN() IRC channel of the Raku Programming Language (raku.org). Log available at irclogs.raku.org/raku/live.html . If you're a beginner, you can also check out the #raku-beginner channel!
Set by lizmat on 6 September 2022.
SmokeMachine aruniecrisps: did you think more about migration? 00:22
00:25 mark22k left 00:46 jpn joined 00:51 jpn left 00:58 ACfromTX joined 01:47 jpn joined 01:52 haxxelotto left 01:53 jpn left
aruniecrisps @SmokeMachine yea it makes sense 02:00
@SmokeMachine i did, i like the idea of having different schemas, but I was wondering whether or not we could automate the generation of schemas using the Red command line tool 02:01
02:01 tea3po joined
SmokeMachine Why we would not? 02:02
aruniecrisps Makes sense 02:04
SmokeMachine I think with RakuAST it would be easier…
aruniecrisps I looked at your last comment on the issue, not sure what you mean by that
SmokeMachine But still possible without it (I think)
aruniecrisps > I've been wondering... would it make sense to on updating local db, save the dump of the DB to be able to restore it in case the user want to revert it?
Wait sorry I had a long day I just reread it it makes sense 02:05
02:05 teatwo left
Yea I think this is a solid plan @SmokeMachine, I was doing some reading up on CompUnit::Repository 02:06
SmokeMachine I mean, when we do update on local db, we may lose data (it’s dev data, but that’s not ok to be lost), so that way we could not lose data if we revert the update… 02:07
With that last option (use RedSchema (…)) we don’t even need a custom CompUnit::Repository 02:08
aruniecrisps To what extent should we store the dump of the DB, should we just store the last backup or should it be user-configurable per migration? 02:09
SmokeMachine Just a `sub EXPORT(@model)` would be enough
02:10 MasterDuke left
SmokeMachine I think we should store all of them on a .gitignore path 02:11
aruniecrisps Agreed
I'm guess RedSchema or Red::Schema would be a class right 02:13
SmokeMachine that way that will be a local thing only
I see RedSchema as just a EXPORT that would also use Red::Schema 02:16
Like: ```use Red::Schema; sub EXPORT(@models) { my @classes = import-models @models; return Map.new: |@models.map({ .^name => $_ }).Map, ‘\Schema’ => schema(@classes) }``` 02:20
aruniecrisps Ah makes sense 02:22
SmokeMachine (import-models needs implementation)
aruniecrisps I want to get started on this but I'm not sure what I ought to be tackling first 02:23
SmokeMachine I would start with RedSchema but not loading historical models… only the current ones… 02:24
(It would be the case when not passing versions) 02:25
aruniecrisps Ok, I'll have a look at it this weekend
02:26 hulk joined
SmokeMachine This next week I’ll be travelling to work… I might still be online, but if I take too long to answer, that’s why) 02:26
02:26 kylese left
SmokeMachine RedSchema will also be useful for other reasons… 02:30
02:36 Summer left, Summer joined 02:37 Manifest0 left
SmokeMachine Here is an example of a EXPORT sub making odd stuff like that: github.com/FCO/Red/blob/master/lib...kumod#L129 02:38
02:48 jpn joined 02:54 jpn left 03:15 hulk left, kylese joined 03:23 haxxelotto joined 03:25 Summer left 03:26 Summer joined 03:30 kylese left 03:35 kylese joined 03:49 jpn joined 03:55 jpn left 03:56 Summer left 03:57 Summer joined 04:20 swaggboi left 04:50 jpn joined 04:56 jpn left 05:16 swaggboi joined 05:32 Summer left, Summer joined 05:52 jpn joined 05:57 jpn left 06:15 Summer left 06:16 Summer joined, tejr left 06:21 tejr joined 06:46 Summer left, Summer joined 06:53 jpn joined 06:58 jpn left 07:17 Summer left, Summer joined 07:45 haxxelotto left 07:47 Summer left, bdju left 07:48 Summer joined 07:49 bdju joined 07:54 jpn joined 07:59 jpn left 08:18 Summer left, Summer joined 08:49 Summer left, Summer joined 08:55 jpn joined 09:00 jpn left 09:28 sena_kun joined 09:37 Sgeo left 09:38 jpn joined 09:40 Manifest0 joined 09:43 jpn left 09:56 jpn joined 09:59 Summer left 10:00 Summer joined 10:02 jpn left
Xliff \O 10:24
Any progress on github.com/rakudo/rakudo/issues/5534? It looks like it's an issue with attributes of the form: "HAS uint8 @.values[ <n> ] is CArray" 10:25
Maybe a free where there should be none? 10:26
I would have thought that the HAS would prevent any C free semantics, but that may not be given the valgrind output.
10:34 jpn joined 10:38 jpn left 10:57 jpn joined 11:02 jpn left 11:58 jpn joined 12:03 jpn left 12:10 MasterDuke joined 12:11 Summer left 12:12 Summer joined 12:42 Summer left 12:43 Summer joined 12:59 jpn joined 13:04 jpn left 13:13 Summer left, Summer joined 13:22 abraxxa-home joined 13:27 abraxxa-home left 14:00 jpn joined 14:21 jpn left 14:35 jpn joined 14:40 jpn left 14:50 maylay left 14:53 maylay joined 15:18 Summer left 15:19 Summer joined 15:24 xinming left 15:26 xinming joined 15:31 jpn joined 15:32 MasterDuke left 15:36 jpn left 15:38 xinming left 15:40 xinming joined 16:42 vlad joined 17:09 jpn joined 17:14 jpn left 17:25 jpn joined 17:31 jpn left 17:40 jpn joined
antononcube Is there any Raku package that maintains a dictionary of the color names supported by web browsers? 17:49
Here is a list / page of such colors: htmlcolorcodes.com/color-names/
17:49 jpn left
lizmat raku.land/cpan:HOLLI/Color::Names perhaps ? antononcube 18:02
_grenzo I prefer the the XKCD color list 18:04
"ickygreen"
"uglypurple" 18:05
"babypoo" 18:06
"macaroniandcheese"
Which Color::Names supports BTW 18:07
antononcube @lizmat -- Yes, thank you! 18:20
18:35 vlad left 18:36 derpydoo joined 19:13 Sgeo joined
Xliff Now thou canst not unsee it! 19:15
m: my %colors; use Cro::HTTP::Client; use DOM::Tiny; my $r = await Cro::HTTP::Client.get("xkcd.com/color/rgb/"); my $dom = DOM::Tiny.parse( await $r.body ); for $dom.find("div.square")[] { my $k = .parent.text; my $h = .next.next.text.substr(1).chop; say "{ $k } / { $h }"; %colors{$k} = $h; }; use JSON::Fast; %colors.&to-json( :sorted-keys ).say
camelia ===SORRY!=== Error while compiling <tmp>
Could not find Cro::HTTP::Client in:
/home/camelia/.raku
/home/camelia/rakudo-m-inst-1/share/perl6/site
/home/camelia/rakudo-m-inst-1/share/perl6/vendor
/home/camelia/rakudo-m-in…
Xliff Ignore the errors. Embrace the code!
19:31 jpn joined 19:43 jpn left 20:00 MasterDuke joined 20:06 derpydoo left
tbrowder__ \o 20:37
still blind
japhb tbrowder__: What are you using for a client? 20:39
tbrowder__ irccloud 20:40
japhb Any particular reason for choosing that one? It's not one I hear very often around here. 20:41
tbrowder__ but i think my real problem is i don't really understand the IRC model. diff between networks and channels when the same channels are on multiple networks. 20:42
it works with my termius app on iOS as well as a linux computer running chrome 20:43
SmokeMachine I use it and that works very well to me… 20:47
(IRCCloud, I mean)
I like it because I’m always online anywhere on all my computers and cellphone… 20:48
20:58 haxxelotto joined
quib tbrowder__: which channels are on multiple networks 21:04
tbrowder__: are they just different channels with the same name 21:05
22:09 itaipu left 22:11 vlad joined
SmokeMachine aruniecrisps, Voldenet: could you see if this makes any sense? github.com/FCO/Red/issues/15#issue...1986993001 (I’m not saying we should use `Configuration` that was just a way to express what I was thinking) 22:12
antononcube weekly: rakuforprediction.wordpress.com/20...e-science/ 22:13
notable6 antononcube, Noted! (weekly)
22:16 jpn joined 22:20 jpn left 22:23 Summer left, lichtkind joined, Summer joined 22:24 itaipu joined, vlad left
Voldenet SmokeMachine: I don't think migrations should do backups (or keep the data) because it can be too large for any storage 22:31
on top of it, most databases are backed up quite frequently and automatically 22:32
SmokeMachine Voldenet: it wouldn’t be the migration, but the “play around” before the migration. And that is local (and opt out)
Voldenet on the other hand, most frameworks don't even have the option to do this 22:33
SmokeMachine Also, I’m thinking that it could/should be erased when preparing the migration itself…
Voldenet which is pain to develop
I'd say backups should be opt-in 22:34
SmokeMachine About the db being backed up, not the dev one. The idea is just to do that on dev db
It will be done on a script, we can use the default dump tool for each driver 22:35
Voldenet regarding separate module: it's probably more pain that it's worth imo 22:36
because migrations will touch internals of Red, and Red might need something from migrations (like subroutine to migrate on app start) 22:37
SmokeMachine Make sense… 22:39
Voldenet sql drivers for migrations could be separate 22:40
SmokeMachine Do you mean creating drivers for migrations only? 22:43
Voldenet yeah 22:44
Well, maybe Red::Driver::* could be a separate package 22:45
it'd be needed for supporting more db systems
22:46 vlad joined
Voldenet Especially when driver requires some bulky binary library 22:47
SmokeMachine It is possible (for example: github.com/FCO/Red-Driver-MySQL (not finished yet)
I’ve been thinking on removing the drivers, but I’m not sure yet 22:48
22:54 Summer left, Summer joined 22:59 vlad left
Voldenet SmokeMachine: regarding migrationconfig, it totally makes sense, I'm not sure whether keeping it in one class or having a few is better 23:02
SmokeMachine I think, if we are going to use `Configuration`, that class makes sense… 23:06
Voldenet I meant something like `role MigrationPaths { method models-path { … }; method versions-path { … } }; class MigrationConfig { has %.configs; method use-something { %.configs{MigrationPaths.^name}.versions-path.add("file.json") } };` 23:09
the class is fine, just maybe fine-grained approach to config would make it more flexible
Flexible enough approach would allow replacing backup paths with http storage target 23:13
and using both sqlite and plaintext for models storage
depending on the class used
though maybe i'm taking the customization too far 23:14
SmokeMachine That’s interesting! 23:17
23:24 Summer left 23:25 Summer joined
Xliff Is there a more idomatic way to do this: 23:57
my (@a, @b, @c); for <a b c d e f g h i>.rotor(3) { @a.push: .[0]; @b.push: .[1]; @c.push: .[2] }; @a.say; @b.say; @c.say
evalable6 [a d g]
[b e h]
[c f i]

Powered by Cro and the Raku® Programming Language.

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

Thank you!