|
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
|
|||