World: r3wp

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

We did not get it in time. :(  -- But let's make sure not to miss 
it on the 1.3.1 release.

I don't particularly understand, what does it mean, Carl. Who does 
set your timeframes? So you do prefer releasing non-fully-fixed 1.3 
"in time", instead of fixing known issues first, and releasing e.g. 
few days later? That simply does not make sense ..

If Carl delays the release until the last bug is reported and fixed, 
it'll *never* be released. ;)

Agree, get it out there now.

Real Artists Ship
 - Steve Jobs

There is no such thing as "fully fixed" software. :-) 


There are many many many things on the list that didn't get in, and 
even a little change like this--which may seem safe and easy--means 
more testing and inspection, often a lot more than you expect. 


In this case, let's look at how many people are screaming that this 
particular issue is killing their apps; not many; it's been around 
a while. Let's also look at whether we can work around it even if 
1.3 doesn't fix it; yes we can, and without too much trouble it seems. 
So, as one person hammering on RT to ship 1.3, I'd vote to ship without 
it.

Gregg - I am not talking about one particular issue mentioned above, 
more about installer etc. issues. You should distinguish between 
a bug fix importances, as if Installer is not solved in a good way, 
it can annoy many ppl!

Yes, I think we all agree Petr; it's a balancing act. Carl is *very* 
aware of the importance of these things, but also knows that "shipping 
is a feature".

Consider: The installer is run once per version, and the only problems 
left in its function are the location of registry entries that aren't 
visible from View anyway. The problems that affect day-to-day View 
operation have been fixed with the use of a seperate sandbox directory. 
The rest can be fixed in later versions with automagic migration 
code and no REBOL scripts would know the difference. Once installed, 
View can be used in a multiuser environment now (as of 1.2.117); 
we can make the installer multiuser-safe later.

The installer works properly for single-user installations right 
now (as of 1.2.117).

I mean in terms of leaving View in a workable state - internal installer 
functionality has been fixed somewhat since then.

Installer aproach is imo incorrect and I will post my findings

Please do, although perhaps the Debug p1.3 or View group might be 
better for that :)

ok, now I am glad Gregg provided new group for that, so I will move 
and post my observations in new Installer group ...

I am trying to add a newline to separate blocks of hashs I add to 
a file withe the save command.

[idkey: 1 objectname: "article" creator: "Lec, Norm" fulltitle: "Title 
1" pageread: "1"] {#"^^/"} [idkey: 2 objectname: "article" ...
with the line: append bib mold/all newline

Unfortunately I dont find the way to dispose the blocks in a pleasing 
format because the newline separating them is in source format.

I did try a dozen of combination with reduce, form mold and compose 
and the various newline forms I know ^/ "^/" but to no avail.

It shure is stupid but I am stock with this.  If I use write I am 
OK, but would like to learn the trick with save. Thanks.

In last View version (1.3.x) and last Core, there is a 'new-line 
function to format a block in lines. I think it does not work on 
hash! (just try), but you can use 'to-block on your hash! to be able 
to use it.

>> help new-line
USAGE:
    NEW-LINE block value /all /skip size

DESCRIPTION:
     Sets or clears the new-line marker within a block.
     NEW-LINE is a native value.

ARGUMENTS:
     block -- Position in block to change marker (Type: block)
     value -- Set TRUE for newline. (Type: any)

REFINEMENTS:
     /all -- Set/clear marker to end of block

     /skip -- Set/clear marker periodically to the end of the block
         size -- (Type: integer)
>> a: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> new-line a true
== [
    1 2 3 4 5 6 7 8 9 10
]
>> new-line a false
== [1 2 3 4 5 6 7 8 9 10]
>> new-line/skip a true 2
== [
    1 2
    3 4
    5 6
    7 8
    9 10
]