🦋 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. |
|||
00:07
lizmat joined
|
|||
tbrowder__ | hello | 00:47 | |
hi | 00:48 | ||
ho | 00:49 | ||
00:49
tbrowder__ left
00:50
tbrowder__ joined,
Manifest0 left
|
|||
tbrowder__ | hekko | 00:51 | |
SmokeMachine | aruniecrisps: Red is always a priority… how can I help? | 00:59 | |
01:13
xinming left,
xinming joined
01:38
Summer left
01:39
Summer joined
01:57
xinming left,
xinming joined
02:09
Summer left,
Summer joined
|
|||
librasteve | japhb: sorry for slow reply - yes i agree that we have each solved a similar need and I will work to merge them as / when i do incremental changes … the timing column in my README refers to the build time when rebuilding from scratch (which my Dockerfile chains automatically do weekly). | 02:25 | |
antononcube: happy that you are using PDF::Extract - it’s deliberately minimal and was written since all I wanted was a fast text dump (and I had never heard of popper either) | 02:28 | ||
02:28
kylese left
02:29
kylese joined
|
|||
Rog: also github.com/Raku/old-design-docs which I hope is the “maintained archive” | 02:35 | ||
^^ in which case i guess we need to grab the apocalypse and exegesis and put them here too … or perhaps someone knows better than i what the curation plan is!!!? [i do not like relying on web archive except as a last resort) | 02:39 | ||
02:39
Summer left
02:40
Summer joined
03:10
Summer left
03:11
Summer joined
|
|||
japhb | librasteve: No worries, thanks for getting back to me! | 03:11 | |
03:15
kylese left,
kylese joined
04:30
xinming left
04:32
xinming joined
04:42
hudo_ joined,
hudo__ left,
hudo_ left,
hudo_ joined
04:53
jpn joined
04:56
xinming left
04:58
jpn left,
xinming joined
05:07
Summer left
05:08
Summer joined
05:38
Summer left,
Summer joined
05:53
maylay left
06:00
maylay joined
06:54
Summer left
06:55
Summer joined
07:06
gabiruh left
07:08
abraxxa joined
07:21
ericst joined
|
|||
ericst | Hello | 07:22 | |
Starting out, and I stumbled on something that I don't understand: pastebin.com/SCNvZNnX | 07:23 | ||
In that exemple, how come the chargers has only one element ? | |||
Thanks in advance | 07:24 | ||
07:25
Summer left,
Summer joined
07:26
gabiruh joined
|
|||
nahita3882 | hi, Hashes store their values in scalar contaners (so they are mutable), therefore the value you reach has an implicit $ sigil in front if you will. Then the assignment to array will treat it as a 1 thing because scalar, hence elems being 1. There are some ways to strip out the container (decontainerize), for example my @a = %h<key>.self or %h<key>[] or %h<key><> or %h<key>{}. Then the array assignment will see | 07:37 | |
through and do what you expected | |||
my @a = $x then @a.elems is always 1. my @a = @b then @a.elems is equal to @b.elems | 07:38 | ||
with decontainerization, the array assignment sees that the Right hand side is a Positional, so it copies elements one by one | 07:39 | ||
otherwise, if it sees a scalar, it doesn't copy N elements at all -- you can see it doesn't copy by doing, e.g., @chargers[0][1] = -99 and see that %body<Data> is affected too | 07:40 | ||
maybe this page helps docs.raku.org/language/containers | 07:41 | ||
ericst | Thanks for the explaination | 07:42 | |
I will look into it | |||
07:50
Sgeo_ left
08:01
Summer left,
Summer joined
08:32
Summer left,
Summer joined
08:37
jpn joined
08:44
jpn left
08:53
Manifest0 joined
09:06
haxxelotto joined
09:12
dakkar joined
09:19
bdju left
10:01
bdju joined
10:17
sena_kun joined
10:19
bdju left
10:20
ericst left
10:26
bdju joined
10:35
bdju left,
bdju joined
10:47
bdju left
10:49
Summer left,
Summer joined
10:52
bdju joined
11:02
itaipu left
11:04
bdju left
11:10
bdju joined
11:19
bdju left
11:21
bdju joined
11:34
bdju left
|
|||
tbrowder__ | hi | 12:40 | |
howdy | 12:41 | ||
12:58
gabiruh left
13:00
gabiruh joined
13:04
gabiruh left
13:08
gabiruh joined
|
|||
antononcube | @Nahita Good description. | 13:09 | |
aruniecrisps | @SmokeMachine So I've been managing with manual migrations for the time being but I feel like there's a disconnect between the ORM schema side of things and the migration side of things. I was wondering if you wanted to pair up on that | 14:43 | |
14:44
samebchase left
15:50
bdju joined
15:51
jpn joined
16:09
jpn_ joined
|
|||
SmokeMachine | aruniecrisps: sure, how would you like to do that? | 16:10 | |
16:11
jpn left
|
|||
tbrowder__ | \o | 16:52 | |
16:55
tbrowder__ left
16:58
tbrowder__ joined
|
|||
tbrowder__ | \o | 16:58 | |
17:00
jpn joined
|
|||
tbrowder__ | hi | 17:00 | |
17:01
jpn_ left
17:05
jpn left
17:36
dakkar left
17:43
abraxxa left
17:50
haxxelotto left
17:51
haxxelotto joined
18:02
samebchase joined
18:10
ericst joined
18:28
ericst left
|
|||
_grenzo | Shh...they're sleeping | 18:30 | |
lizmat drops a pin | 18:47 | ||
18:47
lizmat left,
lizmat joined
|
|||
aruniecrisps | @SmokeMachine I've already forked Red, I'll make a separate branch to work on migrations, and I'll use the github issue discussion as a starting point, but if you could give me an quick and rough idea of how you envision migrations now I think that would be a great starting point | 18:55 | |
18:57
jpn joined
19:03
jpn left
19:04
vlad joined
19:22
jpn joined
19:25
vlad left
19:26
itaipu joined
19:40
jpn left
|
|||
SmokeMachine | aruniecrisps: there is some code written for it behind a “experimental” tag (have you seen that (github.com/FCO/Red/blob/3e318994d1...umod#L90)? | 19:46 | |
Maybe we should continue this conversation on #red | 19:50 | ||
aruniecrisps | I don't have irc, i'm trying to get that set up @SmokeMachine | 19:52 | |
SmokeMachine | I’m adding a new comment on that issue adding what I’m planning for migration… | 19:53 | |
Have you ever seen the bin/red? I was planing using that to control migrations… | 19:54 | ||
(Currently that’s mostly broken…) | |||
aruniecrisps | I looked at it once and forgot about it | 19:55 | |
tbrowder__ | \o | 20:03 | |
20:24
simcop2387 left,
perlbot left
20:48
jmcgnh left
20:59
simcop2387 joined
21:00
perlbot joined
21:04
jmcgnh joined
|
|||
aruniecrisps | hi @tbrowder__! | 21:10 | |
21:17
jpn joined
21:22
jpn left
|
|||
SmokeMachine | aruniecrisps: I just added this comment there: github.com/FCO/Red/issues/15#issue...1984646787 | 22:29 | |
does anyone have an opinion about this? github.com/FCO/Red/issues/15#issue...1984646787 | 22:31 | ||
22:32
bdju left
22:33
bdju joined
22:49
Sgeo joined
|
|||
tbrowder__ | erg, thnx, but i still can't see my own msgs after i send them | 22:50 | |
Voldenet | uh, isn't irc client supposed to save the lines you send (since server doesn't send them back to you) | 22:52 | |
23:02
sdomi left
23:03
sdomi joined
|
|||
Voldenet | SmokeMachine: I think there should be `red migrate prepare` that would generate "migration commands" (something like `.add-column(:table<x> :type<nvarchar(20)> :name<col>` or `.add-index…`) that would be not specific to any db | 23:21 | |
and executing migrations would generate sql commands on the fly | 23:22 | ||
it's important because user might then migrate the data when `.drop-column(…) .add-column(…)` commands are generated by using `.add-column(…); .raw("update target from tbl1 src join tbl2 target on target.id = src.id"); .drop-column(…)` | 23:24 | ||
or user may even choose to not drop the column or fool RED into using views as tables | 23:25 | ||
Ofc, `red generate-migration-script v1 v2` could still generate sql for production dbs | 23:26 | ||
the flow I described would probably require keeping the old state of the database before applying changes somehow | 23:27 | ||
SmokeMachine | Voldenet: that also makes sense... would you mind to add it on that thread? | ||
I think having the option to edit the SQL important... but what you said also makes sense... | 23:28 | ||
you could do something like that on my description using the form `red migrate update -e 'MyModel.^migration: { .new-column = .old-col1 . " " . .old-col2 }'`, but using DB change commands instead of data manipulation ones... | 23:30 | ||
no? | |||
Voldenet | migrations very often require manipulations that are hard to describe with migration languages | 23:33 | |
SmokeMachine | in that case you can use the `red migrate update --sql 'ALTER TABLE my_model ...'` option | 23:36 | |
Voldenet | also, there's one additional thing, when you use git with multiple people doing migrations, you may not know which changes should be appied | 23:37 | |
so, the db needs to track what migrations were applied | |||
I'll describe my thoughts on github | 23:39 | ||
SmokeMachine | the table storing the migration version will do that | ||
please | |||
now thinking about multiple people writing code, maybe the number on the migration path should be an UUID instead of a int... and use a different way to decide the order... | 23:42 | ||
23:50
haxxelotto left
23:52
sena_kun left
|