SmokeMachine librasteve_: I did not find an example of auth, but it is similar to cookie and here is an example for cookie: github.com/FCO/Cromponent/blob/mai...akumod#L48 00:12
Voldenet huh but why dynamic variable 00:40
01:17 ds7832 left 01:26 librasteve_ left
SmokeMachine In that case it was needed to be able to access the user while rendering, if I remember it well… I’m almost sure I wrote a version with no dynamic variable, but I couldn’t find it… 01:46
github.com/FCO/Cromponent/blob/a2a...akumod#L45 01:51
Voldenet ah, makes sense 01:52
so RENDER/REDRAW quietly uses userId 01:53
SmokeMachine Yes 02:05
github.com/FCO/Cromponent/blob/a2a...akumod#L20 02:26
03:13 arkiuat left 03:19 arkiuat joined 03:24 vasko4535 left 03:25 vasko4535 joined 03:57 Aedil left 04:02 Aedil joined 04:20 stanrifkin_ joined 04:23 stanrifkin left 04:29 scanline joined 05:24 arkiuat left 05:38 arkiuat joined 05:48 arkiuat left 05:51 Sgeo left 06:01 arkiuat joined 06:05 arkiuat left 06:09 cm_ joined, cm left, cm_ is now known as cm 06:16 apac joined 06:18 arkiuat joined 06:19 oodani left, oodani joined 06:23 arkiuat left 06:24 cm left 06:31 cm joined 06:36 arkiuat joined 06:37 cm left 06:41 arkiuat left 06:44 El_Che left, cm joined, wayland76 joined 06:54 kylese joined, wayland76 left, wayland76 joined 06:56 El_Che joined 07:00 wayland76 left, wayland76 joined 07:02 apac left 07:03 wayland76 left, wayland76 joined 07:05 arkiuat joined 07:10 arkiuat left 07:13 scanline left 07:34 arkiuat joined 07:39 arkiuat left 07:44 librasteve_ joined
librasteve SmokeMachine: that’s very helpful … thanks! Tbh I’m a bit worried about the global variable also. I will probably find a way to make a Session class in Air and keep the global at the Cromponent level. 07:48
07:53 gfldex left 07:54 gfldex joined
@aruniecrisps this example is in line with my ideas for maintaining user / session state in order to do stuff like log in/out button, private pages, crud with permissions and so on … at this ”height” this looks like classic ur-web still with the server “stateless” when it comes to browser state. Continuing this line of thought, Air should let you override the Session class so that you can build out custom attributes 07:58
that are tied to cookies. All this is going to take a while to wrap into Air due to time constraints… but looks like you have a path to get something thing going for DataStar and SSE … this basically makes you the CTO when it comes to figuring out where you want state to live in Air::Jetstream. ;-)
SmokeMachine librasteve_: that’s not a global variable, that’s dynamic
librasteve oh yes… sorry 08:00
08:03 arkiuat joined
SmokeMachine And why are you worried with that? 08:03
08:10 arkiuat left 08:21 wayland joined, wayland76 left 08:41 arkiuat joined 08:46 arkiuat left 09:07 arkiuat joined 09:12 arkiuat left
librasteve generally I prefer lexical vars for the standard reasons (which my friend ChatGPT neatly summarizes here chatgpt.com/share/69047e71-2bd0-80...47e17788b) ... but I have not reviewed the way Cromponent uses and I am sure that you have a good reason for that 09:19
SmokeMachine That is a special case, and that’s not inside the Cromponent, that was the way I used the cromponent… and I suppose that’s possible to use cookie, with, etc without using dynamic vars. but we already use a bunch of dynamic variables, many on Cro, many other on Red, for 2 examples… 09:29
09:42 arkiuat joined 09:47 arkiuat left
jubilatious1_98524 weekly: unix.stackexchange.com/questions/2...915#800915 10:03
notable6 jubilatious1_98524, Noted! (weekly)
10:08 arkiuat joined, apac joined 10:13 arkiuat left
Voldenet dynamic variables are like gigantic hash you carry around call stack, they can be useful to pass data from outer to deep-nested methods without modifying anything in its path 10:20
but once you're not even sure which methods are invoked in what order (because you don't do it, framework does) you can't pass that data reliably
lizmat I think that's the wrong imagery 10:21
dynamic variables are lexical variables that can be looked up in the stack, and if not found in the stack, will be checked in the GLOBAL:: and PROCESS:: stashes 10:22
Voldenet yes but in general case I wouldn't expect them to contain thing like dynamic variable from the http request
10:23 apac left
Voldenet I mean the `method REDRAW(:$*user! is cookie)` 10:23
and once you do that with components, it can get messy fast
librasteve SmokeMachine: I just want to be clear that I am 100% certain that if you choose to use a dynvar here and there, then there is a very good reason and I trust that that is the best choice. Sorry that I give any impression that this is a criticism of your module. I have not even had a change to properly employ the latest Cromponent goodies in v14 so I am speaking from a place of deep ignorance! 10:25
Voldenet: in general you may have a point, but I think that Cromponent is a special case 10:28
Voldenet criticism is a strong word, I speak from experience 10:29
I used stack-based sessions and it was horror
now I explicitly pass the context everywhere to everything, in most cases I don't have to even start the debugger to guess the state of the context 10:31
and since I use scope-based DI which automatically resolves anything, usually I ask for type I need - if I decide to keep something it in session/db/cookie it's only edited in the method that describes that type 10:33
maybe middlewares
SmokeMachine I just want to point out that $*user is not part of Cromponent, that’s just part of 1 example of usage for that. 10:34
Voldenet of course, it's just some value from the cookie after all 10:35
SmokeMachine and, of cource, I could, probably, have changes $*user with $!user, I suppose... 10:37
Voldenet in fact, react has similar mechanism, in theory it's usable so that components can communicate without passing props 10:40
but in practice it only makes components hard to reuse later… 10:41
10:42 arkiuat joined
Voldenet …and you end up not seeing any compile errors and not having the context where it should be 10:42
I am team verbose code 10:43
10:47 arkiuat left 11:00 arkiuat joined
SmokeMachine I see the dynamic variable there as I see the $c->stash on mojolicious... 11:00
11:05 arkiuat left 11:09 melezhik joined 11:10 arkiuat joined 11:14 arkiuat left
tbrowder howdy, i'm revisting my problem with Test's lives-ok {}. it looks like using "say" to the default stdout in the code causes the failure during a test with App::Mi6's "mi6/test" but not when the test is run by itself. i'm guessing i can redirect 'say' output to $*OUT to fix that but how do i do that? 11:23
ah, something like this: my $fh = open "/tmp/t", :w; $*OUT = $fh; 11:29
11:38 arkiuat joined
tbrowder well, that didn't work :-( 11:43
11:43 arkiuat left
lizmat why wouldn't that work? 11:44
tbrowder i also tried $*ERR. but nada. i don't know! mysterious lives-ok again 11:45
i am "bamboozled" 11:47
lizmat ok, maybe raku.land/zef:lizmat/Trap is what you're looking for ? 11:49
tbrowder in the meantime, i can fall back on a special arg to stop the say routine with test but stil...what a pain. i'll file an issue with App::Mi6 but i still feel like the issue is with Test. 11:50
but App::Mi6 does a lot of magic! 11:51
ah, i keep forgetting about Test::Output... 11:57
so if i use Test::Output (thnks, Zoffix, JJ, and Lizmat!) what's the shortest way to "swallow" stdout from sub foo()? inside lives-ok()? 12:04
i don't need to see it during this test 12:05
lives-ok { stdout-from(foo) }; 12:10
12:10 arkiuat joined
tbrowder ^^^? 12:10
12:11 donaldh_ joined 12:14 donaldh left 12:15 arkiuat left
tbrowder yea!! that works but change () to {} 12:16
another good reason to clearly separate failure tests to use stderr 12:21
12:34 apac joined
lizmat If this is really just about not seeing STDOUT, you could do: 12:43
m: $*OUT = open "/dev/null", :w; say "foo"
camelia ( no output )
12:43 arkiuat joined 12:48 arkiuat left 13:04 ds7832 joined 13:11 arkiuat joined 13:17 arkiuat left
tbrowder hm, i'll check that out... 13:27
that didn't work for me. stdout was ignored for the CLI run, but not with "mi6 test" 13:36
13:39 Sgeo joined 13:45 arkiuat joined 13:51 arkiuat left 13:56 jgaz joined 14:05 arkiuat joined 14:16 arkiuat left 14:36 apac left 14:37 MoC joined, melezhik_ joined, melezhik_ is now known as melezhik3 14:45 arkiuat joined 14:51 arkiuat left 14:59 arkiuat joined 15:08 arkiuat left 15:10 arkiuat joined 15:12 melezhik3 left 15:17 arkiuat left, arkiuat joined, human-blip left 15:20 human-blip joined
aruniecrisps @librasteve im wondering if there isn't a way to basically get the functionality of liveview in phoenix; but again elixir and the beam don't do state to begin with, they just clone data and pass it around like it'snothing 15:22
15:22 arkiuat left 15:34 arkiuat joined 15:43 arkiuat left 15:48 arkiuat joined 15:52 ds7832 left 15:53 arkiuat left 15:54 arkiuat joined 16:00 arkiuat left 16:02 abraxxa-home joined 16:05 arkiuat joined 16:10 arkiuat left 16:11 arkiuat joined 16:18 arkiuat left 16:19 abraxxa-home left 16:22 melezhik_ joined 16:23 abraxxa-home joined 16:25 arkiuat joined 16:39 jgaz left 16:41 jgaz joined 16:42 simcop2387 left 16:48 melezhik_ left 17:15 simcop2387 joined 17:57 melezhik_ joined 18:04 abraxxa-home left 18:22 apac joined 18:24 melezhik_ left 18:52 Sgeo_ joined 18:55 Sgeo left 19:02 melezhik_ joined 19:04 melezhik_ left 19:12 melezhik_ joined 19:14 melezhik_ left 19:16 oodani left 19:17 oodani joined 19:19 melezhik_ joined 19:21 melezhik_ left, apac left 19:30 arkiuat left 19:32 arkiuat joined 19:38 arkiuat left 19:48 melezhik_ joined 19:55 donaldh_ left 19:57 melezhik_ left, melezhik_ joined 20:03 arkiuat joined 20:08 arkiuat left 20:13 melezhik_ left 20:20 arkiuat joined 20:25 melezhik_ joined 20:57 apac joined 20:58 jgaz left 21:20 librasteve_ left 21:38 melezhik_ left 22:00 apac left 22:05 melezhik_ joined 22:07 melezhik_ left 22:09 melezhik_ joined 22:14 melezhik_ left 22:26 melezhik_ joined 22:30 MoC left 22:31 melezhik_ left 22:42 melezhik_ joined 22:44 melezhik_ left 22:59 melezhik left 23:00 melezhik_ joined 23:10 melezhik joined 23:11 melezhik_ left 23:14 melezhik_ joined 23:18 melezhik_ left, melezhik_ joined 23:21 melezhik_ left 23:54 apac joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!