>> if true [print 2] 2 >> if false [print 2] == none >> b: 3 == 3 >> b: [3 true] == [3 true] >> if (second b) [print 1] 1 >> c: [3 false] == [3 false] >> if (second c) [print 1] 1 >> if (do second c) [print 1] == none >> if (do second b) [print 1] 1
Kaj
Yep
The difference is not so much DO, but BIND
Endo
c: [3 false] ; this should c: reduce [3 false] ; to get desired result
Maxim
Endo yes, that is the prefered method.
Josh
Got it. I have a better working version now! Generates a new schedule that shows for each hour who is available
Anyways, to keep on topic with !liquid, I have a !plug that generates the schedule of availability, it's of a particular type, can I just link it to another type to process data from that? I ask this because I'm not sure what the following line does at the end of the Process(plug,inputs) function
plug/liquid: available
week=> weak
Cyphre
Endo, IMO the best method is to use :
c: [3 #[false]]
Endo
But it leads problems when encapping the script.
Maxim
Hi Josh, here is your inital example rewritten. I put three versions for you and all to compare.
you will have to update your repository, as It doesn't contain fluid and there have been a few fixes since you forked my libs.
and in my scripts, I'll thus use do %../slim-libs/slim.r
(btw, in the above scripts, the scripts where in a subdir of the project, so they have %../../ instead of %../
Maxim
Endo, yes, serialized values are the death of many encaps and the encap system being extremely faulty led me to write a String parsing equivalent which doesn't LOAD scripts.
Josh
Maxim, nice! I will rearrange the libs and adapt my code to match the style of yours if I have time tonight
Maxim
happy it helps you. There will be some improvements to the fluid dialect again this week for sure. We will start using it at the office, so it should be solid (pun intended ;) very quickly.
now if you realize it, adding new stuff to the app is quite easy because you can just link to some of the data which is already processed. no need to even know why or how it ends up there. you can just rely on it being up to date each time its manipulated.
Josh
There can be circles in the graph, right? and different types of plugs as inputs would be differentiated with an if plug/type = !sometype conditional in the process function?
Maxim
in theory, liquid allows circular references, but by default they are verified and prevented. the reason is that when a dependency is modified, it will run in circles indefinitely telling its observers they should adapt.
Maxim
for differenciating input *plug* types, at processing that is not something you should be doing. plugs should not behave differentely based on what type of plug they are linked to but what type of data is comming in. There are a few philosophical and a few technical reasons for this. all of them concerned with your well being in the future.
its funny, my co-worker asked me the same exact thing today and I showed him that it was better to find a different way to link his stuff ... which did in fact solve the problem he had created in the first place.
its a bit like function parameters. their order is significant, you don't react based on which other function called you, only to the data which comes in. in Liquid you have the extra option to have variable number of inputs. it makes it tempting to try and figure out what type of plug sent you each item of data, but its better to just make sure the data items are of the type you expect and put extra effort into linking your stuff properly. the network is as significant as the data flowing through it.