🦋 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:00
reportable6 left
00:03
reportable6 joined
00:35
kjp joined
00:43
Manifest0 left
01:04
xinming left
01:06
xinming joined
|
|||
rf | How's everyone doing today? | 01:21 | |
tea3po | I am well, ty for asking. You? | ||
rf | Good, just had an excellent dinner and some ice-cream :^) | 01:22 | |
Anton Antonov | @rf So, no more cinnamon rolls ?! | 01:33 | |
shmup | @ | 01:34 | |
rf | @Anton, no I ate them all D: | ||
01:37
frost joined
01:40
frost left
|
|||
Anton Antonov | @rf Of course you cook some new ones, no ? Also, do you know how to make ice-cream? | 01:42 | |
rf | I know how to make ice-cream but it is too much work, I am a lazy programmer after all | 01:43 | |
I think I am going to make cinnamon rolls a yearly thing, too many calories haha | 01:44 | ||
Anton Antonov | @rf I see. At this point I completely delegate cooking. When was doing my PhD, I considered spreading butter on bread cooking... | 01:47 | |
rf | Lol, what field did you study? I sure hope it wasn't culinary arts ;D | 01:48 | |
01:51
frost joined
|
|||
Anton Antonov | @rf Good point. My PhD is/was in Large Scale Air-Pollution Simulations. | 01:51 | |
rf | Nice that is a very interesting topic to cover | 01:53 | |
Anton Antonov | @rf Complex systems can be very "entertaining" : github.com/antononcube/SystemModeling . | 01:59 | |
02:00
frost left
|
|||
rf | Mathematica is interesting haha, I have never used it for anything useful though | 02:01 | |
Anton Antonov | Until 2014 I used Mathematica for type of scientific and mathematical modeling and/or data analysis. The corresponding "productized" versions in C++. Then I started doing the data analysis with R. I still do mathematical optimization and modeling with Mathematica; the corresponding productized versions in R or Python. | 02:06 | |
rf | Cool, maybe productized versions in Raku one day | 02:07 | |
Anton Antonov | @rf I doubt it. 🙂 | 02:09 | |
rf | Nemokosch, Template6 is kind of borked too with for loops not having the variable, for example: [% for foo in something %] [% foo.value %] [% end %] If something isn't set it simply prints foo.value | 02:11 | |
Anton ;( | |||
Anton Antonov | @rf I am writing a blog post about it. | 02:23 | |
rf | We can always dream | ||
Anton Antonov | @rf In color or black-&-white ? | 02:25 | |
rf | I think Raku is a fairly colorful language, so let's do color | 02:26 | |
Nemokosch | hm, shouldn't that throw one level up, if something is not set in the first place? | ||
rf | Not sure, but I have to do: [% if something %] [% for foo in something %] [% foo.value %] [% end %] [% end %] | 02:28 | |
to get around it | |||
Nemokosch | tbh I don't quite get why you would want to loop over something that doesn't even exist | 02:30 | |
rf | Well sometimes it will exist sometimes it wont I don't want to write a new template for both cirumstances lol | 02:37 | |
jdv | is Template6 worth it? i havent looked. but doesnt cro have some template thing or raku's interpolation is pretty awesome in the first place. | 02:39 | |
tellable6 | 2023-02-27T15:13:10Z #raku-dev <AlexDaniel> jdv that you can fix yourself :) github.com/Raku/whateverable/blob/...le.p6#L268 | ||
2023-02-27T15:21:39Z #raku-dev <AlexDaniel> jdv I patched releasable with the fix right on the server, but please correct it in the repo as well | |||
jdv | .tell AlexDaniel ok | 02:40 | |
tellable6 | jdv, I'll pass your message to AlexDaniel | ||
rf | jdv, I think it's OK, I'm using it for a fairly large project but there are some rough edges | 02:43 | |
Nemokosch | idk it seems a bit weird to not know what exists on top level lol | 02:44 | |
anyway | |||
m: for Nil -> $big-brain { say 'didgeridoo' } | |||
Raku eval | didgeridoo | ||
Nemokosch | KHM KHM | ||
the usual "strict workaround" won't do because even Nil can convert into a perfectly valid one-element array... | 02:45 | ||
m: for Empty -> $big-brain { say 'didgeridoo' } | 02:46 | ||
Raku eval | |||
Nemokosch | thank heavens | 02:47 | |
I wonder if the "strict lookup" could just always return Empty | 02:48 | ||
rf | That would work like a charm I think | 02:51 | |
Gotta head off the for the night, cya folks | 02:58 | ||
02:58
rf left
03:08
razetime joined
04:08
evalable6 left,
linkable6 left,
notable6 left,
quotable6 left,
statisfiable6 left,
reportable6 left,
nativecallable6 left,
benchable6 left,
squashable6 left,
coverable6 left,
shareable6 left,
bisectable6 left,
sourceable6 left,
committable6 left,
bloatable6 left,
releasable6 left,
greppable6 left,
unicodable6 left,
tellable6 left,
benchable6 joined,
greppable6 joined,
squashable6 joined,
quotable6 joined,
linkable6 joined,
committable6 joined
04:09
shareable6 joined,
coverable6 joined,
notable6 joined,
unicodable6 joined,
tellable6 joined,
bloatable6 joined,
sourceable6 joined
04:10
releasable6 joined,
bisectable6 joined,
reportable6 joined,
nativecallable6 joined
04:11
evalable6 joined,
statisfiable6 joined
05:11
statisfiable6 left,
tellable6 left,
notable6 left,
evalable6 left,
linkable6 left,
bloatable6 left,
squashable6 left,
unicodable6 left,
reportable6 left,
bisectable6 left,
releasable6 left,
quotable6 left,
benchable6 left,
notable6 joined
05:12
tellable6 joined,
linkable6 joined,
reportable6 joined,
bloatable6 joined,
statisfiable6 joined
05:13
releasable6 joined,
bisectable6 joined,
benchable6 joined
05:14
quotable6 joined,
evalable6 joined,
unicodable6 joined,
squashable6 joined
05:18
razetime left
05:31
razetime joined
06:00
reportable6 left
06:03
reportable6 joined
06:16
razetime left
06:47
teatwo joined
06:50
tea3po left
07:02
teatwo left
07:03
teatwo joined
07:06
xinming left
07:31
razetime joined
08:13
Sgeo left
08:27
ProperN[out] left
08:28
ProperNoun joined
09:09
Manifest0 joined
09:12
dakkar joined
09:14
razetime left
|
|||
Nemokosch | rf: I did the patch 😛 | 09:24 | |
09:35
nort left
10:35
unicodable6 left,
evalable6 left,
committable6 left,
linkable6 left,
sourceable6 left,
shareable6 left,
coverable6 left,
statisfiable6 left,
quotable6 left,
tellable6 left,
squashable6 left,
bisectable6 left,
benchable6 left,
releasable6 left,
notable6 left
10:36
unicodable6 joined,
tellable6 joined,
releasable6 joined,
notable6 joined,
quotable6 joined,
shareable6 joined
10:37
sourceable6 joined,
bisectable6 joined,
linkable6 joined,
squashable6 joined,
committable6 joined,
benchable6 joined,
coverable6 joined
10:38
evalable6 joined,
statisfiable6 joined
11:03
Johanna100 joined
|
|||
Johanna100 | I was trying to find a scripting language appropriate for my projects. I considered Guile but I find Scheme difficult to read and Guile doesn't build on MacOS without a hack (for some bizarre reason the build script depends on non-standard sed; the bug has been discussed in their mailing list but nobody thought MacOS was important enough to fix it, | 11:11 | |
and the barrier to entry for me to fix it myself is too high). Raku builds and tests without any problem whatsoever. Keep kicking butt guys | |||
11:20
thundergnat joined,
frost joined
|
|||
lizmat | Johanna100: we try :-) and the girls also :-) | 11:21 | |
11:21
frost left
|
|||
thundergnat | Glad it worked out for you. Raku still has a few rough edges here and there and the performance isn't where we would like it to be yet, but it is pretty usable for a large cross section of tasks. | 11:23 | |
11:25
thundergnat left
11:26
frost joined
11:28
frost left
|
|||
Nemokosch | seems like Guile is GNU software so maybe it's not surprising it comes with "non-standard sed" (I suppose gsed) | 11:29 | |
11:54
grondilu joined
12:00
reportable6 left
|
|||
Geth | Raku-Steering-Council/main: 79cdc3a435 | (Elizabeth Mattijsen)++ | minutes/20230218.md Add minutes of 18 Feb 2023 meeting |
12:01 | |
lizmat | seems this one fell through the cracks :-( | ||
12:03
reportable6 joined
|
|||
Nemokosch | will another weekly hit the net today? | 12:05 | |
lizmat | it's about to drop :-) | 12:07 | |
final proofreading as we speak :-) | 12:10 | ||
Nemokosch | 🥁 🥳 | 12:12 | |
lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/03/07/2023-10-toronto/ | 12:17 | |
12:25
exp joined
|
|||
exp | I'm trying to write a small script using explicitly sized integers, ie `my uint8 $a;`, all operations on $a return `Cannot invoke object of type 'NQPMu'`. Am I doing something idiotic or did this previously work? | 12:27 | |
2023.02 apparently, freshly built | 12:28 | ||
Nemokosch | you could give a snippet to bisectable6 | 12:30 | |
lizmat | exp: could you gist an example? | 12:31 | |
exp | lizmat: literally `my uint8 $a; say $a` | 12:33 | |
ooh actually, no | |||
lizmat | % raku -e 'my uint8 $a; say $a' | ||
0 | |||
exp | on one line it works | ||
on two lines it fails | |||
(the linebreak coming after the first ;) | |||
apologies for not noticing that | |||
lizmat | still cannot reproduce. can you make a gist ? | 12:34 | |
exp | is this sufficient? pastebin.mozilla.org/SXud5UhN | 12:35 | |
lizmat | ah, you're using the REPL | ||
exp | yes i failed to mention that sorry | ||
Nemokosch | then maybe it can be reproduced by some EVAL? | 12:36 | |
lizmat | the REPL has some known issues... I guess this is one more :-( | ||
exp | wow ok, that's a real shame | 12:37 | |
lizmat | yeah... the problem is that each line in the REPL is a separate EVAL | ||
with their own scope, and there are some issues specifically related to natives that don't pass on from one EVAL to the next | 12:38 | ||
exp | ah well, thank you for the fast answer lizmat | 12:39 | |
lizmat | you could try running with the RakuAST grammar by prefixing: RAKUDO_RAKUAST=1 | ||
so: $ RAKUDO_RAKUAST=1 raku | 12:40 | ||
at least the errors are a bit more understandable | |||
exp | yeah, at little improvement at least, i just implemented it in C so no big deal, just very surprising | ||
lizmat | I guess once we have RakuAST at a stage where the setting is also compiled with it, we will have an opportunity to fix the REPL in that respect | 12:41 | |
so no solution before the next release of Rakudo, I'm afraid | 12:42 | ||
12:49
derpydoo left
|
|||
Geth | doc/main: 1d11030921 | (Elizabeth Mattijsen)++ | doc/Type/DateTime.rakudoc Document DateTime.posix(:real) |
13:01 | |
13:02
derpydoo joined
|
|||
Nemokosch | is it possible to turn a string into a character group for regex? | 13:06 | |
if you know what I mean 👉 👈 | |||
Geth | doc/main: b3e0c1d99f | (Elizabeth Mattijsen)++ | 2 files Document Exception|Cool.Failure coercer |
13:07 | |
lizmat | you can with RakuAST | 13:09 | |
m: say Q|$_ ~~ / <[abcd]> /|.AST | 13:10 | ||
camelia | RakuAST::StatementList.new( RakuAST::Statement::Expression.new( expression => RakuAST::ApplyInfix.new( left => RakuAST::Var::Lexical.new("\$_"), infix => RakuAST::Infix.new("~~"), right => RakuAST::QuotedRegex.new(… |
||
lizmat | replace the "elements" arguments with $string.comb.List | ||
Nemokosch | what do I need to set to access it? | 13:12 | |
lizmat | you should copy the .AST output (well, as much as you need) | 13:13 | |
do the change to the elements argument | |||
call .EVAL on the ast, and you'll a regex that you can use? well, I think :-) | 13:14 | ||
also: assuming you're on HEAD | |||
specify either "use v6.e.PREVIEW" or "use experimental :rakuast" | |||
Nemokosch | I only get RakuAST::CompUnit.new 😦 | 13:15 | |
lizmat | gist ? | ||
Nemokosch | > raku -e 'use experimental :rakuast; say Q|$_ ~~ / <[abcd]> /|.AST' | ||
lizmat | then you're not on HEAD | 13:16 | |
m: say Q|$_ ~~ / <[abcd]> /|.AST | |||
camelia | RakuAST::StatementList.new( RakuAST::Statement::Expression.new( expression => RakuAST::ApplyInfix.new( left => RakuAST::Var::Lexical.new("\$_"), infix => RakuAST::Infix.new("~~"), right => RakuAST::QuotedRegex.new(… |
||
lizmat | you should get something like that ^^ | ||
Nemokosch | pfff | 13:17 | |
will the generated code run on 2023.02 at least? | 13:18 | ||
lizmat | there's a good chance it would | ||
13:21
rf joined
|
|||
Nemokosch | hm, okay, building HEAD | 13:21 | |
rf | Good morning folks | ||
Nemokosch | hello | 13:26 | |
lizmat | Nemokosch proof of concept: gist.github.com/lizmat/d1c090e8dcf...b1263f38d7 | 13:34 | |
Nemokosch | actually, I wanted to ask - what can you call EVAL on, and what can you expect to get back? | 13:36 | |
13:37
seekr joined
|
|||
rf | lizmat++ for the Weekly News :^) | 13:40 | |
lizmat | on HEAD, you can call EVAL on Cool and RakuAST::Node objects | ||
as a method | |||
as a sub you could already, but then you also need a "use MONKEY-SEE-NO-EVAL" | 13:41 | ||
grondilu | so, what is RakuAST status? Can we generate AST from arbitrary raku code now? | 13:56 | |
tellable6 | 2023-03-04T12:14:32Z #raku <guifa_> grondilu: you can use the NFC, NFD, NFKC, NFKD ops | ||
lizmat | grondilu: you can if you don't use features that haven't been implemented | ||
grondilu | is it documented somewhere? | 13:57 | |
lizmat | m: the Str.AST method will do that for you | ||
camelia | ===SORRY!=== Error while compiling <tmp> Two terms in a row at <tmp>:1 ------> the Str.AST⏏ method will do that for you expecting any of: infix infix stopper postfix statement end … |
||
lizmat | no, that's being worked on as we speak | ||
grondilu | 🤔 | 13:58 | |
from a Str? | |||
lizmat | there's a *lot* to document | ||
m: say Q|say "yes"|.AST | |||
camelia | RakuAST::StatementList.new( RakuAST::Statement::Expression.new( expression => RakuAST::Call::Name.new( name => RakuAST::Name.from-identifier("say"), args => RakuAST::ArgList.new( RakuAST::QuotedString.new( … |
||
grondilu | nice | ||
lizmat | see also the gist I just posted | ||
it creates a Regex object for you, that you can use in your code | 13:59 | ||
Anton Antonov | @grondilu Some of the current efforts of guifa use RakuAST — that code can be a learning point. | 14:00 | |
grondilu | what about the other way around? Everything is done through the RakuAST package (I'm assuming it's a package)? | ||
lizmat | there's a RakuAST package, but most classes inherit from RakuAST::Node | 14:01 | |
grondilu | m: print RakuAST | ||
camelia | ===SORRY!=== Error while compiling <tmp> Use of RakuAST is experimental; please 'use experimental :rakuast' at <tmp>:1 ------> print ⏏RakuAST expecting any of: argument list term |
||
grondilu | m: use experimental :rakuast; print RakuAST | ||
camelia | Use of uninitialized value of type RakuAST in string context. Methods .^name, .raku, .gist, or .say can be used to stringify it to something meaningful. in block <unit> at <tmp> line 1 |
||
grondilu | m: use experimental :rakuast; print RakuAST.raku | ||
camelia | RakuAST | ||
grondilu | I see | ||
lizmat | you will HEAD to get the full .raku support | 14:02 | |
that didn't make it to the 2023.02 release | |||
grondilu | well, I guess soon I will not have any more excuse not to try to implement google's protobuf. Some time ago you guys told me it would be easier once rakuast is out. | ||
lizmat | I'm not sure right now, lack of context, but probably yes | 14:03 | |
and if you're on HEAD, there's a good chance you can already now | |||
grondilu | once we get an AST, how do we turn it into executable code? | 14:04 | |
lizmat | but of course, this is really bleeding edge stuff :-) | ||
EVAL it | |||
grondilu | oh, ok | ||
lizmat | either with $ast.EVAL or EVAL $ast | ||
see the gist I just posted | |||
re documentation: there are about 250 classes to document | 14:05 | ||
and probably more will still come | |||
grondilu | I see. Very cool. | ||
lizmat | getting the .raku right for those classes was already.... interesting and a lot of work :-) | ||
grondilu | well .raku is not critical for anything is it? I mean it's not like $ast.EVAL actually means $ast.raku.EVAL, is it? That would defeat the purpose of an ast, right? | 14:07 | |
(lol hopefully what I just wrote does not too dumb/obvious) | |||
*sound | |||
lizmat | not dumb at all | ||
there's two things: .raku on an AST will give you the RakuAST::Node calls needed to build that AST | 14:08 | ||
Anton Antonov | @grondilu It doesn’t to me. (So, you are safish…) | ||
lizmat | secondly: the .DEPARSE method will give you back the Raku code for the given AST | ||
m: say Q|say "hello world"|.AST.DEPARSE | 14:09 | ||
camelia | say("hello world") |
||
grondilu | wow that seems ambitious. | ||
is it needed anyway? I mean I don't quite see the use of turning an AST back into raku code. It's a bit like decompiling, isn't it? | 14:10 | ||
lizmat | well, the class responsible for deparsing is subclassable | ||
so in a way, it's like a "tidy" functionality | 14:11 | ||
m: say Q|if 42 { say "hello world" }|.AST.DEPARSE | |||
camelia | if 42 { say("hello world") } |
||
lizmat | hmmm I sorta expected a newline after the opening { there | ||
anyways :-) | |||
rf | m: say Q|if 42 { say "hello world" }|.AST.EVAL | 14:12 | |
camelia | hello world True |
||
lizmat | rf: that's a bit roundabout way, but yeah, that works | 14:13 | |
rf | Yeah haha, just wondering if it was possible | ||
lizmat | m: say Q|if 42 { say "hello world" }|.EVAL | ||
camelia | hello world True |
||
grondilu | in any case I think it's very cool that rakudo can compile into a syntax tree. It reminds me of the Wolfram Language. It's very elegant and it may in the future help interoperability with other programming languages. | 14:14 | |
IMHO | |||
lizmat | possibly, yes | ||
rf | So what happens, Raku Code -> Raku AST -> MoarVM Byte Code? | ||
grondilu | that would be pretty cool. | ||
lizmat | yeah, that's what normally happens | 14:15 | |
grondilu | but maybe Raku AST -> Lisp | ||
lizmat | except that we now have a different way to create Raku AST | ||
rf | New backends would be simpler to build for sure | ||
lizmat | not just from Raku source | ||
rf: no, those would still just need to support nqp (mostly) | |||
it's all still built on nqp | 14:16 | ||
rf | Ah I see | ||
Nemokosch | still, NQP is easier to implement than the whole Raku language | ||
lizmat | indeed it is :-) | 14:17 | |
which was the whole point of NQP to begin with | |||
Nemokosch | so does this mean there won't be more QAST hackery in the frontend? | 14:21 | |
grondilu | 👀 | 14:22 | |
Nemokosch | and surely not in the core, right? 🥺 | 14:23 | |
lizmat | all of the QAST hackery should happen inside RakuAST::Node classes | 14:25 | |
now, I don't see a reason why one wouldn't be able to add a RakuAST::Node class in the module ecosystem | |||
in that case, QAST hacker there *would* be needed | |||
but the idea is that the core RakuAST::Node classes should allow you to do everything you want | 14:26 | ||
grondilu | including macros, right? | ||
lizmat | that'd be the idea, yes | 14:30 | |
although the exact syntax and way to work that, is still undecided | |||
first we need to get spectest to run clean, *then* we need to be able to build the setting with RakuAST | 14:31 | ||
and then we can think about macros :-) | |||
Nemokosch | it would feel more relieving if QAST was completely abstracted out of RakuAST. After all, that's purely runtime-relevant code. | ||
lizmat | we basically replace src/Perl6/Grammar|Actions|World by src/Raku/Grammar|actions | ||
in the old code, a lot of the QAST generation was done in World | 14:32 | ||
which was basically an organically grown mess that works | |||
the RakuAST classes should provide a clean interface for the logic | |||
and that includes generating QAST, at least for the foreseeable future | 14:33 | ||
the RakuAST classes *are* the way of abstracting out QAST out of the normal compilation process | 14:34 | ||
now, one could maybe think about skipping the QAST step in AST -> QAST -> MAST | 14:35 | ||
Nemokosch | yes but at the same time it was promised that RakuAST would become standard Raku, and I still can't see any plans to merge "standard Raku" into Rakudo basically | ||
hence it would be good to have actually pure interfaces to it | |||
lizmat | que? the t/12rakuast/* tests are intended to become part of spectest | ||
once they have completely stabilized | 14:36 | ||
so the RakuAST classes *will* be standard classes in 6.e and higher | |||
Nemokosch | then it's not fortunate that they come with a QAST baggage | 14:37 | |
that was my point | |||
14:37
evalable6 left,
linkable6 left
14:38
linkable6 joined
|
|||
lizmat | Nemokosch as a *user* of RakuAST classes,. you don't have to deal with QAST at all, that's the point | 14:38 | |
Nemokosch | and as far as I can remember Jonathan Worthington's presentations, the plan appeared a bit different | ||
lizmat | then I think you're misremembering... but prove me wrong :-) | 14:39 | |
Nemokosch | that is, the runtimes (compiler backends, in the broader sense) would consume RakuAST | ||
not that RakuAST itself would be the compiler backend | |||
lizmat | well, eventually that *may* become possible | ||
14:39
evalable6 joined
|
|||
lizmat | but that'd be akin to implementing Raku in Raku | 14:39 | |
and yes, that *can* be done (with NQP as the example) | 14:40 | ||
Nemokosch | a related thought: nobody seems to be that interested in keeping Raku abstract from Rakudo overall; I don't think it's coincidental that there haven't been attempts of basically any sort. I can elaborate on that in case but for now I'd just say: what if it's really unnecessary to (try to) maintain a separate standard from Rakudo? | 14:44 | |
Or would that cause too many Perl flashbacks? 😅 | |||
moritz | the most reliable way to keep the two separated would be to have another implementation | 14:45 | |
Geth | doc/main: 92686de1bd | (Elizabeth Mattijsen)++ | 2 files Document ThreadPoolScheduler.new(:max_threads) a bit better And the associated RAKUDO_MAX_THREADS environment variable. |
||
lizmat | what is in roast, determines what is Raku | 14:46 | |
RakuAST classes *will* become part of roast | |||
ergo RakuAST is Raku | |||
Nemokosch | Yes but my point is exactly that the standard is not sufficient to actually reason about something that isn't Rakudo | 14:47 | |
neither comprehensive enough (huge lack of pragmatism wrt metamodel stuff), nor clear enough on how it should be applied regarding versions | |||
I have heard this (informal?) term "full Raku implementation", as in supporting all possible versions of Raku. it's hard to figure out whether this is meant to be normative; one thing is sure, it's sort of obvious for Rakudo (by design) that it supports all versions of Raku - as long as Raku doesn't innovate too much | 14:51 | ||
this sort of "full implementation" also more or less defeats the purpose of versions | 14:52 | ||
of course it's astonishing for backwards compatibility if you just ship a runtime that covers all language versions but 1. it really holds back a lot, especially if your language was huge at the beginning 2. I'm afraid backwards compatibility will never be the major selling point of a language that notoriously broke backwards compatibility by its own existence and we know the rest... | 14:57 | ||
lizmat | as far as I'm concerned, Raku will at least support 3 language versions at a time | 14:58 | |
but at some point 6.c will *not* be supported anymore | |||
Geth | doc/main: 438708cd09 | cfa++ | doc/Type/DateTime.rakudoc Fix signature typo |
15:02 | |
15:09
[Coke] joined
|
|||
[Coke] | github.com/perlconference/tprc-202...i/Raku-BOF - please let me know if anyone is thinking about going. | 15:09 | |
I can drive and will go hang out even if I don't attend the conference proper. | |||
Geth | doc/main: bd8282ece8 | cfa++ | doc/Type/ThreadPoolScheduler.rakudoc Add code preamble |
15:11 | |
doc/main: 8fd5f52b1a | (Elizabeth Mattijsen)++ | doc/Type/ThreadPoolScheduler.rakudoc Change pseudocode into actual code Now not needing the preamble |
15:14 | ||
doc: cfa++ created pull request #4259: Amend documented signatures for `Failure` methods |
15:18 | ||
doc/main: ec0bc09b51 | cfa++ (committed using GitHub Web editor) | 2 files Amend documented signatures for Failure methods (#4259) |
15:23 | ||
Anton Antonov | Is there a video recording of this presentation, "Grammatical (dis)agreement: Mixing grammars in Raku" ? tprc2022.sched.com/event/11neo | 15:24 | |
I could not find one within 5 min search | 15:25 | ||
lizmat | guifa might know :-) I seem to recall that presentation never actually was given, but I hope to be wrong :-) | 15:26 | |
Anton Antonov | @lizmat Agh, thanks! | ||
I am basically trying to decide should I go to Toronto's conference or not. | 15:27 | ||
So, I am perusing schedules from previous years. | |||
lucs | Is having my own local zef repo as simple (so to speak) as copying/editing/using its config file? | 15:30 | |
I'd like to try out stuff, pushing and pulling (with zef and fez) from that repo, and that repo only, without polluting the community shared ones. | |||
Geth | doc/main: 57206323e1 | (Elizabeth Mattijsen)++ | doc/Type/IO/Path.rakudoc Document IO::Path.dir-with-entries |
15:32 | |
lizmat | lucs: if you can use one of the standard storage methods (such as used for fez), it *should* be just a matter of configuration | 15:35 | |
15:37
grondilu left
15:39
razetime joined,
jgaz joined
15:40
razetime left
15:45
Sgeo joined
|
|||
Geth | doc/main: ef66f20a7b | (Elizabeth Mattijsen)++ | doc/Programs/03-environment-variables.rakudoc Document support for INSIDE_EMACS environment variable |
15:47 | |
lucs | @lizmat: Where can I learn about those "standard storage methods"? | 15:49 | |
(about to look at fez documentation...) | 15:50 | ||
lizmat | argh... it's been a while... | 15:55 | |
the default zef config file should be tell you which classes to look at | |||
the default zef config file should be tell you which classes to look at | 15:56 | ||
now, where does that live again ... | 15:57 | ||
tonyo | zef -h | 15:59 | |
shows it at the bottom | |||
lucs: are you trying to host your own version of fez? | |||
lucs | @tonyo Yes, and have zef read from there only (just for trying out stuff). | 16:01 | |
I mean, have zef and fez working hand in hand in that (those?) repo only. | |||
tonyo | ah - if it's laid out similarly to fez then it should just be config on the zef side (i've already written the bits that fetch/build/install from that type of repo)..conversely on the fez side it's just a matter of setting up the right end points for it to hit and modifying the default url | 16:03 | |
lucs | @tonyo If I understand what you're saying, I need to have a properly tweaked zef config, and fez will use that? (I think I can tell zef which config file to use, but not sure how to make fez aware of it.) | 16:07 | |
tonyo | fez has it's own but the urls are all in the source, so on the fez side it requires code changes (they're configurable in the functions, just no way to set it globally or in the commands themselves) | 16:08 | |
zef just needs a config file update | |||
lizmat | see also: raku.land/zef:lizmat/Zef::Configuration | 16:10 | |
Nemokosch | I'm back. So anyway, to wrap it up, I don't think it's among the most important things for now to clarify the situation with Rakudo vs Raku, however eventually it needs to be addressed because the current situation is kind of a false sense of security | ||
tonyo | in what way? | 16:11 | |
16:13
derpydoo left
|
|||
Nemokosch | It comes with the illusion that there could be other implementations when in reality it doesn't account for them | 16:14 | |
lucs | @tonyo: Okay, gotcha, thanks. | ||
Nemokosch | roast, that is | ||
lucs | @lizmat: Thanks for the link. | 16:15 | |
16:16
Johanna100 left
16:23
grondilu joined
|
|||
grondilu | In the 5to6 perlfunc doc page, it is written that ioctl (a perlfunc) is NYI in raku. docs.raku.org/language/5to6-perlfunc.html#ioctl Is it still true and if so, is there a userspace solution to do it? | 16:24 | |
16:28
nommef joined
16:29
derpydoo joined
|
|||
lizmat | grondilu: perhaps any of the Terminal:: modules? raku.land/?q=Terminal | 16:29 | |
16:30
swagg_boi left,
nommef left
|
|||
Geth | doc/main: 52c2ea05e7 | (Elizabeth Mattijsen)++ | doc/Type/List.rakudoc Document roundrobin( ..., :slip) |
16:31 | |
doc/main: 08b4ee46c5 | (Elizabeth Mattijsen)++ | doc/Type/Cool.rakudoc DOcument Cool.Order |
16:35 | ||
16:36
falsifian joined
|
|||
Geth | doc/main: 33a6b17f1f | (Elizabeth Mattijsen)++ | doc/Language/variables.rakudoc Bring version statement more in line with others |
16:41 | |
16:50
swaggboi joined
|
|||
grondilu | well, I thought I could make a NativeCall binding real quick, but then I learn that apparently '...' in a parameter list is a thing in C. | 16:55 | |
I had never seen that before. | 16:56 | ||
and I bet NativeCall can't deal with that. | 16:57 | ||
dakkar | ah, the terrible varargs | ||
s.thenautilus.net/notes/999qqjv162 I wrote some vaguely-working code to deal with varargs | 16:58 | ||
grondilu | oh apparently that's how printf works. I should have guessed. | ||
lizmat | yeah, varargs are a pain | 16:59 | |
grondilu: what are you trying to achieve specifically ? | |||
dakkar | btw, ioctl has a terrible interface for historical reasons (essentially, it became a dumping ground for random features that should have been separate syscalls) | ||
grondilu | I want to get window size | 17:01 | |
Geth | doc/main: 9d53594e5f | (Elizabeth Mattijsen)++ | doc/Programs/03-environment-variables.rakudoc Document RAKUDO_OPT for now |
17:02 | |
grondilu | with the TIOCGWINSZ command | ||
for a broader context, I'm interested in experimenting with the kitty graphics terminal protocol. | |||
In raku that is | 17:03 | ||
dakkar | I suggest you do something like s.thenautilus.net/notes/999oh9hlyu | ||
a bunch of wrapper functions, each declaring their "own" `sub ioctl` with the right parameter types | |||
lizmat | also: raku.land/zef:terminal-printers/Terminal::Print | ||
? | |||
grondilu install Terminal::Print | 17:07 | ||
( | |||
(s) | |||
tonyo | grondilu: printf works that way | 17:08 | |
oh, you found that already | |||
dakkar | printf is the *simple* case of varargs ☹ | ||
ioctly is the hard one | |||
ooh, Terminal::Print "cheats", it runs `tput lines` + `tput cols` | 17:09 | ||
github.com/ab5tract/Terminal-Print...#L104-L105 | |||
grondilu | oh yeah there is tput | ||
well I guess I can use that | |||
Geth | doc/main: 3db8263a4e | cfa++ | doc/Type/List.rakudoc Normalise link (remove ".html") |
17:10 | |
grondilu | the number of lines and columns might be enough, but the ioctl call also gives sizes in pixels. Any way to get those too with tput? | 17:12 | |
ugexe | no tput on windows fwiw | 17:20 | |
tonyo | docs.raku.org/syntax/Coercion%20type | ||
grondilu looks up tput man page, then the terminfo man page | 17:21 | ||
no occurence of "pixel" in the terminfo man page. They talk about dots, though. | |||
dakkar | gist.github.com/dakkar/38703016cb0...a8c5c5a525 | ||
works on my machine | |||
correction: rows & cols are in the other order | 17:23 | ||
17:23
Johanna88 joined
|
|||
dakkar | grondilu: try that? ☝ | 17:23 | |
ugexe | nifty, does it work after resizing the window? | 17:24 | |
dakkar | yes | ||
in a real program, you'd hook on the WINCH signal and call the ioctl again, to keep your cached values up to date | |||
grondilu | dakkar: weird, I get a 'no_fallback' unexpected argument error | 17:26 | |
dakkar | ! | ||
ugexe | mmhmm, thats what i used to do with github.com/ugexe/zef/blob/48ed6a2b...emInfo.pm6 but that was with tput and mode... using that nativecall code would have been much nicer | ||
grondilu | dakkar: apparently it was because I included your code in a module. I don't get the error if I copy your code as is. | 17:27 | |
dakkar | grondilu: that may be some weird precomp issue… | ||
ugexe: keep in mind that the actual value of TIOCGWINSZ may well change between different machines! | 17:28 | ||
so the portability is pretty limited | |||
ugexe | ah | ||
grondilu | try it if you want to reproduci it : use module ioctl; # your code ... | ||
anyway very nice. I love it when people write code for me :-) | 17:29 | ||
also thanks :) | |||
dakkar | grondilu: if you call the module `ioctl`, there's some ambiguity with the `sub ioctl` | ||
change one of the names, and it works again | 17:30 | ||
coleman | Nice newsletter this week <3 | ||
dakkar | (I have no clue why it gets confused / how it should work) | ||
coleman | love the published minutes | ||
grondilu | dakkar: I don't think there should be any ambiguity, should it? | 17:31 | |
m: package foo { sub foo {} }; foo() | |||
camelia | WARNINGS for <tmp>: Useless use of constant value foo() in sink context (line 1) |
||
grondilu | m: package foo { sub foo {} }; dd foo() | ||
camelia | foo(Any) | ||
17:31
vrurg left
|
|||
dakkar | m: module foo { sub foo {}; dd foo() } | 17:31 | |
camelia | foo(Any) | ||
dakkar | yep, typenames are preferred over sub names | 17:32 | |
grondilu | yeah that is more accurate | ||
dakkar | m: module Foo { sub foo {}; dd foo() } | ||
camelia | Nil | ||
dakkar | m: module foo { sub foo {}; dd &foo() } | ||
camelia | Nil | ||
17:32
vrurg joined
|
|||
dakkar | there's always that option, of course | 17:32 | |
grondilu | normally you don't name modules in all low caps, but Ioctl looked very wrong. | 17:33 | |
dakkar | loctI | ||
locntI | |||
(dammit, typo in a joke…) |
|