AltME groups: search

We want a "non-perspective" deform, I suppose.

Does anyone knows what is the actual algo when resizing an image 
as a face attribute using 'aspect or 'fit ?

Actually, there is a diffrence when upscaling but not when downscaling

I think bilinear only works when scaling up. for scaling down, you 
need a different smoothling algorithm. I noticed this in Canvas as 
well

Sorry Cyphre, but if you want to make thumbnails, you need possibility 
to save them as JPG. PNG is too big for thumbnail and there are still 
problems with this format. Forexample today I had problem when I 
wanted to use PNG as a background texture with IE.

a workaround is to blur the image a few times before scaling it down. 
A little time consuming, but if you need HQ thumbnails right now... 
:-)

not yet, but I have it on my 'todo' ;) ...will let you know in a 
few days.

So someone would have to make the Rebol/flash convertor for them 
to be able render it in Rebol. Maybe a good enhancement for Oldes? 
;)

Which means you need either a clever parser, or a call to new AGG.

have a look here to get the idea how Flash renders:
http://blogs.msdn.com/mswanson/archive/2006/02/27/539749.aspx

BTW I'm currently working on some DRAW fixes from RAMBO. So I'd like 
to ask all DRAW users: If you have encountered a serious bug which 
is not in RAMBO, please put it in so they can be fixed in this round.

How about a way to change the coordinate system?

I'd like to see a way to set 0,0 to bottom left ...

I think using top left 0,0 is a bug :)

Graham: lot of people could think writing from letf to right is a 
bug too :)

Maxim...  I've created all the plugs I need to process each value 
in a font object and they are working beautifully but I'm having 
trouble figuring out what the master !font node should look like. 
 I need to be able to copy changes from each of the nodes handling 
the individual values into an object that I can pass to VID.  Do 
you have any words of wisdom to share on this? ;-)

Ah, what wonders a few hours of rest can work.  I just need to produce 
a plug that takes a series of inputs and converts it into an object. 
 I was overcomplicating things (again...)  When I get back from work 
I'll take another shot at it and this time I think I'll go with a 
dialected approach.

pipe servers hanlde multiple view of a single value, coordonating 
everyone so they collaborate in how they share that value.

Is there a movie that shows how liquid works?

pekr:  yes using liquid interactively is one of its mandates.  the 
liquid editor, will be used in this way, changes will be viewable 
in real-time, so the first set of nodes that are going to be integreated 
are globs, which allows a graphic package to be built within a day.

all the entry points can be pipes, which are combined into a singular 
node.

I can just see you with the lightning bolt crackling in the bg and 
a wild look on your face...  hahahaha

Liquid rocks!  I'm getting very close to my goal here and when I 
run into a bug 90% of the time it's because I didn't plug everything 
together properly.  It's pretty sweet.

happy you are "getting" it   :-) it can be a wee bit unsettling when 
the system starts to be knowledgeable about itself.

my most common bug, is to forget to put something stainless or to 
ask for a value... hehe

I turn round and round and wonder why nothing is being printed on 
the console...  then after a very long time... hehe I realised I 
never asked it to perform its  task... hahaha

The last one I ran across took me 15+ minutes to find a reference 
to face in a plug that never got set.  I couldn't figure out why 
it did nothing...

Sounds like a special tracing/debugging functionality should be included.

plugs also have the generic stats method, which gives A LOT of info 
about the current state of the node.  links, state, type, serial 
numbers, etc.

its a simple download and run... all libs are d/l for you in same 
dir... can't be easier to try out.

in this example... way to much, cause we are basically including 
very basic nodes and a core gui api, but if you remove that, in fact 
there isn't that much left.

with the external libs I am building (actually working on them daily) 
code use will be very small.  since the most complicated part of 
the engine will be wrapped within liquid-vid, and you will have a 
lot of example and reusable liquid classes to start off with.

its like a sticky fly trap.

all of this has to be wrapped inside a dialect !

I have built several systems which used dialects... but liquid allows 
so much variance, that its like building a dialect for functions...

but a single function... liquify can actually perform 5 operations 
in one single line, including linking to any number of pipes at once... 
so there would actually be very little code gain.

dialects will be usefull when the use of the plugs is well defined, 
and your plugs  are pre-defined, then the dialect will effectivey 
shrink code size by a huge amount... but that's just like for any 
dialect use.

I guess we could make a generic dialect which uses a set of pre-determined 
plugs (a bit like a vid stylesheet) and just builds up a network 
a bit more easily...    this is planned....   the dialect function 
already has a name.... :-)

an obvious example is a setup where you have a series of inputs, 
which are all linked to one plug which compiles them as an object.

if part of a gui, the "submit" button is inactive, until all conditions 
are met.

all the label types, will just need one link to a different font.

grids are much easier (actually quite easy) to build with liquid, 
and in any case, its still faces... so importing a gadget is dooable, 
if rebgui doesn't depend on too much out of widget infrastructure.

skining will be dynamic (I mean you plug a color gadget and the whole 
ui interacts as you set the scheme).

I've been re-designing the wrapper around the system for a week... 
trying to find a sweetspot between flexibility and styleability.

Max, would your engine be good fit for a spreadsheet calculation 
engine? Steve Shireman wrote this nice tiny spreadsheet widget (http://www.efishantsea.com/nano-sheets.zip), 
I guess that pluging liquid inside would make a killer demo both 
for liquid and REBOL, don't you think so?

I looked at it a long time ago, but realised that its basically easier 
to start from scratch... cause if you remove the processing aspect 
of nano-sheets... there's not much left.

but once liquid-vid is released... really its going to be very easy 
to build up grids and a little equation builder.

Max, you should try to find a route to attach liquid to existing 
GUI like VID or RebGUI. By a dynamic hook or so.

Otherwise it's a all-or-nothing thing which makes it hard to bring 
liquid step-by-step into an existing app.

Overall, it still sounds like a multi-path constraint solver to me.

I myself am building it with faces directly.  so its just going to 
be a quick integration to VID, use of a few facet words and voila.

liquid v0.8.1 released:
changes in this release (from last public release)

	v0.7.2 - 8-Mar-2009/21:25:55(MOA)

  -officially deprecated and REMOVED SHARED-STATES from the whole module
		-ON-LINK() 
	
	v0.8.0 - 15-Mar-2009/00:00:00(MOA)

  -adding stream engine for propagation-style inter-node messaging.

  -STREAM() added for look-ahead messaging (ask observers to react 
  to us)

  -ON-STREAM() added to support callbacks when a stream message arrives 
  at a plug.
		
	v0.8.1 - 28-Mar-2009/00:00:00(MOA)

  -PROPAGATE?() added to valve - allows us to optimise lazyness in 
  some advanced plugs

  -LINK?() regression found and fixed... cycle?() was not being used 
  anymore!

Liquid has been tested under R3 and crashes it outright.  so R3 support 
for liquid will wait until R3 is a bit more stable, unfortunately. 
 I have enough stuff to debug without having to wonder if its the 
platform that's causing the bugs in the first place.

Maxim - I have sent you a note on my intent to add to my piece on 
"slim Liquid Rebol" at eclectic-pencil -  I will pen that note in 
blood ...  piping can be so much more feral that ducts ; - )

any question you have, just ask here and will help as much as I can. 
 I've tutored three people so far, and it seemed to be easy enough 
to grasp that within a few hours, they where semi autonomous.

remember that dataflow is not just about using a new library, its 
a paradigm change in how you develop and design an application.  
so most of the difficutly is not in the actual coding of the plugs... 
which is really easy, its understanding what, how and why they are 
doing their stuff.

it will happen. in a short while, I just had to stop working on personnal 
projects for a week or two... life has a tendency to cut into fun 
stuff... things like lawsuit threats, have a "slight" precedence 
over me hacking away at a keybord for the sheer fun of it   ;-)

actually, I buy all of my digital enternainment.  games, DVDs music, 
etc.  I mean, I (have/do/will) live off of all three mediums... so 
it would be a bit hypocritical for me not to encourage others in 
my own trades

I've got a relevant question

they can even have different data in each... as long as its a two-way 
conversion it would work.

rebgui, not a clue.

all you need to do is capture the action, send a message to the relevant 
liquid. if each control has a liquid which is responsible to set 
the control, when it receives data, they will update by themselves.

how about a one page example of two text lists upddating each other 
?

so just don't do a copy/deep!

whenever one creates a change, that change is performed on the original 
data set, and everyone is made aware of the new data.

cause one data might be a string, another an issue, one a word, and 
still one a tag.

you could have a decimal range, and have it expressed in other formats, 
like colors, or sliders, progress bars... but they still all reflect 
the same original data.

one list might be filtered by gender, another by age, but add a new 
member to the list, and both will reflect the change... however it 
happened.

normally you have to know that whenever the list changes, you have 
a slew of functions to call, labels to update, what if the cursor 
changes, due to some insertion, deletion, what if the current selection 
is deleted... all examples which have to be handled globally... and 
the more the application grows, the hairier it becomes.

and dataflow is a management layer, so patching a flaky event engine 
like view's has to be done properly.

hum... I seem to be getting the reichart syndrome... there is a *NOT* 
missing before "really hard".

easy is a vague term.

but no, its not "hard" its just not a 5 line affair.

so at what point is there a payoff?

payof is in:

 -robustness.  there are NO loose ends, no forgetting.  its impossible 
 by definition.

 -long-term dev speedup: adding features doesn't increase complexity, 
 since all features are developped completely independently.

 -speed: properly designed, lazyness can make an application quite 
 fast, even for very complex apps.  obviously, there are worst case 
 scenarios.. like anything.
 

add a dialect in the mix, and then the code size will shrink a lot, 
but since REBOL itself, isn't dataflow enabled, patching liquid within 
other REBOL components doesn't really benefit from a dialect.  cause 
creating, connecting and processing nodes is really simple.

to get two gui lists to share a dataset, will take as little as two 
nodes.

just wanted to drop a little note saying that I have been using liquid 
for the last few days developping a brand new application (which 
I am not at liberty to disclose right now)  ...


DAMN... its just soooo sweet... really... adding features is "add 
and forget".   not "pry-in and pray" I have been adding feature after 
feature, everything is interconnected, graphical, and not only does 
it allow me to move forward without ever looking back, everything 
that is liquified in the software is down right unbreakble and bug 
free. 


software source  has trippled in size and I have spent only about 
4 hours in a whole week's worth of coding for resolving bugs.  More 
news to come in a little while.

I will be releasing the first liquified api shortly, called paint. 
 this is a rebrand of the infamous glob engine.  This engine allows 
people to use draw, just like if it where faces, where individual 
graphic elements (or groups of them) can receive face-like events.

liquid is a kernel. its goal is to manage processing, by using messaging 
and state at the atomic level.  so it can be used by anything, anywhere.

but in a sense, API's like paint alleviate a large part of the need 
for VID.  cause the dataset is actually "aware", it doesn't need 
someone controling it... in fact its aware at such a granular level, 
than it can actually prevent the majority of processing from happening.

all you need is a controler which knows what the system is "supposed" 
to do, set it up... and leave it to run by itself.

in the app I am building right now, I'll give you the best example 
of how powerfull dataflow can be.  after developping a complex and 
interactive canvas, with animation, and stuff... a new spec comes 
along, that basically changes the coordinate system of the whole 
engine!!!

we have tried to run liquid within R3 an it crashes rebol...  but 
I didn't have time to figure out why, its a pretty complex object. 
 but I will have to look at in sometime this summer... the simple 
10X speed gain of AGG is enough to make it worth, especially since 
gobs provide internally of what paint simulates in R2.

now if Carl is interested in working with me on making this a reality, 
I will definitely give some time to the effort.  even if we only 
use liquid for some part of VID it would make a lot of stufff SOOOO 
much simpler to write afterwards in application, and lazy programming 
really pays off in terms of economies of processing.  in my application, 
rendering 1 graphic or 100 cause no more processing in most circumstances! 
 only the AGG aspect of things slow down.

ultimately, to allow all liquified code to interconnect as one seamless 
system.  its already starting.  Once I have the network plug done 
(relatively easy but not yet a priority), things like the collaborative 
text editors are going to be trivial to code.


I am already working on a collaborative paint concept.  where we 
all draw and manipulate the same canvas without locking!

I even want to allow several people to play with individual CVs of 
a single shape concurrently... its actually harder not to allow it 
than to let it happen!

hm.. sounds mega interesting, I really need to dig into this a little 
more :)

Max, you have a communication problem. A lot of people are interested 
but "don't get it". If you want more people to give it a try you 
need to make the entry very easy. Questions and things I see:

3. The whole data-flow stuff should be like a plug-in into existing 
R2 code. So I just want to take a simple VID based example, attach 
the dataflow stuff and give it a try.

1. liquid needs no config
2. the naming IS very logical.  

3. impossible, liquid is a kernel, you cannot plug liquid Over, you 
have to build tools with it.  and NO I don't force you to use anything 
cause I don't use it myself.

all of my graphics work, even glayout has always been using VID. 
 Using face/init face/action face/feel of standard vid gadgets... 
the blood example of liquid on rebo.org is such a VID example.


4. liquid has never forced you to use any adapted VID, using slim 
is one line of code, no "config and install required", liquid isn't 
even graphics related.

liquid is so low-level, that it could replace the basic datatypes 
themselves, I we could code accessors like in python.  using python, 
I can build a liquid which replaces the core datatypes and makes 
it completely invisible.  this is not possible in R2 and I'm not 
sure accessors will be as open as they could in R3, time will tell... 
 at least brian seems to be on the same page as me wrt this.

rebol is a pretty closed language in the sense where there isn't 
much room to change rebol itself.  you can obviously replace functions, 
but not the real heart of the engine, the datatypes.  Other languages 
like python let you have access to the complete internals of the 
language.   This is often related to class usage, for which it is 
easier to provide hooks and callbacks. 


rebol is a language which doesn't promote objects as the core paradigm, 
its much closer to imperative programming than most "recent" languages. 
  R3 was/is? supposed to let us build our own datatypes, and has 
been reported as eventually providing for some level of accessors 
for objects.   This will make it easier to integrate tools like liquid 
seamlessly.

I often feel like there is a bridge to cross when using liquid.  
on one side, you have object and imperative code which needs a management 
layer over it, and on the other side, you have code that is more 
"aware", it is self-managed.  It knows what is going on, you tell 
it in advance what it should and then let it work on its own. 


 the hard part is to cross the bridge, both in understanding HOW to 
 use dataflow effectively (and that's not related to the name of the 
 functions ;-),   and then there is the actual coding where you'll 
 pretty much always have to bridge the gap between parts of an app 
 which are dataflow and those that aren't.

a small liquid news tidbit.


liquid-paint is now being used as the core engine for two new commercial 
apps, one is going to be based on paint-lab, my up and comming vector 
paint app, which is already working pretty well.

I'm working on a completely new site, with more than just programming.

I just want to share this cause I'm all excited... 


I've been working a lot with liquid recently and I think I've just 
tought of an algorithm which would allow "atomic" multithreading 
using liquid.


it would mean building a kernel which manages the nodes, but basically 
several threads would creep up a liquid processing network in an 
async manner and resolve branches out of order, based on a thread 
semaphore and a stack to realign dependencies...  


If this works... It means Elixir OS could possibly have a multithreaded 
kernel, resulting in ALL applications becoming multihreaded without 
any specific coding needed by the developpers.  :-)


adding a few networked services... you could leverge an entire cloud 
(render farm) without even having to code a single specific line 
of cloud and thread stuff, and this would be directly embeded at 
all levels of the OS down to the button properties... cause even 
the most basic gui properties are built up of tiny liquid nodes...

its going to be a really brain numbing kernel to build, but I really 
see the whole flow in my head.  It doesn't feel impossible like random 
compression so far. ;-)

imagine it like if the kernel, knowing what functions are eventually 
going to be called, pre-emptively starts a concurrent stack and executes 
some stuff in advance, and then inserts the results just as the original 
thread encounters it.  now imagine this using 8 threads in parallel...

brainfuck anyone  ;-)

whenever two parts of a piece of code aren't interdependent, ex:

;-------------------------------
ctx: context [b: "111" prt: func [ data ][ print data return 77]]
result: call-some-func 66
ctx/prt result 
;-------------------------------


they can be forked independently... here both lines 1 and 2 can run 
concurrently, so that the third line, when encountered will already 
have its results, all it needs to do is make sure both ctx and result 
are done.  if it has to wait, then that line is put on the stack 
and the thread jumps to another part of the code in need of processing 
(possibly a part of  call-some-func() can be run concurrently.


when all upper dependencies are met, threads start popping back to 
parts of the code waiting down the stack. until all the code has 
been flushed and the last line of the initial function is all that 
is left to execute.

so instead of having a kernel using a stack its using a tree.  Am 
I right in saying that  this is a shift from the turing machine? 
 :-)