🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm Set by lizmat on 22 May 2021. |
|||
00:02
reportable6 left
00:04
reportable6 joined
01:15
linkable6 left,
evalable6 left
01:16
linkable6 joined
01:18
evalable6 joined
02:11
casaca left,
casaca joined
02:12
MasterDuke left
02:19
SmokeMachine left,
SmokeMachine joined
02:31
leont left,
zostay_ joined,
zostay left,
zostay_ is now known as zostay
02:32
leont joined
03:36
benchable6 left,
quotable6 left,
releasable6 left,
statisfiable6 left,
nativecallable6 left,
coverable6 left,
unicodable6 left,
tellable6 left,
bisectable6 left,
reportable6 left,
committable6 left,
squashable6 left,
shareable6 left,
sourceable6 left,
linkable6 left,
bloatable6 left,
greppable6 left,
notable6 left,
evalable6 left
03:37
coverable6 joined,
sourceable6 joined,
statisfiable6 joined,
nativecallable6 joined
03:38
reportable6 joined
03:39
tellable6 joined
04:38
unicodable6 joined
04:39
shareable6 joined,
bloatable6 joined,
greppable6 joined,
evalable6 joined
05:38
linkable6 joined,
notable6 joined
05:39
committable6 joined
06:02
reportable6 left
06:03
reportable6 joined
06:38
bisectable6 joined
06:40
benchable6 joined
07:39
quotable6 joined
07:40
releasable6 joined
07:46
MasterDuke joined
08:26
squashable6 joined
10:46
evalable6 left,
linkable6 left
10:47
linkable6 joined
10:48
evalable6 joined
10:54
notna joined
10:55
notna left
10:56
notna joined
10:57
notna left
10:58
notna joined
|
|||
sena_kun | releasable6, status | 11:45 | |
releasable6 | sena_kun, Next release will happen when it's ready. 1 blocker. 282 out of 282 commits logged | ||
sena_kun, Details: gist.github.com/63d8dbcb67eff76cf9...71295a3083 | |||
11:58
evalable6 left,
linkable6 left
12:00
evalable6 joined
12:02
reportable6 left
12:05
reportable6 joined
|
|||
Geth | rakudo/release-2021.10: ece1fc9f50 | Altai-man++ | 3 files Update changelog + announcement Deliberately not logged: 1e25f4f 4bca3e6 c99ffc5 d6be10e 59debb4 ef95fe2 6d45da8 bcd3ae0 b1200b6 28303d0 b2bfa4d 1d8bf66 308d685 067bef4 1ddd6e7 59d12ec 5799714 9e6b1cc ec65ffc |
12:39 | |
rakudo: Altai-man++ created pull request #4585: 2021.10 release |
|||
12:47
notna left
|
|||
lizmat | sena_kun++ # 2021.10 release! | 12:49 | |
ah, not yet merged :-) | |||
12:50
frost left
|
|||
sena_kun | not yet merged | 12:53 | |
I'm writing a response to you. :) | 12:54 | ||
12:59
linkable6 joined
|
|||
sena_kun | lizmat, wrote a reply. | 13:18 | |
lizmat | sena_kun: read it, will respond after some time afk | 13:20 | |
13:35
Xliff joined
|
|||
Geth | roast/6.d-errata: d3af368aec | (Jonathan Worthington)++ (committed by Altai-man) | S12-meta/primitives.t Modify tests to account for method cache changes Pre-calculated method caches are not a part of new-disp. The built-in meta-objects will stop producing them soon on MoarVM; hopefully, with time, we'll adopt the new-disp approach on JVM too, and can fully deprecate the method caching related functionality in the metamodel primitives class. ... (6 more lines) |
14:29 | |
roast/6.c-errata: 73d819ee81 | (Jonathan Worthington)++ (committed by Altai-man) | S12-meta/primitives.t Modify tests to account for method cache changes Pre-calculated method caches are not a part of new-disp. The built-in meta-objects will stop producing them soon on MoarVM; hopefully, with time, we'll adopt the new-disp approach on JVM too, and can fully deprecate the method caching related functionality in the metamodel primitives class. ... (6 more lines) |
|||
sena_kun | oh now | ||
14:50
evalable6 left,
linkable6 left
14:55
notna joined
15:02
notna left
|
|||
Geth | nqp: e7edc21ae2 | Altai-man++ | tools/templates/MOAR_REVISION [release] Bump MoarVM revision to 2021.10 |
15:06 | |
nqp: 8faf703d36 | Altai-man++ | VERSION [release] Bump VERSION to 2021.10 |
|||
rakudo: 709432f6b2 | Altai-man++ | tools/templates/NQP_REVISION [release] Bump NQP revision to 2021.10 |
|||
rakudo: 1891cd24a5 | Altai-man++ | VERSION [release] Bump VERSION to 2021.10 |
|||
sena_kun | oh no | 15:11 | |
Geth | rakudo/release-2021.10: ea0f8067bc | Altai-man++ | 3 files Update changelog + announcement Deliberately not logged: 1e25f4f 4bca3e6 c99ffc5 d6be10e 59debb4 ef95fe2 6d45da8 bcd3ae0 b1200b6 28303d0 b2bfa4d 1d8bf66 308d685 067bef4 1ddd6e7 59d12ec 5799714 9e6b1cc ec65ffc |
15:12 | |
rakudo/release-2021.10: 6faaf389ea | Altai-man++ | tools/templates/NQP_REVISION Revert "[release] Bump NQP revision to 2021.10" This reverts commit 709432f6b296f1cfb196e07e9e03687d96703fa6. |
|||
rakudo/release-2021.10: 4a4481f408 | Altai-man++ | VERSION Revert "[release] Bump VERSION to 2021.10" This reverts commit 1891cd24a5d5869c416723f4ff0ef7f2d4e230c9. |
|||
rakudo/release-2021.10: d623d33206 | Altai-man++ | tools/templates/NQP_REVISION [release] Bump NQP revision to 2021.10 |
15:23 | ||
rakudo/release-2021.10: b7d5acec24 | Altai-man++ | VERSION [release] Bump VERSION to 2021.10 |
|||
rakudo/master: 6 commits pushed by Altai-man++ | 15:25 | ||
¦ rakudo: Altai-man self-unassigned Suggestions on release announcements github.com/rakudo/rakudo/issues/4314 | 15:30 | ||
15:51
evalable6 joined
15:53
linkable6 joined
|
|||
sena_kun | .note test | 15:55 | |
weekly test | |||
weekly: test | 15:56 | ||
notable6 | sena_kun, Noted! (weekly) | ||
sena_kun | weekly: twitter.com/koto_san_kana/status/1...4425327616 twitter.com/koto_san_kana/status/1...1010384896 twitter.com/koto_san_kana/status/1...8807632900 | 15:57 | |
notable6 | sena_kun, Noted! (weekly) | ||
16:15
notna joined
16:16
notna left
|
|||
lizmat | sena_kun++ # thanks for all the releases! | 17:20 | |
17:33
linkable6 left,
evalable6 left
17:34
evalable6 joined
18:02
reportable6 left
18:05
reportable6 joined
18:34
linkable6 joined
|
|||
Geth | roast: 9525fa6ee6 | (Christian Bartolomäus)++ | 6 files [JVM] Fudge some failing tests Some of the fudged tests are new (S06-signature/closure-parameters.t, S12-methods/fallback.t), or have been modified recently (S12-construction/destruction.t). The test in S12-methods/submethods.t is a regression. The other tests have been flapping for a long time and it seems better to have them as 'todo'. |
18:45 | |
roast: 691f062f94 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 6 files Merge pull request #761 from usev6/jvm_fudge [JVM] Fudge some failing tests |
|||
lizmat | grrrr | 19:05 | |
Missing or wrong version of dependency 'gen/moar/stage2/NQPHLL.nqp' (from 'site#sources/45334C557865A97D1ECA0D3F3A3FAF2017FCE553 (OO::Monitors)') | |||
OO::Monitors yet again :-( | |||
uninstalling / re-installing OO::Monitors seems to have fixed it | 19:06 | ||
sena_kun | lizmat, do you have a bit of time in this nice Saturday evening? :) | 19:10 | |
lizmat | yes I do | 19:11 | |
sena_kun | if possible, I'd like to discuss the PR thing interactively. My experience tells me when people start to post messages of more than 2-3 sentences, but 2-3 dozens of sentences, exact intentions of those who write disappears somewhere. | 19:14 | |
lizmat | I'm listening :-) | 19:16 | |
sena_kun | So far I can see 2 separate things, 1 is smaller padding between messages you asked about some time ago. As far as I tested the PR out, it was implemented, but rejected due to a tiny flaw? The second thing that somehow suddenly was brought up is to change how the website serves CSS based on a domain (?). I'm re-reading a couple of last posts and cannot grasp where from the idea came? | 19:17 | |
lizmat | sanity check: what do *you* mean with "domain" ? | 19:19 | |
sena_kun | URL | ||
I remember you saying you enjoy working on it, and I guess it makes sense for you to get a nice break from all the infinite amount of rakudo hackery you've done in the past, so I was thinking if I can get you interested in reviving the docs project, given you kinda sailed the logs website (yay!) and it can now live a life. | 19:21 | ||
lizmat | that's not what I suggested: only that 3 different sets of templates would be used for the different modes | ||
sena_kun | Sanity check: templates include CSS or not? | 19:22 | |
lizmat | no, not necessarily | ||
I could imagine it making sense as well, but that would be more up to the designer really | 19:23 | ||
sena_kun | Well, templates are also the design domain. This aside, where did this idea came from? | ||
Oh, "domain" here as "area of expertise". | |||
lizmat | because I'm seeing a lot of conditionals everywhere that one could do without if there were an external conditional | 19:24 | |
sena_kun | lizmat, conditionals where, in templates? | ||
lizmat | yeah, "only do this in mobile mode" "only do this in desktop mode" etc | 19:25 | |
sena_kun | hmm | ||
Can you please put a link to one, so that I knew what you mean? | 19:26 | ||
A github link to a file/line or just a line in a file, I'll open it here. | |||
lizmat | github.com/lizmat/App-Raku-Log/blo...rotmp#L745 "is-hidden-touch" "is-hidden-mobile" | 19:28 | |
the way I understand that, is that you effectively ignore the tags inside of that for the given mode | 19:34 | ||
sena_kun | lizmat, are you sure there are "a lot" such classes used "everywhere"? In the whole common file we have 3 (!) `is-hidden-mobile` classes used and 1 usage of `is-hidden-tablet`. | 19:35 | |
lizmat, yes. There is one cool thing about making it this way, let me write it up for a bit. :) | 19:36 | ||
lizmat | ok, please do! | ||
sena_kun | lizmat, you are correct, we have a couple of UI elements (a menu, a sidebar) in a single template, but always only one among them is displayed. The triggering for a change happens using declarative rules in CSS, they are neat. The good thing probably missing is that it allows users to have "responsible" website. If you resize the window smaller you auto-magically have a bit different, bit fitting view, and if you resize it back it's the same again. You | 19:44 | |
might argue this is a rare use-case, but I imagine people with lots of floating windows would appreciate that. I'm using tiling WM and if the browser takes half or a quarter of a screen (e.g. when I write a changelog I do that to have an editor nearby), it also Just Works. You suggest to load an appropriate layout dynamically using JS maybe? If I understand correctly, this requires asking the server to serve more content if the user resized the window | |||
and is hardly a nice solution to preserve its bandwidth. | |||
lizmat | no, I'm just saying that the switches between the modes, I'm not suggesting creating a separate version for all possible screen geometries | 19:45 | |
sena_kun | lizmat, can you please elaborate what do you mean with "mode"? | ||
I get you mean desktop / tablet / mobile views, but you do you imagine "switching" between them? | 19:46 | ||
If not reloading content nor relying on CSS rules. | |||
lizmat | switching would mean a reload / redirect | 19:49 | |
sena_kun | lizmat, hmm, then this is "yes", not a "no", no? I described how reloading a page on window resize is 1)slow, has a delay when network is used + parsing DOM on the client again; 2)makes the server serve content as many times as the window is resized instead of just "once and forget"; 3)breaks the flow of using a page. | 19:52 | |
lizmat | no, it would only be a reload if the resizing would mean a mode change | ||
sena_kun | well, yes, I resize a window to make it smaller and suddenly the page is reloaded. I resize it back and boom, the same. | 19:53 | |
lizmat | and people wouldn't be resizing all of the time | ||
well, it was just an idea I was playing with | |||
because I see duplicated HTML just to be able to support different modes | 19:54 | ||
sena_kun | you're right, people don't resize windows all the time. | ||
lizmat | which implies that *every* user gets *all* of the HTML for *all* modes *all* of the time | ||
just so that a mode change would be smooth | |||
sena_kun | lizmat, will be against me doing some perf measurements? | 19:55 | |
lizmat | we say in dutch "meten is weten", aka " to measure is to know" | ||
so go ahead :-) | |||
sena_kun | aye, thanks | 19:56 | |
As a simple experiment I can think about, I'll remove the mobile bits and load a desktop version, record precise timing, then the same with original to see how much difference there would be. | 19:57 | ||
lizmat | please, also do that server side ? | 20:02 | |
sena_kun | here is the diff of changes I got www.diffchecker.com/801T5haU <- removing things hidden on desktop. I did 10 page loads for each one and the results vary from 70 milliseconds to 130 milliseconds both. I would expect no visible difference, because the file with mobile elements stripped takes 8060 lines of code and the one without has 400 more, 8467. This is for localhost:10000/moarvm/2014-01-02.html a relatively small page. That's less | 20:08 | |
than 5% more code to parse for the client. | |||
lizmat, what server data you want me to measure? I am not sure something as cheap as serving a file would work easily, I'll have to write a testing script to create some serious load for Cro and alas I'm too beaten for it now after a release. | 20:09 | ||
s/something/MEASURING something as.../ | |||
lizmat | ok, forget the server part then :-) | 20:10 | |
sena_kun | But given you did not listen to my dumb advice and still made the server cache the page content on disk... :) | ||
I suspect it should be alright. Raku grammars would be only faster. | 20:11 | ||
lizmat | did I call hour advice "dumb" ? | 20:13 | |
*your | |||
sena_kun | In conclusion I hope we can agree that sometimes every user getting all of the HTML for all the modes all the time is not that much more expensive. I guess we are lucky because we need to change only a couple of menues and the main content (messages, taking 95% of page on average) are the same HTML. | 20:14 | |
No, that what I think about me being surprised with caching every page on disk in retrospective. | |||
lizmat | well, only the pages that are static once the templates are no longer in flux :-) | 20:15 | |
sena_kun | Yes. | ||
lizmat | aka, the daily pages | ||
sena_kun | I still enjoy what we (well, mainly you to me being absent, heh) made, IMO it's much more pretty than it was and has more features. | 20:17 | |
s/you to/you due to/ | |||
lizmat | ok, I guess relatively speaking it is indeed not a lot extra HTML | ||
still, I guess a design where the duplication would not be necessary, would be better | |||
sena_kun | Better for whom? | 20:18 | |
lizmat | anybody trying to understand the tenplates | ||
and in the end, up to 5% less work for the server / client | 20:19 | ||
for creating / parsing the DOM | |||
sena_kun | Well, designers survive somehow. | ||
I don't think it's a stable less work thing, no? | |||
lizmat | ?? | ||
sena_kun | As I wrote, if the user resizes a window, the server needs to serve again and the client needs to parse DOM again for 95% content being the same. + network usage. I'd say that this way one trades O(1) algorithm (where 1 is 100%) for O(N) algorithm (where 1 is 95%, but given you have N resizes...). | 20:20 | |
lizmat | yeah, you convinced me that that is not a good reason to go for different templates :-) | 20:21 | |
sena_kun | You win 5% at first load, but then you might lose twice the amount of work. Twice, trice etc. People don't do it all the time, but when they do... | ||
That's an interesting question though. | 20:22 | ||
I guess super large websites have mobile versions for this reason, but they are not "responsive". If you resize the window it screws, no reloading. Maybe when you're as big as Wiki you can have your own tradeoffs. | 20:23 | ||
Alright, now we have the rest, the first thing we discussed, smaller paddings. I see the PR is closed, but it does what suggested without a lot of patching, no? | 20:24 | ||
lizmat | it makes the special messages seem odd, as the image shows | 20:25 | |
sena_kun | Aaaah. One more thing I wanted to mention, about the Safari dropdown bug. That's not because how we serve templates, but because how Safari processes "hover" on mobiles (well, there are no mouse to "hover", huh). We'll need to change it to click-driven dropdowns and it'll work. | ||
lizmat | but the pulldown works on the day view ? | ||
sena_kun | lizmat, the first iteration was as your image, but it was patched to looks alright, no? There is a smaller padding between a "smaller" message and special message, but it's maybe not that critical. | 20:26 | |
lizmat | will look again in a moment | 20:28 | |
I'm just rebuilding everything after a zef nuke | |||
sena_kun | lizmat, i.ibb.co/1dzqhzj/image.png <- this is how it looks for me now. | ||
lizmat | ok, that looks indeed better | 20:37 | |
merge needs rebasing in the generated files, meh, I'll just push the changes manually | |||
and that is live now | 20:41 | ||
20:41
linkable6 left,
evalable6 left
|
|||
sena_kun | lizmat++ # awesome! | 20:41 | |
thanks for your patience with me. :) | |||
lizmat | and you with me :-) | 20:42 | |
20:55
squashable6 left
20:56
squashable6 joined
21:43
linkable6 joined
23:02
Kaiepi left
23:19
discord-raku-bot left,
discord-raku-bot joined
23:44
evalable6 joined
|