Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

steel... update... of the week (for more advanced rebolers)

 [1/17] from: maximo::meteorstudios::com at: 23-Jun-2003 13:30


hello fellow rebolers... I hope I'm not bothering anyone... but I just wanted to drop a line saying that steel is proceeding as planned (in fact, maybe even ahead of schedule ;-). I have just put the finishing touches on the v1.0 liquid engine... one of the bulding block of the steel application and one of the basic modules you'll have free with steel. Its basically a notification engine which is not signal-centric, but rather data-centric. It now has integrated (and a little bit more flexible than stock) datatype conversion to-from individual nodes and the data master... I have been using liquid's ancestor for a month now and I'm having so much fun... as an example of how it changes the workflow, instead of defining an action function for your text fields, you connect them to a master, and then add an action function to a data handler, if you need it. Integrated to a ui, you can connect labels, menu items, buttons, all linked to that same master. Just by changing the data in the master (actually its more like peer-to-peer), all of the ui updates without you even having to know what is currently displayed on screen... the master keeps a tab of everyone linked to him and signals them to update. my code size has shrinked by half. Moreover, I can build such dynamic setups that its scary, cause its practically free. Anyone who has used BOOPSI before (like I've said in the past, I've used many obscure systems )will understand a little of how it works. BUT liquid is a zillion times more fun to use and is extremelly friendly (a natural reflection of rebol). here is a short code snippet: ------------------------------------------------------ ------------------------------------------------------ rebol [] liquid: open-library 'liquid 1.0.0 ;---- ; create a liquid pipe network (the master) pipe: liquify liquid/pipe [] ;liquify replaces make ;---- ; create a vid layout vidblk: layout [ stylize liquid-steel below sheet-metal ; the default steel backdrop tmp: text do [ tmp/attach pipe] tmp: field 200 do [ tmp/attach pipe tmp/fill "START NAME:" ] tmp: button [view/new layout [tmp: button [unview] do [tmp/attach pipe]]] do [ tmp/attach pipe ] ] recipient: liquify liquid/recipient [ --valve--: pipe ; liquify has an init function which checks if --valve-- was set. fill-action: function [data user-data][ write %./save.txt data ] ] view vidblk ------------------------------------------------------ ------------------------------------------------------ Pressing the first window's button would open new windows which have a button labeled to the string set in the pipe. The tmp/fill call, fills the pipe with data (a.k.a. liquid) ("START NAME:" string!). Also note that the tmp/fill call occurs before the button's attach and it's label will still be set to "START NAME:". Changing the value in the text field will change the label of ALL text displayed in all windows. and we only had to allocate two variables in our code (tmp and pipe). We don't even have to create any action functions to update the ui. the recipient is an object which will get called each time the pipe's liquid will change (by any means). So, that when you fill-in the pipe with new data, you will also automatically save the setup! there's more, but I wanted to keep the mail short... (well, sort of ;-) some of you have had a taste of the glass-ui others know that I am obsessed with dynamicity this was just a short mail elaborating on the kind of tool that you all should expect in STEEL. If you have comments, concerns or requests about steel, it is the right time to do so, I've got my hands dirty... I'll be glad to add or integrate any tool in steel. (who knows, maybe its already planned ;-) I'm even thinking of integrated CVS and stuff like that... so no feature should seem far fetched. that's all folks. -max ----------- meteor Studios, T.D. ----------- Strong enough for a man, but made for a woman

 [2/17] from: roland:hadinger:arcor at: 24-Jun-2003 1:27


Hi Maxim,
> I have just put the finishing touches on the v1.0 liquid > engine... one of the bulding block of the steel application
<<quoted lines omitted: 5>>
> data master... I have been using liquid's ancestor for a > month now and I'm having so much fun...
[...]
> Changing the value in the text field will change the label of > ALL text displayed in all windows. and we only had to
<<quoted lines omitted: 4>>
> you fill-in the pipe with new data, you will also > automatically save the setup!
Whoa -- this is VERY good news for me, I always wanted all of this being possible in REBOL. Orthogonal persistency is an extremely nice feature to have, this also suits the philosophy of REBOL down to the ground, in my opinion, and the example code you gave did look very elegant - with one exception. 'tmp as a word is almost devoid of any meaning and used quite ambiguously in the example, so at first glance I had a hard time to follow what was going on in the nested part at the end. Perhaps assigning different words like 'btn1, 'btn2, ..., to the face instances would make things clearer. But thanks for the info, this already made my day (1:26 am) ...and happy birthday! -- Roland

 [3/17] from: g:santilli:tiscalinet:it at: 24-Jun-2003 10:42


Hi Maxim, On Monday, June 23, 2003, 7:30:18 PM, you wrote: MOA> here is a short code snippet: [...] I have something similar, probably much simpler (I only needed notification). BTW, your code screams for a dialect. ;-) Or, maybe, a custom type... :)) MOA> tmp: text MOA> do [ tmp/attach pipe] Do you need to call attach after init? Otherwise, you could just: text with [attach pipe] or, if you add ATTACH to the words block of each style (or add it to LAYOUT...), text attach pipe Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [4/17] from: greggirwin:mindspring at: 24-Jun-2003 10:50


Hi Max, Sounds very exciting! MOA> ; create a liquid pipe network (the master) MOA> pipe: liquify liquid/pipe [] ;liquify replaces make Without knowing the design goal, my initial reaction is that more standard names would be helpful (e.g make-pipe instead of liquify). Just a thought. -- Gregg

 [5/17] from: rotenca:telvia:it at: 25-Jun-2003 2:26


Hi,
> Orthogonal persistency is an extremely nice feature to have,
Something about strings (and other datatypes) can be already done with: str: "shared" view lay: layout [ button 100 str field 100 str [show lay] text 100 str as-is ] The only problem is to check if the style copies the string or use it "as-is" --- Ciao Romano

 [6/17] from: maximo:meteorstudios at: 25-Jun-2003 15:34


> -----Original Message----- > From: Gabriele Santilli [mailto:[g--santilli--tiscalinet--it]] > MOA> here is a short code snippet: > [...] > > I have something similar, probably much simpler (I only needed > notification).
liquid stems from a notification class I built a few weeks ago. but the liquify command has very powerfull private initialisation methods, which are new and added to the standard make workflow. Each instance can ADD initialisation stuff, which will be recursively called. This basically means that if you base objects on other objects, the master's intialisation stays private and still does iteslf, even if you define your own init as none !!! :-). Each function can ALSO have a public init which basically gets overwritten as normal by the instance of an another object.
> BTW, your code screams for a dialect.Or, maybe, a custom > type... :))
Well, liquify does scan the spec block and does magic with it... you coulds say that its is a tiny dialect which parasites make. ;-) If you do not use liquid in vid, like for the recipient I used in the code, the use is extremely short and sweet (all initialisation is done invisibly, as explained above right in liquify). ;-)
> MOA> tmp: text > MOA> do [ tmp/attach pipe] > > Do you need to call attach after init? Otherwise, you could just:
yes, cause attach executes code to link to the notification master .
> text with [attach pipe]
but does the "with" block really EXECUTE the block or does it just pass it to the make [] call... I thought the later (which would make the "do" a little more pointfull). If the "with" executes the code, what word holds the value of the face being created?
> or, if you add ATTACH to the words block of each style (or add it > to LAYOUT...), > > text attach pipe
... I guess I could patch the vid block and add a word to it so that it is recognized as a an internal facet... but is the invested time worth it if it means glass will be delayed a week or two because of it... I'll have to check if its easy or not... Thanks for the ideas and comments...

 [7/17] from: maximo:meteorstudios at: 25-Jun-2003 15:43


ah... the concepts are so fluid (oops there I go again.. liquid really is getting to me ;-) oh no.. really, its just that all the method names are base on a pipe and liquid flowing to/from them. when reading the docs, you will see that it all gets sooooo clear because all terms map almost directly when following data flow and liquid flow... its also cause I want to be sure the product has its own identity, just as glass uses some non common terms. it all help when you try to differentiate the code in the end... you know that a marble, is not the same part of the system as the liquid or the object. If all where named object something, it gets hard to separate the different levels of code. its also because I'm a creative type deep deep inside ;-) -max ----------- meteor Studios, T.D. ----------- Strong enough for a man, but made for a woman

 [8/17] from: antonr:iinet:au at: 26-Jun-2003 16:36


The answer is self:
>> view layout [field with [text: 'hello print [text self/text]]]
hello hello As you can see, in the with block, you can refer to facets directly or via self. Anton.

 [9/17] from: g:santilli:tiscalinet:it at: 26-Jun-2003 14:23


Hi Maxim, On Wednesday, June 25, 2003, 9:34:22 PM, you wrote: MOA> standard make workflow. Each instance can ADD initialisation MOA> stuff, which will be recursively called. This basically means MOA> that if you base objects on other objects, the master's MOA> intialisation stays private and still does iteslf, even if MOA> you define your own init as none !!! :-). Going to reinvent class-based OOP? ;-) MOA> yes, cause attach executes code to link to the notification master . Ok, but does it need to be linked AFTER the code in face/init has been called by LAYOUT? MOA> but does the "with" block really EXECUTE the block or does it MOA> just pass it to the make [] call... I thought the later MOA> (which would make the "do" a little more pointfull). MAKE. But you don't get any difference wrt DO in that case. MOA> If the "with" executes the code, what word holds the value of the face being created? SELF. You're inside the face object. MOA> ... I guess I could patch the vid block and add a word to it MOA> so that it is recognized as a an internal facet... but is the MOA> invested time worth it if it means glass will be delayed a MOA> week or two because of it... I'll have to check if its easy MOA> or not... Very easy to add to the facets, you could do something like: Style Text Text with [ if not block? words [words: make block! 10] insert insert tail words 'attach func [new args] [ new/attach args/2 next args ] ] Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [10/17] from: maximo:meteorstudios at: 26-Jun-2003 18:23


> -----Original Message----- > From: Gabriele Santilli [mailto:[g--santilli--tiscalinet--it]] > Sent: Thursday, June 26, 2003 8:24 AM > > Going to reinvent class-based OOP? ;-)
hehe not reinvent ... I did that for the wheel ;-) Its just that rebol is a little static when in comes to objects.. I had a lot of "problems" or should I say ... issues... with objects when creating the glass dialect, and I was tired of having to re-code inits and having to call them after creating the object. glass has its own private init system. liquid was always part of the glass design (actually its part of a complete low-level module framework thats 10 years old)... when glass will be at v3 you'll really see new ui concepts (things like parasites and data based ui descriptions)
> MOA> yes, cause attach executes code to link to the > notification master . > > Ok, but does it need to be linked AFTER the code in face/init has > been called by LAYOUT?
not really, if you use attach/quiet it does not actually call a notification... but you could call a notification... since the object already is allocated when parsing the dialect right?
> MOA> If the "with" executes the code, what word holds the > value of the face being created? > > SELF. You're inside the face object.
of course !
> MOA> ... I guess I could patch the vid block and add a word to it > MOA> so that it is recognized as a an internal facet... but is the > MOA> invested time worth it if it means glass will be delayed a > MOA> week or two because of it... I'll have to check if its easy > MOA> or not... > > Very easy to add to the facets, you could do something like: >
ok. I've done fancy styles (like a vid blocking menu system) but I'll need just a few clarifications on this one (if you have time):
> Style Text Text with [ > if not block? words [words: make block! 10]
does the value at the end of "make block!" really matter i.e. could it be 1? is it similar to: [words: copy []]
> insert insert tail words 'attach func [new args] [
new is sort of like "self", but on the newly allocated face, right? I guess args points to the word block at the first argument word (ptr to a notifer, for example),
> new/attach args/2 > next args
and this return the list past all arguments you need... :-)
> ] > ]
this is PAINLESS indeed, Steel v1 will already be easier to use :-) thanks a lot, -MAx

 [11/17] from: g:santilli:tiscalinet:it at: 27-Jun-2003 15:49


Hi Maxim, On Friday, June 27, 2003, 12:23:44 AM, you wrote: MOA> Its just that rebol is a little static when in comes to objects.. The problem actually is, that we have to do things differently. We continuosly try to apply "old" techniques in REBOL, and this is sometimes frustrating. Only when we realize that there's a different way, everything becomes so simple that we feel very stupid for not having thought of it the first time. :) For example, wrt face/init, it's not casual that it is a block. This way, when creating a new style from an old one, we can write: Style MyButton Button [ append init [ ; ... ] ] Who needs inheritance? MOA> I had a lot of "problems" or should I say ... issues... with MOA> objects when creating the glass dialect, and I was tired of MOA> having to re-code inits and having to call them after MOA> creating the object. That's why LAYOUT does that for you. And that's why you usually write a make-xxx function. Another approach would be that of creating a custom type and then defining your TO action for that type, so that basically you use TO instead of MAKE to create your values. (If this was supported by REBOL natively, MAKE would do it for you...) MOA> does the value at the end of "make block!" really matter i.e. MOA> could it be 1? is it similar to: [words: copy []] It doesn't, except for the fact that the interpreter won't have to reallocate the space when you'll be inserting values in it. MOA> new is sort of like "self", but on the newly allocated face, right? Exactly. MOA> I guess args points to the word block at the first argument word (ptr to a notifer, for example), If your VID code is: Text attach pipe ARGS will be set to: args: reduce ['attach pipe] That's why I used ARGS/2.
>> new/attach args/2 >> next args
MOA> and this return the list past all arguments you need... :-) Actually, one position back, because LAYOUT is already applying NEXT to the value you'll return. (This is because it is optimized for the case of facets without arguments, where you just return ARGS without having to worry about advancing it. I find this behavior a little confusing; I would change it if it wouldn't break almost every custom style out there. ;-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [12/17] from: rotenca:telvia:it at: 27-Jun-2003 22:58


Hi Gabriele,
> For example, wrt face/init, it's not casual that it is a block. > This way, when creating a new style from an old one, we can write:
<<quoted lines omitted: 4>>
> ] > Who needs inheritance?
This is inheritance, trough a dialect. Don't you think? In my last vid programs I have found myself using more and and more stylize and style, I encapsulate code in styles, re-use the code, inherited the code, extend the class, add some methods or values (facets or words), replace them, and all with styles (not only). I am more and more thinking that writing Vid code is, at its best, writing custom styles like oo class. For me it is an example of a different approach to oo: with a dialect instead of the usual methods of C++ and Java. --- Ciao Romano

 [13/17] from: maximo:meteorstudios at: 27-Jun-2003 18:43


Hi list, thanks to Gabrielle I created a liquid-metal skin its a superset to the metal skin that is currently in the steel toolset. here is a snippet of code I have at home which works now! note that code size has been cut in half wrt last example! ----------------------------------------------------- ------------------------------------------------------ rebol [] liquid: open-library 'liquid 1.0.0 ;---- ; create a liquid pipe network (the master) pipe: liquify liquid/pipe [] ;liquify replaces make ;---- ; create a vid layout vidblk: layout [ stylize liquid-metal below sheet-metal ; the default steel backdrop text-str: text pipe field 200 attach pipe fill "START NAME:" button [view/new layout [button [unview] attach text-str]]] ] recipient: liquify liquid/recipient [ ; recipient has an init function which checks ; if --valve-- was set and attaches to it automatically. --valve--: text-string/pipe-obj fill-action: function [data user-data][ write %./save.txt data ] ] evrything updates without one action func. further replies below:
> -----Original Message----- > From: Gabriele Santilli [mailto:[g--santilli--tiscalinet--it]] > Sent: Friday, June 27, 2003 9:49 AM
[...]
> For example, wrt face/init, it's not casual that it is a block. > This way, when creating a new style from an old one, we can write:
ok, but layout still has to call face/init ... so the vid dialect handles "dynamic" init, not the object system itself... in glass I must also call some sort of face/init after creating. I know its not a big deal... :-) it just an extra line of code I don't write anymore. It also means initialisation remains private at the object level so I don't need to think about always copying empty blocks and strings or whatever... directly on objects. I love the fact that there are no classes in rebol and that objects aren't instances. But I sorely miss some aspects like private methods and members which, are most usefull (I find) when developping frameworks, api, and tools. I also understand that all this comes at a price that isn't always used by the mass... (that's why python is more flexible wrt rebol objects BUT that's also why its 10 times slower) I do agree with you that rebol thinks differently and the package as a whole is exceptional. Its just a little tough to customize the stuff when the internals aren't overly documented... THAT'S WHY I LIKE THIS LIST... we all have little secrets and I find it cool that people, here aren't affraid to share them :-)
> Another approach would be that of creating a custom type and then > defining your TO action for that type, so that basically you use > TO instead of MAKE to create your values. (If this was supported > by REBOL natively, MAKE would do it for you...)
aren't custom types just in the sdk?
> MOA> does the value at the end of "make block!" really matter i.e. > MOA> could it be 1? is it similar to: [words: copy []] > > It doesn't, except for the fact that the interpreter won't have to > reallocate the space when you'll be inserting values in it.
thanks... didn't know that
> MOA> I guess args points to the word block at the first > argument word (ptr to a notifer, for example), > > If your VID code is: > > Text attach pipe > > ARGS will be set to: > > args: reduce ['attach pipe]
ok, so then when back in layout it does something like?: last-arg-used: my-facet-word-function args new-offset: find vid-spec last-arg-used?
> MOA> and this return the list past all arguments you need... :-) > > Actually, one position back, because LAYOUT is already applying next
[...] weird...I am using: return tail args And it works fine... Am I just lucky? -Max

 [14/17] from: atruter:labyrinth:au at: 28-Jun-2003 11:49


> In my last vid programs I have found myself using more and and more > stylize
<<quoted lines omitted: 3>>
> them, > and all with styles (not only).
I find this as well. I tend to push as many of the business and validation rules into styles (eg. integer-field, date-field, dir-selection-btn, etc) as possible. Regards, Ashley

 [15/17] from: g:santilli:tiscalinet:it at: 28-Jun-2003 9:48


Hi Romano, On Friday, June 27, 2003, 10:58:55 PM, you wrote: RPT> This is inheritance, trough a dialect. Don't you think? Yes, it is a form of inheritance gained from the ability to treat code as data. However, usually people have a precise idea in mind when they talk about "inheritance". (The person you know ;-) would bash you forever if you called what i wrote above "inheritance"!) RPT> For me it is an example of a different approach to oo: with a dialect instead RPT> of the usual methods of C++ and Java. Indeed, REBOL is OO the Smalltalk (dynamic) way instead of the (bloated, complicated, static) class-based way. But, with REBOL, you also have the ability to add class-based OOP in, if you want. Actually, I wonder why noone has done it yet. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [16/17] from: g:santilli:tiscalinet:it at: 28-Jun-2003 10:03


Hi Maxim, On Saturday, June 28, 2003, 12:43:57 AM, you wrote: MOA> But I sorely miss some aspects like private methods and MOA> members which, are most usefull (I find) when developping MOA> frameworks, api, and tools. The nice thing about REBOL is that you can add them yourself to the language. :-) MOA> aren't custom types just in the sdk? Nope, they're an hack of mines (with help from Ladislav and Romano). ;-) You can find it both on: http://www.compkarori.com/vanilla/ and: http://www.rebol.it/giesse/custom-types.r http://www.rebol.it/giesse/complex.r complex.r implements the complex! custom type. WARNING: just an hack, undocumented, etc. etc. Feel free to ask me about how it works etc. MOA> last-arg-used: my-facet-word-function args MOA> new-offset: find vid-spec last-arg-used? It does something like: new-offset: next my-facet-word-function args Let me see if I can find the real code... Ok, inside LAYOUT you have: new: select styles value if not new [error "Unknown word or style:" value break] set [specs facets] do-facets specs new/words styles new: make new either val: select facets 'with [expand-specs new val] [[]] if :var [set :var new new/var: to-word :var var: none] new/style: value new/pane-size: pane-size new/styles: styles new/flags: exclude new/flags state-flags if not flag-face? new fixed [new/offset: where] grow-facets new facets With DO-FACETS and GROW-FACETS being: do-facets: func [ {Build block of parameters (and attribute words) while not a vid word or style.} specs words styles /local facets item ][ facets: copy [] forall specs [ item: first specs if set-word? :item [break] either word? :item [ if any [find vid-words item find styles item] [break] facets: insert facets either any [ all [words find words item] all [find facet-words item] ] [to-lit-word item] [item] ] [ facets: insert/only facets :item ] ] reduce [specs reduce head facets] ] grow-facets: func [new args /local pairs texts colors files blocks tmp][ new/facets: args pairs: clear [] texts: clear ["imanXwin kludge"] colors: clear [] files: clear [] blocks: clear [] images: clear [] forall args [ val: first args switch/default type?/word val [ pair! [append pairs val] integer! [append pairs val] string! [append texts val] tuple! [append colors val] block! [append/only blocks val] file! [append files val] url! [append files val] image! [append images val] char! [new/keycode: val] logic! [new/data: new/state: val] decimal! [new/data val] time! [new/rate: val] word! [ any [ if all [new/words tmp: find new/words :val] [ until [function? first tmp: next tmp] args: do first tmp new args ] if tmp: find facet-words :val [ either 0 >= offset? tmp fw-with [ until [function? first tmp: next tmp] args: do first tmp new args ] [ either tail? args: next args [error "Missing argument for" :val] [ set in new val either positive? offset? fw-feel tmp [ first args ] [ if first args [make any [get in new val vid-face/:val] first args] ] ] ] ] ] ] ] [ error "Unrecognized parameter:" val ] ] new/multi/text new texts new/multi/size new pairs new/multi/file new files new/multi/image new images new/multi/color new colors new/multi/block new blocks ] Notice that DO-FACETS is converting "keywords" to lit-words and then applying REDUCE to the whole block. The result is the ARGS block that then is passed to GROW-FACETS. Here, ARGS is used in a FORALL loop (and this is the reason for the "extra" NEXT you get); the part that uses custom facets from face/words is: if all [new/words tmp: find new/words :val] [ until [function? first tmp: next tmp] args: do first tmp new args ] MOA> And it works fine... Am I just lucky? See above. You're just ignoring any other facet after your ATTACH. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [17/17] from: greggirwin:mindspring at: 28-Jun-2003 9:47


Hi Romano, et al RPT> In my last vid programs I have found myself using more and and more stylize RPT> and style, I encapsulate code in styles, re-use the code, inherited the code, RPT> extend the class, add some methods or values (facets or words), replace them, RPT> and all with styles (not only). RPT> I am more and more thinking that writing Vid code is, at its best, writing RPT> custom styles like oo class. RPT> For me it is an example of a different approach to oo: with a dialect instead RPT> of the usual methods of C++ and Java. This is such an interesting topic that I wish I had time to dig into it (from a research standpoint) and play with different ideas I have. Basically, I think there are two sides to it. One side is the code side, where we approach it with a more standard OO mindset. The other side is the data/dialect side; and that's where it gets interesting. It's not just that we can design and build styles in an OO way, but that the data can be the driving force behind them and that data can be shared with other interfaces. For example, rather than putting the business rules in your style, you build them into a dialect-based framwork. What you do first is model your domain, then, when you know what a customer-ID is, or an order-number, you have use your custom VID dialect to bind those rules to your styles, which then use the rules to validate data entry. The same rules are used for messages sent to the system in other ways as well. This is not a new concept by any means, but REBOL will let us do it more easily, and in a much more natural and accessible way, IMO. Romano, I'm finding the same sort of thing, but I still haven't spent much time understanding VID internals, and my styles are all very basic. At this point, I'm reusing pieces of code more than entire styles. Designing a good set of generic styles will be a lot of work, and has no real payoff for me right now so I'm glad that I can build new styles so easily for just a specific purpose. -- Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted