<beneroth>
freemint, btw. I would be interested in a pil wrapper for telegram.
<freemint>
beneroth: i proposed several levels of implementatino, i would like your feedback on that. Do you need a refresher?
<freemint>
my ideas are for the telegram bot are 1. dumb interface (message "bla") '*Group1) 2. an http_server like setup (text is parsed in to commands triggering functions) 3. 2 but with addtional times/conditions/IFTT(if this then that) to make use out the "push" side of messaging and domain specific language to manage all that.
<freemint>
or to express in existing picolisp analoges: 1. 'client 2. @lib/http.l 3. @lib/form.l
<beneroth>
yeah. I'm interested in telegram.l :)
<freemint>
beneroth: how does that help me with my decision. I have 3 ideas how to do it.
<freemint>
And i can not decide.
<beneroth>
ah. well I understood as one idea. I would split the stuff up.
<beneroth>
1) telegram.l which does the wrapping, so which handles the telegram API. 2) telegram-hooks.l (or however you name it) to do your text parsing to trigger something 3). telegram-trigger.l for the IFTT features.
<freemint>
good idea.
<freemint>
I might start in a month or so earliest.
<beneroth>
different layer for different tasks/logic. 1) is just encoding/decoding, pil API for telegram.
<beneroth>
no pressure. :)
<freemint>
beneroth: that really helped me -
<freemint>
thanks
<beneroth>
you're welcome
<beneroth>
make an effort of trying not to build unnecessary restrictions on the lower level functions (e.g. type/number of arguments or so). I mean: try to only restrict what is necessary to be restricted to gain the intended functionality, but try to no have any other restrictions which are a result of "it will never be used that way anyway".
<beneroth>
this is one of the things I learned and try to make a habit thanks to picolisp (applies also to other languages)
<beneroth>
that way you get great re-usability and maintainability you can't plan for.
xkapastel has quit [Quit: Connection closed for inactivity]
<beneroth>
freemint, I watched the full talk. Thank you very much for pointing this out! Great talk!
<beneroth>
I wish I would have found such an explanation of systemd a year ago. I researched a bit but not enough, as it appears. the notion of systemd being intended as a universal process-watchdog I kinda missed until this talk, and I can see the attractiveness for that concept.
<beneroth>
humm.. I still suspect the systemd implementation is rather flawed, but I can see the concepts are meaningful and valuable.
<beneroth>
I will forward the talk to other people. Thanks freemint !
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
ubLIX has joined #picolisp
<rick42>
<beneroth> and in a way it serves as a good filter to keep the people away who are not really interested in understanding programming stuff, who would probably attempt to pollute picolisp with comfort.
<rick42>
Read: pythonifying the language. lol :)
<beneroth>
I don't know python enough to say so :)
<beneroth>
One thing is having a tons of libraries, that must not be bad. But compromises on language principles is another thing.