🦋 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:08 reportable6 left, reportable6 joined 00:39 frost joined 01:39 linkable6 left, evalable6 left 01:42 evalable6 joined, linkable6 joined 01:51 kjp left 01:58 kjp joined 03:25 statisfiable6 left, releasable6 left, nativecallable6 left, tellable6 left, sourceable6 left, greppable6 left, shareable6 left, linkable6 left, bisectable6 left, committable6 left, notable6 left, coverable6 left, unicodable6 left, reportable6 left, evalable6 left, quotable6 left, benchable6 left, bloatable6 left 03:26 unicodable6 joined, bisectable6 joined, sourceable6 joined, releasable6 joined, committable6 joined 03:27 evalable6 joined, linkable6 joined, greppable6 joined, shareable6 joined, coverable6 joined, tellable6 joined, notable6 joined, benchable6 joined 03:28 nativecallable6 joined, reportable6 joined, quotable6 joined, bloatable6 joined, statisfiable6 joined 03:37 frost left 04:28 zostay left, maettu left, JRaspass left, maettu joined, zostay joined, JRaspass joined 04:41 Altai-man joined 04:44 sena_kun left 05:44 tellable6 left, quotable6 left, releasable6 left, greppable6 left, evalable6 left, nativecallable6 left, shareable6 left, notable6 left, statisfiable6 left, reportable6 left, bisectable6 left, bloatable6 left, unicodable6 left, sourceable6 left, committable6 left, coverable6 left, linkable6 left, benchable6 left, quotable6 joined, releasable6 joined, bisectable6 joined 05:45 unicodable6 joined, bloatable6 joined, tellable6 joined, sourceable6 joined, shareable6 joined 05:46 greppable6 joined, benchable6 joined, evalable6 joined, reportable6 joined, nativecallable6 joined, statisfiable6 joined, committable6 joined, coverable6 joined, linkable6 joined 05:47 notable6 joined 06:08 reportable6 left 06:10 reportable6 joined
Geth rakudo/rakuast: 4 commits pushed by (Stefan Seifert)++ 06:48
06:59 JRaspass left, JRaspass joined 08:16 nine left 08:17 nine joined 08:27 |Tux| joined, Tux__ joined
lizmat Files=1353, Tests=117195, 297 wallclock secs (36.20 usr 10.00 sys + 4095.85 cusr 341.47 csys = 4483.52 CPU) 08:30
08:34 Tux__ left 08:52 frost joined
lizmat notable6: weekly 09:16
notable6 lizmat, 1 note: 2022-05-02T08:19:14Z <MasterDuke>: marketplace.visualstudio.com/items...-navigator
lizmat notable6: weekly reset
notable6 lizmat, Moved existing notes to “weekly_2022-05-02T09:16:35Z”
10:14 Altai-man left 10:15 Altai-man joined
|Tux| Rakudo v2022.04-32-g74a60a961 (v6.d) on MoarVM 2022.04-1-g4e2eab056
csv-ip5xs0.774 - 0.859
csv-ip5xs-205.066 - 5.081
csv-parser3.665 - 3.853
csv-test-xs-200.400 - 0.402
test6.447 - 6.453
test-t1.397 - 1.430
test-t --race0.828 - 0.864
test-t-2021.029 - 21.603
test-t-20 --race6.344 - 6.423
 10:37
10:42 sena_kun joined 10:51 frost left, frost joined
Geth problem-solving: e5b8cbf16d | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | .github/CODEOWNERS
Remove self as owner of that section

I can no longer claim responsibility for the documentation repo *de facto*. It's only sensible to remove myself from here too.		 11:08
problem-solving: 894e41f708 | (Elizabeth Mattijsen)++ | .github/CODEOWNERS
Fix formatting in CODEOWNERS
 11:09
12:01 frost left 12:07 reportable6 left 12:08 reportable6 joined 12:37 frost joined
Geth rakudo: a84e16849d | (Elizabeth Mattijsen)++ | src/Perl6/World.nqp
Remove superfluous return statements

When processing a phaser in your code.		 12:47
13:03 frost left 13:04 carlmasak joined
carlmasak ahoy, #raku-dev 13:05
tellable6 2022-01-30T22:29:00Z #raku-dev <tonyo> .tell carlmasak if you haven't, check out haskell's package management. go's isn't great, there are a lot of problems with the way go.mod works, particularly when you're doing stuff inside of containers. haskell's is
2022-01-30T22:29:00Z #raku-dev <tonyo> .tell carlmasak pretty great but also v picky
carlmasak hm
way I understand it, Haskell isn't centralized enough to have _one_ package management 13:06
13:07 shareable6 left
japhb o/ carlmasak 13:07
carlmasak japhb \o 13:08
japhb What's news from your corner of the 'verse? 13:09
carlmasak .tell tonyo the thing that would make me consider Haskell's package management a significant step up from Go's isn't some technicalities around go.mod, but how well it solves the "stable dependencies" problem.
tellable6 carlmasak, I'll pass your message to tonyo 13:10
13:10 shareable6 joined
carlmasak japhb: not much. we've had some interesting experiences with more covid cases here, but fortunately not so many in my city. 13:10
japhb: right now I have a few days off around Labor's Day -- going to use that to code up some hobby/dream projects ;) 13:11
japhb :-/ Never good news to see a Covid resurgence.
Ah, sounds like fun!
carlmasak it's more of a surgence, not a resurgence 13:12
unless you count Wuhan and Hong Kong, both of which you could, I guess :)
japhb I think that would be falling into the "All countries I'm not in are small" trap 13:13
carlmasak haha
no, I mean, we've been blessed here with two years of no covid. I know that sounds crazy, and hard to believe
japhb Wow, that's actually quite impressive 13:14
carlmasak yeah. it took a lot of work, though
basically, you can turn a nanny state to good use in a crisis like this. all the infrastructure for tracking and speedy quarantines is already there 13:15
and then there was Shanghai last month. they were like "hah, we're Shanghai, we got this". but -- surprise twist -- they didn't 13:16
[Coke] ... trying to use raku to run the equiv of "start google.com" from a raku script. I suspect I might need to actually launch 'cmd' and pass args; anyone done this?
japhb I can imagine. (But only imagine, since our local area tried very hard to keep the Covid cases down, but Silicon Valley is such a giant intersection of people from across the planet even strict measures couldn't hold it back.
[Coke] (for windows, obvs.)
oops. wrong window 13:17
carlmasak japhb: Sweden was like "oh, you can't actually stop a virus. individual citizens are welcome to try". the only saving grace is that the population is small and not so dense -- otherwise it would have been a much bigger failure than it was. 13:20
but enough about covid! :D
I wanted to say that I think I grok Harper's "abstract binding trees" now.
wasn't all that difficult, in the end 13:21
japhb Yep, quite the topic switch that ....
carlmasak: You merely needed to reach enlightenment first?>
carlmasak that has applications for macros, I believe, although Harper himself doesn't use it that way 13:22
well, I found out about them a year or so ago -- and only recently did I start reading PFPL
there's something about the way Harper writes (and talks, in the courses he gives) that makes you feel this guy knows what he's on about. like there's a One True Way to do things, but unfortunately people are mostly deviating from that 13:23
I know that's not a very Perlish notion ;)
that's more like something GvM would say
japhb Or one of my math profs in college 13:25
carlmasak here's the super-short summary of abstract binding trees ("abts"): imagine there's a kind of pointer/link between the use of a variable and its "binder" (declaration site). now forget all the symbolic names, and just keep the pointer structure itself. that's abts
if this sounds like "terms modulo alpha renaming", that's exactly it
japhb Sounds like a long way around saying "You can do this without the extra level of indirection, you know." 13:28
carlmasak japhb: yes! I think Bob Harper is essentially a math prof, but for programming languages :D
japhb: I think what I like about him right not (and this might change, I guess) is that his theories (in the sense of "explanations of the world") feel like they have predictive power. as in, what he's saying isn't just strong opinions, but strong opinions backed by working models of computation and typing 13:31
japhb :-) 13:32
carlmasak I'm mulling over his (scathing) indictment of dynamic languages 13:33
japhb 🙄 13:42
carlmasak japhb: partly because I don't agree with it, at least not fully. but it's like he's arguing for it convincingly _within the framework he set up_. 13:43
the short story is, dynamic typing doesn't mean "no types", it means "one big type". (which, fair enough.) but that in turn means that a lot of actual type checking has to be done at runtime. also every time you construct a new value, you have to add a "type tag" to it. both of those things end up harming performance at runtime. 13:45
japhb It's at this point in such discussions that I pull out the "shine a warm light on your DRAM and suddenly you've invalidated all the " 13:49
'proofs' that the JVM has made about your code"
argument 13:50
carlmasak oh, you'll have to step me through that one. literally shining a warm light on the DRAM?
japhb Yeah, lemme see if I can find it
carlmasak does that... change the bits...?
ok, so your arguments is basically "that runtime slowdown the dynamic language gives you is _necessary_, and you're foolish for believing otherwise" ? interesting. 13:51
japhb www.cs.princeton.edu/~appel/papers/memerr.pdf 13:52
Gotta love a paper with the line "Since we lacked the time or inclination to learn the oil drilling trade ..." 13:53
13:53 [Coke] left
japhb carlmasak: Yeah, you can force a bit flip with basic infrared 13:54
carlmasak oh
japhb And with some care, break out of the sandbox
So my point is that we actually have proof by example that mathematical proofs about types made before execution actually don't stick. Now mind you, I'm not saying every VM is going to do "the right thing" faced with bit flips. But the assumption that you can make proofs at compile time and have them valid throughout run time is just not true. 13:56
13:56 [Coke] joined
japhb So then it becomes a question of just how careful you want to be ... since you can get a null pointer from a valid one via bit flips, do you throw out all the useful null check elision? I'd argue not (in favor of recovering if it *does* happen), but the sanctity of mathematical proof doesn't survive reality. 13:58
(With current technology, at least.)
13:58 carlmasak left
japhb ... all of which is to say, this is part of why I stopped worrying about whether dynamic languages are "less than ideal", because meh, so is reality. 13:59
13:59 carlmasak joined
carlmasak argh. I apologies for my spotty connection. comes with the territory -- literally 13:59
[Coke] carlmasak: oh hai 14:00
[Coke] also returning from a spotty internet connection... due to 5g for home being spotty here in suburbia.
japhb carlmasak: Well, I guess that's what logs are for ... 14:01
carlmasak [Coke]: hi. I'm in burbia. that's not the problem here :)
.oO( great walls of fire! )
 14:02
japhb Goodness Gracious!
14:06 carlmasak left 14:12 carlmasak joined
carlmasak someone mentioned logs...? 14:13
where are they nowadays?
sena_kun carlmasak, logs.liz.nl/raku-dev/2022-05-02.html 14:14
carlmasak gracias 14:15
japhb: your "reality is less than ideal" comment is what I missed. yes, makes sense. 14:22
I'm not sure it's all that much of an either-or situation, though. 14:23
I can feel the attraction _both_ of the proof-like certainty afforded by typing, and of the lightweight expressiveness of omitting types (which goes further than just "let the inferencer add type annotations") 14:26
I guess what I'm looking for is a glorious synthesis 14:29
I'm a very visual person. I think of this as programs having three colors: white, if a type system would say it's good; grey if a type system says "bad" but it's actually good; and black if it's actually bad 14:38
the grey part is due to things like undecidability, and type systems erring on the side of simplicity 14:39
I think the thing the "statically typed" people get wrong is to dismiss the grey part as if it were automatically the black part 14:40
but the thing the "dynamically typed" people get wrong is to act not-at-all interested in the black part, which can actually help provide early feedback about program errors without having to discover them at runtime 14:41
nine Also irclogs.raku.org 14:43
carlmasak arigato
japhb carlmasak: This is part of why a gradually-typed language like Raku appeals to me -- I can spend effort proportional to my desire to detect additional common cases of programmer error. 14:44
For me the synthesis is *having* a type system without being *beholden to it* 14:45
carlmasak japhb: granted, but -- the term "gradually-typed" is too narrow to apply to Raku. sorry to say that
japhb Do you have a better term? 14:46
carlmasak Raku's type system is steadfastly dynamic. it _could_ be made truly gradual, but... that'd take a rather big change to the spec
and to Rakudo
japhb Could you expand on that a bit? 14:47
carlmasak yes, I'm trying to now
japhb ah
carlmasak give me a few moments with camelia
m: my Int $x = "five"; say $x
camelia Type check failed in assignment to $x; expected Int but got Str ("five")
in block <unit> at <tmp> line 1
carlmasak that's a runtime error, no? 14:48
I know we keep saying "well, we _could_ make that a compile-time error, if we wanted, but that would inevitably weigh down on compile times"
it's that (understandably) attitude that makes it a dynamic language
understandable* 14:49
gradual typing is "you get what you pay for" -- in the sense that, the more type annotations you put in, the more your program actually turns statically typed
Julia is the same way -- I consider it something of a missed opportunity in both Raku's and Julia's case 14:50
japhb carlmasak: Yes, and that's actually the case for sub calls, because of the "can this ever work" checks
carlmasak right
we're close, but not quite there
japhb And in both cases, you're talking about the *implementation* not the *language*. I grant that in previous Larry languages, those were the same thing. 14:51
carlmasak 100% static languages "never go wrong". the same guarantee for gradual languages say that when something _does_ go wrong, it's the fault of the untyped part of the code
japhb: no, I'm talking about the spec
japhb That claim bugs me. "Type correct" does not at all mean "semantically correct". One is a (tiny) subset of the other. 14:52
carlmasak fully agree
actually, the "never go wrong" claim is dodgy, as soon as you have simple things like division, which isn't defined when the denominator is zero 14:53
look, I'm not a statically-typed fanatic myself. that's at least half of my point here
japhb People have actually tried to prove (in the compiler) that the denominator can never be zero, but I agree.
nodnod
carlmasak I'm saying something like, we could actually be more truly gradual if we wanted. 14:54
japhb Fair.
carlmasak I'm not sure we ever will, because it'd require actually being a bit academic, which doesn't come easy to languages in the Perl family ;)
we "don't have axes to grind"
which I think is our way as a group to say that we're not ivory-tower obsessed with things like types 14:55
gradual typing is not a subset of static typing, but it's a heck of a lot closer to static typing than it is to dynamic typing 14:56
japhb (Funny that Audrey worked on PUGS to study TAPL)
carlmasak I actually remember that detail! I'm a Perl 6 historian, you know :D
and TAPL was written by Benjamin Pierce, who studied under Robert Harper 14:57
japhb Wheee, full circle.
carlmasak I haven't read all of TAPL, but PFPL reminds me quite a lot of it
both are fueled by operational semantics (with types)
safety = preservation + progress, and all that good stuff 14:58
japhb Tangent: A couple years ago, this book was making the rounds: mitpress.mit.edu/books/engineering-safer-world 15:00
Watching how it was applied, there seemed to be a fair number of people who read it as "How many ways can things individually go wrong *without* the whole system melting down?" 15:01
carlmasak ooh -- immediately follow-up question: is there anything you can tell me about "systems thinking" that would make me not conclude it's some kind of nice-sounding mumbo-jumbo? 15:02
(not saying it is, just saying I'm not yet convinced either way)
immediate*
"we need to think in terms of systems" sounds very nice, of course. how does it improve on, say, reductionism? a system is the sum of its components and their interactions. 15:04
japhb Hmmm. I think because it's not natural for most programmers to think like they're trying to prevent Chernobyl- or Challenger-style epic disasters. Thinking that way is different and affects your brain in somewhat the way that learning a concatenative language does -- it just starts to stretch in new directions. And analyses of the failure modes that led to the previous disasters is rather instructive 15:05
in itself.
carlmasak fair enough 15:06
you're saying people have good intentions, and that's not always enough
I think I've been saying similar things in JavaScript courses for many years :P 15:07
japhb Well, actually that's a key point, I think: Truly *safe* systems (as opposed to "merely" reliable) are able to recover from inevitable failure; they have checks-and-balances built in. For example, a system that stays up 100% of the time but *could* be brought down by one guy flubbing a keystroke may be reliable, but it's not safe.
carlmasak it's always fun to see people's faces when they enter `0.1 + 0.2` into the JavaScript console
japhb Heh
carlmasak ok, I actually get that point. and I think I appreciate it 15:08
these days I'm not as 100% sold on TDD as I used to be, but I still like the idea of it
the idea being that you're kind of your own attacker along the way. you try to imagine all the ways not just to use the system under test, but to stress/abuse it, too
japhb There was a somewhat famous case of the code in the Apollo computers being designed to shed inputs in priority order when it got overloaded. And that functionality actually got used during an actual landing. And saved the mission. 15:09
carlmasak happy path; sad path; evil path
nice!
not just stories about failures, but about successes
japhb nod
carlmasak recently I've been really interested in "design by contract", not so much as proposed by Eiffel, but as proposed by Racket 15:11
it seems to me it's connected to the whole gradual-types story, but in an interesting and non-obvious way
japhb At Google it was getting a fair amount of traction from SREs looking at what paths (not just code paths, action paths of any sort including operations work) had no safety net. And discovering for example that someone could push config that was semantically but not syntactically invalid, and the server code might not check the semantics *before* overwriting the current config. And thus shoot itself in 15:12
carlmasak "design by contract" is about module boundaries, and about predicates, which are more fine-grained and more runtime-grounded than types
japhb the foot.
carlmasak ooh -- sounds a lot like the kind of work I ended up doing as a team lead in some of the best projects I was in at Edument 15:13
japhb :-)
carlmasak basically, when you have things running smoothly enough, you get time over to optimize for things like that
answering the question "where are we losing productivity due to not enough semantic safety nets?"
japhb nodnod
carlmasak the answers that turn up are always really interesting
linters are good, but they are sooooo stupid! 15:14
japhb Heh, indeed
carlmasak they only care about surface stuff
I would give an arm and a leg for a _semantic_ linter
...which also brings us full circle, because I think that's what type systems should really be about. but the type systems are also far too narrow-minded
japhb
.oO( Looks at arm and leg. Looks at semantic linter. *thinks very hard* )
 15:15
carlmasak haha
like I tell my 7-year-old, "it's an expression" 15:16
japhb :-D
carlmasak the gradual-typing posse have reached an interesting preliminary result, by the way: "gradual typing is dead" 15:17
15:17 evalable6 left, linkable6 left
carlmasak as in, it's too costly to defend the static/dynamic boundary with runtime type checking 15:17
japhb Shades of Gödel there 15:18
Ah, got it
15:18 linkable6 joined 15:19 evalable6 joined
carlmasak the result has been cast somewhat in doubt, but it's fairly strong -- the static parts are paying a sizeable "toll" on runtime-checking values coming in 15:19
japhb I mean, I am *regularly* struck by just how much my Raku programs can do before a frame refresh. And at the same time, there are papers like the one brought up in #moarvm last week that basically say "The cost of GC is *way* worse than people have been thinking!" and yet -- I wouldn't go back to using a non-managed language for anything but the deepest layers of whatever stack I'm working on. 15:21
carlmasak *nod*
people say Java brought GC to the people, but before that there were Perl, awk, and Lisp 15:22
japhb TRUE 15:23
carlmasak :D
japhb One of the things that gets me about people trying to tweak a few percent more performance out of a compiler is that we regularly lose way more performance than that when a security researcher discovers a way to catch the CPU designers cheating. 15:24
(This from someone who has at least half a bookshelf of books on assembly languages and micro-optimization) 15:25
carlmasak actually, manual memory management vs GC is structurally fairly similar to static typing vs dynamic typing 15:26
japhb From my point of view, what the CPU designers did for around a decade after I left university was make dynamic languages fast enough for me to stop caring about day-to-day stuff.
carlmasak I believe that's true -- but... 15:29
...that's still too much of a dynamic-languages perspective for me. I'm so spoiled, I want static help from a good type checker _and_ the freedom afforded by dynamic typing
it's all about that grey area in the middle. the type checker can warn me about things, and I'm free to ignore them and run the program anyway
15:29 carlmasak left
japhb :-) 15:30
15:32 carlmasak joined
carlmasak this kind of assumes the modern setup of an IDE which can give you information/warnings at a quicker clip than just compilation cycles 15:33
japhb nodnod 15:36
carlmasak I believe Raku _could_ be that language. I believe it isn't, right now, by spec. the nicest thing I could say is that it's probably compatible with such a vision. 15:38
as in, someone who wanted to really push the gradual-typing angle all the way would find Raku a fairly decent starting point. 15:39
japhb: I think I was like you at some point, calling Perl 6 a gradually-typed language. but Raku is only gradually typed from a dynamically-biased perspective. 15:41
or, maybe a more fair way to phrase it is this: "gradually typed" means two things -- it means one thing to the static people and another thing to the dynamic people 15:42
Raku is "gradually typed" according to the definition prevalent among the dynamic people
unfortunately, it's the static people's definition that's the interesting one. they have evolved a thing called the "gradual guarantee" -- it says that removing type annotations should never make your program fail. I seriously dig that property. 15:43
Raku currently does not have that property. I don't have immediate proof. 15:44
15:57 |Tux| left
carlmasak for anyone who's interested, this paper gives the definition of "gradual guarantee": drops.dagstuhl.de/opus/volltexte/2...pdf/21.pdf 16:01
japhb Unless I misunderstand you, Raku fails that guarantee immediately due to the several ways that multi dispatch happens. (Of course, I haven't read the paper yet, so I don't know if I'm misunderstanding what they mean.) 16:08
16:09 |Tux| joined
carlmasak I'm not sure, but let's say that's why 16:10
earlier today, someone on a group I'm on pointed me to a paper they wrote about how "OO-style" code and "FP-style" code can be automatically converted into each other. I haven't read their paper in full yet, but... 16:12
...the question I want to ask them is, if that's true, that there's always a bijection between these two ways of writing things, then isn't there also a way to write code which straddles those two styles? 16:13
something more like Lisp's CLOS or Julia's generic functions
in FP, functions are primary. in OOP, classes are primary. in CLOS/Julia, generic functions are primary; these could best be described as a kind of table-join type between classes and functions 16:15
Geth ¦ problem-solving: lizmat assigned to codesections Issue Taking responsibility for Raku Documentation issues github.com/Raku/problem-solving/issues/324 16:38
¦ problem-solving: lizmat unassigned from codesections Issue Taking responsibility for Raku Documentation issues github.com/Raku/problem-solving/issues/324
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/05/02/2022-18-period/ 16:59
carlmasak lizmat: nice! hi! 17:03
lizmat carlmasak o.
o/ rather :-)
carlmasak :)
carlmasak was wondering whether the '.' was a fist or something
lizmat nope, . just adjacent to / on my keyboard 17:04
carlmasak "the keys are like right next to each other"
lizmat so that's quite a lot of discussion while I was away cycling :-) 17:05
carlmasak I have a few days off, and I decided to show up here :)
lizmat nice to see you here again... 17:13
and knowing you 3 (4?) are all healthy :-)
carlmasak 3. and yes :) 17:20
hope that goes for both of you as well. 17:21
lizmat we had a little bout with Covid... but only a little bit 17:22
cycled 40km today, so there's that :)
carlmasak great 17:23
all of my original family members in Sweden have had "a little bout" too at this point -- it seems to be more or less inevitable
lizmat we also still have no idea where we picked it up 17:24
we had someone staying for use for a few months, and they tested positive at one point (and they had been out far less than Wendy and I did)
carlmasak I take it as a really good reason to stay healthy and exercise, something I'm generally bad at 17:25
lizmat a week later Wendy and I also tested positive...
carlmasak so that when it finally comes to these parts, at least my body has a good defense
lizmat well, I guess my physical condition (albeit pretty overweight) is compensated for by ~ 800km / month on a bicycle 17:26
carlmasak you do seem to be good at that, yes
I walk to work and back home every day, but that's not enough
lizmat that would not be enough for me either, and a *lot* less :-) 17:27
carlmasak during this 5-day vacation, I've taken up running (again). that feels pretty good.
17:28 sena_kun left
carlmasak will try to keep something like that going when work resumes 17:28
like it or not, we're stuck with physical bodies for now, and have to tend to their upkeep
lizmat indeed.... :-) 17:31
carlmasak lizmat: glad to hear you and wendy have made it through the covid barrier seemingly unscathed 17:40
17:40 carlmasak left
nine I think, the trick is to find some sports or exercises that you can actually enjoy (at least after getting used to them) 17:44
jdv kinda same as $work/$jib 17:59
gah. $job.
18:06 reportable6 left 18:07 reportable6 joined
drakonis lizmat: could you amend the visual studio support paragraph to visual studio code? 18:11
lizmat ah, have I misunderstood? 18:12
drakonis: like this? (please reload) 18:13
drakonis it hasnt updated here yet 18:14
lizmat it now says: "In related news, bscan has announced Raku Programming Language support in Visual Studio Code." 18:16
drakonis ah, cool. 18:18
works for me
lizmat :-) 18:24
18:31 rypervenche left 18:36 rypervenche joined
drakonis it is quite nice to have an lsp implementation 18:38
its nice to not be locked to comma for editing
lizmat is locked in vi for editing :-) 18:41
jdv is a lazy, stuck vi'er 18:47
lizmat
.oO( Stockholm Syndrome )
 18:48
I guess it was a more natural transition from WordStar to vi :-) 18:49
19:32 Altai-man left 19:33 sena_kun joined 20:21 sena_kun left 20:22 sena_kun joined 20:23 sena_kun joined
Geth rakudo/rakuast: cecd54ff94 | (Stefan Seifert)++ | src/Raku/ast/code.rakumod
Automatically set onlystar flag on onlystar routines
 20:56
Bscan🍺 I created the vscode Raku extension because I'm interested in learning Raku and didn't want to switch editors (not sure commaIDE does remote dev anyway, and I primarily use a linux VM with a Windows front-end). Hopefully it's useful to other people as well. 21:00
[Coke] bscan++ 21:09
SmokeMachine Bscan: Thank you very much for that! Just installed perlnavigator on my nvim and that's working perfectly! Next I'll install rakunavigator! :) 21:40
drakonis it is good to hear that there's interest in raku 21:43
from the perl community, that is.
timo it seems a little like overselling to say visual studio gets raku support when it's only vscode 21:50
japhb timo: Isn't vscode where most of Microsoft's effort is going for IDE work these days? 21:52
timo i 21:56
don't think so actually?
but i don't actually have any source for that claim
Bscan🍺 Vscode seems more popular. Maybe not for C/C++, but it's a great fit for Perl and Raku. insights.stackoverflow.com/survey/...llab-tools 21:58
Raku-navigator has far fewer features than the perl-navigator, but pull requests are welcome
drakonis raku weekly got updated to mention its actually vscode 22:00
timo ah good 22:01
i see now you already asked for this exact thing hours ago 22:02
Bscan🍺 smokemachine, if you have any feedback on either navigator, feel free to reach out. The Raku language server piece doesn't do much yet, but it's a start. 22:05
22:35 evalable6 left, linkable6 left 22:37 linkable6 joined 22:38 evalable6 joined 23:17 TempIRCLogger 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!