World: r4wp

>> reverse comps sort/skip/compare/all comps 2 func [a b][length? 
a/mcapz  > length? b/mcapz ]
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

Try:


func [a b][probe type? a probe type? b length? a/mcapz  > length? 
b/mcapz ]

when you use /all,   you get two BLOCKS.  one for each record of 
length /skip

so your function is called like so: 

sort-func [   "2009-2010"  #[object! [  ... ]]  ]      [ "2011-2012" 
 #[object! [ ... ]]   ]

aha, that means you don't need the REVERSE. You just need to reference 
the values differently.

reverse comps sort/skip/compare/all comps 2  func [a b][probe type? 
a probe type? b length? a/mcapz  > length? b/mcapz ]

block!
block!
** Script Error: Invalid path value: mcapz
** Near: length? a/mcapz > length? b/mcapz

Maxim's SORT-FUNC block shows you how to reference the values properly.

my last example above with ?? added shows this clearly:


>>  sort/skip/compare/all [1 [2  "a"] 0 [4 "z"] 5 [4 "m"]] 2 func 
[a b][ ?? a  ?? b   a/2/2 < b/2/2 ]
a: [0 [4 "z"]]
b: [5 [4 "m"]]
a: [1 [2 "a"]]
b: [0 [4 "z"]]
a: [5 [4 "m"]]
b: [1 [2 "a"]]
== [1 [2 "a"] 5 [4 "m"] 0 [4 "z"]]


what is part of the record is completely irrelevant to sort, it transfers 
all control to your function.

the only really problem with a compare func is that you must be sure 
that your data can be compared (which is not true for all types.

ex:  true/false  is not defined for all comparison ops:
>>   true > false
** Script Error: Cannot use greater? on logic! value
** Near: true > false

am getting somewhere (i think)
>> sort/skip/compare/all comps 2 func [a b][o: a/2/mcapz probe o]
=== make hash! ["2003-2004" make object! [
        yyyymmdd: 30-Sep-2003
        rebal-year: 2003
        ...]]
etc

so it is a referencing problem

yep... its the /2/ which is important here  <:-)

just discovered another problem though...not all inner hashes have 
the same years - so one objects inner hash may have key "1991-1992" 
while another may not

looks like i will have to collect the objects/inner-hash-objects 
into a separate collection, then apply the sorting on the new collection

c: copy[] foreach [k v] comps [if select v/mcapz "1991-1992" [append 
c v]] or some such

then use maxim's sort-func on c instead

is that generally the right direction? i would have ideally liked 
to have avoided creating new blocks to conserve memory...

you can simply say that when an entry doesn't have a year, it is 
always larger,  so you have them at the end of the list.  you could 
then sort those without a date according to their name.


if you want just the list for "1991-1992" yes, that is a good approach... 


however usually, the fastest way to filter-out lists, is to copy 
the block (not deep, so its quick) and then use remove-each on the 
new block... like-so:

filtered-data: copy data

remove-each [hash mcapz] filtered-data [ not select mcapz "1991-1992"]

will try with both approaches.

thanks for the filtered-data tip maxim - will definitely move to 
that!

anyone know which one of these would be the correct one to use?

1. percentile: func[s p /local n][n: round/floor (p * (length? s) 
+ 0.5) return s/(n - 1)]

2. percentile: func[s p /local n][n: round/floor (p * (length? s) 
+ 0.5) return s/(n)]

s is a sorted series, p is a decimal from 0.0 to 1.0

Those radio buttons are a real pain in the ... . Somebody please 
rewrite those and make a radiogroup that makes sense?

view layout [
    radio-line of 'a "Check this out"
    radio-line of 'a "or this"
    pad 8
    radio-line of 'b "Or Check this out"
    radio-line of 'b "or this"
    radio-line of 'b "or that"
]

What' exactly is your problem with radio buttons, Arnold?

Well it was quite a problem to get the selected value. I ended up 
first initialising all /data fields to their respective values beforehand 
to true for the one on and false for the two unselected ones. After 
that the fields behaved like you would expect, being true in case 
the selection was on this button and false if not selected.
Radio-line is new to me.

Something like this cost me only a couple of hours trial and err 
(mostly err) for there was no proper example to copy and it didn't 
work out of the box without the initialisations. 
main: layout [
a: radio on 'things lbl-a: "A"
b: radio of 'things lbl-b: "B"
etc]
a/data: true
b/data: false
view main

by default all radio buttons in the same pane switch together, you 
can just wrap your radio buttons in a panel.

ex:

view layout [
	panel [across radio radio radio on]
	panel [across radio on radio radio]
]

Stil that was not the problem. I wanted to know what selection was 
made :)

In my previous example b/data had a value none in stead of false 
and I could have two radioselections selected at the same time.

yeah, well, all I can say is that whenever view or more specifically 
VID is frustrating, you should just mold the face which is aggravating 
you, save the code to a file and read it in your favorite syntax 
highlighted editor.


you will learn A LOT about how VID.view works and learn quite a few 
Reboling techniques too.

very few people use functions as extensively and as precisely as 
Carl.   many functions have supported types I never even realized... 
like 'PICK which supports   true/false

(Carl wrote VID, so its a good example of his Rebol coding)

(its coarse and dense though, so don't despair if you don't undersand 
it all, just go through it line by line ... and learn)

here is a simple way to get the code for a face within the layout 
function ( I found it the easiest to remember):

view layout [
	across
	text "1"
	my-radio: radio on 
	do [probe my-radio]
	text "2"
	radio
]


the advantage of this system is that you get the actual face with 
any facets setup as they really are in your gui.  this is often the 
easiest way to identify just where and how a specific facet affects 
a face... probe it without your change, and then run it again, with 
your change... comparing both probes in a diff or merge tool.

the other way is to use get-style.   the advantage here is that is 
preserves the init block, instead of clearing it after VID has done 
its work


a good look at the 'init block is often useful to understand why 
changing some of the face values is ineffective (like changing face/color 
is often useles... since that face is setup to use face/colors). 
 

this block is run after all the facets have been applied. 

note that you can set or append to this block in your own styles.

HTH  :-)

get-radio-buttons: does [
    reduce [
        get-face option-1
        get-face option-2
        get-face option-3
    ]
]

reset-radio-buttons: does [
    clear-face option-1
    clear-face option-2
    clear-face option-3
]

view layout [

    option-1: radio-line "Option 1" of 'options [probe get-radio-buttons]

    option-2: radio-line "Option 2" of 'options [probe get-radio-buttons]

    option-3: radio-line "Option 3" of 'options [probe get-radio-buttons]

    btn "reset radios" [reset-radio-buttons]
]

Best to use the getter-/setter-methods wherever they are implemented.

anyone know which one of these would be the correct one to use?
1. 
percentile: func[s p /local n][n: round/floor (p * (length? s) + 
0.5) return s/(n - 1)]
2. percentile: func[s p /local n][n: round/floor 
(p * (length? s) + 0.5) return s/(n)]

 - I cannot recommend any of them. (ROUND/FLOOR is not what is recommended 
 in Wikipedia, also the percentile calculated this way is not compatible 
 with the "standard median definition". I recommend to use interpolation 
 on Hazen ranks as mentioned in Wikipedia under "interpolation", or 
 on Mean ranks as recommended by NIST - also can be found in WP)

I have view.txt in my rebol/script folder a copy from system/view, 
it is 80000 lines mostly object definitions and images. quite different 
from the ancient one http://www.rebol.com/view/vid.rthat at least 
makes some sense to me ;-)

getter/setter is a nice theoretical concept, nice for OO purposes. 
Radio buttons of a group should function like this: always 1 selected, 
the default to begin with, each option should have a value that is 
copied to the radiogroup's /data field, so to know what was selected 
can be found just like that. Not more not less.
rg: radiogroup rg1
radio on 'rg1  "Text 1" "A" 
radio     'rg1 "Text 2" "B"
and in your program 
switch rg1/data [
A
 [do this]
B
 [do that]]

Arnold, take a look at the VID Extension Kit. It attempts to make 
VID more complete, although it's no longer directly compatible with 
VID.

One thing to note about VID: It was a demo toolkit that Carl wrote 
about 10 years ago in a couple of weeks. He expected someone to come 
up with something better.

It is hard to beat in its simplicity. But also hard to improve in 
its current state. More a modular way would have been nicer. So it 
would have been clear where to start if you want to improve (or first 
find out) the behaviour of radio buttons for example.

Same thing as he expected the community to come up with the new bindings 
of REBOL3 to about all other Open Source operating Systems (Rebolution!) 
whereas the REBOL kernel source stays closed source. Not much animo 
since. Au contraire. Could have been the final nail...

Arnold, I came up with one solution to the radio question here:

http://stackoverflow.com/questions/6401469/how-do-i-get-the-radio-button-value-in-rebol

It may be overkill, but it iterates through all faces looking for 
the 'of relationship, returning the selected face.

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.)

Today I experimented with calling a REBOL script from my php script. 
Thanks to previous contributions of a.o. Ralph Roberts of abooks.com 
from 1999(!) and an entry on the PHP site I found out how to do this 
on my apache driven site.

It was not quite as straightforward as Robert said like: include 
("rebolnow.r");
Nor was it as simple as: system("rebolnow.r 2>&1", $myout);
echo $myout;

But it worked when I called out for the REBOL program first. Both 
two of the next examples worked for me:
system("/path/to/cgi-bin/rebol -c %rebolnow.r 2>&1", $myout);
echo $myout;
AND secondly
echo system("/path/to/cgi-bin/rebol -c %rebolnow.r");
Work!

The REBOL script must be in the same dir as your PHP script (Not 
in your cgi-bin directory)(I didn't test sub dirs and other dirs 
but I suppose they work like usual)
The script does not need the #!/path/to/rebol line at the top.
The script should not print http-headers and

When printing stuff the last line should read print "" because the 
last printed line will be repeated.

Hope this helps more people to switch from php scripting to REBOL 
scripting for their websites.

If you want to just echo the REBOL output, I would suggest using 
PHP's passthru() instead - it was designed for that:  http://php.net/manual/en/function.passthru.php