World: r4wp

Nice to read about the JAVA bridge ....

btw - probably stupid question by me uneducated :-) Reading a Trello 
card, I can see task "Extend ELF emitter to support shared library 
generation" - does it mean linux is not supported? Or is ELF anything 
else, than Linux executables?

Andreas is working on Linux shared library support. ELF is not limited 
to executables.

Don't want to bother you with primitive questions, but - why in general, 
there is a need for shared library support, on mobile platforms? 
Can we just have - executables? IIRC, R/S code already worked under 
Droid? Well, I know that .apk is some other format (maybe a zip file 
with some files inside?). Is it that in order to have PROPER app 
support (e.g. via GooglePlay), we need to adhere to some rules, and 
one of those is, we need dynamic libraries?

The need is for bridging Red with the JVM and the objective-c runtime.

Red executables (like R3 ones or any other language compiled to native 
code) are not supported directly by mobile OSes. So, it needs to 
be loaded and called from Java or obj-c, hence the need for shared 
library support.


The experiments with Red/System on Android was limited because using 
such approach, you can't have access to the higher level API, can't 
access GUI and need an hack to get it loaded. My goal was just to 
check that Red/System toolchain was able to produce code that runs 
on Android.

Petr, I didn't ask anyone to switch focus, I just asked for information 
repeatedly. I eventually analysed and fixed the problem myself, with 
help from Peter. If that's not enough, I don't know what is

Doc, I keep repeating, I am not "painting a bad picture of whole 
Red", you make that up, blowing the issue out of proportion

I was genuinely disappointed by the lack of Unicode asymetry, and 
had good cause to expect it based on your publications. I made the 
best effort to gain insight into the situation and contribute a fix

I have been digging out this issue with Kaj privately, and it appears 
that several misunderstandings happened a few weeks ago setting up 
a chain of events that resulted in having an unpleasant (for us and 
others) exchange between me and Kaj in this channel.

Kaj raised 
an issue a few weeks ago and asked for information that I failed 
to give. This was my mistake and I'm sorry for that. We've dug out 
the root reasons for that and have set up better rules to avoid, 
as much as possible, such failure in the future. Kaj's dedication 
for Red is obvious to all, from day one, and I'm grateful to him 
for that.

Actually, after setting up this issue, we've come up with 
some interesting new plans and strategies for Red that we will unfold 
in the next weeks...so stay tuned. ;-)

Yay! Thanks for posting that Doc. I was having a hard time choosing 
which of you to keep as a friend.

And it's easier if you're both there, so I can stand on your shoulders.

Hehe :-) You might want then to take an oxygen mask with you, because 
we're going to jump very high. ;-)

Well, maybe I'll ride your coattails then.

As an aside, I needed a break last night, and looked at some Red 
mezz bits again. I realized that REMOVE-EACH was one of the missing 
natives I had written off for a while, assuming you would get to 
it. But I got impatient and wrote a quick mezz version. Fun stuff.

One of my goals is to have as much working at the mezz level as possible, 
so you don't have to write more natives in these early stages. Once 
we find actual cases that aren't efficient enough, then we can optimize 
them.

e.g., I did all the set functions (union, intersect, etc.), even 
though they aren't optimal. They work, and that will let us port 
code.

Sounds fair enough.

Great ... I can take those PERL books back.

I'm very happy with that, Gregg, I follow the same strategy

It can be compiled, anyway, so it's not that slow

I was looking to take cover just in case a battle of the wizards 
was going to happen!  Glad to hear it has been avoided.

I used to be a Dragon-Wizard level 37 in CircleMUD back when Internet 
was mainly text-only, so this could have become nasty indeed. ;-)

Is there comprehensive updated documentation for RED?

Not yet Paul. Though there is for  Red/System.

interesting new plans and strategies
  sounds good :-)

Doc: what do you mean when you say Textpad doesn't support  Unicode 
? I use Textpad 5.4.2 and see options to set UTF-8 as default text 
encoding and others options for BOM and so on.

Didier: see http://stackoverflow.com/questions/8879277/textpad-and-unicode-full-support

Huh, there are versions 6.x and 7.0 for Textpad, I've missed that, 
but the feature page is not mentioning Unicode at all: http://www.textpad.com/products/textpad/features.html

Sadly the recent (March 2013) TextPad v7 release doesn't fix this 
problem.

Got a reply from Avira, they have processed my report and the fix 
should be soon available: 

https://analysis.avira.com/en/status?uniqueid=KwPWqW429CmT1fNpbHWQgDxQ8ryDHO4T&incidentid=1412216

btw, just curious - what is it generally usefull for, to call Red 
from R/S? I can imagine it in reverse direction, but when you would 
need any such callback?

Mainly for external (from bindings) events propagation to Red level.

It will be also used in the Java and obj-c bridges.

Added new #call compilation directive to enable calling Red functions 
from Red/System.

Syntax:
    #call [<red-fun-name> <arg1> <arg2> ...]

Notes:
- it can be used only in routines body or #system body block.

- only function! value can be invoked (refinements not supported).

- arguments are either literal values or Red/System global/local 
variables.

- type casting (to a Red internal datatype) is allowed in arguments 
(avoids wasting an extra variable).

I think it is worth stressing that this is a feature of the Red compiler 
and is not available to Red/System programs compiled with the Red/System 
compiler.

So you can call Red apps from Red/System, but you can't call Red/System 
apps from Red/System, correct?

Peter: right, I've forgot to mention it.

Gregg: not sure what you mean by "Red/System app".

The #call directive invokes a Red function, it has nothing to do 
with Rebol's CALL native.

R is a compiled Red app. RS and RS2 are compiled Red/System apps. 
From RS2, I can #call into R, but not RS, correct?

No, it's not Rebol's CALL native.

Because it invokes a Red function.

Right, I understand that. I don't mean CALL, I mean #call.

There's no way you can call any function from one process to another.

#call is meant for calling Red code from Red/System in the same app.

Ah, I see my confusion. I thought this was some tricky IPC thing, 
but it's just a callback def in Red, correct?

Yes. :)

Oh, I get it now. Thanks.

Petr, in the currently available code, the GTK binding can't function 
without a callback from Red/System into Red; as Doc says, to pass 
GTK events into the Red GUI dialect engine. So far I constructed 
the callback the ugly way, but there's official support now