🦋 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.
japhb .tell Xliff Sorry, was working on other things earlier. I'm working on a slightly larger example to also include showing some of the things I expect you to ask about next. :-) 00:12
tellable6 japhb, I'll pass your message to Xliff
00:16 vrurg left 00:18 abraxxa-home left 00:24 vrurg joined 00:39 MasterDuke joined
Xliff japhb: Thanks! 00:43
tellable6 2023-11-08T00:12:15Z #raku <japhb> Xliff Sorry, was working on other things earlier. I'm working on a slightly larger example to also include showing some of the things I expect you to ask about next. :-)
Xliff japhb: Why would I be getting a "You cannot create an instance of this type (Terminal::Widgets::Form:D) 00:50
"
vrurg Xliff: because you're trying to create an instance of a definite. 01:17
I.e. somewhere the :D type slips as a .new invocant.
codesections . 01:18
01:31 itaipu left 01:37 jmcgnh left 01:47 jmcgnh joined 01:48 itaipu joined 01:58 dbonnafo joined 02:03 dbonnafo left
japhb Xliff: Example written and pushed. You might want to join #mugs here if you want to see my Raku commit streams. 02:18
tellable6 2023-11-07T18:11:31Z #raku <Xliff> japhb Have you had a chance to come up with an RGB Terminal::Widgets::Plaintext example? Thanks.
02:26 tonyo left, tonyo joined 02:40 dbonnafo joined 02:45 dbonnafo left
Xliff japhb, Thanks! 02:48
03:07 edr left 03:22 dbonnafo joined 03:26 dbonnafo left 03:27 nebuchadnezzar left, nebuchadnezzar joined 05:02 [Coke]_ joined 05:04 gabiruh left, gabiruh joined, [Coke] left 05:43 dbonnafo joined 05:48 dbonnafo left 05:49 kaskal- left 05:52 kaskal joined 06:16 dbonnafo joined 06:35 jtza8 joined, jtza8 left, jtza8 joined 07:53 vrurg left, vrurg joined 08:09 dbonnafo left 08:14 lichtkind joined 08:45 Sgeo left 08:58 AlexDaniel left 09:12 constxd left, constxqt left 09:14 constxd joined 09:16 constxqt joined 09:17 dakkar joined 09:21 sena_kun joined 09:52 lichtkind left 10:04 jpn joined 10:14 abraxxa joined 10:26 lichtkind joined 10:30 sena_kun left 11:08 kylese joined 11:44 teatwo joined 11:47 tea3po left 12:16 abraxxa left, abraxxa joined 12:19 jpn left 12:27 edr joined 12:43 jpn joined 12:47 kjp joined 12:48 jpn left
tbrowder__ g'day, Raku Advent is rapidly approaching!! 12:57
(stress out)
videos of Raku Conf look good. thanks to all speakers! 12:58
lizmat weekly: advent calendar 2023 12:59
notable6 lizmat, Noted! (weekly)
tellable6 2023-11-08T04:08:00Z #raku-dev <AlexDaniel> lizmat it does seem to work! Thank you!
antononcube @tbrowder “videos of Raku Conf look good. thanks to all speakers!” — Yes, I watched a few. 13:48
librasteve @tbrowder I agree (sadly could not make it live - so tx for the recordings!) 13:50
patrickb I just found this: harelang.org/blog/2023-11-08-100-year-language/ 13:51
Hare is a very different lang from Raku, but I still have a very big grin, recognizing the "100 year" term we have been using for quite some time already. :) 13:53
13:54 jpn joined
antononcube @librasteve I “featured” one of you packages. (For at least a minute.) 13:56
librasteve thanks! - I watched the first half of your talk last night - highly recommended 13:57
antononcube Thank you! 13:59
14:07 jtza8 left 14:11 [Coke] joined 14:13 [Coke]_ left
Geth raku.org: 1213fa3dfb | (Will Coleda)++ (committed using GitHub Web editor) | source/community/index.html
Add link to PS repo (#217)

Closes #216		 14:40
nemokosch Hare kinda seems like a joke taken too seriously 14:53
"We want to replicate the long-term success of C without actually creating anything new" 14:54
Yo wat
Why don't you just keep on using C then
15:14 unicodable6 left, sourceable6 left, sourceable6 joined, unicodable6 joined, bloatable6 left, bloatable6 joined 15:27 jgaz left 15:28 jgaz joined
librasteve I thought that was Rust 16:33
not sure about manual memory management these days 16:35
Hare fits on a 3½" floppy disc
drakonis i've spotted raku in a wasm benchmark 16:38
github.com/wasmfx/oopsla23-artifx/...effects.pl
codesections drakonis: that link doesn't work for me. Is the … 16:40
supposed to be something else?
drakonis there is no ... here
something's busted with your client 16:41
nemokosch indeed, the link works fine 16:43
codesections Oh... oops! I did that to myself. 16:44
drakonis raku is being used to generate a .wat file
nemokosch XD
but it has a Perl extension and it is referred to as a "Perl script", plain and simple... 16:45
drakonis it is being very specific and using v6 16:46
praise smart operators
codesections Ha, the idea of a "Go compiler for small places" using Raku ammuses me. (I know it's not using Raku in those small places, but still) 16:47
nemokosch I mean yes, it is indeed Raku
but then maybe it would be good if it were actually called a "Raku script" and had such extension...
AND then perhaps a more meaningful version setting
I have the feeling that it's next to no use if somebody uses Raku without knowing/acknowledging that they use Raku... 16:50
17:09 cleo left
codesections github.com/wasmfx/oopsla23-artifx/pull/1 17:10
drakonis: ^^^^ better?
drakonis i mean, its up to them
codesections yeah. But at least I made it *easy* for them :) 17:11
librasteve their dirty little raku habit has been outed
is there a module that takes 3½ as a literal (or a Str) and makes <7/2>? 17:19
17:33 HobGoblin left, goblin joined 17:36 dakkar left
lizmat librasteve not to my knowledge, but with RakuAST and 6.e it's supported in core 17:51
17:52 abraxxa left
lizmat well, or so I thought :-) 17:53
m: say Q|use v6.e.PREVIEW; 3½|.AST.EVAL 17:54
camelia ===SORRY!===
MVMArray: Can't pop from an empty array
lizmat meh
librasteve m: say Q|use v6.e.PREVIEW; ½|.AST.EVAL 18:11
evalable6 0.5
Raku eval Exit code: 1 No such method 'AST' for invocant of type 'Str' in block <unit> at main.raku line 1
codesections Hmm, I *thought* &unival was supposed to do that, but it doesn't seem to 18:13
docs.raku.org/routine/unival
librasteve lizmat: maybe works for individual unicodes like ½, but not in strings like 3½
codesections m: say unival "3½" 18:14
camelia 3
codesections m: say unival("3") + unival("½")
camelia 3.5
lizmat m: say ½
camelia 0.5
lizmat that already worked for a looong time 18:15
codesections is unival's handling of 3½ a bug?
lizmat well, I think the use of vulgar fractions should be transparent 18:16
and I thought I had implemented that 18:17
codesections oh, does unival only look at the first character?
m: say "47".unival
camelia 4
lizmat yes, you want univals
m: say "47".univals
camelia (4 7)
codesections m: say sum univals "3½" 18:18
camelia 3.5
codesections @librasteve does ^^^ do what you're looking for?
lizmat: oh, right, thanks 18:19
librasteve thinking... 18:21
18:23 justThanks is now known as justTesting
lizmat github.com/rakudo/rakudo/commit/51...d7c8728bac 18:23
is what I thought would allow this in RakuAST 18:24
librasteve (thanks - it's a good answer and no module needed ... but I want to write 3½ instead of 3 and "sum univals" is a lot of text ... so not gonna lie, I think I need to make a shortcut of some kind) 18:25
m: say sum univals "3⅞" 18:26
evalable6 3.875
Raku eval 3.875
librasteve .oO
nemokosch yeah it's kinda awkward but it feels like this is the kind of niche thing that would really be enough to be available in a slang 18:27
librasteve nemokosch: I've been giving some thought how to attract more users to raku -- which I think you mentioned at TRC (apologies I could not join live) 18:29
nemokosch I'd say it was one of the main topics of the whole conference this year
librasteve I think for some of the potential "audience" the notion that you can go 0.1+0.2=0.3 #True is a really neat OOTB feature (that eg Python doesn't do) 18:30
lizmat librasteve: 3⅞ will work in RakuAST / 6.e
librasteve so maybe having ½-⅓==⅙ is also cool for a certain curious group? 18:32
nemokosch for 0.1 + 0.2 being 0.3, I wouldn't argue with you because I don't think it makes a big difference how we judge that particular aspect, I get the general sentiment. But I think that general sentiment really quickly gets a completely oppositional effect as well
lizmat m: say ½-⅓==⅙ 18:33
camelia True
nemokosch My point is that predictability and transparency is important to a lot of people; probably more people than the whole notion of "do what i mean"
The "average Joe", so to speak, cares much more about knowing why something happens than whether their thoughts are found out 18:34
if there is too much magic going on, people might think it's kind of a joke, and I think we can already see that 18:35
librasteve so we agree that print(0.1+0.2) => 0.30000000000000004 is bad then (Python on glot.io)
nemokosch I think it's debatable but not worth picking on
it's not universally and absolutely bad, at the very least 18:36
librasteve so you think it's good, then?
nemokosch what the result is matters much less than why it is what it is, and what the consequences are
librasteve fair point 18:38
nemokosch most people most of the time don't care about precise rationals; they can just take that "this is how floating point numbers work" and that "they are way faster"
and those people who do care will, I'd say most of the time, also want precise algebraic numbers, and at the end of the day, probably symbolic computation
lizmat feels an awful lot like Stockholm syndrome to e though 18:39
nemokosch Stockholm syndrome implies that it's clearly an inferior choice but knowing the performance we have to suffer, it isn't
18:42 sena_kun joined
m: (sqrt(2) + sqrt(3))*2 - 2sqrt(6) andthen .say 18:43
evalable6 (exit code 1) 4===SORRY!4=== Er…
Raku eval 5.000000000000002
evalable6 nemokosch, Full output: gist.github.com/c9f696ffb1a249194a...e3b55ab688
nemokosch so yeah, algebraically, this should be 5, shouldn't it
librasteve I get that 0.1+0.2==0.3 is not really very important ... for me it resonates because it's a simple example of how raku reinvents coding and goes beyond int and float, and gives ya benefit of predictability ... but I also get that you don't think is a strong unique selling point 18:44
nemokosch I think it might backfire more, without an actual math-oriented, I don't know, numpy-scipy kind of context where everything is accurate 18:46
with all that, sure. But then that's not "general purpose programming" but more or less a competition with WL, Matlab, Maple and these Python libs 18:47
librasteve you are right to say that rationals do not improve calculations on irrational numbers (and I am not saying "let's make raku do that now before we try to win new converts")
so, what are the messages that we should be using to get attention and interest from the wider programming community? 18:48
nemokosch I also don't want to restrict the topic to accurate rationals 18:49
librasteve well our message can be quite abstract initially, but our claims will need to have evidence
nemokosch as much as I hate to say it, I do think grammars and text processing overall could be a strong point - if they actually worked convincingly well... 18:50
18:51 jpn left
for starters, if they weren't painfully, show-stopper kind of slow 18:51
18:52 jpn joined
or, something that I think both looks terrible and can cause actual problems with grammars 18:52
why do tokens/rules/regexes (some common name for them?) just randomly share a scope with all possible methods that particular grammar has for any reason? 18:53
they probably could be methods under the hood without sharing the namespace
relatively recent related issue: github.com/rakudo/rakudo/issues/5443 18:55
neither pure, nor practical 18:56
librasteve okaaay - we all would like to improve some things ... but you catch more flies with honey than vinegar 18:57
my question is what messages can we confidently use to attract more converts?
18:58 jpn left
[the only rule is that we should not wait for new or improved features ...] 18:58
nemokosch had I known the answer to that question, I wouldn't have asked it so many times, almost desperately, whether this is a serious project or just people hanging out and doing what they feel like... 18:59
librasteve lets say we want to do PR - what would you write on the brochure? 19:00
nemokosch I mean, the syntax is nice I'd say... but how many people can you convince with that - and moreover, what kind of people 19:02
or there is this thing that much like OG Perl, Raku can be seen as a safer and more productive Shell 19:03
but then again, those who use Shell usually have some platform constraint 😬
(who in the right mind would use it otherwise anyway)
librasteve what is OG?
nemokosch "original gangsta" iirc 19:04
www.urbandictionary.com/define.php?term=OG 🧐 19:05
librasteve bash subreddit has 61.7k users (raku is 1,355) --- thats 45.535055:1 19:08
maybe we should have some messages aimed at the shell creatures 19:09
nemokosch I also kinda think that Raku could be a good first language, regardless of its massive size, exactly because the "write-only" nature can be used for benefit 19:10
but even that can only work if there is an aim in the first place, and there is some willingness to do "favors" to this goal
19:11 cleo joined
librasteve we agree the aim(get some converts) 19:11
now we need sub-aims(from where, how) 19:12
its a self-referential loop since "from where" depends on "unique selling points" 19:14
so you want to go after shell and newbie afaict??
19:18 jpn joined 19:23 jpn left
ok -- i must jump -- thanks for the constructive thoughts -- I agree that shell and newbie are two good potential audiences to interest in raku, and I also think that Grammars are very cool as you mention (makes notes...) 19:26
ok -- i must jump -- thanks for the constructive thoughts -- I agree that shell and newbie are two good potential audiences to interest in raku, and I also think that Grammars are very cool as you mention (makes notes...) 19:27
19:30 jpn joined 19:37 jpn left
m: sub prefix:<ℕ>($s) {sum univals $s}; say ℕ"3½"; 19:39
evalable6 3.5
Raku eval 3.5
lizmat librasteve: found what is breaking 3½ in RakuAST... patch coming soon 19:40
m: say Q|3½|.AST.EVAL # librasteve 20:12
camelia 3.5
lizmat m: say Q|6²/₃|.AST.EVAL
camelia 6.666667 20:13
20:13 justTesting is now known as justThanks 20:18 jpn joined 20:25 dbonnafo joined 20:49 kylese left 20:50 jpn left, kylese joined 20:52 constxqt left 20:54 kylese_ joined, kylese left 21:04 kylese_ left 21:05 kylese joined
librasteve these are methods of class Grammar docs.raku.org/language/grammars#Cr...g_grammars 21:05
nemokosch ^ 21:06
feels like a bad excuse 21:07
librasteve lizmat: that's great .... thanks!
feels like a good design - grammar is a loaded synonym for 'class', regex, token and rule are loaded synonyms for 'method' 21:11
the result is a very slick and usable Grammar capability that is built off the core class model
nemokosch I mean, both the ends and the means seem wrong
I don't think it's intuitive whatsoever that something more or less declarative, having its own slang and all, like these grammar components are, are simply registered as methods at a public interface level 21:12
and they cause very actual and bizarre name collisions 21:13
librasteve personally I would like to mix these things (eg. tokens and rules) according to the properties I need within the same namespace
nemokosch a user should never ever have to worry about class inheritance and method names when finding names for grammar components
21:14 constxqt joined
and it seems really simple to keep them separate, like with operators... 21:14
just use some "adverbial" prefix
librasteve on the contrary, a user should be able to inherit and compose these things with their general counterparts
nemokosch yes, perhaps in the separate namespace 21:15
librasteve well they are not operators, they are specialized class and methods
nemokosch but definitely not in the usual method namespace, no
I meant a separate thing like with operators, not literal operators 21:16
like there is infix:<blah> or sym:<stuff> or trait_mod:<of>
idk, grammar:<whatever>
if somebody wants to call them as methods so badly
librasteve so you now want another mechanism between operators and classes just for grammars - but the whole idea of raku is to reuse building blocks and surely we want to keep the already large zoo of the things to a limited size 21:18
21:18 constxqt left
nemokosch I mean, haven't you understood what I said 21:19
the current situation is bad
librasteve you just have to learn that these are methods that share a namespace, and then act accordingly
nemokosch if it costs something new to fix it, so be it
a name collision between Any.print and the character set <print> should not be acceptable really
librasteve you do not seem to understand that I think that the grammar design is good 21:20
nemokosch because I think there is an apparent problem that just killed it and like end of the story...
to me, this is like 2+2
ugexe it would be a bit better if there was a warning or some such, but it is hard to expect the user to know all methods so they can decide what to name their own 21:21
nemokosch apparent theoretical problem causing real damage, no need to "negotiate" it...
librasteve you are thinking about a different thing
ugexe i remember naming a rule or something 'from', and it took awhile to figure out why it wasn't working because it was changing how the grammar itself worked 21:23
nemokosch oh yes, some names are actually more hideous and more damaging, like probably "from" in this case
"print" is almost innocent compared to that
with "print", the funny thing is that <print> is supposedly literally a built-in that name conflicts with another built-in... 21:25
ugexe github.com/ugexe/Raku-Grammar--HTT...a992388f27 21:26
github.com/Raku/nqp/pull/367 21:27
nemokosch I really just think this phenomenon is too bad too obviously to be excused, like one doesn't just release something in this condition... 21:28
librasteve the perfect is the enemy of the good 21:29
21:29 constxqt joined
nemokosch I mean, there is something, maybe we can call it "professional pride" 21:30
I really can't help but wonder with something like this
somebody did it and was like "it's alright, good enough" 21:31
why did that happen in the first place, and why does everybody need to bear with the consequences?
librasteve btw I would support a change that moved these to a different namespace ... and now I have a better understanding of your point, I suppose I agree ... but to have a warning would be a very good step in this direction
I think that raku is a very ambitious project that has struggled to achieve it potential and get wider support 21:33
21:33 constxqt left
nemokosch perhaps but the question is really also what defines the community or what the broader aim is 21:34
ugexe I wonder if changing the internal token uses from <from> to like <Grammar::from> would just work
librasteve that the team did not foresee this issue ( that I took some time to grok ) I do not think makes it fair to say that what we have today is unreleasable shit 21:35
nemokosch as you can see, this has caused problems for a pretty long time
librasteve there was a lot of things to do and a lot of things were done - so perhaps there are still more things to do (btw I was not there)
nemokosch and I think one would really notice it after any serious use of grammars... 21:36
I can actually imagine that the very grammar of Raku in Rakudo needs to pay attention to this some way
ugexe I'm not sure if it wasn't foreseen. it might just be a side effect of implementing something in the most consistent way (which is often easier to reason about in that there are less "rules" to remember). For example currently we can reason about classes/actions just being classes and working the same. That seems like a very Larry way to think 21:37
codesections ugexe: Yeah, I was thinking something similar. In general, if someone *really* needs to call a particular object's method (e.g., Any.elems) instead of the method that has overidden that method, then Raku has syntax for that
librasteve these are modest technical issues that can be solved if there are enough people who come on board ... but the gorilla in the room is that there are not really enough people - either building or consuming
<Grammar::from> ++ 21:38
codesections (e.g., 42.Any::elems)
ugexe yeah, but the user still has to know to do that
if the internals used Grammar::from it wouldn't matter
at least for the cases of e.g. to and from 21:39
librasteve m: say 42.Any::elems;
evalable6 1
Raku eval 1
codesections No, yeah, I was agreeing with you that the internalls should change
The internal code was the "someone" that really wants to call Match::from
ugexe 👍 21:40
codesections (And it would be Match::from, not Grammar::from) 21:42
librasteve real world complex projects often decide that it is a good trade off to release an MVP despite the known limitations in order to get the product to market and to build market share
actually I think that raku has been quite conservative in this regard and I believe that the existential problem we face is having not yet achieved product-market fit 21:43
we all can blow hard here about +/- this or that feature/syntax but (almost) nobosy gives a toss 21:44
nemokosch i feel it's not really a matter of mere luck and some big investor stepping on the right trace 21:45
librasteve "you are the third person today to tell me that they will not switch to raku because the Grammar method namespace is shared"
nemokosch it's a matter of attitude, so to speak
librasteve this is nothing to do with investor / finance 21:46
nemokosch Raku has been treated as a research project to a large extent, let's be honest
librasteve you mean like open AI? 21:47
21:47 tea3po joined
nemokosch where people get to bike-shed and try out all the things they want, feeling little responsibility or entitlement... 21:47
not really making... any sort of decisions 21:48
not even wrong ones
not owning up to a professional decision process
it's as if I challenged Spotify with my hobby Discord music bot 21:49
librasteve first I would say that raku has had very little people trying out all the things since Larry set out the language deisgn pretty much complete many years back (I can name many features that have been skipped0
nemokosch My hobby Discord music bot has its place in the universe, sure, I wouldn't even say it's bad, I try my best, after all
librasteve I challenge you to name one thing in raku that was not in the synopses 21:50
nemokosch but it doesn't exist in the same category of things as Spotify
21:50 teatwo left
codesections nemokosch: the consensus we all just reached is that you're correct that the current behavior is a problem; ugexe and I were discussing what the best fix is. This is *not* an example of anyone insisting that the status quo is perfect 21:50
nemokosch and I wouldn't insist on rambling on about this topic 21:51
it's really just I wanted to clarify that I don't think most of the comparisons we could make to so-called mainstream languages would have a solid basis
because they first set a goal and invested into it, in a way a company works 21:52
librasteve codesections: I see that you guys are stepping in (tx!) - there is a long list of todos and I am happy to see the team rally round when one of us has a concern to tadjust the priority and bring this to the top of the list
nemokosch and that's why they could get support later on
librasteve nemokosch: you state that other teams have invested upfront - I argue that the raku core has and is invested their time to get here - and the goal was clear (the synopses) 21:54
the biggest issue was the goal was very high and the investment / team was comparitively small
nemokosch the only "romanticized" successful language (in recent times) I can think of is Julia. And even Julia had a very specific niche: creating a fast ultra-high level language for data science stuff
librasteve the bad news is that raku / perl6 was therefore 15 years late 21:55
nemokosch the rest are opinionated, sometimes outright ugly languages
Python, Rust, Go
Okay, Swift is kind of a lax language from what I heard 21:56
but it is The Apple Language
librasteve yes, well the synopses are opinionated and huge - but the team (not me) has got 80-90% there
I agree that Swift is fairly close to raku likely since they also copied some perlishness - blah blah concurrency, unicode - BUT already they hit the limits of LLVM 21:57
so, right now all we have is a working MVP, enough folks to know their way around and make incremental progress 22:00
"We few, we happy few, we band of brothers"
we even agree on the aim, right?
22:01 jpn joined
nemokosch yes, perhaps 22:01
and new people are pretty much always required, for any goal, that much is for sure 22:02
even if we don't aim for the moon, just to kind of establish some "cult" stuff
codesections Issue comment summarizing our prior discussion: github.com/rakudo/rakudo/issues/54...1802750445 22:04
Thanks to nemokosch for bringing this up
nemokosch by the way, I for one really liked your talk a while ago, perhaps it was on FOSDEM 22:06
the one about how FOSS projects differ from enterprise projects and how this might resonate with different languages 22:07
22:07 jpn left
it's really good to think out of the box like that in general 22:07
22:13 dbonnafo left 22:30 coleman left 22:31 coleman joined 22:41 jpn joined 22:42 constxqt joined 22:44 lichtkind left 22:45 sena_kun left 22:46 jpn left 22:49 constxqt left 22:52 jpn joined 22:57 jpn left 23:07 constxqt joined 23:36 Sgeo joined 23:37 jpn joined 23:41 jpn left 23:43 jrjsmrtn left 23:44 tea3po left, tea3po joined, kjp left 23:48 teatwo joined 23:50 jrjsmrtn joined 23:51 tea3po left 23:56 jrjsmrtn left 23:58 jrjsmrtn 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!