AltME groups: search

IIRC in all the tests I did, the binding overhead is dwarfed by all 
other considerations. 


a single execution of the block is usually longer than the binding 
process (which is slow, but rebol execution is slower still ;-) . 
 


forskip is by far the slowest loop in R2.  it was several orders 
of magnitude slower than foreach.  and much slower than an until 
block ... not worth it..   I'm happy its native in R3.


obviously, the time spent within the block with relativise the time 
spent in the iteration handling.

On the form validation issue. I managed to get things working as 
I initially intented. Using a Javascript function to change the text 
of the field: 
var changer = document.getElementById('fieldid');
changer.value = fieldvalue;
Where fieldvalue was filled from the cgi data block cgi/fieldname

It was really fun to get this right with all the needed double-quotes 
and curly braces that alle represent comments in rebol as you know 
and generate this from within the well-known function emit: func 
[code] [ repend html code]
I had to add an id tag to all the form fields.

If there is an interest in the basic script with a form with the 
field testing and refilling of field in the case some errors were 
found wrt the input. I make a translated anonimised version showing 
the working.

The "in some cases faster" depends on whether you're going in reverse, 
and how much data you have. REVERSE can have a lot of overhead if 
you have a lot of data, so with enough data it would be faster to 
just work in reverse using a WHILE loop, or possibly better yet a 
REPEAT with an index that you subtract.

Time-out! :D

I have enough information to make my script working with reasonable 
speed. After I publish it on rebol.org we can write out a competition 
to have it gain speed ;)

I wrote a run length encoding function, may be useful for someone 
else too:

rle: func ["Run length encode" b /local v r i j] [
	v: 1 r: copy []
	j: next i: b
	unless empty? b [
		until [
			either all [not tail? j equal? first i first j] [
				v: v + 1 j: next j
			] [
				append r reduce [v first i] v: 1 i: ++ j
			]
			tail? i
		]
	]
	r
]

here is the tests:
>> rle "aaabbcx"
== [3 #"a" 2 #"b" 1 #"c" 1 #"x"]
>>
>> rle []
== []
>>
>> rle ""
== []
>>
>> rle [a]
== [1 a]
>>
>> rle [a a a a a]
== [5 a]
>> rle [a a a a a b b]
== [5 a 2 b]

Endo: I think a much faster version could be coded using PARSE.

Here's a version for R3 parse, with some optimizations:

rle2: funct ["Run length encode" b [series!]] [
	output: copy [] x: none

 r: either any-block? :b [qr: copy [quote 1] [(qr/2: :x) any qr]] 
 [[any x]]
	parse :b [any [pos1: set x skip r pos2: (
		reduce/into [subtract index? :pos2 index? :pos1 :x] tail output
	)]]
	output
]

rle2: funct ["Run length encode" b [series!]] [
	output: copy [] x: none

 r: either any-block? :b [qr: copy [quote 1] [(qr/2: :x) any qr]] 
 [[any x]]
	parse/case :b [any [pos1: set x skip r pos2: (
		reduce/into [subtract index? :pos2 index? :pos1 :x] tail output
	)]]
	output
]

>> rle2 [a a A b b c d D d d d]
== [2 a 1 A 2 b 1 c 1 d 1 D 3 d]

I tried to come up with a more optimal R3 version without using parse, 
but I got blocked by case-sensitivity, without considering binding. 
I suppose I could just consider binding too, or unbind the results. 
It also doesn't do structural comparison of functions, either in 
the parse or procedural version.

Here's a R2 solution with same rules for string! and block! series:

rle: func [s [series!] /local out c i][
    out: make block! 1

    parse/case/all s [
        any [
            [end | c: (
                c: either word? c/1 [to-lit-word c/1][c/1]
                i: 1
            )]
           skip
           some [
               c (i: i + 1)
               | (repend out [i c]) break
           ]
       ]
    ]
    out
]

>> rle "aaabbcx"
== [3 #"a" 2 #"b" 1 #"c" 1 #"x"]

>> rle [a a a a a]
== [5 a]

>> rle [a a a a a b b]
== [5 a 2 b]

>> rle [a a A b b c d D d d d]
== [3 a 2 b 1 c 5 d]

Another version of 'rle for R2 that uses two pointers (like your 
R3 version) instead of a counter:

rle: func [s [series!] /local out c pos1 pos2][
    out: make block! 1

    parse/case/all s [
        any [
            [end | c: (
                c: either word? c/1 [to-lit-word c/1][c/1]
            )]
           pos1: skip

           some [c | pos2: (repend out [offset? pos1 pos2 c]) break]
       ]
    ]
    out
]

Brian: I'm just giving a solution that matches the requirements from 
Endo. The block example he provided contains only words.

Ah, yeah, I overspecced the R3 version by using QUOTE. Although there's 
a standatd workaround for integers (precede it with 1 1), for any-blocks 
and functions it might be best to do the comparison using REBOL code. 
The R2 equivalent of the IF operation in R3 parse would help here: 
http://www.rebol.net/wiki/Parse_Project#IF_.28condition.29

Here's a version of Doc's with all datatypes handled, even unset. 
It even avoids accidentally converting lit-words to words and lit-paths 
to paths:

rle: func [s [series!] /local out pos1 pos2 cont][
	out: make block! 1
	parse/all s [
		any [
			pos1: skip some [
				pos2: skip (cont: if any [
					not-equal? unset? :pos1/1 unset? :pos2/1
					strict-not-equal? :pos1/1 :pos2/1
				] [[end skip]]) cont |
				pos2: (repend out [offset? :pos1 :pos2 :pos1/1]) break
			]
		]
	]
	out
]

For old versions of R2, you might want to change IF STRICT-NOT-EQUAL? 
to UNLESS STRICT-EQUAL?. There used to be a bug in STRICT-NOT-EQUAL? 
in R2, but I forget how far back it was fixed, one of the last couple 
versions.

Here is the benchmark results (execution time for 1.000.000 calls)


>> benchmark [rle [a a a b b c A A a a]] ;BrianH (the old one, not 
the crashing ones)
== 0:00:29.765

>> benchmark [rle [a a a b b c A A a a]] ;endo
== 0:00:32.953

Endo: you should rather bench on one long series rather than 1M times 
on a small one in order to avoid function calls overhead and get 
a more fair comparison. When I try with a 1M size string with random 
a,b,c chars, my parse solution is twice faster than the mezz one 
(Brian's one is crashing so can't test it). I was expecting a greater 
difference though.

Talking of test, I am trying to write a simple function that checks 
if a data item matches a rebol datatype, so for example:

    print is-it-a? "number?" "12.5"
    == true
    print is-it-a? "number?" "xxx"
    == false
    print is-it-a? "number?" "?"
    == false


Except my function goes bad on that third example -- it prints the 
console help text.


Any thoughts on how to check incoming values without executing them 
as code? Thanks

    is-it-a?: func [
       data-type [string!]
       value [string!]
    ][
      data-type: first load/all data-type  
      error? try [
          value: first load/all value 
          return do reduce [data-type value]
      ]
      false
    ]

is-a: func [f v][
	not not all [
		f: get/any load f
		any-function? :f
		f load v
	]
]

Thanks Steeve, that's much more robust than my code :)

Just for info .....


....It needs some error trapping to handle un-loadable values, eg:
    >> is-a "number?" "33.e"
    ** Syntax Error: Invalid decimal -- 33.e


....And (like my code) it's not so good with 'true and 'false owing 
to the way REBOL works:
    >> is-a "logic?" "true"
    == false

But it'll do the job!

You can get rid of this line too for a slight speedup:
				end pos2: emit break |

It's a leftover when I was trying to work around the bug in PARSE.

providing an optional output buffer  (which the user can pre-allocate 
to some ideal size)  would make a VERY big difference on large inputs.


usually, when it goes into the hundreds of thousands, repetitive 
series re-allocation on growing mutable series,  will kill any kind 
of optimisation you can dream of. 


rle: func [s [series!]   /into out  [block!]  /local out emit pos1 
pos2 cont][
	out: any [ out     make block! 2 ]
 ...
]


this is especially effective on repetitive calls to the above function 
and using clear on the given buffer so that it auto-grows to an optimal 
size and is fast on later calls.


just today, I was doing some encryption benchmarking and when I hit 
strings larger than 1MB it was taking several minutes... thats until 
I realized that it was my dataset generator (a looped string insert) 
which was taking 98% of the cpu time.  !

>> head rle/into "ddeeee" rle/into "aaabbc" make block! 10
== [3 #"a" 2 #"b" 1 #"c" 2 #"d" 4 #"e"]

now that's a pretty nice RLE encoder.     :-)

>> mold/all rle reduce [() () 'a () 1]
== "[2 #[unset!] 1 a 1 #[unset!] 1 1]"

It is what I like about this community :)

I knew that when I write a RLE function, BrianH will come up a much 
better version. Doc and others joined as well and now we have a very 
good function. Just like the CSV tools. Thanks.

In mezzanine style:

decode-rle: func [
	"Decode a run length encoded block"
	rle [any-block!] "Block of [integer value]"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The output buffer (modified)"
	/local x
] [
	unless into [
		x: 0  foreach [i v] :rle [x: x + :i]  output: make block! x
	]

 foreach [i v] :rle [output: insert/only/dup :output get/any 'v :i]
	either into [:output] [head :output]
]


Instead of testing for strict format compliance of the input block, 
it uses get-words to keep people from sneaking in functions and then 
passes the length value to + and INSERT/dup, counting on the type 
tests of those functions to do the screening for us.

You're right, having the make block! take the foreach expression 
as a parameter is safe; I forgot that make block! can take none as 
a parameter.

Sometimes you want to allow someone to pass in functions and then 
let them evaluate, as long as you have a good semantic model for 
what is supposed to happen and are careful about how you call them. 
The ARRAY, EXTRACT and REPLACE functions in R3 and R2 2.7.7+ are 
a good example of this.

decode-rle: func [
	"Decode a run length encoded block"
	rle [any-block!] "Block of [integer value]"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The output buffer (modified)"
	/local x
] [
	unless into [
		x: 0  output: make block! forskip rle 2 [x: x + :rle/1]
	]
	forskip rle 2 [output: insert/only/dup :output :rle/2 :rle/1]
	either into [:output] [head :output]
]

Darn, just found a bug in ARRAY for R2 and R3. Litwords are converted 
to words and litpaths are converted to paths.

Steeve, that's basically the same as my R2 RLE's block rule, but 
with the IF workaround replaced with IF. It has a few gotchas:
- Executes function values in block data
- Doesn't handle unset! or error! values

- Converts lit-paths to paths and lit-words to words before comparison 
and again before putting in the output.
- Lots of intermediate block creation overhead

- Considers bindings of words when comparing them, not just case-sensitive 
spelling


The first 3 can be handled by using :p/1 and :e/1 instead of p/1 
and e/1, and the fourth by using REDUCE/into instead of REPEND. The 
last one can't be handled by any built-in function or operator in 
R3 (see http://issue.cc/r3/1834for details) but you could do a combination 
of functions and operators to get case-sensitive comparison without 
considering bindings. PARSE/case's QUOTE operation is the fastest 
method for doing that at the moment.


Nice job on neatly bypassing the relaxed bounds checking of R3 blocks. 
Though the if (p/1 == e/1) would succeed if p/1 is none and e is 
at the end of the block, the skip would still fail. That trick saves 
one e: operation.

Having a strict line of progression for the R3 equalities turned 
out to be a bad idea, since the binding check seems to be tripping 
up case checks.

The advantages of == or =? comparison over PARSE QUOTE would be lost 
if you serialize the data and save it to a file or send it over a 
network. REBOL syntax doesn't keep track of those distinctions.

The PARSE IF method does let you add a /compare function option though, 
so you can be as specific as you want. Instead of if (:p/1 == :e/1) 
you would do if (apply :f [:p/1 :e/1]) then pass :== or :strict-equal? 
as a parameter..

Here's a version of my last one above, but with Steeve's trick adapted 
to make a /compare option. It defaults to its old case-sensitive 
behavior.

rle: func [
	"Run length encode to series of [length value]"
	s [series!] "The series to encode"

 /into {Insert into a buffer instead (returns position after insert)}
	output [any-block!] "The output buffer (modified)"
	/compare "Comparator function for equvilance"
	comparator [any-function!]
	/local x r qr b e
] [
	unless into [output: make block! 2] x: none
	r: case [
		compare [[any [e: if (apply :comparator [:x :e/1]) skip]]]
		any-string? :s [[any x]]
		'else [qr: copy [quote 1] [(poke qr 2 :x) any qr]
	]
	parse/case :s [any [b: set x skip r e: (
		output: reduce/into [offset? :b :e :x] :output
	)]]
	either into [:output] [head :output]
]

Whoops, forgot a bracket:

rle: func [
	"Run length encode to series of [length value]"
	s [series!] "The series to encode"

 /into {Insert into a buffer instead (returns position after insert)}
	output [any-block!] "The output buffer (modified)"
	/compare "Comparator function for equvilance"
	comparator [any-function!]
	/local x r qr b e
] [
	unless into [output: make block! 2] x: none
	r: case [
		compare [[any [e: if (apply :comparator [:x :e/1]) skip]]]
		any-string? :s [[any x]]
		'else [qr: copy [quote 1] [(poke qr 2 :x) any qr]]
	]
	parse/case :s [any [b: set x skip r e: (
		output: reduce/into [offset? :b :e :x] :output
	)]]
	either into [:output] [head :output]
]

You could reduce the compressed size of a string-specific RLE by 
putting runs of singletons into strings, like this:
>> rle "Hello World!"
== ["He" 2 #"l" "o World!"]

Agreed. Not that many repetive runs of characters in string data, 
so a better compression method would be preferable.

but when you submit this as a JSON parameter ... it fails

{"b":null} is the actual value
{{"b":null}} is Rebol's way of telling us it's a string

Hm, that's a lot of differences

If you are doing anything in PARSE, or generating blocks, or a wide 
variety of other things, it almost always pays off to do it in R3 
if you can, rather than R2 or any of the other REBOL-alikes except 
maybe Topaz. Topaz has a few PARSE enhancements that R3 could use, 
but the rest don't even come close; there are so many bugs in R2 
that need to be worked around that code for it can be quite different. 
Unfortunately, other factors can prevent people from using R3. Hopefully 
when Red itself is developed, not just Red/System, it will adopt 
the changes that we made for R3.

Gabriele has done a great job of reimplementing many of R3's PARSE 
enhancements in R2 using rule generators. If you're stuck on R2 or 
REBOL-alikes with R2-like behavior, that's a good place to start. 
It also helps to look at the parse project page, since there are 
a lot of code equivalent examples in the proposals there. That way 
you can translate your rules manually, and in some cases get faster 
rules as a result. Be careful with unset! vlaues though since there 
are a lot of bugs and limitations to R2's unset value handling, as 
demonstrated in the R2 RLE code above.

Brian, it's so nice to have a Parse expert here. Thanks for your 
advice.

Speaking of Parse. I think it could be useful to compile some kind 
of FAQ or even better a tips&tricks doc.

Two things:

- It iterates through a range of numbers by step, sort of like FOR, 
returning the new value.

- It saves the state of these iterations in a block that is local 
to the function, which it calls "stack" even though it is not a stack.

Here's the function commented:

iter: func [idx start end step  /local stack][

 stack: head []  ; Saved iteration states, persistently updated, indexed 
 by idx
	; Prefill with none through idx
	while [tail? stack: at head stack idx] [insert tail stack none]
	; Initialize iteration state to end value
	if stack/1 = none [stack/1: end ]
	; Increment by step
	stack/1: stack/1 + step
	; If we've gone past the end, rotate back to the start
	if stack/1 > end [stack/1: start]
	; Return the current value of the iteration
	stack/1
]

And optimized/simplified:

iter: func [idx start end step /local stack][

 stack: []  ; head unnecessary, the inline value is at its head already

 insert/dup tail stack none idx - length? stack  ; faster than while

 stack: at stack idx  ; will succeed now, position doesn't persist 
 between calls

 stack/1: step + any [stack/1 end]  ; initialize and increment in 
 one step
	if stack/1 > end [stack/1: start]
	stack/1
]


Note that the function doesn't work if idx, start and end aren't 
numbers, start isn't less than end, and step isn't greater than 1. 
However, all of the code that calls it has these qualities.

It is stil confusing (to me) because the variable 'stack' is declared 
to be a local variable.

It is stil confusing (to me) because the variable 'stack' is declared 
to be a local variable.
 - more confusing is that it is not a stack as Brian pointed out

Arnold, 'stack is local to the function.  Ordinarily you would make 
a copy each time the function is called so that you have an empty 
new block.  But here the function does not so that the block contents 
are available unchanged between calls.

however, the STACK local variable is actually not just "local variable", 
it is a value in the function body. In this case the only way how 
the value could be collected is to collect the function

so you would have to unset the function ?

 - you cannot unset a function. You can only unset the variable referring 
 to it.

Arnold, What I meant to say (and what ladislav is trying to say, 
I think) is that the code inside a function is not Garbage collected, 
so when a function has a litteral value.. that litteral value is 
the same at each execution (its static).

no.  it depends if they are referenced at least once in a value which 
is not also GCd.

so if you have a function in a block, named or not, it won't be GCd 
if that block is still refered to somewhere.

so let's say you have something in a vid defintion

button "Test" [
	use [ f ][
		f: func [] []
	]
]

this is not subject to GC?

this is not subject to GC?

 - Such a function looks like a subject to GC, but you need to find 
 out *when*.


- in R2 it is a subject to GC right after the button is pressed and 
released

- in R3 the function *may* persist after the button is pressed for 
the first time and *before* it is pressed for the second time

@Ladislav, have you written a paper on GC in Rebol ?

have you written a paper on GC in Rebol ?

 - the reason why the function persists between presses in R2 is based 
 on the fact that USE modifies its argument block "leaving" the local 
 variable in it. (it is described in Bindology). In R3 USE is a closure 
 written in REBOL, that is why there may be some "persistence" until 
 the USE function is called next time

IIRC in R3 closures do a BIND/copy of their bodies at every call, 
then execute the copy. As soon as the USE is finished executing its 
context and body are no longer referenced, at least if you didn't 
save a reference elsewhere. The context containing the 'f and the 
function it references would be able to be GC'd as soon as the USE 
returns.

Yeah, R3's USE does a COPY/deep of the body, then make closure! uses 
the copy itself, then when executed (IIRC) the closure executes a 
BIND/copy of its body. So it copies its body more than once, but 
possibly less than twice.

so to control GC one should in such a block unset the contents before 
leaving it ...

Sorry, didn't get that. In R2 if you are using functions not defined 
by the CLOSURE function then you might want to set some local variables 
to none before returning - that's what ALSO was for, btw. In R3 you 
don't need to unset anything because the GC will collect the set 
of values associated with the function's local variables after the 
function returns, or the whole context after a closure returns.

It's a stack frame. Stack frames are automatically available for 
collection after the particular function call returns. All function 
words are referenced stack-relative.

Whoah, it turns out that R3's closures do more than a regular BIND/copy 
when they run, they copy strings too. Surprised I hadn't tried that.
>> c: make closure! [[] [append "" 1]]
>> c
== "1"
>> mold :c
== {make closure! [[][append "" 1]]}

Same in R2: MAKE function! does more than a BIND/copy on its body 
as well, it also copies strings.
>> c: closure [] [append "" 1]
>> source c
c: func [][native action function! [[throw]] [append "" 1]]
>> c
== "1"
>> c
== "1"
>> source c
c: func [][native action function! [[throw]] [append "" 1]]

Functions and objects aren't copied, but everything else seems to 
be:


>> a: reduce ["" #{} 'a/b [] quote () make list! [] make hash! [] 
does [] context []]

== ["" #{} a/b [] () make list! [] make hash! [] func [][] make object! 
[
    ]]
>> b: bind/copy a 'a

== ["" #{} a/b [] () make list! [] make hash! [] func [][] make object! 
[
    ]]
>> map-each [x: y] b [same? :y first at a index? x]
== [false false false false false false false true true]

I guess that R2's make function! and R3's closures to a BIND/copy 
after all.

What we need is a document that discusses best practice for writing 
Rebol code.   Or is there such a beast?

Ideally this should be in a book chapter .. perhaps Jerry could include 
it in his book as a guest chapter ?

In your first try (bind 'e self), you're binding only this 'e word, 
not the :e function body, so if you replace it with: bind second 
:e self, it will work.


In second try, you're never binding 'e function body, you've just 
binded a new instance of 'f word that you have created using FIRST. 
That's why it works when you add DO, you're evaluating that new 'f 
instance which has the correct binding. Just remove FIRST, it will 
bind 'e body block and you'll get the result you've expected.

>> e: func [] [f]
>> o: context [f: does [print "ok"]]
>> bind second :e o
== [f]
>> e
ok

Got it, thanks a lot. I didn't know that FIRST gives me a "new" word, 
I thought that I'm BINDing *the* word itself and it should stay BINDed.

This confused me a bit:
>> o: context [a: 1 b: 2 c: 3]

>> foreach x bind [a b c] o [probe get x] ;this works, BINDs block 
to O

>> foreach x [a b c] [probe get bind x o] ;this works too, BINDs 
the word 'X to O

No, it doesn't bind 'x, it binds x, which is evaluated to 'a, 'b 
or 'c.

I see, thank you. And in the first line, it doesn't BIND *the block* 
to O, it BINDs the block of words (which are 'a, 'b and 'c) to O. 
It's clear now. Thanks!

Another interesting problem I have: I have a script as follow:
REBOL []
probe system/options/args
halt


I encap this script, no problem, it works as expected, console opens 
and "none" appears:
none
** Press enter to quit...

If I run it with some params like "test.exe --test"
["--test"]
** Press enter to quit... 


But if I run it with some parameters, like -c, --sec, it prints nothing? 
(-c and --sec seems to be special for rebol.exe but it works with 
-s which is special too)
** Press enter to quit...

Why and how PROBE doesn't produce an output?

Let me simplify:

REBOL []
print "ok"
print system/script/args
ask "test"


When I encap this script and run with a parameter like "-cxx" it 
doesn't print ANYTHING.

no "ok" no "test" nothing. BUT when I WRITE system/script/args to 
a file it looks it is there.

REBOL []
print "ok"

write %test.txt system/script/args ;there is "-cxx" in test.txt file.

It's very weird, so we don't have a chance to use a parameter starting 
with -c (and many other) in our encapped executables.

Might be a bug where encapped REBOL tries to consume its own command-line 
options (while it shouldn't).

Aha PRINT and PROBE doesn't work in encapped executable if command-line 
parameter includes a "c" character.

Endo, when you are using set-words with MAP-EACH and R3's FOREACH, 
be sure to include at least one regular word, or it won't advance 
and you'll get an endless loop. We made that possible in order to 
support the foreach [x:] data [... take x ...] code pattern. It's 
the type of thing that would generate a warning in other languages, 
but REBOL is inherently incompatible with warnings.

BrianH: Yes I realized that at least one word is required.

sqlab: I encap a script and run the executable, so I should able 
to use any command line parameter. And I don't encap with cgi option. 
Also -w parameter has no such a problem (which is "no-window option 
for REBOL)

Anything that include "c" char prevents to print/probe to the console.

On the other hand it doesn't prevent opening console window. I see 
"** Press enter to quit" message when program HALTed but PRINTs don't 
output anything.

A beginners question. I have some code that allows a user to input 
a date or leave it blank;

datetime: field

I get the data by accessing;

datetime/text


My question is, if the user leaves the field empty, how do I test 
for this? I have tried none? And empty?

If none? datetime/text [print "Select a date"]


produces a Script Error: 'datetime has no value'. How do I test if 
datetime/text is null so I can ask the user to go back and fill in 
the datetime field?

a one liner:

until [  view layout [fld: field]    not empty? fld/text ]

GrahamC, It was simpler than that. The program I am working on has 
over 1300 lines of code, and I mis-typed a variable name! So it turns 
out I was trying to access a word that did not exist, was not defined. 
I'll remember that for next time. (Yes, there will be a next time). 
Thanks for all the help. I am beginning to feel competent programming 
in Rebol2.

Found some code/documentation about playing a sound (wav) on www.rebol.com/docs/sound.html 
 

but although rebol/view 2.7.8 (Win XP) has Sound 1.4.0 on board it 
seems using the sound:// port is reserved for use by the SDK version? 
** Access Error: Cannot open sound
** Where: halt-view
** Near: sound-port: open sound://
on MacOSX I get
** Access Error: Invalid port spec: sound://
** Where: halt-view
** Near: sound-port: open sound://

But that is less surprising since there is no Sound module available 
there.
So what is Sound (1.4.0) about?

could be a rights issue? That the port may not be freely accessible.

That was a long time ago, and it should say "Feature not available 
in this REBOL"

Arnold, I've been using sound in a recent app with 2.7.8.3.1 with 
no issues (on XP too). I use a version of Nick's code http://musiclessonz.com/rebol_tutorial.html.
Look for "play-sound"

An answer in a not web public group -> Chit chat

Somehow indeed I managed to mix up core and view console so sound 
did work afterall. Sorry for the noise :( 
But still a wish for sound in REBOL on other platforms.

Not at the moment, as far as we know. At least if there's a workaround 
noone has figured it out yet. You can signal asynchronous events 
with callbacks though, afaik.

even the event list is a hard-coded list.  which is part of the problem.

callbacks do have issues which make them unusable in the real-world 
IIRC (its been a while)

wasn't there a bug wrt errors and stuff like that?

There was a plan to make device extensions, but Carl didn't know 
what API to use. He did a callout for advice, but that didn't get 
much response.

people who where able to help did respond and he liked a few of the 
ideas, he just never acted on it or actualy start a real discussion.

IIRC they had some success with the pattern of using a callback to 
signal R3 to grab data using a synchronous call.

to allow full (run-time) extensibility of R3 as it is, it needs two 
other apis:
-a decent event registration mechanism (add new types and specs)

-a device registration system (so we can link schemes and protocols 
to them).