AltME: Liquid

Messages

Josh
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.
http://www.pointillistic.com/open-REBOL/moa/files/josh-test.r
http://www.pointillistic.com/open-REBOL/moa/files/josh-test-fluid.r
http://www.pointillistic.com/open-REBOL/moa/files/josh-test-glass.r
Maxim
btw, I usually put my libraries at the same depth as my projects, so that all my projects use the same libs by default.... so I have this on disk:
dev/projects/
    slim-libs/
        slim/
        liquid-libs/
        glass-libs/
        utils-libs/
        ...
    projectA/
    projectB/
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.
in the examples I wrote, you'll notice how I inspect the input data within the '!AVAILABLE plug type.  that is the proper way of filtering out input.  also, since you'll be setting the plug/liquid to none, and each node will likely ignore any none input, it just fails gracefull, until one node in the graph decides its can recover from bad input and reset part of the graph below it.
Josh
I see a few things I was doing improperly,  The data plugs don't need to be the !available plug type.  You set them as containers.  Is the PICK DATA 1 just getting the first linked plug?  If so, iss that a common practice? (The order of linking is important?)
Maxim
yep, you got everything right  :-)
the linking order is guaranteed to be preserved (until you change it)
Josh
Which is why I was worried about !plug type to begin with, but using containers is just data, unless it isn't a leaf
Maxim
containers are always leafs... anything you use  'FILL on becomes a leaf (or more precisely can be or contain, a leaf)
when you fill a plug, it bypasses the normal dependency system.  but you can setup a plug so it uses both the filled data and the links.  
When you set it up like so, the filled data acts just like a link, which you can decide to be always the first or last item in the process data you receive.
Josh
If I dynamically create a lot of plugs/containers with random data and linked them to a plug, what would be the best way to unlink them if necessary?

Last message posted 308 weeks ago.