🦋 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
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
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
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
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
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
SmokeMachine RedSchema will also be useful for other reasons… 02:30
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
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.
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/
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
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!
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
quib tbrowder__: which channels are on multiple networks 21:04
tbrowder__: are they just different channels with the same name 21:05
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)
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
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
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
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]