World: r4wp

I'm moving to a new dual-core machine. When compiling Red, it uses 
only one core, so I'm considering using 0MQ to make use of the extra 
core

When we'll have modular compilation, we'll be able to leverage multicore 
processors.

A new dual core machine? Do they still manufactor those? 

I kind of had the idea the OS decides when to use more than one processor.

It's only seven years old. :-) My previous machine is eleven years 
old

If your program is only one process and no threads, it's impossible 
for an OS to run it on more than one core at the same time

So on your eight-core machines, only one is really used :-)

sometimes I wonder about that even. Must be calculating that spinning 
wheel then.

Yep, it could dedicate a whole core to that :-)

I think OS X GUI apps are fundamentally dual-threaded, with one thread 
for the GUI, so in the best case, it uses two cores more or less

But seriously why not a machine that is more actual? Because you 
prove the minimalistic needs?

Yes; for example, in Syllable Desktop, almost no speedup is noticable 
in regular use

That is to say, the old machine was already more than usually needed 
for Syllable

Our fifteen years old laptops are still among the best machines we 
have to run Syllable on

Better run an ad in the local paper: "We collect your old PC's for 
free"

Nah, that costs money. We can get computers without ads :-)

Try this in Try REBOL:

call "cat /proc/cpuinfo"

That server was also donated

It is not possible to create struct with function datatype as a member?

In most cases, you have to cast to integer! to handle function pointers

fine.. this got compiled:
wc/lpfnWndProc:  as integer! :WndProc

Haven't checked to see if it's a known issue, but if I append/dup 
with a large number of elements it crashes. I'll try to track down 
the exact number. 75K does it, 65K does not (in a quick int append 
test).

Ah, I tricked myself. It is OK at 65536, but crashes at 65537. I 
thought it wasn't right at the 64K boundary.

It's too early to stress test the memory manager, as it's not yet 
completed for the handling of bigger series.

Maybe it causes stress to Gregg, that he can't stress-test :-)

Here you can compile your Red scripts online and then download the 
compile executable file:
http://bircomteknoloji.com:8181/

You can use it to test for compiling Red scripts and generated executable 
file.

Doc: Red header is case sensitive, red [ ] doesn't compile, "Invalid 
Red program" it says. Red [ ] works.

Some antivirus programs gives false alarm for compiled executables, 
so I think its better to not spread this site too much, people can 
think that it downloads viruses.

Ah, that would explain my errors Endo. I didn't include a header.

Endo, nice work! Could come handy sometimes.

For false alarms from AV software, please report them to me so I 
can contact AV vendors to whitelist Red binaries.

For Red header, I've made it case sensitive on purpose as, unlike 
Rebol which is a very uncommon name, Red is very common, the risk 
of a false header detection is much higher (for scripts embedded 
in HTML, makedoc document, etc...). So the case-sensitivity would 
lower the number of false positives. An added benefit is that it 
forces users to write Red name correctly, so not RED or red.

Endo, you could even make it a webservice that could be used with 
a simple WGET call from a command-line. ;-)

Also, when asking for the file to be downloaded, you should rename 
the file to something more human-friendly or ask the name from the 
user. You can use Content-Disposition HTTP field for doing that easily. 
Here's an example from one of CureCode's RSP:

        response/buffer: get-modes file 'full-path	

        response/set-header 'Content-Disposition  rejoin [{filename="} name 
        {"}]

On the header, having it be Red may lead to the most false positives. 
If it's at the top of a file, it would normally be capitalized.

As long as it must be followed by a left bracket, you should be OK 
though.

I do agree that it avoids being confused as an acronym.

It was my understanding that string/rs-head returns a UTF-8 cache 
of a string. How can I get this value?


I'm trying to get UTF-8 back that I fed in. The problem I'm having 
is the following:

write %syllable.org.html read "http://syllable.org"

This writes out just one character instead of the expected file.

Doc, on stress testing, I was just trying to do eyeball speed testing 
of some mezz code.

I agree that the allocator is important to fix

On the stress testing, and keeping in mind that I fully expect Red 
to be slow at many things at this stage, It is really wonderful to 
see that it's not. Yes, these are still small tests, but Red still 
impresses me with what works and works so well.

And because there are holes, it makes me think about different ways 
to solve things, which is fun.

My small test was for a FILTER function:

filter: function [
	"Returns all values in a series that match a test."
	series [series!]

 test [function!] "Test (predicate) to perform on each value; must 
 take one arg" ; TBD: any-function!
	/out "Reverse the test, filtering out matching results"
][
    result: copy []
    ; The lambda here is like QUOTE, but it evaluates.
    op: either out [:not] [func [val] [:val]]
	foreach value series [
		if op test :value [append/only result :value]
	]
	result
]

Given the block size limit, I used a block with 60K elements in it:

b: append/dup copy [] [1 b #c "d"] 15000

Then tested with simple type testing funcs. e.g. 

filter b :integer?
filter/out b :integer?
etc.

I have to loop >5 times before I see *any* delay in the console prompt 
returning. At 10 times, it seems to take about a second.

If you check http://www.red-lang.org/p/roadmap.htmlyou can see that 
GC is made just from 10%. You are allocating large memory blocks, 
but do not free them posibly.

Yes, they never get freed. I "freshen" my console frequently. :-)

It doesn't seem to slow down as I continue testing. Just eats memory.