🦋 Welcome to Raku! raku.org/ | evalbot usage: 'p6: say 3;' or /msg camelia p6: ... | irclog: colabti.org/irclogger/irclogger_log/raku
Set by ChanServ on 14 October 2019.
leont Is there any way of controlling how declarator blocks render in raku --doc? 00:41
leont I like their idea, but the default behavior is entirely unusable for my purposes 00:41
leont I like that the information exists in the code, but without control over where it renders, that's all kind of moot. 00:43
tbrowder leont: there is, somewhat, but i notice somehow my env var to help the situation a bit has gotten lost in the docs...let me see if i can find the reference. 02:08
tbrowder it's BURIED in the section on pod, try setting env var RAKUDO_POD_DECL_BLOCK_USER_FORMAT. then run raku with the '--doc' option 02:18
summerisle i'm doing something a little bit insane with raku-mode. does can someone point me to a raku syntax torture test? 02:21
or might there be one in rakudo?
japhb summerisle: torture test in what sense? If you're just looking for "really damn big", the setting would do that. 02:22
tbrowder .tell leont check docs pod for env var RAKUDO_POD_DECL_BLOCK_USER_FORMAT
tellable6 tbrowder, I'll pass your message to leont
summerisle japhb: exhuastive use of syntax 02:23
within reason
japhb summerisle: And of course, the Raku grammar would use quite a lot in that particular braid.
codesections well, I'm not sure exactly what you're looking for, but all/most of the S02 tests in Roast might be along those lines
e.g., github.com/Raku/roast/tree/master/S02-literals
summerisle roast definitely has it, i was just hoping that there would be some mother-of-all-tests out there. 02:24
japhb summerisle: The problem is that any such "every syntax ever" file has a decent chance to either succeed or crash and burn without giving you a lot of info about what went wrong. 02:25
japhb I mean, the Raku grammar being what it is, it would try to point out the problem. Good luck getting that kind of feedback from an editor mode. 02:25
But perhaps I'm being too cynical. :-)
summerisle in this case it's feasible to figure out where things are halting 02:27
codesections japhb: I think you are. In some ways, editor modes can give *more* info, if built right: they're not tasked with trying to check whether the syntax in 100% guaranteed to be valid, and can afford to hold more context about the state of the file 02:29
codesections Said differently, they can (/should) keep parsing after finding an error, because the file they deal with will be invalid 99% of the time they see it 02:30
summerisle ^
the gist of what i'm doing is exploring the feasibility of reworking raku's syntax propertizer around lower level parsing rather than using syntax-propertize-rules, which hides a lot behind the scenes. as it stands, certain aspects of the current propertizer are pretty iffy (e.g. inserting POD before the end of the file can often completely throw off indentation and highlighting past that point) and i'm looking for an excuse to write some elisp 02:31
codesections summerisle: as an aside, have you looked at all at integrating between raku-mode and a raku process via JSON? Between emacs 27 and JSON::Fast, both sides of that seem snappy enough to make that practical, and I keep meaning to investigate 02:34
summerisle that just came to mind actually
and i may prefer to go that route
codesections (but maybe I'm just looking for an excuse *not* to write some elisp)
summerisle there would still be plenty
codesections yeah
summerisle i need to figure out how to get that data out of raku - what's most important though is being able to correlate that data with character positions in the buffer 02:35
the other thing is that emacs' propertizers work on chunks rather than the whole file, or are expected to at least
really it's the working on chunks bit that makes things... interesting 02:42
summerisle ah, i just realized what you were suggesting - i thought you meant to suggest that rakudo would emit json and i would consume it 02:45
i think the idea of a highly responsible language server is not a bad one 02:46
it would need to be performant enough but capable of handling weird situations (e.g. chunk contains the end of a heredoc but not the beginning)
i feel like at that point things become difficult though
these things work really well when you don't need a lot of surrounding context
codesections Yeah. There's definitely a continuum. A full-scale LSP-complient server would be a _lot_ of work (though awesome if someone could pull it off). At the other end, having Rakudo emit some json for emacs to consume would be a lot easier, but not nearly as powerful/interactive. I've been wondering if there's a sweet spot in the middle somewhere, but mostly that's just been idle speculation on my part (so far, anyway) 02:50
summerisle well, what i need to teach emacs about in particular is proper (not inferred) nesting level (in some cases), heredocs, line continuations in prec drop method calls, `-->` in single-element argument lists when on separate lines, and some other things that don't come to mind now 02:52
having used raku for a while I think it's an extremely good programming language (minus current speed issues in the parse stage), and would like better editing support for it 02:53
the extremely blurred line between runtime and language is beautiful 02:54
codesections another item for that list: Q-lang support for custom delimiters. `Q @'@;` is a fast way to break highlighting for the rest of the file atm 02:56
Geth doc: f414ff665c | (Richard Hainsworth)++ (committed by Juan Julián Merelo Guervós) | doc/Language/numerics.pod6
related to #3841

This is not an obvious mistake. From the link it seems to point at a different file. Since this is a judgment call, I'm flagging my correction for review.		 06:52
doc: 4486bd6328 | (Richard Hainsworth)++ (committed by Juan Julián Merelo Guervós) | doc/Language/numerics.pod6
Update numerics.pod6
linkable6 Link: docs.raku.org/language/numerics
Geth doc: 1ee3ded883 | (Richard Hainsworth)++ (committed by Juan Julián Merelo Guervós) | doc/Language/operators.pod6
Related #3841

Removing B<..> **inside** a X<> for $*COLLATION . The problem is that there is no specification for a corresponding `L<>` in another file. As the present, the link author has to know how the target will be rendered. So `B<>` could be rendered as `<b> ... </b>` or `<strong>...</strong>` in HTML. **BUT** if this were to be rendered in some other output format (pdf? epub? latex?), the link would fail. This has already happened in `Language/Operators`, where the link author did not include `<strong>...</stro
So, I have removed B<> inside the X<>, and simplified the X<>, and corrected the link in Operators. If this has a knock-on effect in other documents, it will be picked up in `Collection` tests when the documentation files are re-rendered.		 07:02
linkable6 Link: docs.raku.org/language/operators
Geth doc: a14b1a2d36 | (Richard Hainsworth)++ (committed by Juan Julián Merelo Guervós) | doc/Type/Any.pod6
See #3841 #3857

simplify the X<> for $*COLLATION		 07:03
Xliff What would be the best way to take an IO::Path and get its path fragments? 09:56
There doesn't seem a method for it in the docs.
m: "/a/b/c/d/e".IO.parts.gist.say
camelia IO::Path::Parts.new("","/a/b/c/d","e")
Xliff m: sub fragments ($p) { $p.dirname.split($p.SPEC.dir-sep) }; "/a/b/c/d/e".IO.&fragments.gist.say 09:59
camelia ( a b c d)
Xliff ^^ Ah! That works!
Is there any reason this isn't a method?
What is the likelyhood a PR implementing such would be accepted?
lizmat I'd say, pretty good, unless we missed something and that functionality *is* already available somehow, in which case we would need better documentation ? 10:04
Xliff lizmat: Well, I'll continue looking for it. Already discovered a minor flaw: Simple case works for Unix, not Windows. 10:13
Not sure how I'd handle that.
Particularly when a drive is involved. 10:14
sub fragments ($p) { $p.dirname.split($p.SPEC.dir-sep) }; "g:/a/b/c/d/e".IO.&fragments.gist.say 10:15
evalable6 (g: a b c d)
Xliff Actually, that's not bad
lizmat m: dd $*SPEC.splitpath("/a/b/c/d/e".IO) 10:19
camelia ("", "/a/b/c/d/", "e")
lizmat m: dd $*SPEC.splitdir("/a/b/c/d/e".IO) # Xliff 10:20
camelia ("", "a", "b", "c", "d", "e")
lizmat m: dd $*SPEC.splitdir("c:/a/b/c/d/e".IO)
camelia ("c:", "a", "b", "c", "d", "e")
Xliff lizmat: The only problem is that's not on the IO::Path. 10:22
I knew we did have that somewhere though. Thanks.
lizmat well, yeah, but I'm not going to touch that part of Rakudo ever again: got burned a little too much on that, technically wise 10:23
Xliff sub fragments ($p) { $p.SPEC.splitdir($p.absolute) }; "g:/a/b/c/d/e".IO.&fragments.gist.say
evalable6 ( home bisectable git whateverable g: a b c d e)
Xliff sub fragments ($p) { $p.SPEC.splitdir($p.absolute) }; "g:/a/b/c/d/e".IO.absolute.say 10:24
evalable6 /home/bisectable/git/whateverable/g:/a/b/c/d/e
Xliff Ah.
Xliff lizmat: So the implementation is even easier! 10:25
sena_kun m: my \a = "\{\"state\":\"HOM\",\"comment\":\"test\"}"; say \(a); say (\(a)); 10:33
camelia \("\{\"state\":\"HOM\",\"comment\":\"test\"}")
\("\{\"state\":\"HOM\",\"comment\":\"test\"}")
sena_kun m: my \a = "\{\"state\":\"HOM\",\"comment\":\"test\"}"; (-> (:$state, *%rest) {}).signature.ACCEPTS(\(a));
camelia Cannot unpack or Capture `{"state":"HOM","comment":"test"}`.
To create a Capture, add parentheses: \(...)
If unpacking in a signature, perhaps you needlessly used parentheses? -> ($x) {} vs. -> $x {}
or missed `:` in signature unpacking? -> &c:(…
sena_kun Can anyone please explain to me what's the difference?
m: my \a = "foo"; say \(a); say (\(a)); 10:34
camelia \("foo")
\("foo")
sena_kun m: my \a = "foo"; (-> (:$state, *%rest) {}).signature.ACCEPTS(\(a));
camelia Cannot unpack or Capture `foo`.
To create a Capture, add parentheses: \(...)
If unpacking in a signature, perhaps you needlessly used parentheses? -> ($x) {} vs. -> $x {}
or missed `:` in signature unpacking? -> &c:(Int) {}
in block <unit> a…
sena_kun to simplify the input 10:34
m: my \a = "\{\"state\":\"HOM\",\"comment\":\"test\"}"; (-> :$state, *%rest {}).signature.ACCEPTS(\(a)); 10:36
camelia ( no output )
sena_kun work ok
lizmat m: dd \().^name 10:38
camelia "Capture"
lizmat \() is special syntax for creating a Capture ?
sena_kun yes 10:39
I am not getting why when it does not match the signature without parens it just says "Ok, this capture doesn't fit, return False and fine", but when the signature has parens it throws.
Or, hmm. 10:40
Maybe it is normal to throw here, I am starting to get it. It tries to remove a level of () from bare string and fails to do so.
It's just me expecting ACCEPTS to be silent and just return False when something is not going well. 10:41
lizmat well, maybe it should ? 10:42
sena_kun Hard to tell, honestly. On the one hand it's a nice thing to know you screwed a signature somewhere instead of it silently not saying anything with you scratching a head. 10:43
Anyway, I got it now, thank you. :)
lizmat glad to have been able to rubber duck :-) 10:44
Geth doc: ba217999a0 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/newline.pod6
newline.pod6 correct ref see #3841

In link \n		 10:59
leont tbrowder: that just affects formatting. It doesn't allow me actually process them 11:47
tellable6 2021-04-04T02:22:56Z #raku <tbrowder> leont check docs pod for env var RAKUDO_POD_DECL_BLOCK_USER_FORMAT
tbrowder what is it you expect Raku to do? 11:48
or would like it to do?
i'm going to go back and try to bring my wip pod change to leading declarator blocks into a PR, and maybe i could help. 11:50
if the author's format is respected, then you can use pod formatting in the decl block, extract it, and then process it as pod in a subprocess is what i think Damian was visualizing. 11:52
my words, not his. see his comments ref decl blocks on the rakudo github site 11:55
leont Main difficulty is that there's already a default handling 12:17
Declarator docs are added to the method's docs, and to the compilation unit docs 12:18
The former works as I'd want, the latter I want more control over.
1) because I want precise control over where it ends up, and now my best way of doing that is to put certain pieces before and other after my code (which I don't like) 12:19
I can't weave it 12:25
2) it doesn't easily allow me to inherit docs. Stuff like "these are the methods class Bar inherited from class Foo." Doing this sort of stuff is way more difficult than it should be. 12:26
I'm currently playing with a DOC INIT phaser, and I think I'm able to munge it, but it's all much more difficult than it should be 12:28
leont It doesn't allow me to add docs for generated methods (new, or handles methods) the same way as hand written ones either 12:39
Xliff If I have a .pause document and want to encrypt it with gpg. How would I go about doing that? 12:57
Doc_Holliwould m: dd 0.100000000000000006e0 13:00
camelia 0.1e0
Doc_Holliwould m: dd 0.100000000000000006
camelia 0.100000000000000006
Doc_Holliwould is that a bug? it seems to lose precision when using the exponential form
lizmat m: dd 0.100000000000000006e0.^name 13:03
camelia "Num"
lizmat m: dd 0.100000000000000006.^name
camelia "Rat"
lizmat Num have limited precision
*Nums
Doc_Holliwould ^^
the "exponential" form is really the "Num" form 13:05
Doc_Holliwould it should fit into a 64 bit float though= 13:18
? 13:19
Xliff JSON::Fast is failing to deserialize JSON that passes jsonlint.com 13:25
JSON data is here: replit.com/@Xliff/FrequentSplendid...META6.json 13:27
leont That doesn't show any JSON for me 13:28
lizmat m: printf("%.20f",0.100000000000000006e0) 13:35
camelia 0.10000000000000000000
lizmat m: printf("%.30f",0.100000000000000006e0) 13:36
camelia 0.100000000000000000000000000000
lizmat hmmm
Xliff leont: Shows fine for me. 13:38
Try this: replit.com/join/vgttffvw-xliff
ugexe parsed it for me fine 13:43
codesections .tell leont re: documenting with declarator blocks -- I agree the current implementation leaves a fair bit to be desired. FWIW, I think some of the issue is that parts of the design are just NYI (see this issue for example: github.com/rakudo/rakudo/issues/38...683174352) 13:50
tellable6 codesections, I'll pass your message to leont
Xliff Hmmm... 14:05
Lost a full 10 minutes in p6-GLib compiles.
400 seconds on the parallel compile. Wow 14:06
See github.com/Xliff/p6-GLib/blob/mast...Counts.ods 14:10
You will need to download and open the file to see the data.
Also need OpenOffice
lizmat afk for a few hours& 14:16
leont codesections: I don't think the problem is NYI 15:52
tellable6 hey leont, you have a message: gist.github.com/88d13c22cd046f3e0f...ad15ffcf3a
lucs If @foo.elems is 42, is there a @foo.｢method｣ that gives 41? 16:57
lucs Um, Happy Easter everyone, I guess :/ 17:14
[Coke] m: my @a=1..42; say @.kv[*-1] 17:16
camelia 5===SORRY!5=== Error while compiling <tmp>
Variable @.kv used where no 'self' is available
at <tmp>:1
------> 3my @a=1..42; say @.kv7⏏5[*-1]
expecting any of:
argument list
term
[Coke] m: my @a=1..42; say @a.kv[*-1]
camelia 42
[Coke] m: my @a='A'..'Z'; say @a.kv[*-2]
camelia 25
[Coke] (second one, first is wrong.)
lucs [Coke]: Right, but still, I'd use ...elems - 1 instead of that. 17:17
codesections or just @foo - 1
lucs Oh, right, in scalar context. 17:18
codesections if you don't mind the coercion being implicit
codesections (you could also call it as `@foo.&infix:<->(1)` if you need it as part of a method chain) 17:22
[Coke] :) 17:24
CIAvash @foo.elems.pred? 17:28
summerisle hot idea: raku-flavored-lisp, a lisp built around the MOP 17:30
codesections that'd pair well with examples.p6c.dev/categories/interp.../lisp.html 17:32
summerisle and do it as a slang
codesections oh, or a variant on what [Coke] suggested: @foo[]:k.end 17:38
Geth doc: 24ca149966 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/packages.pod6
packages / interpolation #3841

Change reference to Glossary entry		 17:41
linkable6 Link: docs.raku.org/language/packages
Geth doc: d8f23ec421 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/regexes.pod6
Regexes / backtracking 2 see #3841

More than one occurrence of backtracking.		 18:03
linkable6 Link: docs.raku.org/language/regexes
Geth doc: d7f7dfbef4 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/structures.pod6
structure / lines see #3841

method_lines -> routine_lines		 18:08
linkable6 Link: docs.raku.org/language/structures
softmoth tbrowder, perl6-pod-to-markdown #26 is fixed. Let me know if you have any issues. 18:15
tbrowder okay, thanks so much, Tim! 18:16
softmoth You're welcome! By the way, do you know the status of Rakudo #2863 (getting Rakudo to actually parse table elements as Pod)? AFAIK a few people have tried to fix it and given up, but it seems like it shouldn't be that hard. I don't know why it's been unfixed for a decade.... 18:18
Geth doc: 542729c220 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/traps.pod6
traps change || to %7C%7C
 18:31
linkable6 Link: docs.raku.org/language/traps
Geth doc: 90bb3e635d | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/typesystem.pod6
typesystem errors, see #3841

  - section title was changed -> Constraining_argument_definiteness
  - reference for where clause
  - with/orwith section title was changed		 19:37
linkable6 Link: docs.raku.org/language/typesystem
Geth doc/finanalyst-patch-1: 34c45046b6 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/typesystem.pod6
Reference error to .^

Part of #3841 . But I'm flagging this error because the orginal documentation calls `.^` a postfix op, but in ` language/operators` it is called a metamethod. So I have also change 'postfix' to 'metamethod' to be consistent.		 19:43
doc: finanalyst++ created pull request #3863:
Reference error to .^
doc: 3d53e92933 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/unicode_entry.pod6
unicode entry #3841 error

from set/bag operators -> Operators_with_set_semantics		 19:51
linkable6 Link: docs.raku.org/language/unicode_entry
Geth doc/finanalyst-patch-3: 18 commits pushed by (Richard Hainsworth)++
review: github.com/Raku/doc/compare/4beefb...6ea16afb24		 20:00
Geth doc/finanalyst-patch-2: bf894b50e8 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/packages.pod6
interpolate using wikipedia

There was discussion of this and I caused a conflict by editing twice. Here it is again		 20:06
doc: finanalyst++ created pull request #3864:
interpolate using wikipedia link (resubmission)
Geth doc: 6f06c4d972 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Language/variables.pod6
variables #3841

Change to a valid reference		 20:17
linkable6 Link: docs.raku.org/language/variables
Geth doc: db1e19fd51 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Any.pod6
Any #3841 errors

  - prepend method -> routine
  - join Any.list is a method not a routine
  - categorise is a routine not a method
  - map is a routine
  - title changed to Destructuring_arguments
  - hyper ref corrected to methodop_%C2%BB._/_methodop_%3E%3E.		 21:00
linkable6 Link: docs.raku.org/type/Any
Geth doc: 714af7fdd1 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Dateish.pod6
Dateish #3841

missing _ in method later		 21:04
linkable6 Link: docs.raku.org/type/Dateish
Geth doc: 0bace98f51 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Distribution/Locally.pod6
Distribution::Locally #3841

method_prefix is in the same file (::Locally), not in the parent class file.		 21:10
linkable6 Link: docs.raku.org/type/Distribution::Locally
Geth doc: e2f159eadc | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Hash.pod6
Hash #3841 error

Postional vs named. lower-case and add extra from header		 21:13
linkable6 Link: docs.raku.org/type/Hash
Geth doc: 849b2c502f | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/IO/Handle.pod6
IO::Handle #3841

  - get is routine not method
  - filehandles not file Handles		 21:19
linkable6 Link: docs.raku.org/type/IO::Handle
Geth doc: a253f3b806 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/IO/Path.pod6
Path #3841

open is a method not a routine		 21:26
linkable6 Link: docs.raku.org/type/IO::Path
Geth doc: f7f36763e2 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/IO/Special.pod6
Special #3841

extra > in ref		 21:30
linkable6 Link: docs.raku.org/type/IO::Special
Geth doc: 53c21f3267 | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Signature.pod6
Signature #3841

Extra chars in ref to where clause		 21:47
linkable6 Link: docs.raku.org/type/Signature
Geth doc: 2878d0305e | (Richard Hainsworth)++ (committed using GitHub Web editor) | doc/Type/Iterable.pod6
Iterable #3841

Extra chars in reference		 21:49
Geth ecosystem: softmoth++ created pull request #587:
Pod::To::Markdown has moved to CPAN		 22:42
tbrowder softmoth: excellent! my new table is much better with proper math symbols. see it in the README at github/tbrowder/Math-FractionalPart 23:43
thanks, Tim 23:44
Geth ecosystem: 85bc52beda | (Tim Siegel)++ | META.list
Pod::To::Markdown has moved to CPAN
 23:45
ecosystem: cc5e0b1f66 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | META.list
Merge pull request #587 from softmoth/pod-to-markdown-cpan

Pod::To::Markdown has moved to CPAN
softmoth tbrowder, You're welcome. Thanks for letting me know. 23:54

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!