World: r4wp

That would really butcher all my bindings. And it's too much work 
just to do temporarily for the demo

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

I'll extend FORM tomorrow so we can print more types.

#233 is back

Looking into it.

Fixed it. Going to rest now, will process other tickets tomorrow 
morning.

I'm busted, too. Night

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

Will there be possibility to use inlined ASM code?

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 :-)

one small question though - what "secret project" are you guys talking 
about? :-) I expect you will not want to tell, otherwise it would 
not be secret anymore, right? :-)

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...}

Secret project: that's a secret! (there's actually two secret projects, 
one by Kaj, one by me ;-))

ok, cool, so looking forward to the reveal of the secret projects 
... which is going to happen cca ... when? :-)

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

ging=going

Yes.

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

Well, when CPU I/O instruction will be added, you'll be already able 
to make kernel drivers for Windows or Linux....and an OS is typically 
90% made of hardware drivers.

Pekr, if you are interested what action!s and native!s are currently 
available, I wrote simple parser that goes thru %actions.reds and 
%natives.reds and outputs list of all implemented functions.

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?

Only the examples I posted above yesterday night.

We don't even have proper string! support yet. I plan to implement 
it this week.

I'm trying to wrap my GTK dialect in a context, but I'm hitting more 
context bugs

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

The overhead of the current implementation is about 5-6 times the 
program execution time, so it's very usable. I will publish it today, 
and I hope someone will pick it up to improve it and add features 
(like a GUI front-end for the reports, with sortable columns).

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

That's great Doc!

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.

Doc - your twitter account got spammed?

Calculator Hero lets u fulfil challenging computing tasks with simplest 
operations!! DOWNLOAD NOW 4 iPad ver. 

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

Thank...has my password been cracked or are they means to post in 
name of someone else?

(tweet deleted)

I've changed my password just in case.

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?

set 'make-profitable func [][] instead of make-profitable: func [][] 
the link overwrites this line in my version of AltMe sorry!

This also was meant for Rebol-school. Closing down AltMe and restart.....

Arnold - that's the old altme url bug. In order to be able to read 
such lines, just change the size of text for a while (aA button above 
the text field)

Arnold - 'set example is one trick you can use in REBOL. Normally, 
when you enclose the function in the object/context, it is accessible 
via a path notation, e.g. context/make-profitable. When you use 'set 
aproach, it lives inside the context, but is exposed to the global 
context, so you can call it directly, or something like that :-)

Thank you Pekr. It is a little to subtile for my mind and current 
REBOL knowledge, I will have to live with this ;-)

It's "make-profilable", not "profitable"...well at least, not yet. 
;-)

LoL! I was totally unaware I changed that. :D

:-)

@Arnold: I've pushed an update to profiler and I've made nested functions 
exposition to global context more elegant. ;-)