AltME groups: search

0x00FF format would kill pair! syntax, remember that Red/System is 
a dialect of Red and that Red will have pair!.

Hexa format: you're right and I hope to fix that once we rewrite 
Red/System in Red (then we'll have our own lexer instead of been 
limited by LOAD).

So I build my first Red/System DLL, but R2 refuses to load it with: 
** Access Error: Cannot open builds/temp.dll as library.

Works fine here. I'm testing with:

Red/System [ ]

i: 56
foo: func [a [integer!] return: [integer!]][a + 1]

#export [foo i]

RED/System[
	Title: "RED/System inline compilator test"
]

f1: func [a [integer!] return: [integer!]] [a + 1]
#export [f1]

Or just send me a copy of your DLL at [nr-:-red-lang-:-org], I should be 
able to quickly see what's wrong.

Try with following C executable:  http://static.red-lang.org/tmp/loadlib.exe
(or .zip if you have issue downloading the exe).


Put it in the same folder as temp.dll and run it from DOS shell, 
you should have something like: 

C:\Dev\Red\red-system\builds>loadlib
error: 0
hModule: 268435456				;-- library handler
error: 0
&f1: 10001a85				;-- f1 function address
124						;-- f1(123)
error: 0

Guess what. That works:

c:\code\Red\red-system\builds>loadlib.exe temp.dll
error: 0
hModule: 268435456
error: 0
&f1: 10001a85
124
error: 0

So it's probably really a bad day here for coding/testing :)

The only cause I can think of is because the DLL produced by Red/System 
are not (yet) relocatable, they can be conflicting with other loaded 
DLLs (but shouldn't happen with a fresh REBOL session), or are triggering 
something in anti-virus or Windows security sub-systems.

just a note that the REBOL that is linked on the Red github page 
is core, and that doesn't work

https://github.com/dockimbel/Red/zipball/dyn-lib-emitter

You can now provide an entry-point callback, see the commit log: 
https://github.com/dockimbel/Red/commit/8e7c1f84226b8a7ebfde0ec08136e88f566fb4bb

Red/System []


on-load: func [a [integer!] b [integer!] c [integer!] return: [logic!]][
	print-line "on-load executed"
	true
]

f1: func [a [integer!] return: [integer!]][a + 1]

#export [on-load f1]

Doc - the SW you suggest for Git is extremly nice, almost like working 
with tablet, but otherwise not much usefull to me. It does not add 
context menu to the shell, so no right click upon the directory. 
I also did not figured out, how should I add red in there? There 
is no place to paste the https://github.com/dockimbel/Red.gitURL 
... I will install back some other git client ...

Pekr: it's easier than you think: just open https://github.com/dockimbel/Red
and click on the "Clone in Windows" button ;)

Also, because it needs the latest non-released Red/System, I have 
put the binding changes in a separate developing branch:

http://red.esperconsultancy.nl/Red-SQLite

what is now latest temp.reds source? I got:

Compiling tests/temp.reds ...
Script: "Red/System IA-32 code emitter" (none)
*** Compilation Error: missing argument
*** in file: %runtime/win32.reds
*** in function: ***-dll-entry-point
*** at line: 204
*** near: [hinstDLL]

Red/System []

on-load: func [a [integer!]][
	print-line "on-load executed"
]

on-unload: func [a [integer!]][
	print-line "on-unload executed"
]

i: 56
foo: func [a [integer!] return: [integer!]][a + 1]

#export [foo i]

I mean - now we can make wrapper libs, coding almost in REBOL (syntax), 
no need to become dirty with C, and hence get more libraries to work 
with R2, via a wrapper libraries written in Red/System?

can you statically link other C libs...

 you mean link static libraries with Red/System executable, right?

My personal favorite is Blender, I'd very much like to add Red/System 
support to it (and kick out Python later when Red will be there). 
;-)

I have added a sample program for those who want to play with DLL 
generation:


https://github.com/dockimbel/Red/blob/dyn-lib-emitter/red-system/tests/shared-lib.reds

you used -dlib option, does it replace -t one? Not skilled here, 
but - can I generate e.g. ARM executable/library from Windows Red/System? 
Or is target environment needed?

Doc, this page can be updated because of the support of DLL generation. 
http://www.red-lang.org/p/roadmap.html

Blender: yes, API is huge and it's a lot of work, but I'm convinced 
that Red, with appropriate dialects, would do wonders there and it 
could be a great way to make Red known.

can I generate e.g. ARM executable/library from Windows Red/System?


You can cross-compile ARM/ELF code from Windows or MacOSX, just use 
the appropriate target (https://github.com/dockimbel/Red). Currently 
there's only two ARM targets: Linux-ARM and Android. You can cross-compile 
to these targets from any platform Red/System compiler works on.

Is Rebols GUI code (view etc) going to be usable in Red? Or is it 
going to something completely different? A while back I think there 
was talk of an dedicated Red editor (Reditor?). Is this still included 
in the roadmap?

I think that guys had some kind of GUI in mind, or maybe more specifically 
- some GUI targets, as e.g. html5, etc., being native on target devices. 
Myself, I would support and sponsor bit a View plus VID3 transition 
towards the Red, but not sure if someone would pick up. So - in the 
end, some "GUI" might appear ....

I'm not sure it's useful to repeat this, because people seem to wipe 
their memory and start over the discussion, but:

- Red's roadmap includes binding to native GUIs. That means there's 
supposed to appear a binding for every platform Red is ported to. 
The intent is to try to create one dialect that would be able to 
drive all these native bindings. This would be a common denominator 
dialect.

- Some of those GUIs are actually cross-platform, such as GTK and 
Enlightenment. so those can figure as a cross-platform GUI. They 
could offer more functionality than the common denominator dialect 
but still be cross-platform.

Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot 
of work but we would get a simple and fast to use GUI. One of the 
major USPs of Rebol. I don't know any other simple to use interpreter 
that gives you a GUI out of the box. And, in these app days, it's 
no longer so critical to support native look & feel in all aspects.

About the native GUI option (using only what the OS provides), I'm 
pretty confident that the minimum common should be enough to cover 
most needs for business apps, I will do a prototype for the Red IDE. 
Having a free drawing x-platform canvas, for games and non-native 
GUI would also be needed, SDL seems to be the best backend for that 
AFAIK (that gives us also OpenGL for free).

I guess then that some code from R2/R3 applications will be reusable 
in Red (as Red uses Rebol syntax), but not the GUI code.

I have this code for Red/System DLL:

f-1423181: func [a [integer!] return: [integer!]] [a + 1]
f-10584225: func [a [integer!] return: [integer!]] [a - 1]
#export [f-1423181 f-10584225]

and this code in R2 to load it which throws error:

>> lib: load/library %builds/routines.dll

>> foo: make routine!  [a [integer!] return: [integer!]] lib "f-1423181"

>> bar: make routine!  [a [integer!] return: [integer!]] lib "f-10584225"
** Access Error: Cannot open f-10584225

Is it Red/System or R2 problem?

Have you tried loading a Red/System DLL with Wine?

https://github.com/dockimbel/Red/commit/0443c4c4fe9bd7a2a86f9b62b566b80f310539e4

Doc, will you extract all the information string of Red source code 
into a file, so I can translate them into Chinese without modifying 
the source code.

New Twitter message from Doc: "Making good progress on Red language 
layer, got a stable core compiler now and minimal datatypes set"

There are still a lot of details to work on, but the core part is 
there. The bootstrapping does had several complications (like literal 
series handling) that will vanish once we get Red compiler rewritten 
in Red.

I should be able to make a "hello word" script in Red in a few days. 
I still have to make some design decision wrt Unicode internal handling, 
that's really a complex part.

Thanks for the link...if I take Linus' code and add it to Red/System, 
I should be able to output a VM image directly from a Red/System 
program, no? ;-)

For Red, the bootstrap stage is really costly, I'm really impatient 
of getting rid of the REBOL part and only have Red code.

Pekr: thanks for the advice. :-) I haven't followed very closely 
the developpement of R3 nor I have ever wrote R3 code, so I'm not 
aware of all the reasons for some design decisions. That's why I 
ask when I need to. AFAIU, R3 was designed to solve R2 issues. I'm 
building Red from scratch, so I don't have legacy issues (so far) 
to deal with, I have more freedom than Carl with R3 and I intend 
to use it. They are some parts of R2/R3 design that fit well my plan, 
so I use them as inspiration, but there are other parts (especially 
in R3), that I am not fan of. Also, do I need to remind you that 
Red is compiled while R3 is interpreted? These are two different 
models which require different trade-offs.


The difficulties I have to deal with in Red (both design and construction 
process) are inherent part of any non-trivial work to build something 
new and that's my role to solve and overcome them. The best way others 
can help me are by pointing out errors or inconsistencies both in 
the design and implementation.


Wrt Unicode support, I should be able to say in a few days how long 
it will take to support it. I doubt I  need as much as 2-3 months, 
but anyway, nobody but Carl knows what he had put in, and exactly 
how long it took him. ;-)

There is a bit that is worth learning from R3's Unicode transition 
that would help Red.


First, make sure that strings are logically series of codepoints. 
Don't expose the internal structure of strings to code that uses 
them. Different underlying platforms do their Unicode APIs using 
different formats, so on different platforms you might need to implement 
strings differently. You don't want these differences affecting the 
Red code that uses these strings.


Don't have direct equivalence between binary! and string! - require 
conversion between them. No AS-STRING and AS-BINARY functions. Don't 
export the underlying binary data. If you do, the code that uses 
strings would come to depend on a particular underlying format, and 
would then break on platforms where the underlying format is different. 
Also, if you provide access to the underlying binary data to Red 
code, you have to assume that the format of that data can be corrupted 
at any moment, so you'll have to add a lot of verification code, 
and your compiler won't be able to get rid of it.


Work in codepoints, not characters. Unicode characters are complicated 
and can involve multiple codepoints, or not, but until you display 
it none of that matters.


R3 uses fixed-length encodings of strings internally in order to 
speed things up, but that can cause problems when running on underlying 
platforms that use variable-length encodings in their APIs, like 
Linux (UTF-8) and Windows/Java/.NET/OSX? (UTF-16). This makes sense 
for R3 because the underlying code is compiled, but the outer code 
is not, and there's no way to break that barrier. With Red the string 
API could be logical, with the optimizer making the distinction go 
away, so you might be able to get away with using variable-length 
encodings internally if that makes sense to you. Length and index 
would be slower, but there'd be less overhead when calling external 
API functions, so make the tradeoff that works best for you.

However, the part of the concurrency model that was designed so far 
affected the design and implementation of the system model and module 
system. You'd be surprised how much the module system was affected 
by the system, binding and interpretation model of R3; very little 
of its design and implementation was arbitrary. You might be able 
to get the syntax the same for Red's module system, but given the 
different system/binding/execution model there wouldn't be much of 
the implementation in common.

I am for sure no expert regarding unicode, but as red is a compiler 
and open source, why not not add flags that the user has to choose 
which unicode/string support he wants; either flexibility, but of 
cost of speed or no unicode support, then he  has to do the hard 
work by himself

One hypothetical advantage you have with Red is that you can make 
the logical behavior fairly high-level and have the compiler/optimizer 
get rid of that at runtime. REBOL, being interpreted, is effectively 
a lower-level language requiring hand optimization, the kind of hand 
optimization that you'd want to prohibit in Red because it would 
interfere with the machine optimization. This means that, for strings 
at least, it would make sense to have the logical model have a lot 
of the same constraints as that of R3 (because those constraints 
were inherent in the design of Unicode), but make the compiler aware 
of the model so it can translate things to a much lower level. If 
you break the logical model though, you remove the power the compiler 
has to optimize things.

sqlab, it would make sense to have the user choose the underlying 
model if you are doing Red on bare metal and implementing everything 
yourself, or running on a system with no Unicode support at all. 
If you are running a Red program on an existing system with Unicode 
support, the choice of which model is best has already been made 
for you. In those cases choosing the best underlying model would 
best be made by the Red porter, not the end developer.

but that means, that Red has to support all unicode models on all 
the systems, it can be compiled for.

That's not as hard as it sounds. There are only 3 API models in wide 
use: UTF-16, UTF-8, and no Unicode support at all. A given port of 
Red would only have to support one of those on a given platform.

Red user code would only need to support the codepoint-series model; 
Red would translate that into the system's preferred underlying model. 
More encodings would need to be supported for conversion during I/O, 
of course, but not for API or internal use.

So far, my short-list of encodings to support are UTF-8 and UTF-16LE. 
UTF-32 might be needed at some point in the future, but for now, 
I'm not aware of any system that uses it?


The Unicode standard by itself is not the problem (having just one 
encoding would have helped, though). The issue lies in different 
OSes supporting different encodings, so it makes the choice for an 
internal x-platform encoding hard. It's a matter of Red internal 
trade-offs, so I need to study the possible internal resources usage 
for each one and decide which one is the more appropriate. So far, 
I was inclined to support both UTF-8 and UTF-16LE fully, but I'm 
not sure yet that's the best choice. To avoid surprizing users with 
inconsistent string operation performances, I thought to give users 
explicit control over string format, if they need such control (by 
default, Red would handle all automatically internally). For example, 
on Windows::

    s: "hello"		;-- UTF-8 literal string

    print s		;-- string converted to UCS2 for printing through win32 
    API
    write %file s	;-- string converted back to UTF-8

    set-modes s 'encoding 'UTF-16 ;-- user deciding on format
or
    s/encoding: 'UTF-16

    print length? s	;-- Length? then runs in O(1), no surprize.



Supporting ANSI as internal encoding seems useless, being able to 
just export/import it should suffice.

BTW, Brian, IIRC, OS X relies on UTF-8 internally not UTF-16.

If you support different internal string encodings on a given platform, 
be sure to not give logical access to the underlying binary data 
to Red code. The get/set-modes model is good for that kind of thing. 
If the end developer knows that the string will be grabbed from something 
that provides UTF-8 and passed along to something that takes UTF-8, 
they might be better off choosing UTF-8 as an underlying encoding. 
However, that should just be a mode - their interaction with the 
string should follow the codepoint model. If the end developer will 
be working directly with encoded data, they should be working with 
binary! values.

Well, then I'm sure you'll be glad to write string unit tests for 
Red in order to ensure things are done in the proper way. ;-)

Doc, pardon me because I don't know what the intended datatype model 
is for Red. Something like the REBOL datatype/action model could 
be used to implement the different underlying string encodings that 
you want in-memory support for. Each supported encoding would have 
its own set of action handlers, which would all have the same external 
interface. Swapping the encoding would be as simple as swapping the 
handler set. Resolving the difference at compile time could be similar 
to generic type instantiation, or C++ template generation.

Got my first real Red program working: 
    Red [] print 1
outputs:
    1


It doesn't look like much, but it validates the compiler + runtime 
from end to end, and at this point, it's really cool! FYI, the native 
PRINT here triggers a FORM (action) on the passed argument. No REDUCE 
yet (not implemented).

Wow!!! awesome .. from print "hello worl" to print "<html>...</html>" 
to make webapps is not that long way, I was just afraid you would 
never get to RED, Awesome!

+1 for Red :)

Wooow.. Wooow... Did I hear the crying of a baby... I think this 
is the birthday of Red. The past 1.5 years are just pregnancy.

:-) Can't wait to show Red to the Chinese people.

Pekr: right, from now on, you can expect daily progress on Red layer. 
I will push the new code soon, I still need to complete it a bit 
and clean it up.


Jerry: the baby looks nice, we'll just have to keep it away from 
junk food and it will grow up well. ;-)

Pekr: "I wonder what the strategy for Red is going to be in regards 
to GC ..."


Currently Red is using a per-OS thread mark-sweep-compacting GC. 
I intend to make it concurrent (maybe parallel) and incremental when 
(and if) possible. The collector is not yet fully implemented. It 
is also possible to easily make it generational if we need it. When 
we'll have big Red apps, we'll profile them and determine the best 
tuning options for the GC.


There's no silver bullet for memory management & GC, you need to 
adapt it to the language specific needs (and they may vary depending 
on the type of application: client-side, server-side, realtime, ...).

I am giving a speech in SDCC conference tomorrow. http://sdcc.csdn.net/speaker.html
My topic is Dart. I hope it will be Red next year when Red is mature 
enough. :-)

Well who is issuing them, with what authority and what fundamental 
value? I cannot see this, whereas the state has the authority of 
the land where we live and foods are produced to base money value. 
(Second life 'money' was a hype.)  But that is a discussion for outside 
this Red message group.

I do not bother to obtain bitcoins. Vague draining of computational 
powers of my tiny computer to compute some hashes(????) to unknown 
benefit to get by chance(???) ome 50 bitcoins of a limited(who controles 
this, I have serious doubts here too) supply of them. I am a real 
bitcoin sceptic, sorry. But again I think the Red group is not the 
place to discuss this matter, not that I have much more to say about 
this.

You made your point, but I have to counterbalance them for potential 
sponsors to Red. Nobody controls the Bitcoin supply, the limit is 
built into the system. You don't have to compute them yourself, you 
can exchange your other currencies for them

But old valuations are irrelevant for current valuation. If you can 
pay me Bitcoins to do Red work, is that worthless to you?

Please move non-Red payment chat to another group.

Gregg, I'm not speaking hypothetically, I do intend to solicit Bitcoin 
donations for my Red contributions in the future

Doc, a bit late congratulations for your first Red program! (I was 
offline for a week)

I will write about Red Unicode support in a blog article this week.

BTW, I might also post soon a description of a redbin format (similar 
concept as Carl's rebin). The overhead and footprint of the Red boot 
script (loading all the words and their values) is not negligeable, 
so I may switch to redbin option sooner than later.

I will push the current Red compiler & runtime code base tomorrow, 
still some more code cleaning to do. It will contain the Red boot 
script with all base definitions (currently actions, ops, a few natives 
and a few char! values) and a compiler front-end (similar to %rsc.r).


Don't expect too much, only MAKE has been fully implemented and FORM 
on integer! values only. PRINT is the only native currently.


This is not the first Red alpha, but it's a working base we can implement 
the alpha on (basically implementing actions and natives).

Can Red/System code be included yet, so the new platform can be sort 
of tested as a shell for Red/System programs?

Kaj: not yet, there are several ways to integrate Red/System in a 
Red program:


- inlined in Red code: it will be done using a #system compiler directive 
followed by a Red/System block of code. You should be able to use 
it pretty much anywhere. Trivial to implement.


- executed at runtime: using a DO/SYSTEM, but we need the Red/System 
compiler written in Red to be implemented first for that.


- through Red/System exposed functions to Red: this needs a native! 
definition in Red. It needs some intermediary code for supporting 
automatic marshalling/unmarshalling arguments passed between Red 
and Red/System. But it could be added quickly. Red's routine! type 
will use the same approach for mapping imports.

- by directly coding the native! in Red using something like:

    foo: make native! [[<spec>] [<Red/System body>]]

Lot of fun in perspective! ;-)

You'll got it by tomorrow. 


And BTW, the generated Red binary is in the working directory by 
default. ;-)

Here we go: https://github.com/dockimbel/Red/tree/v0.3.0/red

@BrianH: as you can see from the source code, R3 actions are a strong 
inspiration. ;-)


I also plan to add some actions from Topaz, but Topaz is still higher 
level than Red currently.

If you want to see how the boot.red script is compiled, use:

    do/args %red.r "-v 2 %red/tests/hello.red"

not trying to panick, maybe downloaded bad branch, but:

>> do/args %rsc.r %tests/hello.reds
Script: "Red/System compiler wrapper" (none)
** Syntax Error: Invalid word -- <<<<<<<
** Near: (line 2028) <<<<<<< HEAD

So, I have compiled my first RED program succesfully!

Two notes:


- when in root directory, where %red.r resides, is there a need to 
specify it in compilation process? do/args %red.r - or do we expect 
more compilers here?


- executable is spilled out into the root too. I would probably use 
the way compatible to red/system, and create /builds subdir?


Or is all above intentional to allow to compile/link from working 
dirs?

*Important*: Red will be distributed as a binary to end users and 
the effect of:

    red script.red
    

will be to compile and run it from memory directly. So the -o option 
will become mandatory in the future for generating an executable 
without running it. During the bootstrapping stage, it is complex 
to support that feature, but it will be implementd as soon as possible.

Could you please elaborate? Is red executable going to be kind of 
launcher for our scripts? Hence it compiles them before running it? 
Most probably not a solution for CGI, as the compilation stage will 
happen each time?

For CGI, you should obviously pre-compile them if you want performances. 
The future JIT-compiler should be able to handle such cases fine 
though.


But yes, the goal is to be able to run Red scripts directly in the 
same way REBOL does. The fact that Red compiles them should be transparent 
to users. The -o option will be roughly equivalent to what encap 
provides (except that scripts will be compiled to native code).

The main drawback right now to support direct Red script execution 
is REBOL inability to execute native code from memory. The workaround 
would be to provide a DLL to pass the memory pointer and call the 
Red code, but as I aim at a single Red binary, this option wouldn't 
be very satisfying.

I would prefer Red to compile either to the directory, where the 
source is by default or at least not to the system/options/home path, 
but to the path I get with pwd

Kaj: what do you think of that? (for Red/System)

    #define MAX(a b) [either a > b [a][b]]

    print MAX(78 12)

outputs: 78

Arnold: it's for Red/System, not Red.

hello.red segfaults on my ubuntu 12.04 system, any idea?

No, I haven't yet tested the Red codebase on Linux, but I will in 
a few minutes.

Doc, did you know you have a possible theme song? It goes back to 
when I was a young lad but it still rocks:  "Red" by Sammy Hagar. 
http://www.youtube.com/watch?v=sfdy7tC-Us0&feature=fvwrel

Nice Red rock song. :-)

I did this 
$ git clone https://github.com/dockimbel/Red.git

so how come red.r doesn't come down?

Math operations now supported in Red (integer! values only for now). 
For example:

    a: 123
    a: a + 2
    print a * 6 - a

will correctly output 625.

We'll inform Peter Busser that Red supports round brackets now ;-)

I've updated the recipe in the Syllable build system to add Red:

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/apps/utils/Builder/packages/Red--current/

I've found the cause of the linux regression, it was this commit:


https://github.com/dockimbel/Red/commit/fabad833b6bb8b82f9efdf4933c18bfd997a863f

Fixing it...

Doc - looks like you are having fun finally coming with Red :-), 
though it is clear it is a hard work :-)