World: r3wp

Why not ? :)

I wish I had some understanding of inference rules. Never studied 
Lisp stuff.

I think all those parens scared me away.

i don't think common lisp does any type inferencing.

That's how much I know. :)

and, i think an interpreted language would probably have a hard time 
at it, except for simple cases like the seasoning above.

which is elegantly solved as ladislav pointed out anyway.

the only advantage of having a real type in that case is type checking 
in fuction arguments; you don't get that with my custom-types (i 
don't think it is worth redefining FUNC etc. just for this), and 
it's not a big deal actually.

Are you actually using the custom types in any apps ?

i'm using something close (i.e. a very dumbed down and specialized 
version of it) in the backend for the portals for the Detective

basically the scripts interface to the mysql db via custom rebol 
values

I see.

I've just noticed a new global word PATH existing since View 1.2.10, 
an undocumented function.

--> rambo

About custom types: thats objects. they work like dynamic OO, no 
static typing and inferencing like ML

Thanks for all those suggestions.   I was out for quite a while and 
am very happy of all those remarks. It will help orient my trials&errs. 
 About  objects, dynamic versus static, If I understand it, in Rebol 
it is static?  I never had to use them except to encapsulate the 
whole of an app.  Is there a trick to mimick something dynamic to 
hold changing values?  Maybee a copied block is enough?  I wonder 
because I regularly try to add code to a bibliographic database, 
a kind of a variation on bibtex (never ended, allways in progress), 
And I am not too far from aiming the storage mechanism and wonder 
what I should use to hold something like from 5 to 10 thousand references 
(my actual need is 3.5K)  I used endnotes in the past, but dreamed 
about my own.  It is a lot of work (more than I expected as it is 
my first app).   Up to now I think I will use simply name-value pairs, 
like Carl's cardex.  This kind of data is more like a ragged array, 
the fields and their numbers allways vary, and I may amend their 
list with time.  The idea of using an object would be nice but need 
something where I may add or retract variable names and change their 
values.  By the way, I thank Volker for his edit-tools, that may 
help to add a writing pad.  And his double slider is refreshingly 
new for such and old paradigm as an editor.

The structure of an object is static (which fields in which order), 
but the values assigned to those fields are as dynamic as you want. 
Also, if you want to add or delete fields it is quite easy to create 
a new object with your changes at runtime. If you are just using 
an object as what other languages call a dictionary or hash map, 
you might as well use a block or hash type for your data.

Adding or deleting fields in objects can be tricky if you have multiple 
references to the object:
  obj: make object! [a: 1 b: 2]
  block: copy []
  append block obj
  obj/a: 9

  probe block     ; shows the object in the block is the same as obj
  obj: [a: 7]     ; attempt to update obj to remove b

  probe block     ; the object in the block still has a 'b -- it's 
  still the original

Otherwise, the technique is fine.

Or in other words, you can't add/remove fields in objects, but you 
can clone objects, and add/remove during cloning 

>> a: make object! [b: 1 c: 2]
>> b: make a [d: 3]
>> probe b

make object! [
    b: 1
    c: 2
    d: 3
]

>> c: make object! head remove/part find third b to set-word! 'c 
2
>> probe c

make object! [
    b: 1
    d: 3
]

Just as a little helper ...

>> third b
== [b: 1 c: 2 d: 3]

Thanks a lot.  It the kind of thing I normally learn the hard way, 
like the first time I was confronted to [ ] instead of copy [ ]. 
 Judging when it is better to use a block or object or structure, 
hash or else is not evident from a new eye.  The small Ladislav tutorial 
on blocks (series) is the kind of thing that helps a lot,, it help 
a newcommer realise how the language is articulated.

blocks are arrays. many items of the same kind. partners of loops. 
objects are records. items are addressed by names.

blocks are also good for records if you have only a few fields (2-3). 
like [key value]. then its sometimes easier to deal with offsets 
instead of names. block/1 -> key, block/2 -> value. less to declare.

blocks are also great for composing in, e.g creating a dynamic layout 
block to pass to the layout function or draw

Normand, probably blocks will be better for you than objects, because 
they are more flexible.

I am new in encription. What is alternative in Rebol for php MD5 
function?

checksum

checksum/method "somestring" 'md5

I showed some rebol code to some people and they all screamed "eww, 
non standard math functions! why is it sine, cosine instead of sin, 
cos, etc. like every one else use" My best answer was consistency 
to other functions, which are described in their whole word instead 
of an abbreviation. Is that correct?

Why not show them SIN: :SINE , COS: :COSINE or ALIAS 'COSINE "COS" 
etc.? They'd sure be baffeled again, but probably would dislike REBOL's 
strict left-to-right evaluation of formulas instead of having a bunch 
of operator preceedence rules to remember, too :)

But, yeah, they probably aren't *that* wrong. Has anyone ever used 
REMAINDER instead of // ? I do think that for the math function names 
this "be explicit" style is really a bit over-the-top.

Yes, Henrik, that's correct (par Carl). For complainers, use Christian's 
example to show them how easy it is to "fix" and maybe explain a 
little more about how REBOL works.

I've used REMAINDER here and there. Sometimes I use functions, rather 
than ops, for precedence control and clarity. A normal human should 
be able to understand what "remainder" means, but may not have a 
clue about the distinction between / and //.

It is, Gregg, understandable, of course, and a nicety to have for 
people not used to thinking in math terms. That's supposed to be 
the reason why both approaches are build in: Let people decide what 
fits their needs. Admittedly, me too apparently use REMAINDER, especially 
in cases where operators otherwise would catch a functions argument 
to it's left without parens.

I like the spelled-out math terms. Aside from the basic four, there 
is a lot of inconsistency between programming languages on operators. 
Spelling things out makes your code clearer. Besides, there will 
always be people who look at the word sin and think you are doing 
bad things.

:-)

Now if REBOL had unicode support, we could do a Fortress dialect 
for the people that actually know what the operators are supposed 
to be.

Help, help!

Well, I'm not exactly new... but I never before had noticed thisone:

A hidden field is showed when get focus...

I mean:

view layout	[
    across
    lbl "field 1" f1: field return
    lbl "field 2" f2: field return
    btn "hide f2" [hide f2]
]

hide the second field by pressing the button, then go to the first 
field
and press enter, and the second field is showed again with focus.

I hope there is a simple way to void hidden objects get focus.

someone can help me?

It's a known issue: http://www.rebol.net/cgi-bin/rambo.r?id=3477&

I don't know if someone has a fix out there or not. You might try:

	deflag-face f2 'tabbed

Thanks for the quick answer Gregg!

I see the problem is also for XP not only for linux... 


I tried with 1.2.8 and newers all XP included yesterday betas. All 
the same.

Man, your code works!, thanks a lot!!

Glad it helped!

me too :-)

A simple patch would be to had the test of 'show? in ctx-text/next-field 
and ctx-text-backfield.

had = add

ctx-text/next-field: func [face /local item][
    all [
        item: find face/parent-face/pane face 
        while [
            if tail? item: next item [item: head item] 
            face <> first item
        ] [

            if all [object? item/1 flag-face? item/1 tabbed item/1/show?] [return 
            item/1]    ;<==== I  ADDED IT HERE
        ]
    ] 
    none
]

RAMBO masters: if one can add this correction to the Rambo entry.

Now that's Cool