World: r3wp

Last year I created a small database which I wanted to talk to via 
a dialect. So I created a builder dialect that would build the database 
command dialect in two sets, one for server side for query handling 
and one for client side for response handling, so 3 dialects.

Then I would build client- and server-apps using a make-file like 
dialect which preprocesses and builds apps and uploads them to specific 
locations. 4 dialects. Great amount of control. Very little code.

( pypy is python interpreter in python )

Henrik: very interesting

Janko; you may know this; dobeash.com has RebDB as well as a SQLite 
driver.   RebGUI with RebDB ...  livin'   :)

btiffin :)  yes I use their sqlite driver and it works great , haven't 
tried rebdb or regbui yet

Though not included in the rebol.org submission (it's in QM), I actually 
have two data matching dialects that use the same validation vocabulary 
(in both cases, set-words are the anchor to each rule).


 import [this "1"] [this: integer! is 1] ; import extracts name/value 
 pairs

 match [1][this: integer! | decimal! is 1] ; match evaluates a free-form 
 dialect


Both have different basic expressions, yet use exactly the same validation 
code.

VID:   How I can change button color? I tried:
view layout [ a: button red [  a/color: 0.0.0
        show a]
    ]

but nothing happens....

yeah, typical problem ....

IIRC, button colors are being held elsewhere. I don't remember if 
there were introduced accessor functions for them, or not ... let 
me see ...

Color in a button is a graduated effect.

Take  a look at:
    a/effect
and then try changing it something like:
    a/effect/3: 0.0.0

(It ought to be easier!)

Thank you, I'll try and let you now!
Cheers!

yes, it ought to be easier. the color of the button is a hardwired 
effect that is calculated upon initialization of the button. when 
initialized, it can't be changed easily without knowing the source 
code for the button style.

>> view layout [b: button "OK" red [probe b/effect]]
[gradient 0x-1 255.32.32 223.0.0]


I think that you might be able to change those tuple values, but 
will it work with gradient easily? :-)

>> view layout [b: btn "OK" red [probe b/effect]]
[colorize 255.0.0 128 extend 14]

you need to check feel/redraw to make sure the effect is not overwritten 
by it

If I put 
b/effect: [ gradient  0x-1  0.255.0 0.255.0]
??

MaxV - to study it further, you can type following in console - print 
mold get-style 'button

Should work, remember to call show b in you code ...

also remember, there are two button versions - button, and btn - 
slightly different. You might also be interested to look into RebGUI 
VID alternative ...

Yes, yes. 

I'm trying to write a italian guide to Rebol, but now it's coming 
R3, and VID will be changed significantly., so I use Rebol just for 
the programs I need. 

I think that Rebol is what a programmer really needs, but finding 
guides about it is so difficult...

>> view layout [b: button "OK" red [probe reduce [b/color b/font/colors 
b/effect]]]

[255.0.0 [255.255.255 255.180.75] [gradient 0x-1 255.32.32 223.0.0]]

yes, R2 was kind of rather badly documented. And VID2 is really not 
that easy to hack, extend, beyond what it does. In the past I was 
reluctant to use RebGUI, because it looked rather unatractive, but 
that is not case anymore ....

Yes, I was confused by b/color

hmm, seems b/color is the red color. b/font colors is font colors 
- normal and over, b/effect - dunno ...

well b/color after initialization is ignored, so I have to change 
effect

this is the button's init function part - it looks if you have image 
for button, and if not, then:

            if not any [effect effects] [
                either color [
                    effects: reduce [

                        reduce ['gradient 0x1 color + 32 color - 32]
                        either all [block? colors colors/2] [

                            reduce ['gradient 0x-1 colors/2 + 32 color/2 - 32]
                        ] [

                            reduce ['gradient 0x-1 color + 32 color - 32]
                        ]
                    ]
                ] [
                    effects: [
                        [gradient 0x1 66.120.192 44.80.132]
                        [gradient 0x-1 66.120.192 44.80.132]
                    ]
                ]

either color

  means, if you have submitted a color facet in VID level ... e.g. 
  button red

I was not succesfull changing only 'effect. You have to change b/effects 
block, because of following engage/redraw code imo:

if face/effects [face/effect: pick face/effects not state]

>> view layout [b: button "OK" [probe reduce [b/color b/font/colors 
b/effect b/effects]]]
[44.80.132 [255.255.255 255.180.75]
    [gradient 0x-1 66.120.192 44.80.132] [
        [gradient 0x1 66.120.192 44.80.132]
        [gradient 0x-1 66.120.192 44.80.132]
    ]
]

If you change only b/effect, it will be rewritten by redraw imo ....

view layout [b: button "OK" red [b/effects/1: [gradient 0x1 100.100.100 
120.120.120]]]

From there on, you can work out your final solution imo ...

Yess!  Effect is the color of the button pushed, effects normal button 
state.
Thank you

Effect is the actual color in actual state imo. Remember that you 
can call 'show in many places. Effect is initialised upon button 
state by redraw code: "pick face/effects not state"

You just have to do a little math, if you want the gradient. From 
the oce you can see how to aproach it - VID applies +- 32 tuple offset 
...

oce=code

OK Thanks

I took a bit of a Rebol break for the new year.  But last night I 
had an idea that just wouldn't get out of my head.  It happened after 
I read about "code golf" on StackOverflow.  The premise is to use 
the fewest characters possible to solve a problem using a general 
purpose language (albeit perhaps one optimized for such a game, like 
"GolfScript")

Some of the things people do are utterly ridiculous.  They compile 
assembly to DOS .COM files and claim the resulting hex bytes constitute 
program code because you can feed them into the console.  Other approaches 
obfuscate the code beyond belief to where you really can't make the 
slightest change to them--they are effectively not source, but the 
result of a bizarro compilation--often written using some kind of 
assistive tool or calculator.

Philosophically, it would seem Rebol could compete, if the functions 
had shorter names--which is easy enough (Huffmanize natives and the 
mezzanine, whatever).  But the whitespace policy for words is a bit 
of a problem.  Then I thought of what I called "mushing"

>> unmush [aBcDe/fG/h]
== [a b c d e/f g/h]

>> unmush [AbCdE/Fg/H]
== [a: b c d e/f: g/h:]

interesting

Still parseable Rebol, but each time you switch the case it's a conceptual 
word break.

and how do you decipher a set-word ?

Here's a 77 character Roman Numeral to integer converter:

rSfeCs[Nse[i1v5x10l50c100d500m1000]twCi~J[JnCN]Kk+elJn[alN-j N0]'jJn]pK+j

If you start a mushing sequence with a capital letter that indicates 
the desire for a set-word

http://hostilefork.com/2010/01/08/modest-proposal-for-code-golf-in-rebol/

And I just pushed the source for a proof of concept to GitHub: http://github.com/hostilefork/Rebmu/blob/master/rebmu.r