World: r3wp

Please have a look at the signal handling code. It doesn't comply 
with SWITCH semantics anymore

Kaj: have you tested again with latest commit? This issue should 
be fixed now, I've left some lines commented in _PRINT function, 
so that pointers and structs addresses were not printed anymore, 
that matches with your buggy error report.

Kaj's article on OSNews translated in Chinese for OSEye.net: http://www.oseye.net/kb/show/2774

I wonder what is written on the orange banner on top of the Android 
screenshot?

Cool :-)

Thanks, I'll test again

They have taken over Syllable articles before

Kaj, Will float deployment in Red allow GTK range widgets to be supported 
in your binding?

I think so, but you won't be able to calculate such things yourself 
yet. Do you need them?

Floats work better on Linux now. Before, it crashed when combined 
with other code

On Syllable, I now get:

*** Runtime Error 101: no value matched in SWITCH
*** at: 80000C2Eh

Indeed, I don't see the SWITCH fixed in POSIX.reds

The fact that it crashes with a signal in the first place, I can 
fix with the workaround from bug #129, so this is another case this 
bug affects

Basically, nothing works without LibC initialisation code, except 
programming the kernel directly and exclusively

What's the ETA for fixing this? I would like to promote all the bindings, 
on OSNews and such, but I can't really do so as long as they don't 
work on Syllable

Do you have an unhandled choice in SWITCH? Rather than return an 
undefined value (since Red/System doesn't have none!) it triggers 
an error instead. Put in a default clause.

Of course if that's not the problem, never mind.

Right, the SWITCHes in POSIX.reds need default clauses. I need to 
see which signal is raised on Syllable that is not listed in ***-on-signal.

LibC init code: I need to have a deeper look in the init/exit libC 
routines first to see what's exactly happening there before wiring 
it in Red/System. I'll do that once I finish the current work on 
partial float support.

Kaj, I am doing very simple UI now using GTK based on your Doc-Kaj 
work.  It is totally adequate for what I need to do in the next month 
but after that I want to add value to my users with the range widget 
and some others such as Calendar.   I think they will allow me to 
build smaller more precise user interfaces quickly.

I have been looking for keyboard event handling in GTK with little 
luck. Is this gtk_key_snooper_install () how to detect Home,End, 
PgUp, PgDn keys?

I haven't looked into that yet, but I'll keep it in mind for the 
coming time

Are you using Red in production? That's exciting

and risky? :-)

I don't know of much that isn't risky these days

All of us in Red are forcefully steering towards production, so we're 
well aligned

Is it already possible to get input args (when I run the app from 
console)?

Yes, using system/args-count and system/args-list, see: http://static.red-lang.org/red-system-specs.html#section-12

Yes production use but not yet controlling nuclear warheads.   The 
fall back is to use the web based UI  ... now used for 2 years.  
But in 2012 the data entry requirements are being made more challenging. 
  I am planning to use GTK UI using a smaller UI surface area ... 
 looks like a good starter project in a high school course ... unfortunately 
I haven't been in high school in a few decades.

Better check the license ...some of them exclude the use for controlling 
nuclear weaponry

Kaj, you mentioned something about your Red repositories on announce. 
Is it possible to update all libs through one fossil repository now 
or do I still need to update each separately?

They're separate repositories, as they're separate projects for different 
libraries

However, Fossil remembers archives it has handled. You can do "fossil 
all ls" to see which it knows about and "fossil all pull" to update 
them

pull only syncs the archive database. You still need to go into your 
checkout and do "fossil update" to check out the updates, but you 
could do that off-line

Doc just tweeted about floating point support improvement - the list 
got updated - https://github.com/dockimbel/Red/wiki/Floating-point-support-todo-list

Doc - thanks for the update :-)

Good stuff

Doc, might be of interest to you: http://drdobbs.com/blogs/parallel/232301070

Yes it is, thanks. Good stuff for 64-bit Mach-o version. The GOT 
handling seems intricated in Mach-o, I will try to avoid the methods 
that involve fixups in code.

For the floating point format experts around: 


I am investigating the simplest and most accurate way to support 
floating point comparison by implementing an `almost-equal` operator 
in Red/System. Due to the intricacies of such task, I have selected 
the two algorithms that look the best to me:


1) Tolerance-based: http://realtimecollisiondetection.net/blog/?p=89

2) Ulp-based: http://www.cygnus-software.com/papers/comparingfloats/Comparingfloating point numbers.htm


Of course, in both approaches, there are some accuracy parameters 
to be set by the user to adjust the comparison formula (good defaults 
will be provided anyway).


Are there better algorithms or better implementations of methods 
1) or 2)?

I have x-posted that message to the Red ML also: http://groups.google.com/group/red-lang/browse_thread/thread/527afaf181eee8c7?hl=en

2) is now used in R3

Do you know if it uses the implementation from above link or a custom 
one?

ad 2) This seems to be dated, and new stuff by Bruce Dawson's here 
- http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm

Well, the implementation may be dated, but the principle remains 
the same. Moreover, we use it for doubles, not for floats, but as 
said, the principle remains the same.

Well, I just pointed to the new stuff, can't comment on validity, 
as I don't understand  the topics discussed properly, so you might 
be right of course ...

Doc, the last part of your 2nd choise (the ulp-based) named "Comparing 
using integers" is the method, I would look at. It's simple and I 
would guess, performs well. Tests are needed to say, if the other 
methods are faster. Could it be CPU dependent, which is faster?

In order to implement the algorithm for doubles did you need to have 
64-bit integers available?

I guess, you could split the 64-bit in 2 times 32-bit. If the most 
significant 32-bits are the same, you do the comparison the the least 
significant ones. This should work.