AltME groups: search

Mandelbrot
Syllable Server, AMD Athlon XP 1800+ (256 KB L2 cache)
						CPU Time	Relative
C (GCC -O2)				.025		1
C (GCC 4.4.3 i686)		.05			2
Red/System				.11 (0.3)	4
World (complex math)	4 (7)		150
World					6 (9)		250
Boron (i486)			7.5 (10)	300
ORCA (i486)				9 (12)		350
REBOL 3 2.100.111.4.4	9 (12)		350
REBOL 2 2.7.7			11 (13)		450
Ruby 1.8.7.248 (i486)	12 (15)		500

It's a bit strange, because the inner FP code should be identical 
between C and Red/System now. But anyway, it's more than enough for 
now.

I have a case where the library wants to use a function that should 
be defined in the program. This doesn't work, apparently because 
Red/System doesn't export the function. The library can't resolve 
the symbol

In any case, a block works in Red/System, so it doesn't get compiled

I don't believe Comment is a function in Red/System as it is in REBOL. 
I think it is more like a compiler directive.

To be more precise, there's a string stage and a block stage in the 
preprocessor. All the compiler directive are processed at the block 
stage. The string stage is just a front-end to handle R2-incompatible 
syntax, like the Red/System hex notation, and count source lines.

Behold, an OpenGL triangle rendered by a Red/System program:
http://earl.strain.at/share/reds-opengl-triangle-20120227.png

Doc, do I understand it correctly, that lists/arrays are now supported 
via 'typed funcitonality, hence structs? How much would it complicate 
red/system to have a native block implementation? :-)

I'm sure Doc will answer this question as: "Red/System is for low 
level system programming, no need to implement blocks unless we need 
it while writting Red".  :)
I think blocks etc. is for Red not for Red/System.

When I will write app in Red, it will compile to Red/System in the 
first pass, and then to the native code from R/S? So that it means, 
that you write Red in R/S? Hmm, if Carl would release R3 sources, 
it would not help you much, as you plan to write Red in R/S, not 
C?

Kaj is reporting a success of compiling this software.  He hasn't 
done the binding to Red/system yet?

As we do the compilation and code generation in one pass in current 
Red/System, we can't look ahead to determine the boundaries of each 
expression in a variadic block of arguments in advance, to be able 
to extract their datatype.

Actually, the single pass nature of Red/System strengthened my assumption 
that the computation would be in natural order

The first Red will probably have all the capabilities of Red/System, 
so I think it will be able to do quite a lot

dunno, maybe via type casting? as integer! ... but not sure if it 
works for floats, or only pointers ...

http://static.red-lang.org/red-system-specs.html#section-4.9

Support for converting between integer! and float!/float32! has not 
been implemented yet. The only way to achieve it right now is to 
rely on an external lib (libc?) or implement your own conversion 
routine in Red/System.

Once the Red runtime is more fleshed out I'll see what is still useful 
to add in Red/System

I think he was tallking about  a similar  flexibility as REBOL in 
passing arguments to functions; the programmer can enforce strict 
typing or not.


It will be interesting to see if Red allows the programmer to define 
new types. Red/System does with alias!s for struct!s and enforces 
strict typing. But it doesn't allow the programmer to define other 
types.

There is no (public) Red yet, only Red/System in which Red will be 
written https://github.com/dockimbel/Red

REBOL/View also depends on an external graphics library, namely AGG. 
The difference is currently in the level of integration. Once the 
Red/System compiler linker becomes more capable, for example when 
it can produce libraries or object files, it may be possible to integrate 
graphics libraries as tightly with Red as AGG is integrated with 
REBOL

james - there is no Red yet, just Red/System. And yes, you can kind-of 
create Android apps. But - those are bare-bones linux ARM apps, which 
can run on an Android phone. I tried that on my HTC Sensation. Right 
now, there is no app-store support, nor the ability to link to Android 
API, which would require the JAVA bridge. You can find some info 
here - http://www.red-lang.org/2011/12/arm-support-released.html

Pekr: I am finishing the generation of the intermediary representation 
for the output of Red compiler. I had to change it several times 
as it is uneasy to design properly without all the other pieces ready 
(another chicken and egg problem).


For example, to properly store literals (especially series literals), 
I need some kind of Redbin format, but designing it and implementing 
it now seems like a bit premature (as most types are not defined 
yet). So, I went for a dynamic construction model at run-time for 
now. I'll move literals to Redbin when it will be available.


For Redbin, I want it to be powerful enough to be able to serialize 
the whole state of a running Red program, but I don't know yet to 
what extent it is doable when running native code directly (needs 
some significant research work).


Also, I need to make a few changes to Red/System compiler to better 
integrate witht Red's one, I should finish those changes and release 
them this weekend.

Any updates on a date for Red ( not system ) ?

Arnold - I think, that right now, we have to wait. There's only a 
Red/System low level (VM) language RED will compile to. You can do 
some library binding using Red/System. What you most probably will 
want to program in, though, is Red itself. Doc is working on it ...

Printing is included in Red/System. Reading environment variables 
is in my C library binding. The only problem is standard input. I 
think it can be bound on Windows to platform specific functions, 
but on Unix platforms it requires importing the standard file descriptor 
data, which Red/System can't do yet. So that would be the only limitation 
to wait for here, but it can already be done on Windows

Another option would be writing an Apache module in Red/System. I 
think that would require producing a plug-in as a shared library. 
The Red/System linker can't do that yet, so that would be another 
one to wait for

If you want RSP templating with that, you'd have to port one of the 
REBOL versions to Red. If you want it to be close to the REBOL version, 
you'd have to wait for Red for that, but you could also write a simpler 
version in Red/System

@Graham and others: I should have wrote you earlier about what I 
am currently doing instead of leaving you with no info, sorry for 
that, I was very busy these last weeks, with both real life events 
(good ones ;-)) and a new customer from which I accepted a short-term 
job to help pay the bills. The contributions I've received so far 
*are* helpful and I can't thank enough all the people that made donations! 
But their are not enough to cover all my expenses here, if I could 
get 3-4 times more from donations, that would be perfect, but as 
long as the userbase won't be larger I think that it won't be  possible.


So I've accepted a short contract (til end of june) to build a trading 
bot generator with a visual editor (GUI in View) that emits MQ4 language 
source code for feeding the Metatrader4 application. Of course, I'm 
building it in REBOL (Red not ready yet for that). The plan was to 
work part-time on it and part-time on Red, but these last two weeks 
I had to work almost only on that project. I still have a few days 
of intensive work on it, then I'll switch to part-time.


I have quite a lot of code to commit (the Red compiler), but I'll 
wait to finish first the internal modifications in Red/System (to 
ease the integration with Red) before publishing it.

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

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:

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.

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. ;-)

you can look into Other section - that can be good reminder into 
ports, schemes, devices and low level event system - http://rebol.net/wiki/Table_Of_Contents

http://rebol.net/wiki/Event_System

@Doc: Seem there is a new update for my system. I will first download 
and install it and I'll retry later the Red/system app in Native 
mode.

Which documentation? There's currently no documentation about Red, 
only about Red/System.

Red and Red/System are two different things that you should not confuse.

Have a look at these ones:
- http://static.red-lang.org/red-system-specs.html#section-1

- slides 7 to 13 in my SFD presentation: http://www.red-lang.org/2011/09/red-at-software-freedom-day-2011.html

a "hello world!" written in and compiled by red/system running on 
a raspberry pi:

[pi-:-raspberrypi]:~$ ./hello-reds.arm 
hello from red/system!

([pi-:-raspberrypi]:~$ uname -a

Linux raspberrypi 3.1.9+ #90 Wed Apr 18 18:23:05 BST 2012 armv6l 
GNU/Linux)

I haven't found away to pre-allocate memory for a c-string! in Red/System 
except by initialising a string.

Red/System has no memory manager. You need to use the allocate/free 
wrappers provided by the runtime (see %Red/red-system/runtime/libc.reds). 


Once Red's memory manager will be stable, we could easily add some 
simple functions to make it available from Red/System too, so you'll 
be able to either manually manage memory or rely on Red's memory 
manager (including being able to call the GC).

Hi Doc,

   I have found the time to view the documentation of RED/System on 
   your site.

   Red/system brings the expressiveness of REBOL in a low level language.

   I see there is no object orientation capabilities into this language. 
   Is it planned ? Otherwise, as a programmer, why you dont find it 
   usefull ?

I think it is planned for Red as Red/System is a low level system 
language.

I believe that it will be possible to access all Red datatypes from 
Red/System via the Red Memory Manager (which is being built in Red/System). 
I doubt that Red/System will have any built-in functions to traverse 
and manipulate series though.

I don't think it is useful for Red/System, look at Kaj's bindings, 
its all system structures, API calls, enumerations and a few functions.

When we have Red we (or someone) can write wrappers in Red, so "normal" 
users will not need to use Red/System.

And there is no use series etc. kind of high level features in bindings/API/kernel 
calls.

No object! nor series! support planned for Red/System, remember that's 
supposed to be just a low-level dialect callable from Red meant for 
system programming. However, as Peter mentioned, it will be possible 
to access Red values and actions (mainly series and I/O actions) 
from Red/System when deeper interfacing with Red is needed.


OOP is just not necessary to Red/System, only code and data encapsulation 
is IMO worth adding in the form of a module system. I'm not a big 
fan of intensive use of OOP, as done in C++ or Java (or I'm probably 
just repelled by class-based OOP). I find prototype-based OOP (REBOL, 
Javascript,...) much more appealing and will support it in Red.

I thought about implementing some basic series functions in Red/System, 
but they would be primitive and hardly used once the Red memory manager 
is available. There could still be a place for them in low level 
coding, but right now it doesn't justify the effort for me

f: func [
	val	[integer!]
	return:	[struct! [value [integer!]]]
	/local s
][
	s: declare struct! [value [integer!]]
	s/value: val
	s
]

s1: f 1
print ["s1/value:" s1/value lf]
s2: f 10
print ["s1/value:" s1/value lf]

; --- outputs:

C:\code\Red\red-system\builds>test
s1/value:1
s1/value:10


After setting S2 value, S1 is changed. Why? Is it a bug?

If you don't get the memory from the operating system

yes, I'm looking for Red/System solution.

I'm still discovering how Red/System works :)

But in short - Red is going to be compiled language, and it will 
probably get some kind of JIT too, to allow interactive stuff like 
console. Red language compiles down to Red/System, which is kind 
of VM for it. In fact, it is REBOL-like low level wrapper to C, allowing 
some bindings. Red/System apps recently run even on ARM, eg I am 
able to run it on my HTC Sensation. But that's raw ARM Linux, no 
Android API linking yet ....

Red/System is not VM or wrapper to C, it has compiler that creates 
executable files.

Rebolek: "Thanks, I hope so too :) I will test it and see." - it 
would be really helpful if you could use qutick-test.reds to wriite 
your tests. We could then add them to the Red/System test suite which 
would allow Nenad to discover regressions before he relaeses fixes.

Hi Doc and everybody, since I'm studying the opportunity to create 
myself - in a loooong future - a test  version of Red/system running 
over the JVM - I asked myself, after reading some doc titled "Create 
ypour own programming language" by Marc-Andre Cournoyer, if in any 
case Doc had thought about this way of doing things for his future 
implementation of Red (not Red/system), as described by this excerpt 
from the doc itself under the section :  PROTOTYPE-BASED

Except for Javascript, no Prototype-based languages have reached 
widespread

popularity yet. This model is the easiest one to implement and also 
the most
flexible because everything is a clone of an object.

Ian Piumarta describes how to design an Open, Extensible Object Model 
that
allows the language’s users to modify its behavior at runtime.

Look at the appendix at the end of this book for a sample prototype-based

language: Appendix: Mio, a minimalist homoiconic language. For a 
follow-up about these concerns here is the URL related to the Extensible 
Object Model upon which the author has based his own Mio language, 
itself inspired by the IO language  -  http://piumarta.com/software/cola/objmodel2.pdf

It's unfortunately integer! only, I need float! version, so maybe 
for next release I find something :) i'm most happy with float-to-int 
and int-to-float, I was really missing it from Red/System.

Doc, thank you for your swift response to my bug reports. There's 
clearly visible daily progress in Red/System and it's getting more 
and more usable every day. Red/System clearly shows advantages of 
open sourced language compared to closed source ones. I'm really 
happy with it and I look forward to next versions of Red/System.

With all the talk of Red ... are you aready working on it? I thought 
you are working on Red/System still?

I am too dumb to use Red/System .. so I'm waiting for Red too :P

Janko, that's just prejudice. If I can work with Red/System, anybody 
can!

Looks interesting. I can see how you're finding those expression 
bugs. :-) This is a really nice example of how Red/System can replace 
C

Red: I'm still working on both the compiler and the minimal runtime 
required to run simple Red programs. I have only the very basic datatypes 
working for now, no objects (so no ports) yet. I not yet at the point 
where I can give an accurate ETA for the first alpha, but I hope 
to be able to provide that ETA in a week.


Red string! datatype will support Unicode (UTF-8 and UTF-16 encoding 
internally). I haven't implemented Unicode yet, so if some of you 
are willing to provide efficient code for supporting Unicode, that 
would greatly speedup Red progress. 

The following functions would be needed (coded in Red/System):

- UTF-8 <=> UTF-16 LE conversion routines

- (by order of importance) length?, compare (two strings), compare-case, 
pick, poke, at, find, find-case
- optinally: uppercase, lowercase, sort


All the above functions should be coded both for UTF-8 and UTF-16 
LE.

Porting existing C code to Red/System is fine as long as:
- the C source code license allows it.
- the used C algorithms are fast and light on memory usage.

Please take some time to give good thought about this kind of things 
and specifying in more detail what is needed, so other people get 
a chance to help out with doing a little programming for Red (/system). 
While not everybody is a topgun like yourself, there is a lot of 
legwork that could be taken out of your hands.

It's really nice, and puts Red/System definitively above C

I was hoping the demands for Red would push more REBOL features into 
Red/System :-)

sorry, I meant Red/System, in Red, contexts (wherever functions, 
objects or modules) are first class values.

In Syllable, I repackage Red and Cheyenne in a package with a Unix-like 
structure, such as a separate subdirectory for the executable, but 
it gets cluttered because they find all their other files related 
to that executable. Actually, that's the way we want it to work for 
Syllable Desktop GUI applications, but for a console program that 
needs to be in the system path, you need the Unix structure with 
separate search paths for separate subdirectories

`system/words` virtual path support was added in today's commits, 
to be able to get/set a global variable or call a function from within 
namespaces with conflicting local names.

Example:

    e: 123
    a: context [
        e: -1
        print-line e
        print-line system/words/e
        system/words/e: 0
    ]
    print-line e

will output:
    -1
    123
    0

is there aliasing possible? e.g.

sys*: :system/words
sys*/print

No, you can't do that. You can use macros for full paths if it's 
really required. Anyway, the use of system/words should be rare.

I just need to upgrade Red/System specifications, improve the Red/System 
runtime with this new feature, and I'll be ready to merge this branch 
into master. I might also make a new global release (v0.2.6).

If some external library requires 64bit integer, but Red/System supports 
only 32 bit integers, how can I supply that number? Can I "cover" 
it with a struct?

Actually, I wrote a small lib to perform the 64-bit arithmetic ... 
but I only needed subtract and divide.

it's at:

https://github.com/PeterWAWood/Red-System-Libs/tree/master/Int64

I'm actually behind on using the newer Red/System features...

For example, I have a check type = system/alias/gtk-window!

Should that become system/alias/gtk/window! in a GTK CONTEXT?

So it should be: system/alias/gtk-window! unless there are bugs (I 
think we haven't tested mixing aliases with namespaces).

But system/alias/window! will lead to clashes with window!'s in different 
contexts

Aliases in Red/System are names for C-like structs. It's quite a 
different concept as anything that would be called an alias in REBOL

Anthony, the current runtime is written in Red/System, to be precise

http://www.osnews.com/story/25716/Syllable_gets_Red_System_bindings_with_C_cURL_SDL_SQLite

REBOL is also in there, because the Red and Red/System compilers 
are currently written in it

Ah, but that is exactly what the API is for. Programs are notified 
through the API that the system is about to shut down, whatever, 
and then those programs can save their running state and reload automatically 
after the restart and pick up where they left off. It happens for 
power failures too, if you have a UPS or laptop battery.

(Continue from !Cheyenne)

Graham: it would be nice to write OpenDBX binding for Red/System 
too.

Here is the code I use to load your ODBC extension, which patches 
it after load:

; Load and patch the ODBC extension
odbc: import/no-user %odbc.dll
unless 'case = pick body-of :system/schemes/odbc/actor/open 10 [

system/schemes/odbc/actor/open: func [port [port!] /local result] 
bind [
	port/state: context [access: 'write commit: 'auto] 

 result: open-connection port/locals: make database-prototype [] case 
 [
		string? select port/spec 'host [ajoin ["dsn=" port/spec/host]]
		string? select port/spec 'target [port/spec/target]
		'else [cause-error 'access 'invalid-spec port/spec]
	]

 all [block? result lit-word? first result apply :cause-error result] 
	port
] odbc
]

Did you port WITH from Red/System? ;-)

Closing down the system is not possible with media player active. 
Once mediaplayer is quit the system ends with it.

Plugging in the mouse (non-usb port) seems conflicting with mounting 
my usb mp3 player. Unplugging the mouse made my mp3 player disks 
visible again.Well it is not consequent in this. After another try 
it took me some time to mount it because it didn't show up. After 
mounting I plugged in the mouse again. For else I cannot copy files. 
It worked. System hangs up on me or doesn't respond copying the 20th 
mp3. Enough testing for today.

Hung applications can prevent the system from shutting down:

It seems to me that a major obstacle to operating system adoption 
is the difficulty of partitioning a hard drive, and potentially losing 
all the data from the other operating system partition. Raspberry 
pi is a $35 ARM system with an SD card designed to teach people how 
to program. It's an embedded system, so syllable would shine because 
it is light weight. One of these systems is powerful enough to output 
1080p video and extremely small.

So Syllable is going to use Qt for some apps or the system in overall?

You seem to be skilled in porting various toolkits. No intention 
to port View engine to Red/System? :-)

But other engines you name are far from what View engine in fact 
is - system of gobs, etc. Widgets are VID. I still prefer not so 
much perfect VID, instead of overbloated stuff ...

The shared libraries on my system currently total 5 MB, without dependencies 
from outside Enlightenment

Yes, all true. I've long been working on a system with roughly that 
model, but we only use it internally so far

But then how do you catch the input if it not already part of your 
own system ?

It's a web system currently, but it's prepared to support other platforms. 
My Try REBOL site is made with it

I'm pretty sure this is a grevious abuse of R2's port system, but 
it does mean there is no new global words.

To start some new discussions, 1) I like Squeak/Pharo Smalltalk's 
AIDA/Seaside systems. Hope to to practice them in realworld soon 
(creating a community site)... 2) I'm coding a new Oberon system 
 which will be able to do one of the following at once: a) interpret 
oberon b) translate oberon to x86 machine code c) translate oberon 
to javascript. This is a very long-term project, but I get excellent 
support from the oberoncore.ru community, and am actually making 
good progress. Current oberon project status is c++ sourcecode-based 
ssystem interprets oberon, interpreter has many temporary stubs.