AltME groups: search

*Important*: Red will be distributed as a binary to end users and 
the effect of:

    red script.red
    

will be to compile and run it from memory directly. So the -o option 
will become mandatory in the future for generating an executable 
without running it. During the bootstrapping stage, it is complex 
to support that feature, but it will be implementd as soon as possible.

Doc, the new commits are in master, not in 0.3.0, so it can't effect 
the problem on Syllable Server

Another interesting side effect of the strong separation is that 
it would be possible to implement the client-side of the extension 
interface in other languages, such as Red, so that it could use R3 
extensions without changes. The REBOL portion of the extension might 
be trickier to implement though, because that code tends to be more 
tied into the actual R3 runtime model. You could write your own wrapper 
code if your system model is different, but the native code could 
be used as-is.

Side effect of compilation. The compiled code retrieves a value from 
a value slot or other indirect type, manipulates the values in typed 
stack or register variables, then puts the results back in the value 
slot or wherever.

In effect, we have to different notions of "first position": one 
used in HEAD, one used in FIRST.

never mind, talking about View engine itself. I don't like gobs logic 
in some aspects anyway ... I e.g. don't like separate gobs for text, 
color, image, effect, draw. Dunno low level logic, but it could be 
all in draw dialect. Simply put - always hated when you can do gob/text, 
but then you can do another text in terms of draw, ditto effect, 
etc.

With increased iterations, the effect is big in Fibonacci, but dramatic 
in Mandelbrot

It shouldn't have any effect on the generated code size. Can you 
send me the function?

Doc, I'm very glad to see you're still working hard on Red!  I was 
concerned that the psychological effect of everyone paying attention 
to R3 source, plus your own curiousity about it, might derail you 
for a while.  I'm still eagerly awaiting every advance you make!

BREAK will probably be implemented before 2.0 (not sure for CONTINUE). 
So, you can't break from a loop currently. 


As a workaround, you can EXIT/RETURN instead. So if you write your 
loop in a separate function, you'll get similar effect as with BREAK.

Let me stash my changes to see if there's a side-effect.

The changes I made in the interpreter for not exiting the console 
on errors have a very bad side-effect: some errors are passing silently 
through the unit tests and are not reported! :-/

A [catch] flag will have no effect on exceptions launched from the 
same level (enables re-throwing exceptions).

Didn't say anything to that effect, and it's not what I'm thinking 
either.

My first impressions on your proposition:


1) arr[i] is a useless syntactic addition as we already have indexed 
accesses: arr/i


2) #7 and #8 are going way too far from the Red/System application 
domain, it's basically  a series abstraction. Red internal API already 
provides series (the internal API is not yet completed nor formalized 
though), so this is both unneeded and overlapping with Red standard 
library.


What you might not realize is that you already have array-like capabilities 
with Red/System pointers (including structs and c-strings). If you 
want automatic memory management in Red/System, you won't have it, 
low-level programming requires a manual management of memory for 
accuracy and avoiding unnecessary burdens.


The only array-like part that Red/System is really missing right 
now is the literal array-like declarations, which can be achieved 
without a new formal array! type. As I said earlier, adding a array! 
type would only add bound-checking abilities (which is a nice feature 
to have) and provide you with #5 as a side-effect (not very useful 
anyway, as array would be fixed-size).

The main effect is that Red/System init code is not run when the 
shared lib is loaded, this affects floating point exceptions flags 
and runtime error catching routines. Not a problem for now.

Thanks for the compliment Doc, not really sure what you mean exactly 
by making it more like Red/System and less C: use more descriptive 
names? I will take a closer look at some ed/System examples out there.

Thanks Kaj for finding those and for the tips, the size of MM makes 
it the same in effect in this case, but it has to be <= then. Program 
not crashing, I was lucky then! off-by-one errors? My index goes 
from 1 up, where in C it is from 0 up, I had to debug this to make 
sure elements were swapped in the same way as in the original program. 
That is also why I declare KKP and LLP to as to save from adding 
1 to KK and LL over and over again. 


Knuth's algorythm was the first one I found, and I knew already of 
its existence, so it made sense to use what you have. Sure my Red/System 
code is not optimised.


Going to work on it now and tomorrow, and later I take on the Twister. 
It is a good exercise!

I suspect that if I do 
    ptr: ran_arr_buf 
and I progress ran_arr_buf 
by 1 that I progress ptr too.


That's a wrong assumption. Those two variables are distincts, so 
each one has its own memory slot. If you change one, that has no 
effect on the other. What is shared there is the pointed memory region. 
So, if you change ran_arr_buf/value, that will affect ptr/value (they 
both point to the same memory location).

Oh nice effect. array1: 1 2 3 4 5 
m: 2
;;print array/m ;; 2
array1: array1 + 2
;;print array/m ;; 5

it is tricky to move the array pointer around, beware of the dog 
;)

Red/System is a dialect of Red meant to address specific needs. You 
should see it as a feature of Red, even if it can be used alone (which 
is kind of side-effect of starting Red project by building R/S first).

MaxV: radiobuttons are best used with true and false in stead of 
on and of like in some documentation mentioned. The true and false 
I just tried out of frustration and I discovered it worked. Undocumented. 
Same with the block after a text or label to make the label clickable 
like a button. 
VID has an effect and a draw that could be better documented.

There is no single truth here. There are a few realistically defensible 
positions, all of which have been argued extensively before.


The legal opinion of the FSF (publisher of the GPL) is pretty clear, 
by analogy to Perl or Java: all/most REBOL mezzanines are library 
functions to which a user script dynamically links. If the mezzanines 
are GPL licensed, the source to user scripts will have to be provided 
in a GPL compatible way.


Equally clear is e.g. Lawrence Rosen (IP lawyer) in articulating 
his legal opinion. Paraphrased: "linking is irrelevant for deciding 
wether the result is a derivative work" -- this mostly matches Ladislav's 
stance.


The whole point of this debate is not really ultimately deciding 
the resolution for that issue as pertaining to a GPL'd REBOL, but 
pointing out that, without additional clarification, the GPL results 
in a problematic legal uncertainty. This legal uncertainty may lead 
to quite the opposite effect of what many believe Carl actually intends.


So one very easy solution, is to include a few definitive clarifications 
along with the GPL.


Another, probably much easier, solution would be to simply sidestep 
this issue and use a different license.

Using R3 natives can have that effect as well if they're not declared 
to be part of the interpreter.

Sqlab, do you have Fossil in the same directory as download.r? The 
script changes directories, so on Windows when Fossil is not really 
installed, this could have the effect of not finding it

Kaj, I deleted all files and subvols created by fossil and run download.r 
again.

The probem is not only with executable files, but with all files 
simple as containing just "Hello". 
write %test.txt "Hello" has the same effect.

What effect with write %test.txt "Hello" do you mean

It's internal, exported as a side effect of it being an action, used 
as part of path evaluation. Don't use it.

Perhaps it helps to learn about the mechanisms: There are several 
ways to generate a dynamic UI:


The LAYOUT function works by creating an object tree, a tree of faces 
that are simply ordinary objects. When passing this to the VIEW function, 
a layout is displayed. The layout function is part of VID and is 
as such a high level function. VIEW is a low level function to interpret 
the face tree.


The face tree consists of objects that contain other objects through 
the FACE/PANE word. If the FACE/PANE contains an object, that object 
is a single face, that is displayed inside the parent face. If the 
PANE contains a block, that block may contain multiple objects that 
are simply multiple faces. As such, a typical window is a face with 
a FACE/PANE that is a block that contains other objects.


Graphically, the face is represented by a region on the screen that 
has the size and offset, possibly an effect, such as coloring, blur 
or mirroring or a text attached to it, and image or other faces that 
are only visible inside that region.

A window is also a face.


To navigate to the parent face from a face, use the FACE&/PARENT-FACE 
word. Note that FACE/PARENT-FACE is many times not set by VID, which 
is sometimes problematic.


You can manipulate the face tree by adding removing objects dynamically 
and calling the SHOW function. You can also change values in existing 
face objects in the tree, such as for resizing or moving the faces 
and then calling SHOW again. You can also build a face tree entirely 
by hand, and this is usually the starting point for different layout 
engines, such as RebGUI, that simply build face trees in their own 
way.


The prototype face is FACE, which is a minimum requirement face for 
the View engine. The prototype face for a VID face, which contains 
a few more words, is SYSTEM/VIEW/VID/VID-FACE, which is the minimum 
requirement face for VID.


One condition for the face tree is to not use the same object in 
multiple locations. The VIEW or SHOW function will return an error 
if that is the case.


A simpler way is also to generate a new face tree every time you 
want to change the layout. Although this is slightly more computationally 
heavy, it allows you to manipulate the block that was passed to the 
LAYOUT function instead of manipulating the face tree directly. This 
technique is best used, when the face tree changes dramatically by 
each manipulation.


Another important concept is the DRAW engine which is a separate 
entity in REBOL2. It can be called to draw on an image bitmap, using 
the DRAW function or as in effect for a face object, by adding a 
parameter in the VID dialect block or by changing the FACE/EFFECT 
word. DRAW is used by calling a dialect. if you just want to use 
fields, buttons and simple user interface designs, you may not need 
to use DRAW.

Hi Chris! Thank you. I consulted this site also. But there is better 
news to this! In stead of the words on and of you have to use the 
words true and false and the problems are solved! Didn't even have 
to initialize the /data fields between creating the layout and calling 
it in action with view.

Not documented but stil possible. (Like it is also undocumented on 
the REBOL site that you can have a checkbox followed by an action 
block.And this is also possible on text-labels making them clickable 
and have an mouse-over effect.)

In the script display-chess-board.r on rebol.org there is this part
   ;;  counter is now an image -  note the 'key effect 
    ;;  user to make the black in the image transparent.
    ;;  ------------------------------------------------
    counter: box 30x30 effect [key 0.0.0 oval]
 

This does not work, when keyword merge is added the middle part is 
transparent when the tuple is replaced with an integer, but only 
the other way around or the oval is limiting the working of merge 
to the inside of the circle?

not even needed. you may DO the same script several times for the 
same effect.

Henrik, I don't know how hard is to add gradient on line but you 
can 'emulate' it using textures. See this R2 example:


g: draw 100x10 [pen none fill-pen linear 0x0 0 100 0 1 1 red green 
blue yellow box 0x0 100x10]

view layout [origin 0 box 300x300 black effect [draw [pen g spline 
0x0 100x100 200x30 300x300 16]]]

I don't rememeber who did the neon effect, but here it is.

font-C: make face/font [style: [ bold ] size: 64]
neon: "REBOL BAR"
coord: 30x15
inc: 0.25.25
draw-block: compose [
	line-join round font font-c

 pen (inc * 1 + 255.0.0.230) line-width 11 text vectorial coord neon

 pen (inc * 2 + 255.0.0.205) line-width 9 text vectorial coord neon

 pen (inc * 3 + 255.0.0.180) line-width 8 text vectorial coord neon

 pen (inc * 4 + 255.0.0.155) line-width 7 text vectorial coord neon

 pen (inc * 5 + 255.0.0.130) line-width 6 text vectorial coord neon

 pen (inc * 6 + 255.0.0.105) line-width 5 text vectorial coord neon

 pen (inc * 7 + 255.0.0.80) line-width 4 text vectorial coord neon

 pen (inc * 8 + 255.0.0.55) line-width 3 text vectorial coord neon

 pen (inc * 9 + 255.0.0.30) line-width 2 text vectorial coord neon

 pen (inc * 10 + 255.0.0.5) line-width 1 text vectorial coord neon
]

view/title layout [ box black 450x200 effect [ draw draw-block ] 
] "NEON"

Such an app can bring up a GUI, yes.


However, it will always pop up a console window (which can be closed 
immediately, but this will result in the "console flashing" effect 
some dislike).

Brian, I build the Red examples in both modes, so you can try out 
the effect if you want. MSDOS/console programs can open a window, 
but Windows/GUI apps don't seem to be capable of using stdout, at 
least not to a console they're started from

As for that blog, the behavior described there has some practical 
problems. There is nothing in the code itself (I mean the example 
code in the blog, not the implementation code) to indicate that 'last-stock 
is a free variable, but 'if and 'not are not - they are all words 
not declared at the top level of the module (by using them as set-words, 
like in an object) or elsewhere in the code. This means that if you 
want it to have 'last-stock be made local to a module, you would 
have to make 'if and 'not local as well. That works if lib words 
can only be set once, but not if they can be reset, since changes 
wouldn't propagate to the other modules or user scripts (since those 
values are copied to words in other contexts).


We determined that the behavior described in that blog could be useful 
enough to be worth supporting, but had some nasty side effects that 
made it not be what we wanted to do by default. That is why we made 
it an option, in particular the isolate option. If you specify the 
isolate option, your module acts like it does in the blog, and this 
has the effect of isolating your module from all external changes 
to the lib context.

Regular

 modules have names and versions so they can be loaded only once, 
 and upgraded in place if need be. As a side effect, this makes the 
 module's context effectively global. We have a few built-in global 
 contexts, but we don't necessarily have to make built-in global contexts 
 for stuff that is managed by modules because the module contexts 
 are themselves global.

Private

 modules were a side effect of the module name being optional. If 
 a module doesn't have a name, you can't check for whether it is already 
 loaded, so you have to load it again every time it is requested. 
 The module itself can't even tell if it was loaded before, so it 
 can't know whether it needs to resolve conflicts between itself and 
 other instances of itself. That makes it basically unsafe to have 
 an unnamed module export to lib. So instead, we skip the lib middleman 
 and import those exports directly into the target module or user 
 context, which makes the unnamed module effectively owned by that 
 target, a "private" module.


We found this facility useful enough that we added an explicit option 
to make it private (options: [private]). That makes it possible to 
have a named private module, which has some interesting abilities 
just from having a name. Having a name means that you can have the 
module load only once, and being private means that if you want to 
use its exports you have to import the module explicitly, so combined 
it means an explicitly accessed module that can share resources with 
other targets that also explicitly import the same module.

Adrian, I wrote the Bindology article. There are differences in the 
behaviour as you noticed, some of them are quite minor (like the 
latter you mentioned), some may have a more noticeable effect. In 
the future, some revision of the article to adjust it for R3 will 
be needed.

In effect, that is :)

From the "design architecture" POV we should focus on stabilizing 
the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. 
If these layers are fine-tuned you have great base that allows us 
make experiments at the low-level graphics and also as well at  the 
high-level GUI abstraction layer.

I think the first thing to look at is the structu sizes. Either press 
it back to fit 32bit size, or expand it into 64bit space. Not sure 
what kind of side-effect this will have.

string comparisons are, in effect, right padded, to equal length 
before comparing.
The comparison is really
max "1000" "999*"

   where "*" is whatever the pad character is (probably a binary zero)

your trouble is, that the evaluation of X doesn't have the same effect 
as if you replace X by its value. The evaluation of X only yields 
a set-word instead of setting anything. If you really want to set 
a word 'y, then there are two ways:

set x 'z

do compose [(x) 'z]

I don't want to "probe system" after a while, if you wait long enough, 
then it will print out but I thought that there were some optimizations 
made to make "probe system" start printing sooner or something to 
that effect.  It's not "probe system" that I'm interested in.  What 
I'm interested in is finding the conversations that I participated 
in several years ago on the REBOL ML concerning the problems with 
"probe system"  but none of the search engines I used could produce 
them.

So did !
The color styles used right now are here:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/css-view-system.r
(search for colorizer)

We already (in effect) collapse some into the same color: like file! 
and email!  Perhaps url! should be the same color too.

REBOL.org looks like it is down right now -- the whole ISP who host 
it seem dead too. (they've not been as reliable since they merged 
with another ISP).
Apolgies!

This has no effect on  REBOL.com or REBOL.net .... they are completely 
separate.

At the moment, I'd be worried about standarising the Library on utf-8 
as the effect of multibyte characters would have during script and 
mail processing is not understood. It could well be that the system 
handles multibyte characters without a hitch but nobody knows yet.


I have started to write some scripts to try to help move to a consistent 
character encoding of the Library data but, due to time constraints, 
I have been very slow.

And the last bug is that the "byte" word is not initialized to none 
and this cause a problem but I don't remember the effect :
;------ Data reading ------


;	b0: b1: b2: b3: int: int24: long: string: field: len: none	; Removed

 b0: b1: b2: b3: int: int24: long: byte: string: field: len: none	; 
 Added

Couldn't reproduce the bug...When an empty set is returned, the driver 
returns an literal empty block! value. This shouldn't be an issue 
as long as you don't modify the returned value. Anyway to avoid such 
side effect, the driver now return a fresh new block!.

The effect it had was eerie. When I moved a file in the Gnome filer, 
the hard disk stopped running and wouldn't come back when rebooting

Trying to run VidaLinux has the same effect on my disk

fnt1: make face/font [
	name: "/usr/share/fonts/truetype/freefont/FreeSans.ttf"
	size: 32
]
fnt2: make face/font [

 name: "/usr/share/fonts/truetype/freefont/FreeSansBoldOblique.ttf"
	size: 64
]

view layout [
	origin 0
	box snow 400x100 effect [
		draw [
			pen black
			font fnt1
			text anti-aliased 0x0 "Rebol Rulez!"
			pen blue yellow
			fill-pen red
			line-pattern 10 10
			line-width 2
			font fnt2
			text vectorial 0x30 "Rebol Rulez!"
		]
	]
]

I'm trying something to this effect:

If you update your rules script the updates will be in effect the 
next time you fetch your mail (i.e. you do not have to restart the 
program)

the reason it is a big problem is that when you're sitting in the 
same place for ten or more hours in a little thing in every little 
thing will eventually effect you

effect .... Speech? or are you typing?

Sorry Allen, I overlooked that you had written something nearly to 
the same effect.

Span wil get you a similar effect, though there are differences.
Never heard of idiv -- is it a browser-specific thing?

view layout [box edge [size: 12x12 image: logo.gif effect: [tile 
gradcol 1x1 255.0.0 0.0.2
55]]]

progress: make face [
	    effect: copy [draw [pen blue fill-pen blue box 0x0 0x0]]
		data:	0
		font:	none
		para:	none
		feel:   make feel [
		    redraw: func [face act pos] [
		        if act = 'show [
		            face/data: min 1 max 0 face/data

              face/effect/draw/box: to-pair reduce [to-integer face/size/x * face/data 
              face/size/y]
		        ]
		    ]
        ]
    ]

just a detail: in facets document, /span datatype is pair! . you 
could use it to store other data, but if you set a pair! to /span, 
/view will use it as virtual size for face (it still works in later 
betas, so one should be careful to not use it to store coordinates) 
ie:
f: layout [
   banner "Testing /span" guide 
   box 400x400 effect [gradient 1x1 0.0.0 255.255.255] 
   button "Hello!" return 
   text-list data ["just" "a" "list"] 
   image logo.gif logo.gif/size * 2
]

f/span: f/size  ; here we tells /view to use virtual coordinates 
for all subfaces

view/options f 'resize ; will give a fully resizable window (widgets 
included), but it only works for reducing window's size.

Good diagnosis. I knew assigning a pair! to span did *something*, 
I could never quantify exactly what though. As Ammon said, an interesting 
effect but somewhat useless in an age where screen ratios are all 
over the place and resizing needs to occur both vertically and horizontally.

check: make face [
    edge: none
    data: false
    para: make para [origin: 14x0]
    effect: copy [draw [
        pen 96.96.96 fill-pen 255.255.255 box 0x0 12x12
        pen none line 0x7 5x12 11x0 line 0x6 6x12 12x0
    ]]
    feel: make feel [
        redraw: func [face act pos][
            if act = 'show [

                face/effect/draw/9: either do face/data [255.0.0][none]
            ]
        ]
        engage: func [face act event][
            if event/type = 'down [
                face/data: not do face/data
                show face
            ]
        ]
    ]
]

http://www.dobeash.com/it/rebgui/facets.html#section-5

May be you can add to the 'effect definition that any effect can 
be used. Not only 'bezel, 'bevel and so on

progress: make face [

  effect: copy [draw [pen blue fill-pen blue box 0x0 0x0]] ; is copy 
  needed?
		data:	0
		font:	none
		para:	none
		feel:   make feel [
			redraw: func [face act pos] [
				if act = 'show [
					face/effect/draw/box: to pair! reduce [

      to integer! face/size/x * face/data: min 1 max 0 face/data face/size/y
					]
				recycle
				]
			]
		]
	]

for example: face/effect/draw/box: to pair! reduce [

      to integer! face/size/x * face/data: min 1 max 0 face/data face/size/y

it's box edge [ size 3x3 color: gray effect: 'ibevel ] :)

v-splitter: make face [
    size: 5x100
    edge: make edge [size: 1x1 effect: 'bevel]
    feel: make feel [
        engage: function [face act event][f p n delta][
            if event/type = 'move [
                f: find face/parent-face/pane face
                p: first back f
                n: first next f
                delta: face/offset/x - face/offset/x:
                    min n/offset/x + n/size/x - 1 - face/size/x
                    max p/offset/x + 1
                    face/offset/x + event/offset/x
                p/size/x: p/size/x - delta
                n/size/x: n/size/x + delta
                n/offset/x: n/offset/x - delta
                show [p face n]
            ]
        ]
    ]
]

face/effect/draw/box: to pair! reduce [

    to integer! face/size/x - 3 * face/data: min 1 max 0 face/data face/size/y 
    - 3
]

hslider: make face [
    size: 200x20
    data: 0.0

    effect: [draw [pen 48.48.48 fill-pen 192.192.192 box 1x0 10x17]]
    feel: make feel [
        redraw: function [face act pos][delta][
            if act = 'show [
                face/effect/draw/7/y: face/size/y - 3

                delta: 5 + to-integer face/size/x - 12 * min 1.0 max 0.0 face/data
                face/effect/draw/6/x: delta - 5
                face/effect/draw/7/x: delta + 4
            ]
        ]
    ]
    init: does [
        feel/engage: func [face act event][
            if find [move down] event/type [

                face/data: min 1.0 max 0.0 event/offset/x / face/size/x
                show face
                face/action face
            ]
        ]
    ]
]

Pekr: "What is the concrete plan, if any?" ... shadwolf was on the 
mark.

1) Create a set of base widgets with the desired *functionality*
2) Select a look & feel to approximate
3) Apply this look & feel *consistently* to all base widgets


Vincent is correct when he says we should discuss this sooner than 
later as look & feel can effect how a particular widget is implemented. 
As an example, a 'button widget trying to mimic WinXP might use multiple 
images and / or effects to mimic the various states a WinXP button 
can be in; while a minimalistic approach might just make use of 'edge 
and 'effect to toggle between several states.


I'm leaning towards a minimalistic yet modern look & feel (perhaps 
even PDA-like) so put any useful links / comments / opinions / designs 
here for folks to look at. Here's one to get the ball rolling: http://projects.o-hand.com/matchbox/screenshots.html

offset is still needed for precise effect but using this kind of 
organisation that is more powerfull than below accross  we ca  make 
quite and easy beatifull graphic interface

over: func [face act pos] [
    face/effect/draw/pen: either act [active-color][edge-color]
    show face
]

G4C TUT_MCListview

// ===========================================================
// A Multi Column (or Database) Listview..
// ===========================================================

WINDOW 126 90 367 373 "Listview"
	winattr style resize

xOnLoad
	// add some records to the listview & open..
	gosub #this AddRecords
	guiopen #this

xOnClose
	guiquit #this

// ===========================================================
// The listview
// - This is a normal MULTISELECT listview (the default).
// For this type to be triggered, you must double-click it.
// ===========================================================

XLISTVIEW 0 0 0 0 'The Title' "" var

	attr ID mylv
	attr resize 0022
	attr frame sunk

	// Give it a grid and allow the user to drag, drop & re-arrange
	// the lines - You can add more styles here..
	attr style grid/arrange/drag/drop/arrange

	// Add some columns. The first one we state with a '#'
	// in front to indicate we mean the 1st column.
	attr LVCOLUMN '#Item/width/120/TITLE/Description'

 attr LVCOLUMN 'Units/width/60/TITLE/Units/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Amount/width/60/TITLE/Amount/TYPE/number/JUSTIFY/RIGHT'

 attr LVCOLUMN 'Total/width/60/TITLE/Total/TYPE/number/JUSTIFY/RIGHT'

	// show the line double clicked..

 SetWinTitle #this 'SUM: $%Units x $%Amount = $($%Units * $%Amount)'


// ===========================================================
// This is a routine to add 100 records with various
// meaningless values to the above listview. Note how
// the fields can be used as normal variables.
// ===========================================================

xRoutine AddRecords
	local c

	use lv #this mylv

	// before we start, we HIDE the listview. This will
	// stop Gui4Cli from visually refreshing it every time
	// we add a record and will GREATLY increase the speed.
	// This will have no effect if the window is closed.
	// After we finish, we show it again..
	setevent #this mylv HIDE

	for c 0 100
		// add an empty record..
		lv add ''

		// Fill the fields with various values..
		%Item   = "This is Item $c"
		%Units  = $($c * 3)
		%Amount = $(($%Units / 2)*1000)
		%Total  = $($%Units * $%Amount)

	endfor

	// Show the listview again, refreshing the display..
	setevent #this mylv SHOW

// ===========================================================
// Right mouse button handling - Some menu choices..
// ===========================================================

xOnRMB


 QuickMenu -1 -1 'Select All/Remove selected/Add 100 records/#sepa/cancel'
	use lv #this mylv
	docase $$choice
		case = 0			// Select All
			lv select all
			break
		case = 1			// Remove selected
			lv delete selected
			break
		case = 2			// Add some records..
			gosub #this AddRecords
	endcase

OT: the problem with AGG AA on smaller glyphs (not just arrow) is 
that it tends to have an adverse effect on glyph weight.  'course 
it beats bitmaps when it comes to scaling, but even pre-AA Draw gave 
more precise control -- hence the deterioration of the Arrow glyph 
post-AGG.  Illustrated here: http://www.ross-gill.com/r/chevron-test.png

tab-panel: make face [
		color:	none
		pane:	[]
		l-arw: none 
		r-arw: none
		dir-buttons: false
		feel:	make default-feel [
			redraw: function [face act pos] [test-size test-wid] [
				if act = 'show [face/pane/1/size: face/size - 0x20
; 					
; 				 	test-wid: face/pane/1
; 		    		test-size: test-wid/size/x
; 					if greater? test-size face/size/x  [
; 						either not dir-buttons [
; 				 			dir-buttons: true
; 		    				insert tail face/pane face/l-arw: make arrow [
; 	        					size: 20x20
; 		    					offset: as-pair (face/size/x - 40) 0
; 		    					data: 'left
; 		    					action: [print "you clicked left" ]
; 	     					] do face/l-arw/init
; 		    				insert tail face/pane face/r-arw: make arrow [
; 	        					size: 20x20
; 		    					offset: as-pair (face/size/x - 20) 0 
; 		    					action: [print "you clicked right" ]
; 		    					data: 'right
; 	     					] do face/r-arw/init
; 	 					][	
; 	 						face/r-arw/offset: as-pair (face/size/x - 20) 0 
; 	 						face/l-arw/offset: as-pair (face/size/x - 40) 0 
; 	 					]
; 	     			]

; 			    print "la liste des bouttn est plus grande  que ce que l'on 
voit!!!" 
		    	]
			]
		]
		
		init:	has [tab-offset last-tab] [
			;	create main display area
			insert pane make face [ offset: 0x20 edge: default-edge]
			;	add tabs
			tab-offset: 0x0

   insert tail pane make face [ offset: 0x0 pane: [] color: none ]
			container: last pane

   insert container/pane make face [ offset: 0x0 pane: [] color: none]
			foreach [title spec] data [
				insert tail container/pane/1/pane make face [
					offset:	tab-offset
					size:	1x20
					pane:	[]
					text:	title
					effect:	reduce ['round edge-color 5 'draw copy []]
					resize:	none
					font:	make default-font [align: 'center valign: 'bottom]
					para:	default-para
					feel:	make default-feel [
						over: func [face act pos] [
							either act [

        insert face/effect/draw compose [	; compose required for AGG betas
									pen over-color
									line 3x1 (as-pair face/size/x - 4 1)
									line 2x2 (as-pair face/size/x - 3 2)
									line 1x3 (as-pair face/size/x - 2 3)
								]
								show face
							][

        if face/parent-face/parent-face/parent-face/pane/1/pane <> face/data 
        [	; clear unless selected
									clear face/effect/draw
									show face
								]
							]
						]
						engage: function [face act event] [pf old-face] [
							if event/type = 'down [
								pf: face/parent-face
								pf3: pf/parent-face/parent-face

        if pf3/pane/1/pane = face/data [return]	; has a new tab been selected?
								clear face/effect/draw
								old-face: pick pf/pane pf3/data			; find previous tab
								old-face/resize: pf3/size				; remember last size
								old-face/size: old-face/size - 0x1		; deflag old
								clear old-face/effect/draw
								face/size: face/size + 0x1				; flag new
								face/feel/over face true 0x0
								pf3/data: index? find pf/pane face		; set new pane#
								pf3/pane/1/pane: face/data				; init tab panel
								if pf3/size <> face/resize [				; recursive resize
									span-resize pf3/pane/1 pf3/size - face/resize
									face/resize: pf3/size
								]
								show pf3
							]
						]
					]
				]
				last-tab: last container/pane/1/pane

    last-tab/size/x: 10 + first size-text last-tab	; set tab title width

    display/layout "" spec last-tab					; generate tab spec into tab 
    pane
				last-tab/data: last-tab/pane					; swap pane into data
				last-tab/pane: none								; clear pane
				last-tab/resize: size							; original panel size

    tab-offset/x: tab-offset/x + last-tab/size/x	; set offset for next 
    tab title
			]
			print "size et countainer a la con !!"
			probe size/x
			container/size: as-pair size/x 20
			probe container/size/x
			container/pane/1/size: container/size

   container/pane/1/pane/1/size: container/pane/1/pane/1/size + 0x1	; 
   flag 1st tab
			data: 1								; set pane#
			pane/1/pane: container/pane/1/pane/1/data			; init tab panel

   container/pane/1/pane/1/feel/over container/pane/1/pane/1 true 0x0	; 
   flag first as active
		]
	]

mutch faster but more code and a strange effect  ;)

I do agree, strange effect for sure.

maybe Ashley will make an effect draw line on the current mouse position 
;)

this is can be similate by over drawing a line  with effect draw 
;)

last thing to do is to draw a vertical line with effect draw at position 
of the mouse

line-selection: 
- How about using a TINT effect for images in the selected line?

- Changing the state of the select box in column 2 isn't reflected 
in listview/picked output

Carl has talked several times about a binary format for saving REBOL 
structures (can't find any references off-hand).

That would probably solve this problem as what is saved is, in effect. 
the internal in-memory format: useless for non-REBOL data exchange 
and perhaps dangerous for cross-REBOL releases data exchange, but 
much much faster as it'd avoid most of the parse and load that REBOL 
does now.

Every MAKE object! takes a spec block that is an init function, in 
effect.

you can just do a mold/all load, that will in effect copy the whole 
tree along with all the series too.

You must create sound with stereo effect. Once you insert something 
to sound:// you lost control and cannot change even the volume.

has anyone noticed this side-effect with rebol before?

I'm not sure, how to make a use of it, but it does have an effect:
>> blk: [a b c]
== [a b c]
>> path blk 3
>> blk
== [a b]

In Carl's blog is written "More than 50 RAMBO tickets have been implemented 
or fixed." so there's at least ten more fixed bugs and convolve effect 
has been added, so there are some new features (or at least one :)

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

Graham, yes. Reichart, the price comparison is:

	Mac mini 1.25GHz with 40GB Combo drive and 512MB RAM: AU$799

Mini-ITX equivalent:

	VIA EPIA-TC10000 (DC-DC onboard): AU$229
	OEM 40GB 2.5” 5400rpm HDD: AU$100
	OEM Slimline CD/DVD combo drive: AU$140
	512MB DDR333 SO-DIMM: AU$81
	Mini-ITX case (difficult to source): ~AU$150
	Cabling: ~AU$10
	Power supply brick: ~AU$15

which comes to AU$725 (wholesale), and excludes:

	Software
	DVI output
	Packaging
	Assembly


Look at other folks who are trying to do the same thing (with an 
emphasis on small and quiet):


 http://www.hushtechnologies.com/(starting at about 750 Euro (AU$1200))

 http://www.theregister.co.uk/2005/12/01/evesham_aopen_minipc_win/
 ($499 pounds, so about AU$1,200 for me)


The Mac mini, for this class of device, wins hands down – even if 
you purchase it as a Linux or Windows (when re-released as an Intel 
Mac mini) box. It's smaller, quieter, cheaper, and more compatible 
(USB2, Firewire and DVI out of the box; and includes a DVI-Analog 
converter for PC folks still living in the 80's).


What's also telling is the noticeable increase in the number of folks 
asking me, “does your software run on Mac”, since its introduction 
– but this might also be the iPod halo effect at work. Regardless, 
I see a lot of them around these days and the general consensus is 
that “they're cheap” - and this from the Dell generation who only 
care about price! ;)

Well, for the most part this database metadata isn't really stored 
in tables in SQLite. Instead queries about the metadata are generated 
from internal structures when needed, by pragma statements. Still, 
the effect is the same.

BTW, someone needs to consider the new plugin activation that Microsoft 
added to get around that BS patent, and what effect it will have 
on the IE browser plugin.

column if you want to stack your faces in Y , row to stack them X 
.

it has no effect on resizing.

since nodes actually are objects, its not some mysterious hidden 
thing you try to grasp by reverse thinking of cause effect.

Great start.  Feedback

-	Allow full screen: Stretch to fit.
-	Start with larger tiles (some of us are old)

-	Tiles need to be much brighter and higher contrast (yes I know 
I can change this myself).

-	3D effect should center single point perspective, not isometric.
-	Score?
-	Seed value?
-	Help? (shortcuts, etc.)
-	Undo?
-	Timer?
-	When there are no more moves, you should be notified.

ahh - forest and cave are from stock photos and the blue is a geometric 
effect

You are going to want to have the ability to "highlight" things. 
 Which means one of two things.


The art needs to be bigger to begin with, for example to have a highlight 
or glow, or you need to add the glow or effect afterwards.


So for example, when the cards are on the board, they are normal, 
when a card lifts off the board, it should be highlighted in some 
way.


It is a simple and subtle trick that will bring the board to life, 
and give it depth.

- Need help (I have no idea how to play this game.
- Make zoom effect of cards twice as fast.
- Full screen mode?
- Right justify all numbers.

- What is with the status output .......................["blah blah 
blah "]