r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Liquid] any questions about liquid dataflow core.

Mario
18-May-2007
[423]
A suggestion: put the working full script as a downloadable file 
(rebol.org or a link from liquid site) at the beginning of the page. 
I did the example step by step following the page and, at the endo 
of my tests I found the full script I colud copy and paste!!!
Maxim
18-May-2007
[424x4]
and it seems, by a strange twist of faith, that I suddenly have A 
LOT more time on my hands... (I'll let you figure out why ;-)
thanks, good idea  :-)  point taken
but then, its possible having done each step helped you understand 
the magic trick  ;-)
when you see just the trick, you usually are clueless ;-)
Mario
18-May-2007
[428]
I think that samples are a must for such kind of stuff. VID, Draw, 
Services, rebcode and similar powerful things lost their momentum 
due to the lack of eaxamples imo
Maxim
18-May-2007
[429]
ok, well I have to log off, but I agree.  The liquid part of my site, 
has a usefull simple tutorial, but it needs more advanced examples 
and stuf, and that's where I'm at now  :-)
Mario
18-May-2007
[430]
I Agree, Maxim. I was thinkg the same thing whan I met the script...: 
"Maybe Maxim wanted me to understand the basics before I play with 
this new toy or I won't appreciate it"
Maxim
18-May-2007
[431]
it used to be that I was scared the spec of liquid would change too 
much and I would run into support issues, but so far, its remained 
backwords compatible for the last year... and I have implemented 
VERY complex systems using it, so I am now confident its in a state 
of production approval.
Mario
18-May-2007
[432x2]
I sue similar tricks as a teacher, maybe you made the right choice
sue=use
Maxim
18-May-2007
[434]
hehe.
Mario
18-May-2007
[435]
See you
Maxim
18-May-2007
[436]
ciao and thanks for the interest... any question you have, I'll be 
happy to answer.
Gabriele
19-May-2007
[437x4]
max... i've been studying liquid and how it can be used (or not ;) 
in vid+ (or vid2 or vid3 or whatever we want to call it)
my conclusion is the same as nenad's... it's overkill :) i think 
i can do all that users need to do with just event handling. that 
is, recognizing that in the ui everything is about events. the system 
does not need a network, just direct "links" between elements (call 
them widgets, styles, etc).
from the user pov, it looks like a network, but internally it is 
not. in particular, events don't need to be propagated (this avoids 
the cycle problem altogheter)
i'm interested in examples where this would not work. (i think i 
can reproduce all examples i have seen from you so far, ie. sliders 
attached to fields and so on)
Graham
19-May-2007
[441]
Does it make it easier for ordinary programmers though?
Volker
19-May-2007
[442x2]
Just in Mozilla: Was reading rss in sage, opened bookmark-editor, 
moved bookmarks, sage was updated. i think liquid is for such things. 
also the wiring can be shown graphically. Have seen that with Visual 
Age did that long ago. If it is well done its not a bad idea. I still 
fear it will be hard to debug, since all this wiring is invisible. 
Or maybe: it was to easy to create for me. BAck in that days i found 
such connetion-stuff cool and created a lot spagethi. (was not using 
VA, that method worked with pure oops too^^)
Later i moved to oberon. Oberon does not use explicit connections. 
Instead each event is broadcasted to everything. WHich may broadcast 
it to its inner parts. I found that to be easier and more flexible.
Pekr
19-May-2007
[444]
Well, if we interface to user via a dialect, then it is ok to me. 
The thing is - web is full of various frameworks. I read about them, 
about their ideas, and it is OK. The trouble is, that for the thing 
to be usable, you have to study, what the framework author though 
about, when he/she was creating a framework. And I fear, that way 
too much abstract framework will distract coders, as they will not 
understand, how to extend it, etc.
Gabriele
19-May-2007
[445]
graham, i believe easier than using liquid ;) on the dialect level, 
you just use "attach" like max does in liquidgl.
Pekr
19-May-2007
[446x2]
I think that VID is nice. Dialected aproach is the way to go, that 
is for sure. I would be OK, if VID would fix some things as - tabbing, 
cursor change, accelerator keys, visual focus representation to widgets, 
disabling/enabling (for business wide widgets), resizing, methods 
for drag & drop etc. Look e.g. at VID's feel - it was abstracted, 
that you have central storage of "feels", but was that abstraction 
used to any good by anyone? I like self-contained styles/widgets 
of rebgui better.
Let's create new VID, which will be both easy to use from user perspective, 
yet easily extensible for developers. That means, that engine has 
to support those basic functionalities from the very beginning, otherwise 
we will be in the trap once again ...
Gabriele
19-May-2007
[448x2]
petr, we may not be able to deliver all of that for july (or maybe 
yes, depending on community help), but it's certainly planned and 
will happen
volker: broadcasting to everything... do you think that scales well?
Pekr
19-May-2007
[450x2]
Gabriele - that is still nice. I did NOT expect View to be released 
at all, so ....
I thought Core comes first (but more complete), then View ...
Gabriele
19-May-2007
[452x2]
the compositing engine is almost ready... so why not release it.
we may not be able to emulate r2 faces in july... so no compatibility... 
but other than that it should be functional
Pekr
19-May-2007
[454]
Gabriele - but, what I would not like to see is - to start with system, 
which is not flexible enough - e.g. old VID - you CAN'T add some 
things later, unless you count on them from the very beginning! Then 
docs appear, ppl start to produce scripts, and then we complain that 
we can't change it, because there is lots of dependency ;-) Please 
bear in mind, that NOW is the time for the change ...
Volker
19-May-2007
[455]
Gabriele, did i notice i used Oberon? :)

Fastest thing i have seen on a P100. Maybe muchmore on Amiga could 
compete :)
Gabriele
19-May-2007
[456x3]
that may mean that they were smart, it doesn't mean that broadcasting 
scales well. ;)
eg. imagine if every face got every event.
also... we have network events, system events, you could have usb 
events and many more... do you broadcast everything to everything? 
when an event generates another event, is it broadcast to everything? 
it does not seem a great model to me... :)
Pekr
19-May-2007
[459]
Gabriele - is there new event system in View? IIRC we were thinking 
along the lines of plugging some external library into rebol - libevent, 
liboop, etc.
Volker
19-May-2007
[460x2]
It works for the gui. I dont step into theory about slow, if i have 
a real life example which is fast :) about everything to everything, 
that would be in a bad case: each event to 100 receivers, 100 events/sec, 
10k dispatches/sec. cpu can do 1 billion instructions. 10k instructions/event. 
most of them: i am interested? no. ~100.
100k instruction/event.
Gabriele
19-May-2007
[462x2]
petr, yes and no. yes in the sense that events come from devices, 
no in the sense you mean (libevent). i don't see why we would need 
libevent or anything like that.
volker... oberon may be doing tricks, such as not really broadcasting 
to everything... so the fact that it is fast does not make the approach 
a good approach.
BrianH
19-May-2007
[464x3]
No multithreading on Oberon (back in the day - Active Oberon has 
it now). They managed multitasking through shared memory structures 
and other interesting tricks.
Because of this it was able to manage a full GUI and still be as 
fast as DOS.
Single process, no virtual memory - through other tricks, they managed 
to avoid needing it. Because of this the event broadcast, like everything 
else it did, ran by itself on the bare metal. Hence the speed.
Maxim
22-May-2007
[467x6]
Gabriele, liquid (dataflow) adds a level of stability to any project. 
 the fact that its lazy pays off very well so far.
the system in its current form is not meant to be easy to code  (for 
maintenance reasons).  I know many ways to change this, but before 
going to far, I had to have as stable an architecture as possible.
I have gone through 3 rewrites before hitting this sweetspot.  other 
versions might have been simpler in a way, but left the system, non 
generic and unscalable in one of many different ways.
liquid's strength lies in the fact that it is generic.  we all write 
dataflow within our applications, without realising it.  but we then 
recode each little system in its own isolated architecture.  this 
means we just loose a lot of time.
I was able to write elixir in about 40-50 hours of time and the only 
bugs it has are within the parts of code which has no dataflow.  
everytime I trust liquid and switch part of the code to it, I end 
up forgetting about that part, because it gets to be so stable.
I am as anxious as all of you and understand ALL of your qualms about 
using dataflow and liquid. 
 *complexity?
 *speed?
 *scalability?
 *difference in programming model
 * ....