🦋 Welcome to the former MAIN() IRC channel of the Raku Programming Language (raku.org). This channel has moved to Libera (irc.libera.chat #raku)
Set by lizmat on 23 May 2021.
lucs Is rakubrew reliable to use? 01:40
avuserow . 01:41
tellable6 2021-07-09T22:44:45Z #raku <SmokeMachine> avuserow have you taken a look at Red’s SQL generation? Mostly on how it converts Raku’s code into SQL?
2021-07-09T22:47:16Z #raku <SmokeMachine> avuserow it seems more magical than what you want… but maybe it worths taking a look
avuserow lucs: yes. 01:42
lucs Okie doke, thanks. 01:43
avuserow SmokeMachine: I have seen Red. It is definitely too much magic but I am very intrigued in how it works. I haven't delved far enough to get to how the magic is made
lucs, I usually install the latest commit, which usually works fine, but you might be better served by installing the latest release. 01:44
SmokeMachine avuserow: we override many operators to make them return Red::AST objects and based on that we generate the SQL
lucs avuserow: Yeah, I'll stick to stable, thanks. 01:45
I was about to start asking questions about problems I'm having, but realized I'm running 2020.01, so I'll level up a bit :) 01:46
SmokeMachine avuserow: we also have some control exceptions to find Boolean tests inside of map/grep/join blocks that helps it to create SQL based on those blocks
avuserow SmokeMachine: wow, fancy 01:47
I am hoping that if I ever need a "more magic" module, we'll have macros. but operator overloading is pretty cool too.
I briefly considered writing a Slang or using a block to somehow generate where clauses... but I have a real application to finish too :) 01:48
SmokeMachine avuserow: we intent to replace the way we discover what a block do and treate Red::AST by a simple translation RakuAST -> Red::AST once RakuAST is released… 01:50
One could also use Red::AST directly to generate SQL if needed… 01:51
a avuserow this is how it “understands” the blocks: github.com/FCO/Red/blob/master/lib...de.pm6#L56 01:54
avuserow: and here is where the control exception I told you is thrown: github.com/FCO/Red/blob/master/lib...ST.pm6#L28 01:56
avuserow very interesting. 01:58
SmokeMachine So, every time we find a new Boolean test inside the block we add a new column on the truth table and duplicate the rows (1 time for true value and the other for false value)
guifa o/ 04:41
moon-child \o 04:45
ugexe lucs: yes rakubrew is reliable to use 12:42
lucs ugexe: Excellent. Just got up, will proceed with that now. 12:44
Geth doc/methodop_dot_amp: 20d5fa2a99 | (Daniel Sockwell)++ (committed using GitHub Web editor) | doc/Language/operators.pod6
clarify .& methodop

Based on the current docs, I thought that `foo.&{...}` created an unnamed method and called it on `foo`. However, Jonathan's answer to at
  stackoverflow.com/questions/683089...e/68327774
clarified that it creates a Block and calls that Block with method syntax.
This commit clarifies the description to avoid similar confusion.
14:14
doc: codesections++ created pull request #3912:
clarify .& methodop
14:16
Geth doc: a253810b94 | (Daniel Sockwell)++ (committed by Juan Julián Merelo Guervós) | doc/Language/operators.pod6
clarify .& methodop

Based on the current docs, I thought that `foo.&{...}` created an unnamed method and called it on `foo`. However, Jonathan's answer to at
  stackoverflow.com/questions/683089...e/68327774
clarified that it creates a Block and calls that Block with method syntax.
This commit clarifies the description to avoid similar confusion.
15:43
linkable6 Link: docs.raku.org/language/operators
melezhik looks like whateverable rakudo versions are not available at the moment - gist.github.com/melezhik/4fca7b89e...bd1d4c3547 16:16
not sure who is in charge for that ...
leont Seems the government has messed up so badly that I might attend the Raku Conference after all, because my (IRL) plans have been cancelled :-/ 16:42
moritz leont: sounds like NL 17:05
leont Indeed
guifa leont: I want to say nice but … ugh, I'm sorry stuff is hitting so hard 18:01
casaca hi rakudoers. I'm trying to install `NativeLibs` on openbsd, one the tests, 02-cannon-name.t fails on line 13. i think it's because `platform-library-name` in VM.p6 explicitly prevents appening the version number to the library name if running on windows, darwin, or openbsd 19:03
casaca [NativeLibs] # Failed test 'libfoo.so.2' 19:06
[NativeLibs] # at t/02-cannon-name.t line 13
[NativeLibs] # expected: 'libfoo.so.2'
[NativeLibs] # got: 'libfoo.so'
guifa casaca: interesting. You might try posting in #raku-dev as well (sometimes responses in either room can be a bit slow especially on weekends, but hopefully someone will have a quick fix for you) 19:14
casaca guifa: thanks for your reply, i'll keep that in mind. 19:32
ugexe ~ raku -e 'say $*VM.platform-library-name("foo".IO, :version(v3))' 19:58
"libfoo.3.dylib".IO
looks like it works to me
looks like it works to me 19:59
casaca ugexe: ty for taking the time, but you seem to be running on macOS. it fails on openbsd 22:08
ugexe yeah, im running on darwin
and afaik it works on windows as well
but you said it doesnt work on windows, darwin, or openbsd 22:09
guifa ugexe: I read it as saying that VM.p6 did something differently on those systems, rather than failing on all of them. Might be mistaken though. 22:11
ugexe VM.pm6 is doing the right thing on darwin and windows 22:12
what i think they might be getting at is something is wrong with NativeLibs, and not anything core raku like VM.pm6 22:13
casaca it works on those two because they don't need to append the version number; but you have to on openbsd. 22:14
$version.defined and nqp::iseq_i(nqp::add_i(nqp::add_i($is-darwin,$is-win),$is-openbsd),0) 22:16
imo, openbsd needs to be taken out of that check. ill check in #raku-dev 22:17
ugexe thats why im confused, because i just showed you the output of a darwin system that includes the version 22:20
casaca ah, check out after line 88 with comment: "OS X needs version before extension" on github.com/rakudo/rakudo/blob/mast...e.c/VM.pm6 22:24
they take care of that a few lines above the check I posted before 22:26