<glima>
the problem is that the category of the node should be float
<glima>
having a separate module just for arctangent is overkill
<ceolin>
glima: isn't it a sample ?
<glima>
but then we lose that out-of-tree demonstration the guy did
<glima>
it's sample and a node
<glima>
willing to move it altogether to float.c
<ceolin>
but it was made to build out-of-the-tree right ?
<glima>
also out of tree, but our build system builds it too
<glima>
and we get an arctangent.so
<ceolin>
ok, i'm not sure if I understood the problem
<glima>
i don't want to have to package a new module containing just an arctangent operation
<ederson>
yeah - i understood that it's a sample of having a node out of tree
<glima>
kind of ridiculous
<glima>
if we follow this we might as well had one doing add/del/etc
<ederson>
glima: yeah, we could, and it wouldn't make sense
<ceolin>
are you packaging samples ?
<ederson>
but, why do you have to package it, anyway?
<glima>
ceolin: no, but modules
<glima>
ederson: i have to handle all .so outputs on the build
<ceolin>
so, you shouldn't be bothering with it
<glima>
i don't want to have to skip it
<glima>
??
<glima>
it's a sample with a new node!
<glima>
(and module)
<glima>
the sample isnt packaged, but the node is
<Sachiel>
why?
<ceolin>
glima: I know, but it is still a sample, don't build the samples when packaging and you will not have to deal with it
<glima>
+++ b/src/samples/flow/tilt-angle/Kconfig
<glima>
+ depends on USE_FLOW
<glima>
+ tristate "Node type: arctangent"
<glima>
+config FLOW_TILT_ANGLE_ARCTANGENT_NODE
<glima>
@@ -0,0 +1,9 @@
<glima>
+ default m
<glima>
i could ditch it
<glima>
but then, don`t we want the arctangent feature in the lib?
<Sachiel>
do we?
<glima>
sooner or later one could ask for it
<ceolin>
well, we can add it later, I mean, if this doesn't make sense as it is now, you can improve and make a node and add to the lib. But currently is not a problem for the packaging task
<Sachiel>
sooner or later one could ask for a module that orders pizza from dominos, go package one
<glima>
ouch, samples have to be turned off one by one on the build, it seems
<glima>
ederson: damn. if we follow the path of the arctangent node depending on the sample, we get a circular dependency, according to samples-check rule :/
<glima>
i`ll use the global samples switch only, then
<ederson>
glima: isn't the sample that needs to depend on the node?
<glima>
yeah, moving back to that
<glima>
good, new broken dep on samples found
<ederson>
=D
<ceolin>
btw, is anybody here against remove nodejs bindings ?
<glima>
if done today/asap, nope :)
<glima>
lots of corners to clean on the infra, ugh (semaphoneci ppa packages need love, etc)
<Sachiel>
I am. I love nodejs bindings
<Sachiel>
they are the reason of my existence
<ceolin>
glima: remove it will mae everything easier
<glima>
ceolin: sure
<ceolin>
and btw, what is the hurry ? abut today
<ceolin>
Sachiel: would like to maintaing them ?
<Sachiel>
no need, I love them just as they are
<ceolin>
*maintain
<ceolin>
Sachiel: there are too many love in you, where is real Sachiel ?
<ceolin>
there is
<Sachiel>
I bought icecream with 42% discount, of course I'm full of love
<glima>
ceolin: just tired of this, wanna finish soon :P
<glima>
lol
<ceolin>
Sachiel: are you becoming a couch potato ?
<Sachiel>
nah, I walked there
<ceolin>
:)
<ceolin>
92 files changed, 7699 deletions(-)
<ceolin>
glima: ^
<glima>
%jailson
<Sachiel>
pffffffffffffffffffffffffff, all that for under 10k deletions...
<ceolin>
will send the patch
<ceolin>
Sachiel: it was incomplete
<glima>
ederson: did make samples work at master for you?
<ederson>
yes
<glima>
ederson: it seems we fail on GEN build/stage/samples/flow/grove-kit/lcd/grove-lcd-autoscroll-gen.c