AltME groups: search

# rebol -qw red.r %red/tests/hello.red

-= Red Compiler =- 
Compiling red/tests/hello.red ...

...compilation time: 	 30 ms

Compiling to native code... 

...compilation time: 	 1282 ms
...linking time: 	 	 25 ms
...output file size: 	 	30912 bytes

# ./hello
42

Pekr: I had fun too working on low-level with Red/System, but it 
takes a lot of energy while working at Red level is a lot more relaxing. 
;-)


But this is short holidays, once Red gets mature enough (I bet on 
a couple of months), we'll start working on Red/System v2 (rewritten 
in Red, with a new compiler & linker architecture). This will give 
up the opportunity to reboot Red/System, fix a few design decisions 
if required, extend it, and get a clean and lean new code base in 
Red. I plan to write some architectural specs about the target compiler 
before starting, so all contributors will be able provide me with 
feedback before we implement it. Trust me, you _will_ like the final 
compiler! ;-)

Ashley: that point is closer than you might think. Even at bootstrapping 
stage, once Red get enough Core features, you and any other reboler 
will be able to add new libraries or port existing one from REBOL 
(should be trivial in most cases). That's not limited to mezz code 
though, you'll be able to add bindings to pretty much anything, protocols, 
provide Red plugins for 3rd-party apps (browsers e.g.), even make 
a View clone if you want (that one could even be a community project). 
:-)

New macros system and Red/System fixes retrofitted from v0.3.0 to 
master branch.

I guess master if you want Red/Sytsem, v0.3.0 if you want Red

We'll probably merge all in master by the end of the month and celebrate 
the first Red alpha release.

Red doesn't work yet for me on Linux. See tracker

This is the merge that seems to have caused the problem:

Schulz:Red peter$ git checkout master
Switched to branch 'master'
Schulz:Red peter$ git merge upstream/master
Updating 525097b..ffb1f68
Fast-forward

 red-system/compiler.r                           |   77 ++++++++++++++---------
 red-system/linker.r                             |    2 +-

 red-system/loader.r                             |   67 +++++++++++++++-----

 red-system/targets/IA-32.r                      |   33 ++++++++--
 red-system/targets/target-class.r               |   13 ++--
 red-system/tests/source/compiler/pointer-test.r |    4 +-
 6 files changed, 136 insertions(+), 60 deletions(-)

For those who are excited about what Doc is doing, please remember 
to continue donating.  He's devoting all his time and work to Red 
at this point.

Ok, got Red working fine on OS X too.

Red should have a more "modern" set of schemes than the one provided 
by R2, though.

So, yes, there are a few of us waiting to contribute when Red reaches 
that point for us

I will provide the basic ones for Red: TCP, UDP, DNS, HTTP(S), SSL, 
SSH/SFTP, SMTP. Also, I would like to have a few more for remote 
or local storage builtin: Dropbox, MySQL, Postgresql. 


You are welcome to contribute other ones to that list (IMAP, SMTP, 
MongoDB, CouchDB would be nice additions).

I will probably host a server that will provide packaged and selected 
libraries for Red (with builtin support in Red for getting them). 
For sharing code, my plan was to built some support for that right 
into the IDE.

Doc - what are your plan re Uniserve? Will basic engine be present 
directly in Red, or a separate product?

I've started some convesations here about helping fund Red, but no 
commitments yet.

Wasn't it NickA? I think that so far, donations come from the community 
members, in an insufficient amount. Are you talking about more solid 
funding? So far only NickA expressed his will to eventaully fund 
Red ...

Uniserve: we'll see how it fits in the Red I/O model (not written 
in stone yet), we'll probably use a newer approach with sequential 
code instead of having to write callbacks.

I'll tell Bas to schedule a Red presentation at Software Freedom 
Day coming week

I'm very, very happy to announce that Red now works on Syllable Desktop 
0.6.7

There's not much in Red yet, so to have something to show I'm going 
to test my Red/System bindings from within Red

For the tech crowd I'll show some of the inner workings of Red

Finally got around to cloning Red from github and doing the test 
system and Red compiles. I hadn't done so since changing machines, 
so it's great to have it all work the first time out. Great stuff 
Doc.

Not yet Henrik, I plan to make one of the planned/implemented one 
starting from the official first alpha of Red (at v0.3.0 release). 
Actually, I plan to do this in 2-3 weeks.

It's very problematic to use existing Red/System code in the Red 
#system directive, because it mustn't conflict with any of the internal 
implementation of Red

Even if I wring the bindings around it now, it can break any moment 
when Red's implementation changes

The website needs an introduction/instruction section and a downloadlink 
to a zipped version of Red souces, so people can skip the github 
stuff.

So - just link red-lang.org to the zip archive? Doesn't it have a 
static/non-changing link?

As I see it, it is available under https://github.com/dockimbel/Red/zipball/master

Kaj: I might make macros context-sensitive, but I don't see what 
more I can do. The point of #system is to write Red/System code within 
the 'red context, so naming should be done carefully to avoid conflicts. 
But with a few context wrappers, you should be able to solve that, 
no?

does it work like a preprocessor or what? Any example, of how is 
Red/System code inlined in the Red?

why not do it like a Rebcode? make red-system ...., or make native! 
.... etc.?

# char should not be used for anything else but - preprocessor. And 
if it works like a preprocessor, we should stop talking about the 
ability to use inlined Red/System code anywhere in the Red source 
code ... :-)

Arnold: Red source zip links are on github since the beginning. Maybe 
you can write such presentation/instruction section, submit it in 
a gist, put the link here and on the Red ML, discuss with others, 
and when it's ready send it to me so I can review and publish it. 
I need to advance on Red construction rapidly now, so the website 
is currently lower priority to me.

Doc - maybe what does Arnold mean is just simple addition of Downloads 
section, and providing just few links for particular branches - https://github.com/dockimbel/Red/zipball/master
... but - we can live without it if other things are more important. 
But - there might be some truth to the fact, that not everybody is 
skilled to fight with Github "complexity". It was an obstacle for 
me too, although I found my way thru ... but only because of your 
help :-)

Then create some howto's and in time change from REBOL driven site 
to Red driven site.

Doc - just concentrate upon Red. I thought that links to gihub archives 
for particular branches are static ...

just one link - to the github red site ... then user should orientiate 
himself there ... nowadays visiting Red-lang.org does not suggest 
clearly, where one could get Red to give it a try ....

https://github.com/dockimbel/Red/downloads

https://github.com/dockimbel/Red/tags

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

Kaj: I might make macros context-sensitive, but I don't see what 
more I can do. The point of #system is to write Red/System code within 
the 'red context, so naming should be done carefully to avoid conflicts. 
But with a few context wrappers, you should be able to solve that, 
no?

As I said, wrapping a binding in a context isn't enough, in the first 
place because #define's remain global. Making them context sensitive 
would help a lot, because they're currently the most primitive construct 
in Red/System

The other big part of the problem is that we have two languages now, 
Red built on top of Red/System, while they're so similar that they 
will often use the same names for slightly different concepts. With 
the bindings, one builds a world on top of Red/System, but the biggest 
parts of them should also be usable in the world one builds on Red, 
without making them look butchered when programming in Red/System

It's fair enough that #system code runs within the RED context, to 
be able to extend it and write the application code - although as 
I said, it's hard to know which names from Red's internal implementation 
will conflict. However, I need another place to import the core part 
of the bindings, outside the RED context so they won't conflict

Ok, I've added (not pushed yet) a new directive for including Red/System 
libs outside of 'red context. Example:

	#system-include [%tests/hello.reds]


will load and compile the hello.reds script. Notice that relative 
include paths are resolved from Red/System root folder (%Red/red-system/).

Does that cover your need Kaj?

I also need #include's to work the same as in Red/System: relative 
to the source the path is in

The only #include right now are Red/System includes.

#system-include just inserts them outside of 'red context.

They are just inserted at beginning of intermediary script passed 
to Red/System.

It would be easer if #system-include would be like #system so that 
you could wrap an extra context around Red/Sytsem code, without introducing 
an extra wrapper file. Would that be hard?

No, trivial, I would then just remove #system-include and add an 
option to #system to have the code loaded outside of 'red context...but 
semantically, it will be a bit inconsistent with barebone #system, 
as it means "inline the Red/System code here"...Maybe I should just 
rename #system-include to solve that.

I've changed it to #system-global, work exactly as #system but loads 
outside and before 'red context, should I push it?

For the defines, I think the best option (and cheapest) would be 
that I prefix the one I use internally for Red.

It's worse than that. The first error I get is on one of my #define's 
that's a struct! later in Red

I can maybe change some on Red side, if there are not too many conflicts.

It's NONE, but I really wouldn't want you to change that in Red. 
And it's just the tip of the iceberg

Added new actions: AT, SKIP, BACK, NEXT, LENGTH-OF.

You can now do a bit more than just PRINT 1. ;-) See:

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

	b: [4 7 9 [11] test /ref 'red]

	print pick b 2
	print pick pick b 4 1
	print pick next b 1
	print pick next next b 1
	print pick back next b 1

	print length-of b
	print length-of next next b
	print length-of pick b 4
	print pick at b 2 1
	print pick skip b 2 1

	print pick at next b -1 1
	print pick skip next b -1 1

Reading all the discussion about R/S source inclusion in the Red 
- it seems pretty complicated and confusing at best. Apart from the 
three options discussed on friday, it is the "least powerfull" one. 
It is not any kind of inlining R/S code into Red from the runtime 
point of view, hence I wonder, why it is not simply called an #include? 
I know you might want to two cases now:

#include %some.red
#include %some.reds


But that's distinguishable, and unifies the naming, as well as it 
does what the name suggests - it is just preprocessor kind of directive 
for including either the red, or r/s source into Red ....

About your proposition:


- #include is for including files, not for inlining literal code, 
which is precisely the purpose of #system* directives.


- you can't use #include to include directly two different languages, 
that would be confusing for everyone and it's a semantic mismatch 
(making users think Red/System code can be directly used in Red with 
no clear separation between the two).


- #include is a preprocessor directive, #system is a compiler directive 
(processed during compilation)


- #system* directive are not complicated nor confusing, they are 
pretty simple and should look intuitive to C users (having the habit 
to inline ASM code into C). Those users are the target users for 
Red/System (remember that most Red users will never program in Red/System).

Well, not coming from C kind of languages, I actually used code inclusion 
rarely. The preprocessing stuff in any language looks arcane to me, 
but that's just my feeling, as it is REALLY a long time ago, since 
I used code -> compile -> link technique (CA-Clipper - 1998 :-)


So I better wait for more "clean" way - the other method you described 
- simply what I am expecting is kind of Rebcode - writing any function 
in Red, using Red/System or C or ASM, whatever :-) But most probably 
I am confusing and create a mishmatch even in such case :-)

Inline ASM: we might add that at some point, but you can already 
access some low-level CPU/FPU features (like stack manipulation). 
I will extend that in the future to support CPU in/out commands and 
direct registers reading/writing, so ASM support will be less necessary. 
Also, there's a cheap way to support it, adding the option to inline 
machine code directly in Red/System code flow (you would have to 
use an external ASM for generating the machine code). Something like: 
inline #{....machine code...}

Is Red ging to have something like R3's vector! datatype?

looking forward to seeing people writing operating systems in Red/System 
:-)

I've added Red versions of Fibonacci and Mandelbrot to my C library 
binding, but they're just the Red/System code inlined in Red, with 
the timing code stripped out because I can't import the C binding, 
and Mandelbrot doesn't compile yet

Is there any meaningful Red code I can show tomorrow?

So it's going to be a traditional Red/System presentation, with little 
Red and contexts

I've been very busy since yesterday on a new tool for Red: I've built 
a proper REBOL code profiler! (I wonder why I haven't done that since 
a long time...). I went through the profiler scripts on rebol.org 
and couldn't one suitable for my needs or that works with complex 
code, so I wrote one. It is able to deal with complex code, all datatypes, 
recursive calls and it's very simple to use.


Here's a demo profiling Red compiler (output is properly aligned 
when monospace font is used):

-= Red Compiler =-
Compiling red/tests/test.red ...

...compilation time:     40 ms

Compiling to native code...

...compilation time:     10189 ms
...linking time:         60 ms
...output file size:     37888 bytes
>> profiler/report/time


Function                       Count      Elapsed Time         % 
of ET

------------------------------------------------------------------------

compile                        1          0:00:10.249          100.0

comp-dialect                   205        0:00:09.659          94.24

fetch-expression               7505       0:00:09.628          93.94

comp-word                      5668       0:00:08.209          80.09

fetch-into                     427        0:00:07.519          73.36

comp-assignment                597        0:00:07.049          68.77

run                            3          0:00:06.492          63.34

comp-context                   21         0:00:06.398          62.42

comp-with                      1          0:00:05.565          54.29

comp-expression                3172       0:00:04.479          43.70

ns-find-with                   24277      0:00:03.962          38.65

finalize                       1          0:00:03.327          32.46

comp-natives                   1          0:00:03.274          31.94

comp-func-body                 180        0:00:03.271          31.91

comp-call                      2775       0:00:02.732          26.65

comp-func-args                 2861       0:00:01.862          18.16

find-aliased                   9650       0:00:01.86           18.14

resolve-type                   8032       0:00:01.799          17.55

get-type                       10758      0:00:01.546          15.08

ns-prefix                      21765      0:00:01.518          14.81

check-enum-symbol              7509       0:00:01.241          12.10

comp-block                     283        0:00:01.05           10.24

comp-variable-assign           417        0:00:01.034          10.08

BTW, as I was thinking, the above compiler profiling confirms that 
aliases and namespaces support are quite costly currently (ns-* functions). 
So now I know where to improve the code for better performances (not 
that it matters for the users currently, but it matters to me as 
I need to run the whole test suite dozens of time each day, and with 
the addition of now Red compiler, it (and will) adds up to a lot 
of waiting time at the end of the day).

REBOL code profiler released: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r


Should work with any REBOL app. Documentation, comments and example 
included in file header.


Hope someone will pick it up and improve it (like adding functions 
sub-tree stats and a GUI). This is github, so feel free to fork then 
fix/improve.

Or is that new secret Red app for iPad? :-)

Can someone tell me why for example in https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r
to use 

set 'make-profitable func [][] instead of make-profitable: func [][] 

because the second kind of declaration is also use in this script 
and I do not see why both are being used; you have a preference for 
one over the other so you use one, not both?

Red FB group: https://www.facebook.com/groups/redlanguage/

My new public FB profil: https://www.facebook.com/redlanguage


Those that sent my friend requests recently to my private page, can 
now resend them to this new one.

That FB Red avatar is rather ... blue

Good point, I'll see how Doctor Manhattan renders in red shades. 
;-)

This is huge: http://www.pythontutor.com

We need to write Red documentation that way too!

Well my patience is being tested. No red-lang mailing list for me 
for a week or more. Account disabled. (Red-terrorist :) )

Ah, Unicode plan posted, should be announed here :-)

http://www.red-lang.org/2012/09/plan-for-unicode-support.html

Pekr: I guess that all people here interested in Red have subscribed 
to red-lang.org feed. ;-)

Line numbers: there are complicated and costly to handle in a REBOL-like 
language at runtime. The experimentation I did in Red/System confirms 
it. I'm not sure I will add them to Red unless we can come up with 
an efficient solution.

Is there any "tedious" task (not involving manuals, docs or graphics) 
that could be done by some volunteer to speed up Red development 
?

Marco: besides coding in Red/System, I don't see what you could do 
currently to speed it up. Here are some ideas for the additional 
coding that will need to be done:


You can write in Red/System some of the non-trivial natives, like 
e.g. set natives: sort, union, intersect, unique, difference. Other 
natives or support code we will need are codecs for:

- compression supporting these algorithms: deflate, lzo

- cryptography: MD5, SHA-1, AES, ...(all the required ones for SSH 
and SSL support)


You can port C code to Red/System, there are tons of available C 
source code, you just have to make it right (crypto requires accurate 
coding, implementations need to be deeply tested for flaws).

ok, just like in REBOL of course. Still it looks strange because 
I expect it to be there because there always is in other languages 
and it is a loop until a condition is met. So somewhere that condition 
must be tested to be true or false but indeed this part is more the 
definition of how the statement as a whole should be formatted in 
a Red program. I'm back on track, thanks!

I guess this would be more straighforward for Red/System as opposed 
to Red because of the more limited syntax. I would think a regex 
based approach would work for that

might be worth starting with a TextMate bundle for REBOL and simplifying 
that, for Red/System

Red needs a "Red programming language Pocket Reference" (O'Reilly 
book) before the world dominance can set in.

I don't think that all future Red users will be pleased to have to 
provide a long list of advertisement with all their apps, just because 
Red uses 3rd-party libs underneath.

Henrik: something that works. I don't know what you want to use SSL/SSH 
for, but Red/System has a cURL binding. cURL usually uses OpenSSL 
and does most things you would want to do with SSL and SSH

Kaj - the last thing I want is to have to distribute Curl with each 
Red script. How big is the Curl library? Even tens of KB is too much 
.....

That is the same reason why we adopted BSL for Red/System runtime 
code instead of BSD-3.

Well, Rebol/Red headers are extensible. Is that really a problem 
to have a 'credit or 'licence field, and mention authors of particular 
components?

So, in the context of Red/System, it's less confusing that way.

I don't see currently any trivial task that could speed up the progress 
of Red, unfortunately, all the tasks in the Roadmap are non-trivial. 
If I stumble upon some non-coding task that can be outsourced, I 
will contact you.

Ah, there's maybe something that you could do: I need to port my 
current Red test script in Quick-Test (QT) form. I can send you the 
script (very very simple) and the expected unit tests format used 
by QT, you would just have to convert it and check if all tests are 
reported as passing in QT...it's not a big task, but you will save 
me some time for advancing on the code. Interested?

special group for posting small Red tasks?

There are lot of online tools for software project management. Maybe 
picking one could help better organize Red's development...thanks 
for the suggestion, I will look into it.

Are there any guides on how to use these various bindings for red/system?

Actually, the 0MQ docs there include a guide for Red/System, but 
the cURL docs include programming documentation

Including videos about Red installation and the bindings:

Guys, we will really, really, need something like: http://tour.golang.org
or http://tryruby.orgfor Red.


If someone is willing to start working on such tool, that would for 
sure greatly contribute to the success of Red. I have already bought 
the following domains for such kind of use:

- tryred.net
- redtutor.net
- red4.us
- red2.me