World: r3wp

No, it came out of the DotGNU Portable.NET project, though it is 
designed to not be specific to .NET bytecodes.

I would also like to ask about one Carl's Chat message, describing 
DELECT. Do I understand it correctly, that first Carl thought that 
DELECT might be used for some interfacing, but that DELECT is kind 
of functional/procedural aproach which does not fit the concept, 
and hence instead Carl is considering action! kind of aproach?

That's a link for it, though the download links don't work.

DELECT was supposed to be a way for Draw-style dialects to be done 
without exponential growth in the size and runtime of the parse rules 
to handle them. However, it turned out to be not powerfuul enough, 
so it is due for a revamp or replacement.


The days of "just make a dialect" are over - we have improved the 
performance of REBOL to the point where the overhead of processing 
dialects is now noticable enough (in comparison) that you need to 
be really careful about dialect design and implementation. Or about 
the choice to use a dialect at all.

Now about libjit, I considered it years ago, but it was GPL 2, and 
GPL 2 code is license incompatible with REBOL. As of the new version 
released in December of 2008 libjit is LGPL 2.1, and we can use that 
with REBOL. It supports more CPU platforms than TCC and it is about 
the same size. Here's some links:
- http://www.gnu.org/software/dotgnu/
- http://savannah.inetbridge.net/dotgnu-pnet/libjit-releases/

I don't quite understand how you mean libjit would be used ? to jit 
compile rebol code, or some lower level rebol-like dialect like rebcode 
or something third?

Janko - I think the latter - to "compile" some subset of REBOL language, 
a dialect ...

You would compile a low-level REBOL dialect into functions that could 
be called from REBOL. In R3 this could even be a user-defined function 
type. However, the syntax for this dialect could resemble a subset 
of the REBOL DO dialect if you are careful.

BrainH: it scares me a bit - dialecting was supposed to be one of 
REBOL's holy grails. Where have we improved performance of REBOL 
specifically? Or in other words - were dialects here because they 
gained us some speed? I think not. 


As for DELECT, I think that with advent of parse improvements, it 
will not be used much, if used at all. What do you think?

interesting

Dialecting isn't any slower, it's just that everything else has gotten 
quicker in R3, and dialect processing just seems slower in comparison. 
Dialecting just has to catch up with the rest.

BrainH: what is your take on security? I mean - with R2 web plugin, 
we could not allow DLL interface. We are now restructuring R3 security 
model, but I still wonder - what about R3 plug-ins? Those will contain 
native code, no? Will R3 be "internet secure"? Or we will have to 
release special version of R3 for browser, hence making it non-extensible? 
Or it can be secured somehow?

BrainH: well, for me dialects should not be introduced just for the 
sake of using dialects, but for kind of API environments, where they 
make sense. And - you "compile" them to REBOL code in the end, I 
think that the cost is not very high ...

I expect that the browser plugin won't be able to load REBOL plugins 
that have native code in them - they will need to be compiled in.

OK, moving home. I am curious what Carl comes up with. His host isolation 
plan via 'cmd actions looks interesting, although I do not understand 
it fully yet :-)

Some dialects are compiled into REBOL code (I do it often), but most 
people's dialects are either interpreted or handled by natives.

The security model is a work in process - if you don't understand 
it fully yet, that just means you get it :)

BrianH, that libjit thing is very interesting

Geomol, the difference I'm pointing out is the following: suppose 
you have an array of unicode code points. each element in the array 
is an integer that represents a character. you can "encode" it to 
UTF-8. there is no magic, for each integer you have a corresponding 
sequence of bytes.

Now, if your array was representing a url, you could encode it to 
UTF-8 using the % encoding as well to stay in the ascii subset. This 
is encoding, but still, it will not solve your @ problem. each @ 
in the array of integers will become an @ (which is an ascii char) 
in the final string.

it is in your *source array* (re: shouting, i just want to give emphasis 
but we don't have rich text, and the * thing does not work very well 
for long text) that you must distinguish between @ (the field separator) 
and % 4 0 (an escaped @, part of the url field text). There is no 
encoding process that can *automatically* go from your array of integers 
to the correct url string.

You can do it automatically only if you keep your fields separate, 
like in an object. so if you have [user: "[user-:-domain]" host: "somehost" 
...] you can have a function that automatically turns that into the 
correct url string.

Maybe we got unicode encoding end escape encoding confused.


As I see it, given correct rules, auto converting of user input to 
correct url can be achieved. I made this function to illustrate, 
what I mean (it's not optimized, but should be easy to read):

encode-url: func [input /local url components host] [
	components: parse input "@"
	host: back tail components

	url: clear ""
	append url components/1
	components: next components

	forall components [
		either components = host [
			append url "@"
			append url components/1
		][
			append url "%40"
			append url components/1
		]
	]
	url
]


I can use it both with and without specifying %40 for the first @ 
in the url:

>> encode-url "ftp://[name-:-home-:-net]:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"
>> encode-url "ftp://name%40home.net:[pass-:-server-:-net]"
== "ftp://name%40home.net:[pass-:-server-:-net]"


It will give correct result in both cases (I use strings, but of 
course it should be url! datatype in REBOL). Now comes unicode. Given 
precise rules, how that should happen, I see no problem with encoding 
this in e.g. UTF-8.


So I think, it's possible to do this correctly. But maybe it's better 
to keep it simple and not do such auto convertions. In any case, 
the behaviour needs to be well documented, so users can figure out, 
how to create a valid url. I had same problem as Pekr years ago, 
and I missed documentation of that.

unicode encoding *and* escape encoding

I think it is good to have a flexible encoding method, but it should 
not be invoked automatically.

Yeah, maybe give functions like mine above, that users can call and 
get their input encoded, instead of having to know all the escaping 
rules themselves.


If that solution is choosed, then this input should give an error, 
as it is an invalid url:

ftp://[user-:-net-:-net]:[pass-:-server-:-net]

Today R3 just accepts it.

Great!, Ladislav Mecir just registered to R3 chat! Hopefully he will 
be back and is OK!

New short doc to comment on: http://rebol.com/r3/docs/concepts/gui-layout.html

Ladislav is back. I guess we can get more focus on those scanner 
problems now. :-)

:-)

BrianH has finally some companion to talk to, instead of listening 
to my lame questions :-)

But I like your lame questions :)

wow, that is great.. I remember his rebol website showed me that 
rebol is very deep language , I still have plan to read his documents 
more

yes :)

is Chat down again?

Ladislav also seen on skype today :)

yuppy-yay-yea 8-) Ladislav back 8-)

Someone hit him up and tell him to jump in here.

The O3D plugin from google takes up about 15 MB of disk space. I 
wonder how many kb it would take to do the same thing in R3 using 
ReBrowse.

Geomol, so that will give you the correct result for *two* cases. 
Cool. What about the other billion cases? :-) I'd like to understand 
if you have ever worked with this stuff in real life, and to what 
extent, because in my experience what you did above makes no sense 
at all...

On the new R3 GUI document: I think the new guides and layers concept 
will work much better, but of course it depends on the implementation. 
I've asked a range of questions in Chat to get some more information.

Doesn't guides concept reminds 'AT concept in R2, and hence absolute 
positioning, which we were against?

No. AT would be overridden as soon as RETURN was used, so AT was 
only useful per face. Guides are generally a great idea if used correctly.

So in what regard it differs to current 3.4 VID?

They can be set manually, which solves a problem that was present 
since the old VID3, namely to have proper reference positions in 
the layout, usable by multiple panels. Even if it's not possible 
to share guides between panels, we can get good use of this.

Generally they provide much more control over the layout. Whether 
guides are implemented correctly is a different issue.

Not having proper reference positions is one of the reasons VID3.4 
is very hard to produce good layouts with. Faces are just sailing 
around in the window.

Yes, so finaly my "anchoring" model? So that I can e.g. position 
two buttons relative to some text area corner?

(that could be achieved by normal layout model with alignment of 
butons to the right even today otoh)

I'm not sure, but it could be. The anchoring model I was advocating 
was from OSX, which Carl does not like. That reminds me that I didn't 
ask whether guides could be hinged to other guides.

Why Carl proposes different model suddenly? I thought he was OK with 
what he has created?