World: r4wp

Endo: I'm living surrounded by mountains, so it's very close, as 
the temperature climbs very high (from 30°C up to 45°C) here on June/July/August, 
I can enjoy the fresh air on the summits. So I can go by bus (very 
cheap) or just hitchhike, it costs me almost nothing.


Pekr: for July, certainly, I expect to start commiting again in the 
next days, probably on monday.

I somehow had the idea you lived in/near Paris. I must relocate you 
elsewhere, mountains nearby and cost of living only 400 euro's a 
month. (including the ski-pass in the winter sure thing) :-)

Oh by the way, thanks for the update! Success with the contract!

I used to live in Paris, six months ago I moved to Podgorica, main 
city in Montenegro, where life is much nicer and cheaper than Paris. 
One of the main reason is being able to continue working on Red. 
Ski-pass in the winter is about 15€/day.

OpenCV binding coming, cool! I looked into the project several times 
- allows to have camera tracking implemented into your app ...

I made a donation to Red Project via PayPal, and 10% (50 Euro) of 
my payment was missing (excluding any fees). I made a phone call 
to PayPal to find out why they "swallowed" my money, They checked 
the records and told me indeed 10% was gone, and they were not sure 
why. They gonna investigate it and give the the answer. Well, How 
luck I am that I check with Doc, or the money is just gone. Shame 
on PayPal.

Quite incredible that they can loose money like that during a transfer...

Hmm, then I hope Doc, that you always receive 50 EUR, when I send 
the donation? I would be surprised, if it was lower amount of money, 
and would have to use wire-transfer instead of the PayPal in such 
a case ...

Pekr: yes, I always check. First time I see such kind of issue with 
donations through PayPal.

Float32! to integer! conversion routine for Red/System: https://gist.github.com/2919931
(requires the last commit from today from master branch)

great, some commits again :-)

Great!

Thanks Doc.

While dreaming about the next best thing coming from the Red community 
... here are some IDEs for ARMs processors http://www.ti.com/lsds/ti/dsp/support/dev_tool/ccs_overview.page
 and then some emulators and analyzers http://www.ti.com/lsds/ti/dsp/support/emulator_analyzer_overview.page

I've tried running Red/System on my Synology USBstation 2 and hello-world.reds 
works without problem. Great! Howerev, when I tried to run Kai's 
C-linrary (or other extensions), I ended up with this error:

./C-library: symbol lookup error: ./C-library: undefined symbol: 
atexit

any ideas how to solve this problem?

try to search the "atexit" at REBOL3 world, there's few remarks about 
that ...

Thanks, I look into it.

Seems like atexit() is not implemented in some glibc versions.

Well, some progress! I changed atexit to __cxa_atexit and now I can 
run cURL test (with "Couldn't resolve host name" error). Mandelbrot 
and Fibonacci tests from C-library examples give me "Illegal instruction" 
error.

Is your platform ARM-based?

Yes, it's got ARMv5TE processor. I guess it doesn't have FPU unit 
(so no wonder Mandelbrot test  doesn't run). I'm running some tests 
and I've got the Fibonacci demo running (after removing to-float).

An FPU-emulation should be available anyway, but might require a 
different calling convention than the one used by ARM port of Red/System 
currently.

I guess we would need a new compilation flag to choose between differents 
ABI.

Hi, I am looking into OAuth. I see (and thank you a lot for this!) 
that Chriss Ross Gill created OAuth client part in the twitter library: 
http://reb4.me/r/twitter.html, I am reading into it, but does he 
or anyone else know how much additional work would be needed to do 
the rebol OAuth server part ?

Ah sorry! I wanted to post this to web, but got "internet got busy" 
and while I was trying to fix it I posted here

There's already a switch in the C library binding from atexit to 
__cxa_atexit for Syllable. I vaguely remember the problem was indeed 
also reported for other systems on ARM platforms. I can switch it 
for ARM as well as long as we don't have more specific info

Done

The last info was that there are still bugs remaining in Red on ARM 
to get the bindings working, so that's probably the problem with 
cURL

Still callback issues?

Dunno, you reported them :-)

I remember that Andreas should have made an entry in the bugtracker 
to describe a semantic issue with callbacks that could lead to crashes 
if the programmer was not very careful, but I can't find it. I guess 
I should dig out my IRC logs.

https://github.com/dockimbel/Red/issues/204

All I know is that you didn't get cURL and GTK working on ARM Debian

Thanks, so it seems we fixed that one.

Yep, GTK, not so far, cURL, I don't remember, will need to test it 
again.

Doc - I might have idea of how you will aproach port model in Red. 
What about events? Carl said, R3 had fast implementation, but we 
also looked into libraries like liboop, libevent, etc. What is the 
plan in that regard? I expect you created Red because you envisioned 
the concurrency is a must? I hope that RED will be a killer in fast 
event handling and concurrency :-)

LibEv is better

there is also some small library for threading, photonthreads, or 
something like that?

(protothreads)

Well, we need to integrate an R3-like async port/event system with 
multithreading (both internal threads and OS threads), that's the 
real challenge. So port! might be implemented as a sub-class of actor! 
(basically a message-based object). This is still rought as I haven't 
worked on the details of ports and actors yet. I'm not sure that 
using an external library for that very sensitive part would be a 
good idea, because we probably only need a tiny subset of the features 
provided by those libs and we need a perfect integration with the 
rest of the runtime/language. You can count of me to implement the 
solution that will give us the best performances, as this is a critical 
feature for being able to implement state-of-the-art servers...and 
you know that we want a very fast Cheyenne v2. ;-)

Those libraries might be good for inspiration - their code is MIT/BSD, 
cross-platform, documented limitations, etc. But I agree. I simply 
want event port being just another kind of ports, funcitoning as 
a kind of seris - lookup, traversla, sort, filtering, etc :-)

Can't wait, when we get to that level in RED .....

Protothreads is an interesting minimalistic approach to cooperative 
concurrency, but probably too limited for implementing something 
like task! or actor! BTW, I'm not sure if task! will be required 
in Red, in R3, it starts a new OS thread IIRC, although, I might 
use it to spawn a new process instead, as threads management will 
be covered by actors.

Those libraries might be good for inspiration

 Certainly! I have read the source of libevent in its early versions, 
 lot of interesting code there, but nothing really new since the famous 
 "C10K problem" article more than ten years ago.

I simply want event port being just another kind of ports, funcitoning 
as a kind of seris
 

Hasn't that model been abandoned in R3?

as Kaj said - there is new spin-off, LibEv, from 2007 - lighter, 
faster, removed original restrictions, etc. I do remember the C10K 
article, I suggested it to Carl, he read it, but his opinion was 
similar to your - simply that we don't need all those features. He 
probably wanted to rely on what is available under particular OSes 
...

Well, R3 moved to devices abstraction, that's first difference to 
R2 - an abstracted platform agnostic Core and surroundings. Not sure 
if there is any practical benefit ...

so, under R3, evt: open event:// works ...