AltME groups: search

To integrate the extension interface into R2 would be a huge task, 
and I'm not quite sure how to get around the lack of extendable objects 
(to build the module system on, since extensions are integrated with 
the module system). Adding the handle! type would be easy; adding 
the command! type would be a bit harder.

Well, you have to think a little bit if Red is the same as those 
when it comes to searching. Perl is actually unique since pearl is 
the spelling of the oyster product. When it comes to Python, I can 
tell you that in typical English language use, the frequency of the 
word python will be relatively low, so you won't really pollute search 
results for the language which has a relatively large use in the 
IT community. Ruby is somewhat similar in that you won't find too 
many uses of the singular word ruby used by the general population 
- at least not to outweigh its language name frequency. When it comes 
to Red, I can guarantee you that red is quite a common word.

Another C mistake that shouldn't be emulated is in 14.5. Don't call 
your 8-bit integer "char!", as it doesn't work with multibyte characters. 
Use "uint8!" or "byte!" instead.

uint8! is the more accurate, but a bit too cryptic. Byte! sounds 
nice.

Right, that's something to consider too. But I've often found such 
notation a bit hard to read and remember. Also to consider: hex syntax 
opens a hole in the "no digit as first character in words" rule. 
I hoped that I wouldn't have to break that rule again for other literals.

Max: p[20]:  0 and  p[13 string!]: "hello"


These are not valid syntax in REBOL nor will be in Red. You're stretching 
the syntax a bit too far with putting a colon at the end of a block!.

I.e. while you can get rid of pointer! and just use &[integer!], 
that is fine. But if you specify integer! as always being a 32-bit 
integer, you lose out in hiding cross-platform quirks.

One dialect for conveniently interfacing with C ("structs"), a different 
dialect ("records"?) for 100% precise control over bit layouts. Plus 
a way to convert between the two.

Thanks guys for the insights and propositions. I found it a bit difficult 
to follow in realtime, I'm not sure that AltME is the best tool for 
such conversations. Maybe we should give a try to the Red web forum 
next time: http://groups.google.com/group/red-lang?

Doc said "I found it a bit difficult to follow in realtime, I'm not 
sure that AltME is the best tool for such conversations"... I must 
say that I have a problem to follow conversation on blog if it's 
in french only. And I always found it strange that someone writes 
comment under article written in english in a different language... 
usualy in french.

The issue re-opening feature was a contextual option. I still need 
to adjust a bit to github's logic.

Just a note about the string! to binary! renaming (it was proposed 
to avoid future possible collision with a Unicode-aware string! datatype):


After digging this idea a bit deeper, I came to the conclusion that 
the string! datatype (in the C sense, a null-terminated sequence 
of bytes) is only a subset of a what a binary! datatype would be. 
So I would rename string! to c-string! instead.

Interactive development in Red will require a JIT compiler. That 
is a bit later in the roadmap. Remember, the project is in really 
early stages.

Some of us are new in looking at Red, so we need a bit of help.

Humm, looking at it a bit closer, it is not totally equivalent: the 
* and / operators will generate shifts only if the right argument 
is a literal integer. So: 
    a: 4
    123 * b
won't generate a shift.

So, I guess the conclusion would be: it is worth adding them. :-)

Kaj: BTW, Andreas added ELF sections table support a few days ago, 
so, does it help a bit loading executables on Syllable?

Pardon my mistake if you weren't thinking of Red/System as being 
a bit like unsafe code sections in C#, JNI code in Java, or extensions 
in R3.

NULL: a bit strange, need to check the sources for that.

Awi, that would be great, I would love to see Red run on such platform 
but I'm afraid Red's memory footprint would be a bit too high for 
a 60KB of RAM (but this might be specific to the netduino platform?). 
OTOH, Red/System compiler should work nicely there. If you want to 
help for such port, we need two things:


- a target file format emitter (I guess it would be the firmware 
file format)
- a native ARM7 code emitter as Red/System back-end. 


Let me know if you want to start working on these parts, I would 
provide additional documentations.

Doc - there is many such small platforms, even x86 based IIRC. Gumstix 
is e.g. for real, a bit pricey, but definitely not vapor - http://www.gumstix.com/store/catalog/product_info.php?products_id=256

I was a bit confused yesterday about ALIAS usage, due to this ticket: 
https://github.com/dockimbel/Red/issues/39.I jumped on fixing it 
too fast without first checking the specification, so I mistakenly 
extended ALIAS beyond its original purpose (which is just for aliasing 
struct! declarations, as described in section 4.5.5 of the specification).

Red/System requires at least a 32-bit CPU.

Wouldn't it be good to be able to write pointer! [ ] instead of pointer! 
[integer!] for a void pointer? I cringe a bit every time I see it. 
(Spoiled by REBOL, I guess)

We already have similar construction for the struct! type...I really 
don't see why this one should be wrong...Pointer! is not a void pointer, 
simply because a pointer! needs to point on something. A C void pointer 
is just a memory address, so an integer! would work fine to represent 
it on all 32/64-bit platforms I can think of.

Well, it is a bit late now as Red/System implementation is reaching 
its end. I am trying to stick as close as possible to the REBOL syntax 
we are used to, if you have better propositions for the syntax, I 
am ready examine them, but I would like to finish on Red/System and 
start working on upper layers, unless you want me to polish Red/System 
for the next months and start working on Red 6 months later than 
I planned?

Petr, it has been a bit of a process in my head in the past few months, 
but to be honest, I've decided to move all my R3 developments and 
plans to Red. All of those also apply to Syllable

Kaj: regarding chimpanzees...

my father in law has some monkeys which normally help to twist off 
coconuts from palm trees. as these little guys get older, they get 
slower and also grumpier. 2 different ones already bit my father 
in law.

we might give these retired, veteran monkeys a second life as random 
number generator! i would be a great business in thailand if i think 
about how many coconut trees and monkeys do they have here :)

Pekr, as Kaj already said, currently the minimum target is a 32-bit 
CPUs (with an MMU, I'd add). The 8-bit Atmel Arduino will likely 
stay out of reach for a while, but a 32-bit ARM-based Arduino-compatible 
thing (such as the "Netduino" or Microchip's "chipKIT") might be 
realistic sooner.

There is a bit longer description here: http://freshmeat.net/projects/red-language

That might only be useful with integer! as it should be extended 
to 64-bit when Red/System will be ported to 64-bit platforms. But 
I think that a specific macro would be more appropriate (something 
like integer-size?).

A bit hard to update my binding to a Red version that is released 
while I sleep, but I will have a look

PRINT/LINE and PRINT-LINE are a bit too long, especially for using 
from the (future Red) console.

That's what I was thinking, but PUT is a bit generic verb. OTOH, 
users coming from other languages wouldn't be shocked by PUT used 
in this context.

But REBOL users might find it a bit misleading.

freebsd with libc requires a bit more work

for example a struct of an 8-bit char! and a 32-bit integer! takes 
up not 40-bits but actually 64-bits in size (due to alignment constraints, 
in this case).

Bytes don't require alignment, 32-bit values do. In message!, vsm-data1 
is aligned on a 32-bit boundary, leaving a 2-bytes hole after vsm-size.

The 64-bit integer support might also be required in Red/System for 
that.

IA32 32-bit registers can't hold C double floats (64-bit).

I'm not used to working at that low level, so I'm moving a bit slowly 
on it

just found this... it could be a good reference for low-level bit 
handling in Red.
  

though the code is in C, its probably easier to understand this way 
and convert to Assembly after (when no comparable machine instruction 
exists).
http://graphics.stanford.edu/~seander/bithacks.html

I try to make sure that Red/System code can work the same on all 
platfoms (at least for 32/64-bit ones).

Did you do any performance improvements? I just updated after a bit 
over a month and my SDL test, drawing a gradient, is a lot faster 
:-)

Arduino boards use AVR 8-bit MCU (microcontroller), the Netduinos 
use a 32-bit MCU equivalent to an ARMv4 IIRC. The port for AVR 8-bit 
has started but it is still highly experimental. The ARM port started 
by Andreas targets ARMv5 architecture IIRC.

16-bit integers: Red/System does not need them, but interfacing with 
external libraries might require it, especially for struct members. 
I wonder if adding support for a int16! pseudo-datatype, only limited 
to struct members would be hard to add...Will have a look at it, 
once all the current pending tasks will be done.

For IA-32 CPU, it is always 32-bit on stack.

Where you will write stuff like devices (in R3 terminology), events, 
tasking/threading, simply a native stuff? As a RED/System? Or will 
it be RED itself (will not it be slow then?) I just would like to 
understand it a bit :-)

Agreed with Peter, as Red/System becomes more important now, it needs 
to be strengthen a bit more. I will publish an updated roadmap duing 
the SFD event in two weeks.

As it might be a bit verbose in some cases, macros would be welcome 
to shorten them. In such case, the convention of a "type-" prefix 
on the alias name would be a good one to follow (will document that 
in the spec later today).

What I'm a bit worried about, though, is binary compatibility. How 
are the values of type IDs determined?

I guess a solution could be to implement a 'cdecl attribute support, 
to be able to manually force the right convention. But that would 
make things it a bit more complicated for the GTK binding user. 


Another option would be to define a trampoline function in the GTK 
binding that would call the user callback. That trampoline function 
would be directly (no nested calls) passed as argument to the imported 
function, so the compiler could infer its calling convention correctly.

Thinking. I'm a bit foggy today

I think I see your concern. It might be probably less confusing to 
leave the 'callback keyword mandatory for "callbacks" and accept 
'stdcall and 'cdecl as additional attributes, but it is a bit more 
verbose also.

BrianH: I need to correct a bit my answer to your question. Actually, 
there is a small code emitter dependency on the 'callback attribute. 
It is used to save special registers (edi, esi, ebx) to conform to 
IA-32 ABI. It is only needed when providing callbacks that are invoked 
by the OS or external libraries.


I should be able to keep this feature in the new revision while making 
it transparent to the users.

Getting 32-bit literals pools to be generated reliably would already 
be an achievement ;-)

For ARM 64-bit, I just hope we won't have to continue to use literals 
pools...

Looks like Nenad will get 39 bits ARM immediate values :-)


Most likely not. A64 (the ARM 64-bit instruction set) will have 32-bit 
fixed length instructions as well.

Most Android phones run 2.2 or below, so that good is a bit limited.

Harking back to the discussion of Red strings, it might interest 
you to know that the SMS character set uses the 0 position for the 
@ character. Just one of many character sets that won't work with 
C strings. C string support is good for Red/System apps that have 
to access C string library functions, but is a bit too limiting for 
Red itself.

Do they support the Thumb2 set (32-bit instructions)?

Non-block series: in fact all series will use the same allocator, 
so 128-bit (16 bytes) is the minimum allocating unit.

however, it is a bit difficult to use, and also - allowing non-market 
sources could be marked as dangerous. Will there be ability to produce 
native Android apps, which could be published via the market?

Anyway - not sure if such a news article for OSNews is not a bit 
preliminary ... no bindings yet, no possibility to use standard channes 
(market), no RED yet = not much of a REBOL featureset either. Achievement 
is great - RED gets us onto mobile OSes, still far superior to R2 
or R3, except that Red/System is mostly a C with REBOL syntax. I 
can understand, why Doc wants to work on RED itself some bits too 
:-)


Anyway - I am here to do some testing with HTC Sensation. The fun 
part comes, when the bridge is going to be done. Imagine having parse 
and REBOL like series handling, with access to stuff like SMS, calendar, 
address-book, and other APIs :-)

I do agree that it is a bit hard to find specific things in the current 
manual

I know it's a bit frustrating currently, as we could add a lot of 
sophisticated features to Red/System, but that's not the plan. :-) 
Most users will never touch Red/System once Red gets available.

Finally I will be able to help a bit with a donation ... it's done! 
Will do better next time - New year was rough in terms of personal 
expenses - Keep up the good work everybody. For tring things a bit 
I recently ordered a Samsung Galaxy Tab 10.1 inches android tablet 
- I will receive it shortly and will try to test somewthing with 
it ... Don't know what for now but looking for something. For now 
I'm learning iOS programming in the mean time using Objective-C which 
I also have to learn ... A lot of new stuff going on.

Arduino with AVR 32-bit MCU can, there are Linux versions running 
on it.

The only drawback for now is that 64-bit values break the typed/variadic 
stack layout (meant for 32-bit values only). I need to find a workaround 
for that.

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.

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.

Is that assuming you can convert a double to two 32-bit integers 
or that you jsut split the 64 bits into 2x32 bits?

Pekr: the link you're giving is the exact same article I've pointed 
to in 2), it just have a left menu added for quicker navigation, 
but that's the same article. If I haven't just stopped on this algorithm, 
it's because of the initial warning at the beginning: 


This article is obsolete. Its replacement - which will fix some errors 
and better explain the relevant issues - is being crafted as a multi-part 
series


And from Dawson's blog: "Years ago I wrote an article about how to 
do epsilon floating-point comparisons by using integer comparisons. 
That article has been quite popular (it is frequently cited, and 
the code samples have been used by a number of companies) and this 
worries me a bit, because the article has some flaws. I’m not going 
to link to the article because I want to replace it, not send people 
looking for it." 


So it appears that there are some errors (probably some edge cases 
not handled properly).

Agreed, and I plan to keep Red as compatible as possible with REBOL 
wrt the syntax, but Red/System, as a dialect, can be a bit different.

well. I'll go rest a bit today =)

Jerry: values needs space to store various flags, and type information. 
Also, payload access needs to be 32-bit aligned at least.

What's your experience with Red/System wrapping interface? Is it 
suitable to wrap (relatively saying) "any" C defines? I am recently 
scripting VLC a bit, to see if I can use that player instead of LED 
Studio (which is really bad chinese standard LED accompanying sw) 
for our LED screen.


So far, I am fine talking to VLC via TCP - 10 lines of Rebol code. 
But their RC (remote control interface) missess advanced playlist 
handling. I was looking into vlccore library API, and I found various 
wrappers, and e.g. Python one, is auto-generated, by going thru includes.


IIRC, Max worked on something similar for R3, but never released 
the code. Now I wonder, how difficult would it be to achieve using 
Red/System?

Kaj - donation is not a problem imo. I donated and will donate again 
in March. At least a bit, but the question is, if it can speed anything, 
apart from the fact, that Doc will be able to work on the Red fulltime 
eventually. I think that Graham might be in a position of need to 
work on new stuff, and is deciding what tool should he use. In such 
a case, it is a bit preliminary to consider Red imo. But who knows, 
how quickly the RED itself can be written.

It does not sound like much creative work... you can just download 
some existing theme like http://www.bloggerthemes.net/heliumified/demo
and tweek it a little bit... but it requires access to the site.

I was not using preprocessor in my Rebol/Flash dialect and I must 
say, I find the Red/System way useful. It may be true, that additional 
pass may slow the compilation a little bit, but it also provide additional 
features. Also I don't expect that it will be used in some huge projects 
with MB of sources so if it's a few ms slower is not a problem. And 
as Red/System is open, everybody can provide own version:)

OK, thank, that just clears the situation for me a bit ....

Maxim: thanks, that was my idea. Will learn a bit of C too :-)

Ok, found the culprit bit in the exception mask.

Added support for `system/fpu/*` read/write properties. This allow 
controling the FPU at very low-level at runtime.

When compiling in debug mode, `show-fpu-state` function is available 
to print the current FPU properties: `show-fpu-state`

When called on IA-32, it would output::

FPU type: x87
- control word: 0000037A
- rounding    : nearest
- precision   : double extended (80-bit)
- raise exceptions for:
    - precision  : no
    - underflow  : no
    - overflow   : no
    - zero-divide: yes
    - denormal   : no
    - invalid-op : yes


See %red-system/runtime/system.reds for definitions and %debug.reds 
for a usage example.

OK, I will wait a bit

Logic! is stored as an integer (so 32-bit). The specification document 
is not supposed to describe the implementation (that's why I try 
to put implementation-specific details in special notes). Logic! 
uses 1/0 internally to represent true/false values, so if the imported 
function is not conforming to that convention, type casting to logic! 
won't work and a manual test would then be required.

As Doc explained, floating point performance is currently a bit hampered

Making IN and TO as OP! looks ok.
=> looks better than -> but it a bit similar >= and <=

I'm not sure if it reduces readability. Especially if we put string! 
value in a word (I'm not sure either if anyone uses this)

;rebol
>> to t 5
== "5"

;topaz
t: string!
x => t

I like the experiment. I was always a bit thrown off by the order 
of IN

even when  = has higher precedence than executing a function?   come 
on, a little bit of precedence would make a lot of REBOL code simpler 
to write.

a: "eek"
b: "wtf"

if append a  "ouch" =  append b "ouch"  [ a ]  ; ERROR appends boolean 
to a string, so is always "truthy"
== "eekfalse"


this kind of thing makes me go mad !  (there are sooo many other 
examples  ;-)

I guess the common use:

   if 'word in context [...]

makes sense, while the common use:

   var: (...) to string!


is a bit unpleasant. OTOH, maybe this'd give a reason to the various 
to-* functions, so you'd use

    var: to-string ...

still, "to-string" is not a verb... so, i'm not convinced yet. :/

I've significantly reorganized the Topaz source code. A bit more 
manageable this way.

It seems so. I was also a bit surprize when I connected. :)

i'll check back in a bit in case someone else is around. in any case, 
it was a great talk. i guess we can repeat this next month or so 
- my afternoon seems to be the best time. too bad Peter didn't get 
to meet everyone else. :)

He was asking about how to run Topaz outside of a browser. All of 
the suggestions I made above apply to Linux as well, except you have 
to install your own JS interpreter instead of using the one that 
comes preinstalled on Windows. So, it's a bit harder on your "real" 
operating system.

Seems a bit like a cross between a destructuring matcher and regex. 
Useful.

I expect it to be a bit like Lua.

Hand me 100k, and you can get a pre-pre-release! ;p


Or you can wait a bit and see it as a little extra early x-mas present.

Q: Does World compile into bytecodes (a la java) or machine languages?

A: Into bytecodes for the virtual machine. Each VM instruction is 
32 bytes (256 bits) including data and register pointers.

Q: Can you do operators with more or less than 2 arguments?

A: Not yet. I've considered post-fix operators (1 argument), and 
it shouldn't be too hard to implement. To motivate me, I would like 
to figure out some really good examples. With more arguments, I can 
only think of the ternary operator ("THE ternary operator"). I'm 
not sure, World needs that.

Q: Is range! a series! type?

A: No, range! is a component datatype. It has two components just 
like pair!.

Q: What platforms are supported?

A: For now Mac OS X (64 bit), Linux (32 bit) and Windows (Win32). 
The code is very portable. It took me a few hours to port to Linux 
from OS X and just a few days to Windows.

Q: What platforms do you plan to support in the future?

A: It would be cool to see World on all thinkable platforms. I personally 
don't have time to support all. World is not a hobby project, and 
I'm open for business opportunities to support other platforms. The 
host depending code is open source. I mainly think 64-bit.


Q: I'm a little sorry to see the R2-style port model instead of the 
R3 style. Are all ports direct at least?

A: Yes, ports are direct (no buffering). The ports and networking 
are some of the most recent implemented. More work is needed in this 
area. I would like to keep it simple and fast, yet flexible so we're 
all happy.


Q: What in the world is going on with the World Programming Language? 
This looks like something that must have been under wraps for a long 
time. What's getting released?

A: I didn't speak up about this, until I was sure, there were no 
show-stoppers. The open alpha of World/Cortex is being released as 
executables for Mac OS X, Linux and Windows (Win32), as are the platform 
dependent sources and initial documentation. World implement 74 natives 
and more than 40 datatypes. The Cortex extension (cortex.w) implement 
100 or so mezzanine functions and some definitions. The REBOL extension 
(or REBOL dialect in rebol.w) implement close to 50 mezzanine functions 
(not all functionality) and some definitions.

Q: Did you do some speed benchmark? (R3 vs R2 vc World) ?
A: Yes:

(All tests under OS X using R2 v. 2.7.7.2.5 and R3 v. 2.100.111.2.5)

- A mandelbrot routine (heavy calculations using complex! arithmetic) 
is 6-7 times faster in World than code doing the same without complex! 
in R2 and 11-12 times faster than R3. If using same code, it's 2.5 
times faster in World than R2 and 4.2 times faster than R3.
- A simple WHILE loop like:
n: 1000000 while [0 < n: n - 1] []

is 1.8 times faster in World than in R2 and 2.8 times faster than 
in R3.

- I tested networking in two ways. One sending one byte back and 
forth between client and server task 100'000 times using PICK to 
get it, and another sending 1k bytes back and forth 10'000 times 
using COPY/PART to get it from the port. Both were around 3 times 
faster in World than in R2. (I didn't test this in R3.)

- I tested calling "clock" and "tanh" routines in the libc library. 
I called those routines 1'000'000 times in a loop and subtracted 
the time of the same loop without calling. Calling "clock" is 2.4 
times faster in World than in R2. Calling "tanh" (with argument 1.0) 
is 5.9 times faster in World than in R2. (I didn't test this in R3.)


(Some functions are mezzanines in World, which are natives in REBOL, 
so they'll in most cases be slower in World.)

The lexer is 7 bit, so words can only hold 7-bit ascii characters. 
String and other data is 8-bit.