|
00:01
Sgeo left
00:14
Sgeo joined
00:34
PotatoGim left
00:39
PotatoGim joined
|
|||
| guifa | so I can think of two models for notifying folks of new devices for mDNS service discovery | 01:27 | |
| $service-discovery.register($type, &callback) # call the method provided by clients wanting notifications | 01:28 | ||
| $service.discovery.notifications($type) --> taps a supply of said notifications | 01:29 | ||
| I guess functionally it's not going to be too different, the tap needs an emit value | 01:36 | ||
| antononcube | @timo After I deleted my local repository of "Jupyter::Chatbook" and clone it from GitHub the "BOOTException" no longer appears. | 01:59 | |
| ab5tract | guifa: a supply sounds really appropriate tbh. A react block feels like a decent fit, at least from afar | 02:05 | |
|
02:06
hulk joined
02:07
kylese left
|
|||
| guifa | I'm still trying to figure out the in-practice bit of announcing | 02:21 | |
| it seems part of my issue may be because my device already has a service discovery thing running on it, I'm getting some TTLs that indicate data isn't fresh, and I'm thinking to reduce network chatter some devices aren't responding because they think my computer already knows about them | 02:22 | ||
| OMG | 02:26 | ||
| guifa is a true absolute total dunce | |||
| I left a bitmask in as an actual value | 02:27 | ||
| so all the packets I thought were saying "Are you there?????" were saying "Are you there". And no one was responding because they didn't see a question because one bit was off | 02:28 | ||
| ab5tract | “Your off by one is a bit in a uint. My off by one is a bit in a umask. We are not the same” :) | 02:50 | |
| guifa | If a tap goes out of scope | 03:15 | |
|
03:15
hulk left
|
|||
| guifa | does the supplier know it and stop trying to signal it? | 03:15 | |
|
03:15
kylese joined
|
|||
| guifa | and if so, is it possible to know when there are no more taps ? | 03:15 | |
|
03:19
Aedil joined
|
|||
| guifa | hmm okay when out of scope it does seem to just disappear unceremoniously. | 03:20 | |
| meh guess I'll just have a ton of supplies laying around that no one's subscribed to potentially | 03:36 | ||
|
07:29
Sgeo left
|
|||
| antononcube | My X-account is like that… | 08:41 | |
|
08:58
Aedil left
10:59
sena_kun joined
|
|||
| ab5tract | guifa: not 100% sure but I don’t know if that matters in terms of work being done? I’d have to check to be sure though. Also, I’d expect any truly useful tapping to not fall out of scope / be done in a react block | 11:01 | |
|
12:14
sena_kun left
12:20
sena_kun joined,
sena_kun left
12:23
sena_kun joined
|
|||
| tbrowder | hi, guifa and ab5tract is there a good reference youcan recommend explaining yr usage. hypering and such. very useful, but a level above my head and experience. lizmat has helped me on a specific task, but... | 12:45 | |
| i need a book... | |||
| multithreading with raku | 12:50 | ||
| ok, i just found lizmat's reference to @jnthn's excellent article...gotta get it printed | 13:03 | ||
| Geth | ecosystem/main: b8dffb4208 | (Elizabeth Mattijsen)++ | META.list Remove Sparrowdo::Chef::Client It also available from the CPAN ecosystem |
13:07 | |
| guifa | Actually, as anyone implemented an idle timer efficiently? | 13:10 | |
| cue premature optrimization but Promise.in(...) camt be canceled | |||
| lizmat | $*SCHEDULER.cue(:in(5)) returns a Cancellation object | 13:13 | |
| tbrowder | @jnthn's OO::Monitors module !!! it's wonderful for naive raku users | 13:14 | |
| lizmat | m: my $c = $*SCHEDULER.cue({ say "idle" },:in(2)); sleep 1; sleep 3; say "done" | 13:17 | |
| camelia | idle done |
||
| guifa | lizmat: bless you | ||
| lizmat | m: my $c = $*SCHEDULER.cue({ say "idle" },:in(2)); sleep 1; $c.cancel; sleep 3; say "done" | ||
| camelia | done | ||
| guifa | otherwise I was about have a gazillion Promises hanging around lol | ||
| (because mDNS traffic can be very chatty, and each one potentially can provide a new TTL value for some piece of data | 13:18 | ||
| lizmat | oddly enough this functionality does not appear to be documented | ||
| guifa | it's in role | ||
| docs.raku.org/type/Scheduler#method_cue | |||
| lizmat | aaah... yes ok :-) | 13:19 | |
| guifa | This is currently the class guifa adventure. I want X (advertise services that, e.g., a cro app provides), but to do X I need to generate moduels that do Y and Z and I might as well make them fully featured. Eventually I'll get back to X | 13:20 | |
|
13:33
Aedil joined
|
|||
| tbrowder | lizmat: you're a sweetheart, i just saw that "like" | 13:38 | |
| lizmat | yw :-) | 13:44 | |
| guifa | say $the-best.WHO eq 'lizmat'; # True | 13:46 | |
|
13:50
itaipu joined
|
|||
| lizmat | afk& | 13:52 | |
|
15:14
Aedil left
|
|||
| guifa | hmm, that enum trick lizmat gave unfortunately doesn't survive export'ing. not sure if that's a bug or design (I'm guessing it's design, in that you're only exporting the enum symbol, and not the package itself) | 15:22 | |
|
15:35
Sgeo joined
|
|||
| guifa | nm it does | 15:43 | |
| antononcube | How can the Raku version be determined during runtime? | 15:55 | |
| The answers here are obsolete: stackoverflow.com/q/3018456 | 15:56 | ||
| ugexe | s/$*PERL/$*RAKU/ seems like an obvious place to start | ||
| guifa | yeah pretty sure $*RAKU still has everything | 15:57 | |
| antononcube | I tried that -- does not output anything. | ||
| guifa | m: $*RAKU.say | ||
| camelia | Raku (6.d) | ||
| ugexe | i think you should try again | ||
| guifa | m: $*RAKU.compiler.say; $*RAKU.compiler.version.say | 15:58 | |
| camelia | rakudo (2024.12.25.gf.58.bed.9.f.6) v2024.12.25.gf.58.bed.9.f.6 |
||
| antononcube | Ok, that works. But the equivalent of $*PERL.compiler . | 15:59 | |
| ugexe | m: say $*RAKU.compiler | ||
| camelia | rakudo (2024.12.25.gf.58.bed.9.f.6) | ||
| ugexe | is that not equivalent? | ||
| antononcube | Ok. Yes it is! | 16:00 | |
| Basically, I exected to get a result without using say. | |||
| In a WL notebook session. No say is needed in the console or Jupyter. | 16:02 | ||
|
17:51
Aedil joined
19:53
Aedil left
20:47
bartolin left,
bartolin joined,
lizmat_ joined
20:50
lizmat left
20:51
broquaint left
21:02
broquaint joined
|
|||
| aruniecrisps | hi everyone, i'm running into this issue again: ❯ zef install DB::Pg --verbose ===> Searching for: DB::Pg ===> Found: DB::Pg:ver<1.1>:auth<cpan:CTILMES>:api<1> [via Zef::Repository::Ecosystems<rea>] ===> Searching for missing dependencies: LibUUID, pq:ver<5>:from<native> ===> Failed to find dependencies: pq:ver<5>:from<native> Failed to resolve some missing dependencies (use e.g. --exclude="pq" to skip) i | 21:59 | |
| have libpq installed in /usr/local/lib from last time, but i'm not sure where DB::Pg is looking for it. | |||
| timo | i think zef just doesn't have an implementation for finding something from "native", so just put --exclude="pq" in the install command and it should work | 22:03 | |
| aruniecrisps | i'm looking at my message history, i ran into this problem earlier and i seemed to have fixed it with symlinking, but the thing is even though libpq is symlinked, it's still giving me this problem | 22:07 | |
| i also tried running zef install DB::Pg --exclude="pq" zef install --exclude="pq" DB::Pg and zef --exclude="pq" install DB::Pg, but it's still throwing that error | 22:17 | ||
| ab5tract | aruniecrisps: I wonder if it could be a versioning issue? `--exclude="pq"` _should_ work, but | 22:56 | |
| maybe using zef look and altering the META6.json dependency to match your installed version is worth a look? | 22:58 | ||
|
23:14
xinming left
23:17
sena_kun left
|
|||
| guifa | can a hash both autovivify and autostore? such that %hash<previously-unused-element>; results in that key now existing? | 23:46 | |
| using %hash<foo> //= Foo.new right now but I feel like there ought to be a better way | 23:47 | ||