World: r3wp

Append is native too, no?

But APPEND changes the spec block, which caused the speed issue Peter 
pointed out.

At this point, I don't see the value in the OBJECT func myself.

Because of the speed issue?

No, that's incidental.

Yes, looking at object, there are two problems:

  1. it is slow .... though as Gregg says, that looks like it can be 
  fixed by changing its pith to:
                       make object! join blk none

  2, it is unnecessary. I never realised until now that this works 
  fine to set default values:
        make object! [a: b: c: d: none]

Sunanda, the OBJECT function was one of the language usability tweaks 
we made while writing the R3 GUI code. It is likely that the functionality 
of OBJECT will be added to the MAKE object! handler, at which point 
OBJECT will just be another word for the CONTEXT function. In the 
meanwhile we have already seen the value of it in the GUI source.

Sub-panels do no longer work with the demo.
The error messages is

** Script error: append2 has no value

** Where: repeat do switch applier apply if foreach if do-face if 
foreach do-tr

ggers switch-panel view-sub-panel do switch applier apply if foreach 
if do-face

if actor all do-style all until do-event do-event do-event either 
applier wake-

p loop applier wait do-events if view catch either either applier 
do try demo
** Near: repeat n 60 [
    append2 blk 'label ajoin ["Field " n]
    ...

** Note: use WHY? for more about this error

Yeah, I saw that too, I tracked it down to the APPEND2 command which 
is no longer used in the GUI.R

Instead, it looks like the REPEND command took it's place, but was 
not changed in the DEMO.R

This work-around should fix the demo for sub-panels:


Run R3 as you normally would then type this command:  APPEND2: :REPEND

Then you can run the DEMO.  It is just a quick fix until the DEMO.R 
script is changed.

That may not work the way you think since REPEND (which has 2 arguments) 
didn't actually take the place of APPEND2 (3 arguments).

Ah, Carl is preparing to split user and system context. What will 
that mean? Respectively - what is the purpose of such change, to 
have those isolated? Better modularisation?

BrianH,  I thought it was a straigt replacement, but looking closer 
at the code, i do see the change.  Disregard my work-around suggestion.

Patrick, you can replace APPEND2 with APPEND APPEND.

It's a global search-and-replace in the source rather than a simple 
assignment, but it works.

Thanks Brian,  I had changed the APPEND2 to REPEND with the proper 
[ ] which seems to do the same thing as APPEND APPEND.
				repend blk ['label ajoin ["Field " n]]
				repend blk ['field form first+ fields]
				repend blk ['button "Change"]
Thanks!

REPEND has more overhead than chained APPEND.

Didn't know that!!!

REPEND creates an intermediate block - it doesn't REDUCE in place 
like APPLY, since it is mezzanine.

Brian, If I wanted APPEND2 to take on the value of APPEND APPEND, 
how would I do that?
I tried APPEND2:  [append append] but it is not what I wanted.
I also tried APPEND2: 'append 'append but still not right?

What is the proper way to have APPEND2 take on the APPEND APPEND 
so that when you run DEMO, it resolves correctly?

Make a function named append2:

append2: func [blk val1 val2] [append/only append/only blk :val1 
:val2]

Oh so you first need to take a look at the append function like HELP 
APPEND,

then define another function to pass along the same parms etc with 
the APPEND function in it.
so then you could also say this:

append2: func [blk val1 val2] [append append blk :val1 :val2]    
 (without the /only refinement)
I mean to say is that the above could also work,  right?

Yes, but I think you want the /only refinement in this case.

got it!   -- Thank you

You don't need to replicate the type spec of the arguments since 
this is just a helper wrapper function.

Can R3 be run in CGI mode? There seems to be -c command line switch, 
but no CGI helper functions, nor system/options/cgi path ....

IIRC Carl posted some short notice on that, but can't find it. I 
would like to start testing it, e.g. the speed of page build in comparison 
to R2.

Pekr:

http://www.rebol.net/r3blogs/0182.html

Thanks, just found it too :-)

Disappointed by outcome of latest blog. Binary conversion issues 
are still a catastrophe. We were supposed to get it right and easy, 
ok?

Writing a reaction ...

Using issue! to encode binaries is a disaster. We need better conversion 
functions, not syntax tricks.

then issue is completly usless type - remove it

It's useful as a syntax type. We are thinking of making issue! a 
unique and immutable string as well, with supposed modifications 
generating a new issue!. It would be like words without binding or 
as many syntax limitations.

I put my reasoning into blog post ...

hmm, Carl dismissed #1113. I wonder if 'bind is used so often, that 
he was afraid of overloading it, and introduced new mezzanine instead? 
Was that really necessary? Another one to learn ...

Apparently he considers initializaton to be out-of-scope for BIND. 
Oh well, it might have been cleaner - we'll see.

BrianH: is there a bug ticket for?:

>> to-issue #{0001}
== #??


... I did not understand from your blog post, if it is supposed to 
be fixed already, so the ticket exists, or not ....

I mistook the problem you were proposing for one that had already 
been fixed :)

yes, but is above a bug? Should be reported, no? :-)

ah, damned, latest time related changes brought back so called RED 
ICONS problem once again :-) We are still not reporting timezones 
correctly, ignoring summer time ....

Ah, actually quite the reverse. The problem of R2 is gone. Summer 
shift time is different date each year .... R3 works correctly, R2 
does not ...

That's cool - even a73 was broken - when you set time back to winter 
time, it reported wrong zone information. a74 works correctly.

Pekr, the above is not a bug. Your proposed change would be the bug. 
The issue! type is a string type, not a binary type.

We don't want to encourage any tendency to see issue! as a replacement 
for binary!, especially since issue! is a collection of Unicode codepoints 
internally, not bytes. The issue! type is also poor for binary conversions, 
due to the fact that it was designed for other things. It works well 
for what it was designed for, though there are proposals to make 
it work better for that (the unique string stuff mentioned earlier).

I really don't understand your attempt to make issue! be a binary 
conversion device. It never worked as well as binary! for that, nor 
is there any reason to expect that to change. Why don't you want 
to use well-designed binary conversion functions, rather than bad 
issue! tricks? The functions could even be backported to R2.

Because historically I am far from being alone, who finds current 
R2 working as being complete mess. How can anyone defend it? I can 
easily tell you, where it comes from. I am far from good at wrapping 
libraries, but I wrapped some functionality in the end. I can often 
see constants like:

0x0010

Which are for me equivalent to:

#0010  ; which I can get via to-hex or to-issue 16

#{0010} ; to-binary 16 = #{3136} .... and this is big WTF? Now at 
least R3 gets it correctly, although padded by full of zeros to form 
64  bit value


So, as you can see, my thought pattern came from not easy way of 
how to convert between integer and binary representation. I created 
my own crazy 2-binary function :-)


to-binary*: func [value [integer!]][load rejoin ["#{" to-string copy/part 
at to-hex value 7 2 "}"]]

So - stating above in regards to R2, my further thoughts went towards 
hex being a literal representation of binary values. But I forgot 
there is no hex! type, just an issue! type, which serves also other 
purpose. Now as to-binary 16 gives me desired value, I don't need 
to go via to-hex anymore ...

Sounds good to me :)

Carl's back to security for few days - file sandboxes, IP/port masking, 
evaluation limits ...  That sounds good too :-)