00:43 dg joined 00:44 ds7832 left 00:45 sibl joined 01:13 topnep left 01:14 topnep joined 02:28 sibl left 02:50 causal joined 02:51 causal left 02:53 causal joined 03:00 kylese left, hulk joined 03:01 annamalai left 03:15 hulk left, kylese joined
SmokeMachine Did anyone see this? youtu.be/RCHhAEjEjKw?si=F7l_QyVTA6IPu7Md 03:29
03:31 destroycomputer- left, sibl joined 03:34 destroycomputers joined 03:46 annamalai joined 03:56 causal left 04:15 xinming left 04:19 sibl left 04:21 causal joined 04:57 Aedil joined 05:20 causal left 05:22 sibl joined, causal joined 05:47 sibl left 05:51 sibl joined 06:23 Sgeo left 06:58 causal left 07:06 abraxxa joined 07:29 topnep left 07:30 topnep joined 08:19 vrurg left 08:20 vrurg joined 09:15 dakkar joined 09:34 topnep left 09:35 topnep joined 09:59 sibl left 10:05 sibl joined
lizmat did not, have now. Could only find one incorrect statement in it 10:07
Priceline did not use Perl in any serious manner until *after* it took over bookings.nl 10:08
librasteve_ news.ycombinator.com/item?id=47424018 10:55
11:40 topnep left 11:44 topnep joined
lizmat weekly: programming.dev/post/47337716/22780753 12:00
notable6 lizmat, Noted! (weekly)
lizmat in other words: a #raku-debate channel has been created
12:27 sibl left 12:32 human_blip left 12:34 human_blip joined
Voldenet SmokeMachine: nice vid, quite informative 12:43
SmokeMachine I liked it too… I only think it could/should have been more optimistic about Raku… 12:45
lizmat indeed... it mentioned burnout on Raku core devs, but I think it could have also focussed on burnout with Perl core devs... which I think is actually significantly higher 12:48
but then again, I don't follow Perl that much anymore, so I could be wrong
[Coke] what is raku-debate for? 12:53
lizmat "This is a place for debating issues that are somehow related to the Raku Programming Language, but do not need to be. This channel is **not** logged. Anything contentious that has no place on the #raku channel, should be discussed here."
I see it as a lightning rod, really
Voldenet saying that "butterfly is a bug, raku has it in logo, does that imply things" ;> 12:54
[Coke] ... that would explain why it wasn't in the logs for me to see what it was about. :)
Voldenet And people, instead of "stop this" can say "move this to #raku-debate"
bam!
Perhaps is that #raku-debate is a bit less-civil 12:55
s/is that/
so people who can't stomach flamewars would stay away from it
13:02 david7832 joined 13:03 vrurg_ joined 13:05 vrurg left
timo wouldn't it be amazing if we could have debate without flame war though 13:07
lizmat fwiw, I think a debate on whether #raku-debate is a good thing or not, should be on #raku-debate :-) 13:11
Voldenet It would, but flamewar itself isn't literally involving flames – some people would consider heated discussion to be already burning 13:20
so it's debatable
david7832 I actually think that #raku-debate *should* be logged, and that this is quite important for it to fulfill its purpose: When someone considers a topic important enough to keep bring it up in #raku despite being asked not to, then it's highly likely that they *want* it to be on the record (at the very least, they're apparently fine with it). Logging 13:21
#raku-debate also means that, while we ask to move something away from the main channel, we retain the possibility for all to look at it later on, recognizing that the person may have something relevant to say and that a discussion may lead to results worthy of preservation. (Whereas if it feels like being asked to speak into a memory hole, then
the person could easily be antagonized.)    Conversely, when a non-logged channel is desired, creating one ad-hoc is always a piece of cake.
13:27 david7832 left
timo modern debaters heat their detabes with heat pumps 13:37
13:40 david7832 joined
Voldenet ah so that's why I get so hot when I argue on the internet despite no flames ;) 14:01
14:04 david7832 left 14:19 david7832 joined
[Coke] can someone think of any way to improve the likelihood that this github.com/coke/raku-unicode-mangl...8C4-L104C7 actually generates something printable? 14:34
david7832 Is it made sure that line 69 works as intended? It reads:  $char ~ @combinors.pick($count).join;   -- I can't tell exactly what goes on unicode-wise, but perhaps the fact that the connector chars are *first* joined to each other and *then* appended to $char leads to something different than expected? 14:40
[Coke] Any interest in a module that uses postfix subscript for base conversion? 14:41
huh, david7832, hadn't thought of that. Maybe? 14:42
14:43 sibl joined
[Coke] + ($char, |@combinors.pick($count)).join; 14:44
seems to generate *slightly* more readable entries, but not enough. :)
14:48 sibl left
[Coke] I imagine I'd have to use some of japhb Terminal code to check for the given user running the code. 14:49
david7832 This will probably also be very useful: www.unicode.org/reports/tr44/#Cano...ass_Values 14:56
So you can look at the precise numerical value of each Canonical_Combining_Class: Depending on the character class of the specific base letter, certain Canonical_Combining_Class can be ruled out
e.g. if you have a latin character, Canonical_Combining_Class values 6, 7 and more are irrelevant
s/6, 7 and more/6, 7 and others/ 14:57
[Coke] david7832: I mean, I'm only ever testing latin characters, but something more universal would be nice. :) 15:17
m: 0x0300.chr.uniprop('Canonical_Combining_Class').say 15:20
camelia 230
[Coke] "Distinct marks directly above"
disbot2 <antononcube> At least for display purposes, like here: reference.wolfram.com/language/ref...eForm.html 15:22
15:27 david7832 left, david7832 joined 15:28 david7832 left 15:29 david7832 joined
[Coke] david7832: types double_above and double_below seem bad, skipping those. 15:30
others seem fine in general, but not always in a combo. 15:31
david7832 I'm also concerned about combinations of e.g.  two below-marks that *render* fine, but are probably bad practice to use as they look like they're a single mark even though they're two 15:32
[Coke] m: ("d", "\x[1DE7]", "\x[368]").join.say 15:33
camelia dᷧͨ
[Coke] yah, maybe the way to go for this ridiculous thing is to pick above/below/overlay/left/right instead of "2 random combinors"
disbot2 <librasteve> [Coke] I think we have a module already that uses subsript for bases ... looks 15:34
<librasteve> raku.land/zef:lizmat/Slang::NumberBase 15:37
<antononcube> Hmm... I vaguely remember seeing it.
[Coke] librasteve_: ... why is it prefix and not postfix?
lizmat I vaguely remember implementing it :-)
disbot2 <librasteve> oh - don't know 15:38
david7832 Coke [15:33:56]: That sounds sensible. So presumably up to one for each single Canonical_Combining_Class number (since combinations of e.g. one "above-left", one "above-right" and maybe one simple "above" combinor are presumably still acceptable)
[Coke] also, that seems backwards from number<subscript> which means the number is already IN the base, and you're declaring what the base was.
disbot2 <antononcube> It mighe have been one of the reasons I did not use it in my Number theory demos.
[Coke] david7832: something like that, yah.
david7832: any chance you want to play around and submit a PR? :) 15:39
(if not will hit something later this week)
disbot2 <librasteve> I think postfix is more standard
lizmat I think it was to avoid a problem with using raku.land/zef:lizmat/Slang::Subscripts
?
[Coke] librasteve_: I'm looking for something that means 48₁₂ == 56 15:40
david7832 [Coke]: Have to decline, unfortunately, since actually coding Unicode things is too far off for me
[Coke] david7832: no worries. Thanks for the suggestions, appreciate it!
lizmat [Coke]: maybe a simple adaptation to Slang::Numberbase could do this 15:42
disbot2 <antononcube> I will bw interested in this kind of write ups:
<antononcube> cdn.discordapp.com/attachments/633...c0975&
lizmat checks
disbot2 <antononcube> This one is better: 15:43
<antononcube> cdn.discordapp.com/attachments/633...29935&
david7832 You're welcome! Btw, I *have* been thinking about making a PR to replace lines 146–154 [+line 131] with simply: %mappings{$char} // $mappings.invert.Hash{$char}; 15:44
(In github.com/coke/raku-unicode-mangl...#L146-L154
[Coke] I'll take it. :) 15:45
lizmat [Coke]: an update of Slang::Numberbase should be there in 15 mins or so 15:50
david7832 [Coke]: done – github.com/coke/raku-unicode-mangler/pull/6 :) 15:54
15:54 topnep left 15:55 topnep joined
disbot2 <librasteve> '48'.parse-base(12) 15:58
<librasteve> == 56
lizmat [Coke]: Slang::NumberBase 0.0.2 on its way to the ecosystem now 16:02
disbot2 <librasteve> did you change up base to parse-base? 16:03
<librasteve> 48.base(12)
<librasteve> == 40
[Coke] m: say 123.45.base(8), 123.45.parse-base(8) 16:12
camelia No such method 'parse-base' for invocant of type 'Rat'
in block <unit> at <tmp> line 1
[Coke] m: say 123.base(8), 123.parse-base(8)
camelia No such method 'parse-base' for invocant of type 'Int'
in block <unit> at <tmp> line 1
[Coke] m: say 123.base(8), '123'.parse-base(8)
camelia 17383
[Coke] Yah, that just moved the prefix to postfix, but didn't change the logic (according to the readme) 16:13
lizmat [Coke]: actually allows both, if you mean the module
isn't that what you wanted ?
[Coke] ... not pre vs. post. parse-base vs. base
No, it's not. You made the -base- available as either. as I said, I want 48₁₂ == 56 16:14
you made 56₁₂=48 work, I think
lizmat yeah, I did 16:16
eh, no
hmmm... I guess I did 16:17
[Coke] I think 48₁₂ == 56 is standard maths notation - maybe ₁₂56==48 could be there as well? 16:18
lizmat right... I see the diff now :-) 16:19
ok, working on getting postfix TDTRT 16:20
disbot2 <librasteve> [Coke] - I like the idea (though maybe I would not remember it) 16:21
[Coke] and someone will no doubt want FF₁₆ = 255, no idea how hard that is with this slang (guessing it only deals with numbers) 16:22
david7832 For peak Raku, please also implement Radix64, which uses A–Z, a–z, 0–9 and the plus, slash, and equal sign (en.wikipedia.org/wiki/Base64#Alphabet) 16:31
lizmat heh... nice one... 16:41
david7832: so prefix ₆₄12345 would output in Radix64 and 12345₆₄ would interprete as Radix64, right ? 16:46
david7832 Good question – don't know much more :)  The latter notation definitely widely-used notation; adding the former seems logical and useful (but it could also confuse people). 17:08
For longer inputs, one might want to allow multiline inputs like in PGP, one of the most prominent applications of Base64:
-----BEGIN BASE64----- 17:09
LpvQVRf7B+JApA1JICOUXK08eo+JXVdsgt7sNQOqwX3lMgZcWq2UBaeQPk6ocbje
0cP6kuUVYG3L409rg7Ja25n4wrGEGlYDhMZ7pacyAIY21rEC0R5eBqXEOhxWN2su
P8hsqETueckIBis7/M3dpq8CQ2gMlywYEl1+j+ofG9hDyfoQ3g
-----END BASE64-----
lizmat feels that should be a separate slang module then
david7832 makes sense 17:10
17:27 human_blip left 17:29 human_blip joined
lizmat [Coke]: 0.0.3 now on its way to the ecosystem 17:31
with: say FF₁₆ # 255 17:32
17:33 kybr joined 17:47 dakkar left
disbot2 <librasteve> lizmat± 18:04
<librasteve> ++ rather
lizmat thinking about it more... I think support for Radix64 literals since there is raku.land/github:ugexe/Base64 18:08
*not needed
david7832 one can dream though :) 18:34
Can anybody tell why the &infix:<_> defined here gets exported with &infix:<_>.associative eq "", even though `is assoc('left')` is written there (and a `say &infix:<_>.associative` immediately after that definition does output "left" when called)? 18:37
codeberg.org/dss/understitch/src/c...rakumod#L3
lizmat david7832: I wouldn't be surprised if the traits are not applied in order 18:39
have you tried switching them around ?
david7832 yes, switching did nothing 18:40
lizmat and with RakuAST ? 18:41
david7832 I currently know next to nothing about RakuAST, but seems like the time to read up on it
any good entry points?
lizmat no, I mean... if you run it with RAKUDO_RAKUAST=1 does it work then ? 18:42
david7832 ah – – that does give `left` indeed! 18:43
(with either ordering of the prefixes, by the way) 18:44
s/prefixes/traits/
18:44 vrurg_ left
lizmat fwiw, it looks like the exporting process somehow is responsible for losing the "left" 18:48
please make a bug report for this 18:49
david7832 will do. Thanks! 18:50
18:52 david7832 left
lizmat afk& 18:53
18:54 david7832 joined
david7832 Issue: github.com/rakudo/rakudo/issues/6089 ("Associativity trait of infix sub defined in EXPORT() is lost during export #6089") 19:16
19:41 david7832 left 20:04 topnep left 20:05 topnep joined, Aedil left 20:29 vrurg joined 20:55 habere-et-disper joined 21:02 habere-et-disper left 22:09 topnep left 22:10 topnep joined 22:13 Sgeo joined 22:14 abraxxa left 22:41 annamalai left 23:15 david7832 joined 23:17 david7832 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!