<schmars[m]>
jow i'm looking into ucode-ctypes and callbacks. fwiu it wouldn't even need a pointer registry, if the respective libs and callbacks take a userdata argument (e.g. `void *ext` in libyaml or `void *data` in jech/dht.c). is that pattern common enough in C to require it for ucode-ctypes? freeing the callback closure (or func) would be the callers responsiblity anyway in all options i could come up with
tidalf has quit [Remote host closed the connection]
tidalf has joined #openwrt-devel
autkin has joined #openwrt-devel
<jow>
schmars[m]: the pattern is common but not universal, most openwrt libs for example use struct embedding + offsetof instead of userdata pointers
<jow>
schmars[m]: I am also working on a port of luajit's ffi + ctype infrastructure to ucode, which will likely be a superset of the current ctype module proposal
<jow>
schmars[m]: means I am undecided on how to deal with ctype right now, whether to merge it only to deprecate it in the near future, or whether to include it's api 1:1 in the upcoming ffi module
<jow>
as subset
tidalf is now known as Guest11160
Guest11160 has quit [Ping timeout: 480 seconds]
robimarko has joined #openwrt-devel
<schmars[m]>
jow ah that's good to hear - i'm not actively using ctypes yet, callbacks are a dependency for what i have in mind, so don't worry about me
<schmars[m]>
what i have in mind is a custom dns resolver behind dnsmasq that serves a TLD from a custom community-internal bittorrent dht
<EHeM>
What should a rule depend on in order to require package/kernel/linux/module to be processed before the rule? (appears "package/kernel/linux/compile" isn't right)
<EHeM>
(rule is part of something in package/ )
minimal has quit [Quit: Leaving]
<rmilecki>
i just learnt that "uci reorder" and then "uci commit" affect hashes
<rmilecki>
section hash of moved section points to a different section
<rmilecki>
is there a way to know a new hash of moved section?