AltME groups: search

The plugin posts data to a CGI on the proxy and that's how I can 
control the proxy and store requests for repair

hum... and the proxy configuration is handled by small cgi requests?

you see, what I see here is that the actuall application data is 
on the server and your browser based plugins are just synchronised 
to it.

but its nowhere near ready... I'm starting to look at the discrepancies 
of tcp/ip and liquid models.

if elixir where ready for release, then, yes it would be a simple 
click and drag... but alas, its not there yet..

I will try to use the liquid concepts adding attributes to the nodes 
and do a "classical" plugin for the proxy

if I had just a bit more time, I'd be glad to help, but comming back 
from the devcon has but a strain on my time (a lot of time to make 
up at work and at home)

Nevr mind, Maxim. Talking about this with you suggested me easier 
way to implement such services and this is an help too!

but seeing people's real use cases helps me see where to put the 
time on whatever I do next, and your example shows me that I am dead 
on my priorities  :-)

I will be giving a lot more tutorials and examples, in the following 
weeks.

and supporting people who use it.

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!!!

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 ;-)

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

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  :-)

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.

ciao and thanks for the interest... any question you have, I'll be 
happy to answer.

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)

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)

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.

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.

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

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 ...

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... :)

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.

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.

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.

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
 * ....

The truth is, I do not have the reflex of using liquid for most of 
my coding, still, but actuall exposure and use, is forcing me to 
value its effect on my code.  this is empiric use, not advocacy. 
 If you could see just how easy it was for me to build fully bug-free 
AGG gadgets in so little time, you'd understand.


its not about just sharing data between gadgets, its about allowing 
your code to know what's going on.

and in fact, if we do add a measure of reflexivity to VID, we will 
just be redoing most of liquid, or run in the same issues, I had 
in my other prototypes, which led to this design.   ;-)

but we will not gain the advantage of having generic dataflow!

its also nice to know that your GUI is actually capable of reflecting 
data.  not just gui.  change the data:

fill data value


and don't even have to wonder IF and HOW any gadget should change.

but I know your POV.  but you don't see how limited that becomes. 
 we could have what you propose and ALSO have full DF.

it wont remove what you propose... and in fact its not even more 
complex in use.

Hi Max,

Do you have any demo apps using liquid ? Something simple, but usefull 
to help me (and others) understand how and when to use it.

Hi doc, The version of liquid on line is not quite the latest (obviously)... 
 but I'll check out your info... its possible that one was already 
fixed.... I fixed a few minor bugs  since I last released.  Mainly 
due to intense use within glob and elixir.

dideC: well, I'm am working towards that.  I am keeping up the habit 
of working on one thing at a time and currently I'm hard at work 
on Revault.  that being said... guess what are the first libs to 
be put online  ;-)

unfortunately, demo apps are still not available.  One person using 
liquid is making a for profit dentist EMR and scheduling app.  there 
is elixir, and there was the original liquified draw dialect example 
I had released just before the new year.

once revault is at least put to demo on line and I start getting 
feedback, I will turn to liquid fullblast...  what I am really looking 
for are examples of simple apps which can be liquified.

so, my answer to DideC, I guess, is:  

Give me ideas on simple demo applications I can build ! 

And I'll consider which one I do first.  :-)


 I need and want this info to make the whole package more appealing 
 and comprehensible.  The current uber simple Sum example, just gives 
 a glimpse of the engine's capabilities, not of its application.

Sorry if that was confusing. Most of my code has no user interface 
at all. It runs without intervention. Any monitoring or command interface 
is seperate. Most of my data points correspond to physical objects 
in the real world, and the code mostly tracks and directs these objects.

yes that would be easy (figuratively speaking) now it obviously depends 
on the nature of your interfaces and what you track...

and won't trigger other events.

basically a connection based TCP i/o interface to any liquid network. 
 you define the ports, the protocol (on either end) and can then 
interface your Dataflow across machines  :-)  it would allow distributed 
processing without any understanding of such concepts.

so one (actually several)  machines can be a controler and synchronise 
to others which can also locally change their states... and whatever 
they data can generate can be sent to any other machine, including 
the controlers... so you have ONE kernel to handle all aspects of 
your systems.  and its dead easy... and would interface directly 
within any other liquified systems like liquid GL, elixir, globs, 
or eventually GLASS.

want text ports, just make a liquid which spues out text on the console... 
need that logged, just plug in another node which spues out stuff 
on disk as it comes in... but you don't even have to change anything 
in your systems... and can even easily connect your logger to other 
nodes, so you can track the flow of traffic, or the end effects some 
root events are having on the outputs of the system.  sometimes its 
not obvious to see the real world relation of inputs and output... 


liquid allows you inspect all states at all points in time of you 
system's processing and compare it.

and actually generate other data from it  like diffs or comparison 
reports. :-)

Max, on of the best examples would be a Rebol based simple 20x20 
Excel clone. Let people use Rebol code in the cells, and handle the 
reference handling via Liquid. It should be perfect DF applicable.

It would probably be easy to plug liquid in to nanosheets. I'd like 
to see that too. The current evaluation order is fixed L->R-->Top->Bottom; 
with liquid you might be able to do away with that entirely, and 
let the evaluation drive things.

mario, mind maps are very cool... I would like to make an optimised 
tool for quickly creating and organising mind maps in elixir but 
I can say that I hope others will join me in adding toolsets... its 
the whole point of elixir, an open, common framework of integrated 
and live tools.  anything goes into anything, so you can do things 
like share data between, you graphics, mind map and project management... 
why not even use some of it to drive the GUI building for one of 
the panes... I mean, in the end, they are all being used for one 
goal.

robert, If I start from scratch, it will be an n dimension spreadsheet 
with a scale of infinity in each of those dimensions (thus really 
limited by RAM, disk and REBOL types).   why start it up with a limitiation 
which is actually very easy to design correctly for starters... 


especially with GLayout which would just adjust the views as they 
grow.

I'll mail it as well. Not on REBOL.org...just time, priorities, and 
lazyness.

basically going to use a HASH of liquid nodes (the nodes themselves 
being already connected) and just asking for cell values, based on 
what cells are visible within the scrollpane.

and gmail chat

Max lives in a world of his own ... and I don't know the address!

I've been using liquid in a variety of projects for the better part 
of 2 years now... its ubber stable, fast and quite scalable... in 
fact much better than I had anticipated, for such an un optimised 
piece of code.

elixir, for example,  easily allocates 10 000 nodes, creates a several 
thousand line AGG script and actually manages to rebuild the whole 
AGG dialect block faster than view can redraw it.

elixir builds a 100% native AGG GUI .   EVERYTHING is built using 
liquid, event the field (control) properties and cursor management.

the first real GLASS gui prototype is implemented within elixir... 
the whole field widget is about 30 lines of code IIRC and data is 
bound to input type without any coding needed within the actual widget.

I havent done the OS level UI, just the work area system... but the 
OS level GUI is a piece of cake.  basically, just an interactive 
browser of your data cloud, using the query language and user d specified 
tags and information classification.

basically I want to use rebol 3 core and wrap it within an OS shell.

do a movie and let us see what you've got ...

and movie visual effects industry too.

Local TV company is broadcasting in HD using H.264 and although I 
can record, I can't playback :(

Maxim: do you have something cool to menage nodes and trees ? would 
you share? 8)

the difference with dataflow and liquid specifically is that there 
are no functions in the whole application.

Max, I still wait for a simple to follow example and some simple 
to follow docs.

Josh: for simple data compilation and changes (like a D&D character 
creation/evolution), I suggest writing an aspect-oriented type of 
node set for your  application.

basically, how this works is, you have a generic object which you 
pass around from node to node.  each node may add/display/change/remove 
one or all of the attributes in the objects.  


Just plug some aspect-managing node to your "current" node and that's 
it, over and over.   Its as easy as calling a function on an object. 
 the difference is that all states of your character are still available 
up till its creation. 


 you can even branch off at any point and try out another combination 
 with NO risk of corrupting your previous data.

then another aspect called "armour-class" can be added and it know 
to use the current dexterity bonus to itself.


now you can build up the whole character, up to 12th level like this 
(adding all skills and levels, etc), and at the end, decide you want 
to see how it results with an elf, instead... then paf, you change 
the root aspect "race" to elf, which causes dex to increase by one, 
and since everything is still connected, your ac is increased by 
one, without ANY single other thing to do than ask for the resulting 
character.

using this technique, I was able to do skining which is independent 
of the gui engine underneith.  one only has to support the aspects 
in his skin and the skins (and gui using them) remain valid, even 
though you are running on opengl or vid.

yeah I understand... really I do.


as I used to say... "I buit it, and it works really well... but I 
still don't know how to use it !"

but I have spent many hours using liquid, testing it prototyping 
it, and even building an OS Operating Environment with it...and I 
now know its a viable idea.

I'll build up a quick and dirty aspect-driven, character creation 
tool  :-)

basically, the gui will be plugged-in to the aspects directly, and 
the aspects data entry will also be plugged-in directly to the gui 
 :-)

and it was profoundly prototypish, I realise.  not enought comments 
for me to even remember how to use... so I'm scanning my old test 
code in order to make it much more usable.

btw wrt the old code, I realised the issue... I had cleaned up the 
lib, and stopped half way....   so the naming changed, a few features 
missing... :-(

ok, so I have something to send to you... what I have is not really 
usefull to send to rebol.org without any kind of discussion, documentation. 
 I did something different than expected.  I just built a simple 
dataflow driven fsm engine which switches aspects on demand.  then 
I defined aspects which operated on a face, and made a very simple 
feel which sets the various states.

the dataflow takes care of calling any aspect which are built up 
from linked nodes.  basically, you build up a stylesheet by connecting 
nodes together and can branch off at any point, simply reusing the 
previous styles as a base... the cool thing is that the styles aren't 
absolute, you can define more than one style for a single state, 
so that a series of nodes can handle only the edge, others the color, 
yet you can include both in another style  (in my case, the base 
style has both)

I'll add a few more aspects to the system to show how this all scales, 
tomorrow and send you a copy.   :-)

next step will be to add some data to manipulate... I'll do a character 
attributes builder.  all 6 stats with a +/- counter besides each 
which you press and all the display magically adapts, even stopping 
the buttons when out of range, or no more points to attribute   :-)

all is built using direct faces... no VID no GLayout... just make 
face []   so you can understand exactly what happens, and realize 
how easy it is to replace VID, even in R2.

plus, its spring break and I'm with my kids... so taking time with 
them.

ok, so I have a bit of spare time tonight and will build you a stand-alone 
example of a small RPG character editor.   Using !plug objects directly, 
so you can see the process of subclassing the core plug to have it 
do something usefull.

did most of the work yesterday, and will revise it to use VID.  it 
just going to take a little less code.  I think.

its already working, but will add a few gizmos to give it more depth. 
  liquid makes more and more sense, as an application grows.


so adding a few features will show you how simple an application 
remains, even when many things interdepend.

right now I have str, dex, int fields, which cannot contain anything 
else than an integer value, and which are bounded in value...

the detail here is that the bounding is NOT done in the field, but 
at the value level itself.  nothing can cause the data to be invalid.

and the field, thus gets refreshed since its piped to the value.

it will definitely be available tonight.  btw, I found and squashed 
a little but in liquid, so will also release a newer version on rebol.org 
when I release the example.

you can't "forget" to update something, everything is broken up into 
little systems.  the systems don't grow, you only have more of them, 
which is easier to manage and design, IMHO.

hehehe... means a system doesn't work at all until it does... and 
from that point on... its almost impossible to mess up.

you just move on, and forget what has been done so far.  adding stuff 
to a system, doesn't mean patching old code.  it simply means tacking 
new systems to the old, and deciding how they relate.

and apparently I missed the message saying you were uploading it

if you can read (and understand) my last sentence... you are less 
tired than I am  ;-)

Interesting...  I'm a heavy prototyper.  I need one statement that 
does something to start with and I often have to see each additional 
statement functional before I can move on to the next.  If I spend 
enough time within a given environment I'll eventually be able to 
rebuild it from scratch but your code has always been deceptively 
simple so I often need an explanation of why you do what you do how 
you do it.

also note that liquid was NEVER optimised, so if you look at its 
code, you might find slow loops and such... I know!  for me, having 
it work without bugs and making it easy to maintain, is more important 
than raw speed... in all apps I've done using it, a single View face 
refresh slowed down the application more than alll liquid nodes combined, 
so the integrated lazy computing does enough optimisation on its 
own to make raw optimisation less of an issue.... but when I decide 
to go v2, I will make a "fast" version of the tool for production 
purposes... indentical in features, but with debugging removed and 
some loops optimised for speed.

To some extent, yes. We do record counts of "likely human views" 
vs "likely bot views" -- but the stat you see is the sum of the two. 
And the division is not perfect by any means.

I'll slightly reverse my previous statement......The "download this 
script" link is protected by a HTML attribute "rel=nofollow". That 
should prevent well-behaved bots from following the link. So the 
count of downloads is likely to to human rich.

I'm still looking through it.  I will modify some parts of it later 
today or tomorrow, and let you know if I have questions