🦋 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:16 sena_kun left 00:37 yewscion joined 00:43 yewscion left 01:13 yewscion joined 01:18 yewscion left 02:35 yewscion joined 02:39 yewscion left 02:49 wayland76 joined, wayland left 02:51 hulk joined 02:52 kylese left 02:53 yewscion joined 02:58 yewscion left 03:15 hulk left, kylese joined 04:59 Aedil joined 05:00 Aedil left 05:06 Aedil joined 08:05 derpydoo joined 08:09 Sgeo left 08:10 Sgeo joined 09:17 derpydoo left 11:10 jpn joined 11:15 human_blip left 11:16 human_blip joined 11:29 JimmyZhuo joined 12:06 jjido joined 12:10 jjido left 12:12 bartolin left 12:13 Sgeo left, bartolin joined 12:25 jpn left 12:36 tjr joined 12:38 jjido joined 12:44 jpn joined 12:49 jpn left 13:12 jpn joined 13:19 sena_kun joined 13:27 jpn left 14:05 JimmyZhuo left 14:14 jpn joined 14:34 jjido left 14:41 jpn left 15:35 jpn joined 15:41 PipStuart joined 16:07 derpydoo joined 16:40 euandreh left 16:52 jpn left
librasteve SmokeMachine: I have seen your very nice Cromponent and P6-React (aka rakux) --- are there any more? 17:18
17:22 librasteve_ joined 17:30 derpydoo left
SmokeMachine librasteve: yes, a few... let me find a list of them: github.com/FCO/Cromponent github.com/FCO/HTML-Component github.com/FCO/MemoizedDOM github.com/FCO/p6-react github.com/FCO/proact/blob/master/t/01-slang.t github.com/FCO/Cro-WebSocket-WebComponents-test (I feel like there are a few missing...) 17:32
I like MemoizedDOM a lot... 17:33
librasteve .oO
SmokeMachine fco.github.io/MemoizedDOM/todo6.html
I have to find some time to rebuild the MemoizedDOM example... 17:34
librasteve yeah - just says loading... for me 17:36
SmokeMachine it takes some time but loads... (at least here to me...)
on my firefox it works...
librasteve maybe too impatient - lemme try ff 17:37
ok ff works (takes about 20secs 17:38
)
SmokeMachine (it compiles the code on the browser... a code from 7 years ago...)
librasteve safari (barf) is doa
SmokeMachine if you open the page code, you will see raku code there... :) 17:39
librasteve holy crap - it runs in the browser
SmokeMachine (perl6 code... it was built before the renaming, I think...) 17:40
librasteve also before WASM I guess
SmokeMachine it uses this: webperl.zero-g.net/ 17:42
webperl.zero-g.net/perl6.html
that if I remember it correctly uses this: perl6.github.io/6pad/ 17:43
if you test it, you will see that even taking very long to compile/load, after that's done it does run on a decent speed... 17:46
librasteve yeah i tried it - not sure I have a use case for it ;-) 17:47
SmokeMachine and it used to work on all the browsers... I don't know what changed to make it not work in some browsers...
librasteve bitrot
SmokeMachine librasteve_: have you seen the other tries? 18:00
wayland76 Are you telling me I can run Raku on the client side as well? 18:06
SmokeMachine you kinda can... :)
wayland76: github.com/rakudo/rakudo/tree/e2ec...464/src/vm 18:08
wayland76 Crazy! Well, I know what I'm going to want to use for my next UI projects :) 18:09
SmokeMachine if I remember it well, on MemoizedDOM, you could do it the way the example shows, or you could also precompile it to js and not expand time compiling it on browser if I'm not mistaken... 18:10
librasteve voldenet: I have been thinking about your suggestion to make a component tree - you mention that this will help static optimisation ... that got me thinking a bit about my Air module in the context of performance ... so I did a quick test with Chrome Performance. Basically for he trivial <bal ble bli> code on localhost its 0.16/0.12s to LCP of which 47/17 millisec is the localhost packet read (ie all the raku 18:11
processing) - the first number is the first hit on the url after server start, the second number is subsequent hits on the same url - this is comparable to another remote site that uses Cro Template. Since Air is primarily aimed at HTMX, I think that small, dynamically populated payloads will be typical and that wrapping a bit of text via the .HTML calls is likely low overhead compared to real work such as DB dip. Anyway, I was
pleasantly surprise that both the server build times <2sec and web response times (as above) are not too bad - I put this down to that almost all of the code is precomped (eg Air/Base.rakumod) and that the actual raku code to make a response is preloaded by the Cro server into memory.
SmokeMachine librasteve_: does MemoizedDOM HTML looks like your module? example: github.com/FCO/MemoizedDOM/blob/ma...o/Todo.pm6 18:15
another example: github.com/FCO/MemoizedDOM/blob/ma...do/App.pm6
I think the biggest difference it that it uses blocks, right? 18:16
tbrowder hi, does raku treat a string with a trailing subscript of integers as anything special? 18:30
lizmat no 18:31
but perhaps the question is not clear enough
SmokeMachine this one (github.com/FCO/HTML-Component) also looks like that but uses methods... This one a=I was trying to make to not allow invalid HTML by only adding the tight methods in each "TAG"... so, if you are on <body>, for example, you would not be able to call .li, but you would if inside a <ol>
tbrowder that confirms my suspicion, but i think i can treat it specially if desired with user code 18:32
my query/interest is interpreting such a string as a base indicator for the leading part 18:34
as a non-digital number 18:35
librasteve I would say the coding style for the Todo App in MemoizedDOM is pretty much the same that I wrote in Air::Functional - that is with (i) functions (ie subs) for each HTML tag name, and (ii) the raku pair syntax for tag attrs - seems like you were on the right track back then ;-)
tbrowder or even leading decimal digits (with zero or one radix points) 18:36
restrict the trailing subscripts to chars of range 0x2080 - 0x2089 18:39
librasteve For the last 3 months I have been pulling together 3 ideas into the new Air module - Air::Functional for the tag coding style, Air::Base is a lib of tags and other things (eg class Nav, class Page, class Site) and Air::Component is basically Cromponent without Cro Templates
it seems that many of these ideas you had already (and I may have reinvented indendently), or I used your code as a starting point - so fully appreciate and acknowledge your work 18:41
anyway, Air leaked out last week before I have properly documented it - so I will do that next and a bit of a tidy up - also needs some more examples in Air::Play (that's kinda the playground for trying out different site examples) 18:44
SmokeMachine librasteve_: Sorry, my intention is just to point out how interesting it is that 2 different code, written by 2 different people in 2 different times converge to some of the same ideas... my poor english might not have been enough to express that, sorry... 18:45
lizmat
.oO( it's hard to make things air-tight :-)
librasteve I am sure your English is better than my Portuguese
SmokeMachine EntĂŁo quer dizer que eu deveria estar falando em portugues aqui? :P 18:46
Sorry, just kidding... 18:47
But what I'm trying to say is that, it seems Air might be a good solution... :)
librasteve yes - there is something remarkable that our ideas are the same - tbh with Air::Component I had the thought that I needed some way to componentize, but I was really struggling with how until I learned from Cromponent the main idea that methods could be routes 18:48
my thinking for the Air::Functional side came originally from a liking for elmlang and the thought that raku is in fact a capable (but uncontrolling) functional language 18:50
you are, of course, welcome to collaborate on Air - I am glad that you like it - but really it could use quite a lot of improvements (!) 18:52
maybe if we ave the same ideas, they are good ones! 18:53
SmokeMachine :)
thanks! I'll try to find some time to help on that... but now I'm very busy with Sourcing... and after that (talking about functional) I plan to go back to my functional data structures: github.com/FCO?tab=repositories&am...&sort= 18:54
and I also think I may find a way to merge EEL (github.com/FCO/EventExpressionLanguage) into Sourcing... 18:56
and also, at some point I'll need to migrate Red's map/grep/first blocks into RakuAST... 18:57
18:57 shrewd left, shrewd joined, shrewd left, shrewd joined
SmokeMachine if anyoen would like to help on any of these... :) 18:57
tbrowder lizmat: would a core mod to recognize trailing substrings as base indicators be feasible/considered? 19:03
19:04 notna joined
lizmat tbrowder: you mean something like raku.land/zef:lizmat/Slang::Subscripts ? 19:05
tbrowder yes! i forgot about that! i haven’t looked at the code yet, but i’ll bet a beer it could be in core 19:08
lizmat for sure... but that's why it's a slang right now 19:16
tbrowder after looking at it, i think my approach is less “corey@ but i would have to play with yr mod some—and will. i now mostly (nay, always) use ascii chars for input with the \x modifiers for non-ascii 19:17
melezhik. o/ … I am going to write a post maybe on how Sparrow can replace sed/grep/awk - here is on of the things one can do with sparrow task checks - gist.github.com/melezhik/e7a3eee9d...58790131cb 19:18
19:41 Sgeo joined
wayland76 melezhik: That sounds good! Can you use the "tell" bot to send me the link when the time comes (if you happen to remember)? 19:48
19:50 MyNetAz left
librasteve wayland76: just point your rss feed reader to planet.raku.org/ 19:53
SmokeMachine: I see that you are on a yak shave also ... don't forget to add Red Db migration ;-) 19:55
SmokeMachine librasteve_: yes... there is also that...I have already spent so much time on that... I'm kinda taking a rest of that for now... :( 19:59
wayland76 Haha, I just categorised my projects according to step 1 at leaderforgood.com/never-finish-any...-syndrome/ but found I had to add another category (in addition to Dragons, Errands, and Mentors), and it was for Yak Shaving :) . A lot of my projects seem to come back to Table/Tree oriented programming as the Yak Shave I need. 20:00
I also added a category for Mathoms -- projects I may get to someday, but may not. 20:01
librasteve i guess that's a pita - reason I mention is that when Cro + Red + Air goes viral, that will be important (wrt eg Django)
20:05 MyNetAz joined
wayland76: you have found your spiritual home 20:06
wayland76 I knew that when I was buying keyboards, and about 10 people here came out of the woodwork to discuss them :) 20:07
jdv i have a dygma defy 20:15
used to use a kinesis freestyle pro
wayland76 Thanks for proving my point :p 20:16
SmokeMachine about keyboards, I'm using this one: www.zsa.io/voyager with this map: configure.zsa.io/voyager/layouts/blKx7/latest/0 20:17
jdv nice
[Coke] i was super happy to get a keyboardio and I never use it. :| 20:20
jdv used the kinesis for a decade or so then got frustrated with firmware limitations. noticed the defy. no regrets. changed abput a year ago.
[Coke] I should bring it to the con and offer it as a giveaway
wayland76 If we're doing this again, I have a ZSA Moonlander, but have discovered a) that I've never developed hand strain because I hold my hands in non-standard positions when using regular keyboards, and b) a lot of keyboards are designed for keyboard minimalists, and I'm a keyboard maximalist (ie. I want separate buttons for a) the infrequent but important keys, like "Play" and "Restore most recent closed tab", and for all the Raku symbols) 20:21
librasteve maybe a golf trophy
jdv i have 3 regular maps i toggle around. and one special right hand only for palworld cause i mouse only left... 20:25
its fun. not for everyone for sure. 20:26
20:31 Aedil left 20:34 notna left
Voldenet librasteve: real benchmarks are useful only in case everything else is optimized, but the question is whether it's optimizable or not - in case of naive string concat tree, you're pretty much doing a lot more work compared to serving one static string 20:43
string allocation is cheap, but it's not free 20:44
and it's the sort of optimization that can be improved further 20:46
e.g. instead of transfering full strings, keep static references as polymer components, then instead of transferring 10kb of html, it's possible to serve something like `<static id=42><div>dynamic part</div><static id=43>` 20:47
or without polymer, htmx code can be slightly modified to support static fragments of html
librasteve ... looks up polymer... 20:49
Voldenet it would only work where instead of directly rendering `<div><div>blah</div></div>`, what would get rendered is `html("div", html("div", text({ "blah" }))` 20:50
more or less polymer lets you define html elements, so `static` becomes an actual element
that you can use 20:51
in fact, component tree would probably be something fairly simple at first: `class HtmlTag { has $.name; has %.attr; has @.inner; method HTML { … } }` 20:52
librasteve okaay - my initial thoughts are (i) maybe someone wrote a lib for polymer and (ii) htmx and polymer compete for the same space, since I am "all in" on htmx not sure need two of these and (iii) look yes, I am cool with a lazy approach to rendering if preserves the API
20:53 notna joined
Voldenet defining components is not competing with htmx imo 20:53
since you can use both at the same time to reduce amount of js
htmx for reloading parts of the document, polymer for magic components missing in bare html 20:54
20:54 notna left
librasteve aha - lightbulb 20:54
tx
btw already have Air::Component with .id ... 20:56
Voldenet if I understand Air::Base properly, the only thing that'd have to be changed
is that HTML should instead emit HtmlTag 20:57
that would have HTML method
librasteve github.com/librasteve/Air/blob/9a5...akumod#L32
Voldenet the only thing I can't figure out yet is how raw text and dynamic should look in the template 20:58
so instead of `button( :class<hamburger>, :id<hamburger>, Safe.new: '&#9776;' );` there would be 21:00
`button( :class<hamburger>, :id<hamburger>, raw('&#9776;') );`
and instead of `ul( :$!hx-target, :class<nav-links>, self.nav-items, do for @.widgets { li .HTML } );`
librasteve yeah, but you are looking at the mezzanine level 21:01
Voldenet and this is the part I can't figure out, it'd be nice to simply include the code, but it'd remove any further tree-level optimizations 21:02
react for example does map of elements with key, which is extremely slow and inelegant 21:03
librasteve github.com/librasteve/Air-Play/blo...akumod#L41 21:04
sorry I will write some docs tomorrow
Voldenet Hmm, idk about `safe`, it could mean "this component adds safety layer to the text" or "consider this html safe" 21:05
raw would be more directly saying "this is a raw html"
librasteve ^^ this wrt safe as a function (that does Safe.new...)
yeah - i prefer raw ... guess too much rust 21:06
Voldenet I know what it does though, maybe i'm nitpicking
hmm `ul( :$!hx-target, :class<nav-links>, self.nav-items, do for @.widgets { li .HTML } );` 21:08
could be `ul( :$!hx-target, :class<nav-links>, self.nav-items, map(@.widgets, li));` maybe 21:09
with custom multi sub map for components array
librasteve anyway - I like the direction you have outlined - and i would like to rewrite to do that - but it would still be super helpful to see a short raku prototype of component tree you have in mind
Voldenet I know, but I've realized that there's tons of edge cases I haven't thought of 21:10
and half-baked optimization that can't be applied in most common cases feels kind of sad
librasteve yes multi sub makes sense .... so propagate callables up and then render all as one
21:12 kylese left
Voldenet what is also possible is to do something angular-like - emit a subroutine to call to mark piece of template as dynamic in relation to a variable 21:12
or rather, create that 'dynamic placeholder' for the template and pass it to the inner components, which would then be called as method 21:13
21:13 jpn joined
Voldenet but it sounds sufficiently complex 21:13
librasteve sometimes code > english ;-) 21:14
Voldenet and well, angular is fairly surprising compared to react before you get used to how weird it is to use 21:15
or solidjs, which uses similar concept
21:17 kylese joined
librasteve glad you know the ropes ... I have managed to avoid react/vue/angular ... but for Air to be interesting (as the anti-react) it needs to be good and pure 21:18
21:18 kylese left
sorry must sleep 21:20
21:23 kylese joined 21:29 jpn left
tbrowder lizmat: Slang::Subscript is different from my use. my use add the subscripts to the number object itself (as part of th 21:32
*the string
SmokeMachine So, are you planing to “leak” air to client side, or have I misunderstood the conversation?
tbrowder but i'm still working on its implementation 21:33
SmokeMachine librasteve_, Voldenet: ^^ 21:35
Voldenet SmokeMachine: Not directly a plan, just a possibility to optimize things further 21:37
with components having id with static trees, there's no even need to re-render whole static trees of components 21:39
SmokeMachine If doing that, I would try to do that with Raku itself on the browser… :)
Voldenet Hell, sufficiently described template ((…props) -> tree) could directly compile 21:40
SmokeMachine If I remember it correctly, on MemoizedDOM I had done the separation of dynamic and static parts by memoizing the static one… 21:41
Voldenet to any sort of component tree, including js
i'm not sure about running raku directly in the browser 21:46
SmokeMachine Why not? 21:47
Voldenet at least for html component tree rendering
because lag from conversing between raku and js might be substantial 21:48
SmokeMachine I think, on memoizedDOM example, the only really slow part is the compiling part… but if compiling it to js before deploying, I think it would be ok, no? 21:50
Voldenet yeah, that's what I thought of 21:51
SmokeMachine So, that could be written in Raku, right? 21:53
Voldenet yeah, if it was precompiled js directly served, it wouldn't be any problem
SmokeMachine Yes, That’s what I meant… :) 21:54
Voldenet of course, it'd still need some kind of templating system, because MemoizedDOM is using vanilla-js
or rather vanilla raku
but with proper templating, I can see that document.createElement could be used directly instead of rendering things to html 21:55
SmokeMachine Why do you need a template system?
Voldenet for complex applications, naturally
21:56 jpn joined
SmokeMachine If I remember it well, memoizeddom caches the elements and only changes the dynamic parts… 21:57
Voldenet `map(@.users, div { text(.name) })` is sufficiently easier to write than `for @.users do { $!document.createElement("div"); …`
SmokeMachine Like this? github.com/FCO/MemoizedDOM/blob/ma...pp.pm6#L21 21:59
Voldenet sort of, but `do for @!todos` implies that reference identity is being used 22:00
22:01 jpn left
SmokeMachine It could be a map too… 22:01
Voldenet with MemoizedDOM the biggest problem is that with only ~100 items it'd start getting slow 22:03
so, for mapping it'd require additional special data structures
and it'd push the whole framework into vue direction
where you have observed arrays for handling .push 22:04
in htmx case, you probably wouldn't have such problem, because every item could have its route 22:05
SmokeMachine Just to make it clear, I’m not suggesting using memoizeddom, but something similar… it’s 7 years old… but I think it has some interesting things in that that could be used… 22:06
Voldenet yeah, it's the I'd prefer over htmx 22:08
s/the/the approach/
but htmx has good sides - you can have whole state in server's memory and security is not that big of a concern 22:09
it's faster to create something working in htmx, but maybe more pain to test and debug 22:10
either way, clear syntax for rendering tree and defining static/dynamic parts on the raku level is something that could be usable in tech-agnostic way 22:15
`class Element` wouldn't care if `sub JS-ELEMENT { $*document.createElement(…) }` or `sub HTML { … }` gets called
22:16 euandreh joined
Voldenet I suppose having one templating system for both cases would be pretty cool, but idk if it's realistic 22:17
SmokeMachine I really like htmx… 22:18
22:28 jpn joined 22:33 jpn left 22:50 wayland joined, wayland76 left 22:59 jpn joined 23:01 human_blip left 23:03 human_blip joined 23:10 jpn left 23:11 jpn joined 23:19 stanrifkin joined 23:22 librasteve_ left

Powered by Cro and the Raku® Programming Language.

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

Thank you!