This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html
Set by lizmat on 8 June 2022.
01:16 Manifest0 left 07:07 CIAvash joined 07:30 jaguart left, jaguart joined 09:11 CIAvash left
DarthGandalf Hi, there's no Raku bindings for Z3 anywhere? Looks like I'll have to call the C library directly 10:45
lizmat raku.land/?q=Z3 # looks like indeed none known 10:51
11:21 MasterDuke left
librasteve DarthGandalf may want to consider metacpan.org/pod/Z3::FFI via use perl5 12:50
or ericpony.github.io/z3py-tutorial/g...amples.htm z3py via use python 12:51
DarthGandalf my current workaround is to call `run('python', 'day24p2.py', :in, :out);` but after that works, I'll try to port that to `use python`, thanks 12:52
I'm getting segfault with Inline::Python 13:29
I've filled github.com/niner/Inline-Python/issues/45 for it and more 13:45
nemokosch Don't keep your hopes up
DarthGandalf I know :) 13:46
nemokosch It's better to write bindings with NativeCall, that's the one that actually works 13:48
DarthGandalf well, yes, it would work. I managed to make it work with md5 calculation 13:50
but z3 python bindings has much nicer API than C API
because of operator overloading
nemokosch Well it's only up to you what Raku API you create 😉 13:51
DarthGandalf well, sure. That's why I was asking about existing Raku Z3 bindings :) 13:52
I'm not up to the task of creating such bindings myself
nemokosch Well, that's too bad... these packages don't grow from soil 13:53
DarthGandalf I understand
I have too many FOSS commitments already
so doing this AoC on Raku was enough for me, for now
nemokosch I don't mind FOSS commitments but with all due respect, Z3 is a car for me 13:54
DarthGandalf and I already contributed a bit by finding several bugs in rakudo and moarvm itself :)
nemokosch Sadly, that's not a very high tally 13:55
.vushu Does nativecall work on c++? without c api? 13:58
DarthGandalf If I find some free time, I might do it, but don't keep your hopes up :) 14:00
nemokosch C++ is usually binary compatible with C 14:01
I've seen people use it that way
DarthGandalf That's different 14:14
nemokosch NativeCall is about ABI anyway 14:15
Think of ab5tract using Zig
DarthGandalf yes, and C++ doesn't have a defined ABI. You can try to make it work by mangling the function names yourself, but normally ABI calls are done through C API 14:16
.vushu hmm would be nice to be able to translate c++ class to raku class
since c isn’t oop 14:17
nemokosch Again, I've seen people making it work, and defined or not, C compatible code won't magically produce C incompatible binary
DarthGandalf I've been using SWIG for that before
though not for raku
nemokosch That's the whole reason for structs
lakmatiol You need extern "C" if you want non-painful FFI to C++. 14:19
c $ cat a.c int f() {return 1;} $ cat b.c #include <stdio.h> int f(); int main() { printf("%d\n", f()); } $ gcc -c a.c $ g++ -c a.c -o a.cc.o $ gcc b.c a.o $ ./a.out 1 $ gcc b.c a.cc.o /usr/bin/ld: /tmp/cc3YMJXG.o: in function `main': b.c:(.text+0xe): undefined reference to `f' collect2: error: ld returned 1 exit status it will 14:23
nemokosch This is the linker
lakmatiol the symbol name is wrong in the c++ binary
$ nm -an a.cc.o 0000000000000000 t .text 0000000000000000 T _Z1fv 0000000000000000 a a.c $ nm -an a.o 0000000000000000 t .text 0000000000000000 a a.c 0000000000000000 T f notice how to C++ version doesn't have f, but instead has _Z1fv 14:24
I think in this simple case if you just picked the right symbol it would work 14:25
nemokosch I wouldn't expect static linking to be the same deal.
DarthGandalf static vs dynamic doesn't matter mangling-wise
nemokosch Frankly, I wouldn't expect portability for static linking even across different C compilers 14:26
lakmatiol static vs dynamic linking doesn't come into play here at all, that matters when using libraries, here we are just using raw object files.
nemokosch It was literally the linker that threw the error 14:27
DarthGandalf that's because C and C++ assign different symbol name to `f`
you can also mention C++ namespaces and C++20 modules here, which allow creating several independent functions `f`, in different ways. 14:29
librasteve don’t give up on inline python (i) i built some dockerfiles to help github.com/librasteve/raku-Dockerfiles this one should do it librasteve/rakudo:scipy, (ii) the trick to get it to run on your machine is the build devs here github.com/librasteve/raku-Dockerf...Dockerfile at line 9 14:30
nemokosch Respect for your effort 14:31
DarthGandalf librasteve: It builds fine, that's not the problem though
lakmatiol c $ gcc -shared -o a.cc.so a.cc.o $ gcc -shared -o a.so a.o $ python >>> lib = ctypes.cdll.LoadLibrary('./a.cc.so') >>> lib.f Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/adam/.pyenv/versions/3.10.6/lib/python3.10/ctypes/__init__.py", line 387, in __getattr__ func = self.__getitem__(name) File 14:32
"/home/adam/.pyenv/versions/3.10.6/lib/python3.10/ctypes/__init__.py", line 392, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: ./a.cc.so: undefined symbol: f >>> lib._Z1fv <_FuncPtr object at 0x7f0cb9e18a00> >>> lib._Z1fv() 1 >>> lib2 = ctypes.cdll.LoadLibrary('./a.so') >>> lib2.f() 1 here is the same error from pythons FFI.
DarthGandalf or you're saying you made it somehow not crash in runtime, and to support operator overloading properly?
nemokosch Yeah it's not fully clear what to see here 14:33
lakmatiol note how a.cc.so, compiled with a C++ compiler, doesn't have the function f, but the a.so, compiled with a C compiler, does 14:34
nemokosch Where are the source files though
lakmatiol followup from this example 14:35
nemokosch Anyway, it's not like it needs to be reimplemented in C 14:36
lakmatiol interoping with C++ without extern "C" requires implementing name mangling, or wrapping the library in an extern "C" API
nemokosch Maybe the symbol needs to be exposed differently but the underlying data types are the same
Which is exactly the difference between a language like Raku where data types are hand mapped 14:37
librasteve reads the issue … ah - nothing to add on segfault situation, on operator overloading, you can just write your own in raku like ‘infix:<+> (Z3::Int $a, $b) {$a add $b}’ or similar I guess…. 14:44
DarthGandalf I could. But the segfault is blocking that anyway, so... 14:45
.vushu any modules I can look at for c++ to raku bindings? 14:50
nemokosch Rawley fowler
.vushu cool thanks! 14:51
nemokosch There was the simd stuff 14:53
I wonder how Curt Tilmes did it github.com/CurtTilmes/raku-jsonsimd 14:54
DarthGandalf via extern C: github.com/CurtTilmes/raku-jsonsim...erface.cpp 14:55
.vushu cool i’ll check it out
nemokosch Tbh it's much more bloated than Rawley's solution
Hugeass h file
DarthGandalf don't worry, Rawley also uses extern C :) 14:58
github.com/rawleyfowler/JSON-Simd/...ive.cc#L15
nemokosch But it's less bloated 😛
Not too frightening 14:59
Two functions exposed and one is domain specific
DarthGandalf actually, I think they do the same. Rawley also uses the header 15:00
The difference is that he doesn't *bundle* the header
so you just don't see it in the source
nemokosch That's cleaner id say 15:01
DarthGandalf oh, that's for sure
nemokosch Also, the dist architecture is more up-to-date
DarthGandalf I also don't like bundled external libraries
nemokosch Build.rakumod is like a legacy hook
Rawley created a dedicated builder module for CMake 15:02
And it's registered in the META6 file
antononcube I want to simplify this code: 'C2H5OH + O2 -> H2O + CO2' ==> balance-chemical-equation() ==> {$_.say; $_}() ==> molecular-mass() 16:21
Is there are way to replace the echoing chain segment {$_.say; $_}() with something smaller? 16:22
It looks like I have to live with the requirement to add () to each of the pipeline functions... 16:23
nemokosch Literally what snitch does in v6.e 16:24
antononcube Ok. Good to know. Any 6.d solutions? 🙂 16:25
nemokosch I think this is good if you insist on the arrows 16:26
antononcube Should I use :experimental adverb when I start the Raku session?
Of course, I insist on arrows!!! That is a monadic pipeline "for free" from Raku.
Fine -- I have to figure out how make "Jupyter::Chatbook" to include this statement "use v6.e.PREVIEW;" when starting the Raku REPL. 16:30
Another question: if I have a Pair object $p, how can I apply a two argument function that uses both the key and the value? 16:31
nemokosch $p.key, $p.value? 16:32
Lol 16:33
antononcube For example, it would have been nice if instead of f2($p.key, $p.value) I could write f2(|$p).
nemokosch m: my $p = :2a; $p.kv.say
Raku eval (a 2)
nemokosch Good
You could flatten this
antononcube Ok, yes. That works -- Thanks! 16:34
16:51 mcmillhj joined
mcmillhj Probably another dumb question but I am creating a bunch of subs using EVAL (solving AOC puzzles) and some of the subs reference other subs. For example, `sub _hdj { if ($m > 838) { return _A(); }; return _pv(); }` calls both sub `_A` and sub `_pv` depending on the state of some variables. When I try to EVAL the string holding `_hdj` I get an error 16:58
about an undeclared name `_pv`. Is there a way to ignore this error? By the time that `_hdj` is called `_pv` will have already been EVAL'd.
antononcube I think you have to check does _hdj is defined in the way you expect. (In the global context of symbols.) 17:00
DarthGandalf perhaps instead of calling a function by name, have a %hash somewhere in which you'd look up the sub object in runtime? something like %funcs<_pv>()
librasteve my guess is that with multiple EVAL blocks, the symbols from one eval are not available in the next eval - maybe you could do one big eval, but use if / when statements to just run the code you need? 17:03
mcmillhj oh okay, I hadn't thought about using a hash but that could work. So I would do something like `%hash{'_hdj'} = EVAL $stringified-hdj;`. I unfortunately wrote a grammar to transform the puzzle input into these subs so that would require some re-work but not terrible. 17:04
antononcube @librasteve This was my assumption too. 17:05
mcmillhj librasteve: I tried in a block that was separated by newlines. When I tried to call one of the functions though it didn't appear to be available.
DarthGandalf %hash{'_hdj'} is the same as %hash<_hdj> but yes 17:06
librasteve maybe you could post a gist of you code and link it here? (I am a bit in the dark) 17:07
mcmillhj yeah, I feel like I am not doing the best job explaining. I'll push my code up to github, one second.
DarthGandalf I did use eval for the first day, not for day 19 though. But in the first day I randomly found out that the function names defined need to be more nested. But that is probably because I'm using a module per day, so might not be relevant for your evals 17:08
by nested I mean this: github.com/DarthGandalf/advent-of-...akumod#L35 17:09
librasteve antonocube: I updated the Physics::Measure test to "is $fe1, '30mpg'; is $fe2, '10.620186km/l' || '12.754311km/l'," (you are on us-gal and us-mpg since you have en_US locale) should work on v1.0.19 (just released to fez) 17:14
mcmillhj sorry for the delay, had to hardcode the test input: github.com/mcmillhj/aoc/blob/main/...lenty.raku 17:15
yeah, I haven't been defining modules
librasteve tx - looking now 17:16
DarthGandalf > However, since the set of symbols in a lexical scope is immutable after compile time, an EVAL can never introduce symbols into the surrounding scope. 17:30
docs.raku.org/type/independent-rou...utine_EVAL 17:31
mcmillhj oh dang
I missed that when reading the docs :(
librasteve yeah - I would say put the last lines (my $IN = "_in"; ...) into the EVAL block 17:33
DarthGandalf however, the example below that sentence looks like it can introduce names just fine, module M { EVAL 'our $answer = 42' }; say $M::answer;
librasteve our is not lexical 17:35
nemokosch ^ 17:36
mcmillhj lol
wrapping the block eval in a module worked fine
librasteve phew!
DarthGandalf well, I tried to modify mcmillhj's code to add our to the subs, but that still didn't expose the subs
mcmillhj I had to do both. Wrap the subs in `our` _and_ use a new module
looks a little wonky but happy I don't have to do a lot of refactoring. Thanks all for the help! 17:37
librasteve all "advanced" things (sub, class, etc) are default my or our, maybe you need to go 'our sub ...' to override the default or 'sub blah is export' 17:38
antononcube You misspelled my handle. 🙂 So, I did not see it when you posted it...
mcmillhj I guess I still don't understand why the our subs can't apply to the main module? 17:39
if they aren't lexical, shouldn't it be fine?
antononcube @librasteve Should I submit an issue/request for "in session" version of "App::Crag"?
mcmillhj nvm, I am dumb you do not need the additional module. Just the `our` prefix on the subs
librasteve docs.raku.org/language/modules#UNIT::EXPORT::* 17:41
DarthGandalf interesting. I don't see it in `.say for ::.keys;` though
but it is called 17:42
antononcube You can dump all your generated code into a file and use EVALFILE. (Similar to what @librasteve suggested above.)
mcmillhj DarthGandalf `.say for OUR::.keys;` 17:44
DarthGandalf oh 17:45
librasteve antononcube: probably not, its just a toy - what do you mean by in session?
antononcube I would like to use crag as a function in a Raku session. Say, in a Jupyter noteobook, in order to use crag I have to use an exteranal evaluation cell ("bash"), not a "standard" Raku REPL cell. 17:58
@librasteve I still cannot install "Physics::Measure": zef install 'Physics::Measure:ver<1.0.19>' ===> Searching for: Physics::Measure:ver<1.0.19> ===> Staging Physics::Measure:ver<1.0.19>:auth<zef:librasteve>:api<1> ===> Staging [OK] for Physics::Measure:ver<1.0.19>:auth<zef:librasteve>:api<1> ===> Testing: Physics::Measure:ver<1.0.19>:auth<zef:librasteve>:api<1> [Physics::Measure] # Failed test 17:59
'$fe2.in-km/l' [Physics::Measure] # at t/05-cvt.rakutest line 174 [Physics::Measure] # expected: '10.620186km/l' [Physics::Measure] # got: '12.754311km/l' [Physics::Measure] # You failed 1 test of 52 ===> Testing [FAIL]: Physics::Measure:ver<1.0.19>:auth<zef:librasteve>:api<1> Aborting due to test failure: Physics::Measure:ver<1.0.19>:auth<zef:librasteve>:api<1> (use --force-test to override)
But from your explanation, it seems that using --force-test is just fine. 18:00
librasteve yeah just do that for now ...
hopefully 1.0.20 has fixed (sorry I its a pita to change the locale on my laptop) 18:11
use Physics::Unit; use Physics::Constants; use Physics::Navigation; use Physics::Measure :ALL; use Slang::Roman; use Chemistry::Stoichiometry; 18:23
antononcube: ^^ just do this and then all the App:Crag goodies are right there in the cell
Nahita m: sub EEVAL($code) { state $context = ::; state $ctx-str = '$context = ::;'; ($ctx-str ~ $code).EVAL: :$context; } 'sub g { say "from g"; 72 }'.&EEVAL; 'sub f { say "from f"; g() }'.&EEVAL; 'say f()'.&EEVAL 18:24
Raku eval from f from g 72
Nahita EVAL has a context parameter
antononcube Yes, but it is not explained or exemplified. 18:27
Nahita we prefix each code fragment with $context = ::; to keep installing inner lexical scopes because otherwise a lexpad is immutable once constructed as said, and :: is a short way of writing PseudoStash.new which can behave like (pseudo) a context for EVAL 18:29
20:16 mcmillhj left
nhail my $monitorsProc = run <xrandr --listactivemonitors>, :out; my $rawMonitors = $monitorsProc.out.slurp: :close; is there a better way to do this? 22:51
this works perfectly but idk if there's something better
nemokosch Have you thought of using qx? 22:52
The shell quoting structure
It's like backticks in shell
nhail I'm not familiar 22:53
nemokosch With what? 22:54
nhail With the qx you mentioned 23:28
I know backticks in JS, and in markdown 23:29
nemokosch You can look it up in the docs 23:33