[00:25] *** xinming left [00:27] *** xinming joined [00:35] *** xinming left [00:37] *** xinming joined [00:47] *** xinming left [00:49] *** xinming joined [00:55] *** xinming left [00:57] *** xinming joined [01:02] is there a lazy regex/match? something that provides incremental matches on a very long stream of characters? [01:06] i'm using m:g/ ... / maybe that's it? but the $/ is a list, not a seq. [01:08] nm [01:08] i wonder if anyone has tried to switch out the string that's being matched against during the matching ... [01:09] it's probably not that hard to do one match at a time and just increase the starting offset parameter and appeding to the string and/or cutting parts off the start as you match past them? [01:09] *** kylese left [01:10] *** hulk joined [01:26] the least efficient way might be to split the string into overlapping lengths of the longest possible match and then run the regex against all of them [02:06] *** xinming_ left [02:15] *** hulk left [02:15] *** kylese joined [03:54] *** Aedil joined [05:30] *** Sgeo left [05:45] *** [Coke]_ left [05:59] *** [Coke]_ joined [06:03] *** [Coke]_ left [06:13] *** xinming left [06:15] *** [Coke]_ joined [06:20] *** [Coke]_ left [06:49] *** [Coke]_ joined [06:54] *** [Coke]_ left [07:07] *** wayland joined [07:08] *** wayland left [07:23] *** [Coke]_ joined [07:50] @tonyo “your module needs to export your resources for your test to see them” — Yes, this is how I did it : https://github.com/antononcube/Raku-LLM-RetrievalAugmentedGeneration/blob/a6420c76eb5d264c59dfe4d16c06b17b40247b02/t/01-ingest-vector-database.rakutest#L11 [07:52] *** [Coke]_ left [08:03] *** sena_kun joined [08:21] *** [Coke]_ joined [08:26] *** [Coke]_ left [08:49] *** PaulW2U joined [08:57] *** [Coke]_ joined [09:06] *** Guest44 joined [09:07] Hi, I want to invite you to a new free social network! [09:07] The network does not collect personal data, you can find out more on the website https://dkonapp.github.io/start [09:07] Thanks for your attention! [09:14] *** Guest44 left [10:07] *** [Coke]_ left [10:13] *** [Coke]_ joined [10:14] <[Coke]> seen lucs [10:14] <[Coke]> .seen lucs [10:14] [Coke], I saw lucs 2024-08-28T21:30:52Z in #raku: And can that be changed? [10:37] *** MoC joined [12:57] *** patrickb left [12:58] *** greenfork left [12:58] *** atweedie left [12:58] *** atweedie joined [12:58] *** greenfork joined [12:58] *** snonux left [12:58] *** snonux joined [12:59] https://github.com/Raku/problem-solving/issues/438 [13:01] *** snonux left [13:01] *** snonux joined [13:08] *** snonux left [13:09] *** snonux joined [13:09] *** samebchase left [13:10] [Coke]: i'll rm my comment ... having login probs at the moment [13:12] *** BooK joined [13:27] antononcube: why are you using ‘use lib’ in your test? [13:29] See https://stackoverflow.com/a/55940571/1772220 [13:29] @ugexe I assume(d) that might be bad. I try not to have them in the released packages that “stable.” The reason is that I start the testing both from CommaIDE and terminal. If I do not have use lib I get inconsistent results. [13:29] @ugexe Thanks! [13:30] Using use lib in tests is generally bad form. Using ‘use lib . lib’ is *always* bad form [13:33] Ok, I will gradually remove those from all of my packages. [13:33] *** lichtkind joined [13:35] Is there an explanation or discussion why using use lib <. lib> is bad form? I think I saw a comment about that from lizmat a few years ago. [13:38] I’ve made that explanation many times over the years so they exists somewhere. Alas I’m on a phone and don’t have the means to find one. I mentioned in example in that SO post but more generally it can cause extra precompilation [13:39] *** hudo_ left [13:40] using lib lib specifically is particularly bad because it hides issues with the meta6.json that cause code to fail on install even though it tests fine [13:40] such as failing to list a module in the provides section [13:41] *** samebchase joined [13:42] use -I. when invoking a test from the terminal. Use whatever mechanism Comma presumably has to set the lib path for testing [13:45] For tests “use lib” should be reserved for including libraries only for testing such as t/my-test-libs that won’t be installed [13:47] *** samebchase left [13:47] *** samebchase joined [13:50] *** clarkema left [13:51] *** snonux left [13:52] *** samebchase left [13:52] *** greenfork left [13:52] *** atweedie left [13:57] *** snonux joined [13:59] *** samebchase joined [14:00] <[Coke]> tbrowder: thanks, not trying to be a jerk about it - I agree that priorities need to be set, but in-ticket doesn't work (I had so many of these kinds of things in raku/docs) - I tried using discussions there, but that is bad for different reasons. You should definitely track those asks though. [14:01] <[Coke]> tbrowder: I hope now that I have an azure box running Blin I can also get one running raku.land for dev work. (getting it working on mac osx was... challenging) [14:02] *** samebchase left [14:02] *** snonux left [14:07] *** clarkema joined [14:07] *** patrickb joined [14:07] *** snonux joined [14:08] *** Sgeo joined [14:10] *** samebchase joined [14:14] *** atweedie joined [14:14] @ugexe Thanks -- I will search / investigate explanations. [14:15] *** greenfork joined [14:52] *** xinming joined [15:07] *** MoC left [15:15] *** itaipu left [15:29] <[Coke]> m: with Date.today { say "WHEE" if .day-of-week==5 && .day==13} [15:29] rakudo-moar dde756878: OUTPUT: «WHEE␤» [15:30] *** itaipu joined [15:43] *** discord-raku-bot left [15:43] *** discord-raku-bot joined [15:47] *** bdju left [15:49] *** bdju joined [15:59] *** xinming left [16:01] *** xinming joined [16:02] [Coke]: meep [16:04] <[Coke]> hey - thanks for the docs fix. [16:06] *** xinming left [16:06] Sure thing. Um, luckily (just saw your message in raku-doc), those colons had nothing to do with ratcheting (I hadn't considered such a possibility at all). [16:09] *** xinming joined [17:02] *** Xliff joined [17:02] \o [17:02] 2024-08-29T20:49:15Z #raku Xliff: looks reasonable [17:02] Has anyone been able to get C++ Templates (ala Generics) working with NativeCall? [17:23] *** xinming_ joined [17:40] *** swaggboi left [17:45] Even though we have support for C++ name mangling, I think it’s still only really possible to do much binding based on extern functions [17:45] *** swaggboi joined [17:46] That is to say, I don’t know if any OO or fancy type stuff is directly accessible:( [17:47] I would love to be proven wrong though [18:28] i am slowly weaning myself off use lib in my tests .... largely by going zef install . --force-install --/test each time [18:37] ab5tract: Yeah, it looks like most Generic handling will h ave to be done with POPs (plain ole pointers), while actual generic classes will have to be Madlib handled ahead of time. Which defeats the point of Generics in the first place. [18:38] C++ has VERY limited reuse potential for generics EXCEPT for C++. [18:38] That is unless support for them is directly implemented by Moar. [18:40] There is a tentative long term goal of studying whatever Swift is doing, as they are reportedly having some success at more direct integration with C++ [18:45] *** Aedil left [18:46] That seems like the holy grail. Probably by the time we get there everything will be rewritten in Rust. At least we can hope for a robust Rust ABI by that point :) [19:15] Pah! Rust. [19:15] I mean, if we can steal it for MoarVM, great! [19:16] But after what I've read on NativeCall, I don't know if what they are doing will translate. [19:16] Really, what Generics will need is macros. [19:34] *** kaskal- joined [19:35] *** kaskal left [19:36] *** xinming left [19:46] *** lichtkind left [19:52] “they” meaning Swift? [19:55] If Rust proves to be just as opaque a target for binding as C++ is, it hopefully won’t be so taboo to mock the Rewrite in Rust movement [19:56] On the other hand, if they can deliver a smooth. next generation ABI, I’ll welcome and encourage their replacement efforts [20:06] Oh, so will I. I'll just be biased. [20:09] imagine a binding layer that can tell you what it offers [20:09] *what is offered [20:15] C++ generics require either a C++ compiler or a C++ interpreter to work with [20:16] if you already had a c++ compiler build the instantiations of all the templates for you before, you can just load the .so that has them and use the code that way [20:16] at that point they "are no longer generic", they are now "specific" [20:20] I'm not sure what Xliff had in mind, but in Java you have access to parameterized types when you load the .jar [20:20] or maybe I mean un-parameterized types which take parameters [20:21] this is what I tend to understand as "generics" [20:24] *** thaewrapt joined [20:24] Here's a reference to what the Swift folks are thinking on the topic: https://forums.swift.org/t/c-function-template-specialization-and-generic-functions-in-swift/42016/6 [20:52] I think there is a fundamental difference in how generics work in Java an C++. Java has type erasure, where generics actually work with type "object" under the hood. While in C++ the compiler makes a copy of the templates class, replaces the placeholders with actual types and compiles the result whenever you specialize some template. [21:06] yes, with type erasure it's easy to support everything with just one set of bytecode [21:07] C++ on the other hand allows you to put objects with different memory layouts in and the code it compiles is then correct for whatever you put in [21:08] think of this example - i don't know cpp template syntax by heart, so pseudocode: `template add_as(A a, B b) { return A.a + B.a }` [21:09] now make a set of structs: `struct one { uint64_t pad[1]; uint64_t a }; struct two { uint64_t pad[2]; uint64_t a }; struuct three { uint64_t pad[3]; uint64_t a }; /* and so on and so forth */` [21:10] every combination of A and B generates different assembly [21:13] on the JVM i'm not sure exactly but it would have just one set of bytecode that would be interpreted, and if it becomes worthwhile the JIT will make whatever native code at run time [21:13] with templates, what you get is C++ source code, on the JVM you get bytecode [21:13] if you want to have NativeCall work with templates, you have to, at some point, parse the C++ source code where the template is defined [21:14] there is no built-in "reflection" in C++ where you can ask "where in this struct is the field named a placed?" [21:15] you need the source code, the header files. that's also why for every generic that shows up, you compile a full set of needed methods and functions for all parameters that are used anywhere [21:18] *** sena_kun left [21:18] Yeah, C++ templates really are macro-like. That's why it breaks some people's heads. I love the feature I just hate what a lot of people are doing with it. [21:19] *** sena_kun joined [21:21] I _think_ you can make an endrun around at least some of that via llvm but even C++ without templates is a damn tough nut to bind [21:21] i mean, llvm also has a c++ parser and compiler [21:23] i wonder what you can get out of dwarf debug symbols when it comes to templates [21:24] Yes, it does. As well as some “above and beyond” introspection tooling, iiuc. [21:25] But timo++ made some important points that highlight how templates probably are not particularly useful in the wrapper library context. [21:26] i guess it's time to realize why projects like swig exist [21:29] *** sorenson left [21:33] *** sena_kun left [21:35] *** sena_kun joined [21:37] "if your application somehow involves the instantiation of 50000 template classes, your mileage might vary." [21:40] I've always appreciated swig as a legendary and seemingly unsurpassed bindings generator. at the same time, I'm not sure if I've ever encountered it as a dependency on any binding source I've encountered... [21:54] *** sena_kun left [21:55] *** sena_kun joined [21:59] *** [Coke]_ left [22:00] *** sena_kun left [22:07] antoncube: that looks like your test is requesting the resources, not like your module exposing them [22:07] maybe the resource access has changed though, idk [22:20] *** jjido joined [22:26] *** [Coke]_ joined [22:31] *** [Coke]_ left [22:32] oops, disregard - [22:39] *** ian47 joined [23:14] *** [Coke]_ joined [23:16] *** wayland76 joined [23:17] o/ [23:18] Does anyone know why XDG::BaseDirectory (either 0.0.14 or 0.0.13) is giving me "required attribute 'perl-version' is not defined"? [23:18] Is it because my raku version is too old, or is there something else going on? [23:19] *** ian47 left [23:21] *** [Coke]_ left [23:22] For timo, ab5tract, and vendethiel, regarding the "leave" discussion earlier this week, see https://github.com/rakudo/rakudo/issues/5577 [23:23] .tell vendethiel regarding the "leave" discussion earlier this week, see https://github.com/rakudo/rakudo/issues/5577 [23:23] wayland76, I'll pass your message to vendethiel [23:44] *** _________ left [23:45] *** _________ joined [23:47] *** bdju left [23:47] *** bdju joined [23:51] @wayland76 I have a good, useful MVP of the LLM RAG package. [23:51] I want to implant a few more features then I will release it. [23:53] *implement (not “implant.”)