World: r3wp

james, we use the R3 chat built into R3 now.

Download R3. Copy it to a directory of your choosing. Run it. Enter 
the "chat" command.

(but big warning: it's console only)

Oh, I see.  Yeah, I checked it. I was just trying to follow the instructions 
on the wiki which leads one to altme.

we'll help, if you have trouble.

Thanks. I was happy to see the demo gui run.

Demo GUI is still the first prototype.

Yes, but to see it running (I only saw your images prior to this) 
was exciting.  Thanks and take care you all.

Geomol, sometimes I don't know what language I'm speaking in. We 
were talking about URLs, weren't we? files and emails are rebol values 
with rebol rules. url! also has rebol rules which is the main problem 
- REBOL considers %40 and @ to be the same, while they are not (if 
they were, there would be no reason for escaping).

If user friendly means breaking everything, then I'll leave user 
friendly languages to you.

Are you having a bad week?


I'm in doubt about auto encoding, whether it's a good idea or not. 
And I talk in general, not just one datatype. In R3, you can use 
% in an email:

>> a%[b-:-c]
== [a%25b-:-c]


I first thought, it was an error. After some talk here, I realized, 
it's auto encoding of the % character. In R2, you have to write the 
encoding yourself:

>> [a%25b-:-c]
== a%[b-:-c]


So it's the other way around between R2 and R3. Clearly Carl try 
to make REBOL smart. Make it figure out, what the programmer mean. 
In general with computers, I tend to dislike the systems, that try 
to be smart, if they don't get it 100% correct in every situation 
(Windows), and I like the systems, that does not try to be smart 
but put the user in charge (Amiga).


So at this point, I think, auto encoding should be avoided. And avoid 
it in all datatypes, not just url. I may change my mind, if auto 
encoding can be done 100% correct in all datatypes. For url, it would 
mean e.g. this:

>> to url! "ftp://[me-:-inter-:-net]:[pass-:-server-:-net]"
== ftp://me%40inter.net:[pass-:-server-:-net]


So my question is, can auto encoding be done 100% correct for all 
datatypes? If not, avoid it. If auto encoding should be there in 
some cases but not all, I would like to hear the arguments for that.

https://help.ubuntu.com/community/RootSudo

; I do:

sudo -i
sudo passwd yourpasswordhere

; then when your done just do this:

passwd -l root

Geomol, we're talking about two completely different things, and 
if you don't see that, I don't really know how to explain it.

I'm talking about "escaping", while you use the term "encoding" ambiguously 
to mean both encoding and escaping. THEY ARE TWO DIFFERENT THINGS.

Ok, thanks. I'll read more closely into it.

Gabriele, I don't think, I got it wrong. From RFC 1738
http://rfc.sunsite.dk/rfc/rfc1738.html


The word "escape" is only used in the BNF in section 5. Escape is 
defined like:

escape         = "%" hex hex


That must be what you mean, when you gave the example of an url with 
the problem:
ftp://user%40email.com:[pass-:-ftp-:-domain-:-com]

When REBOL read that url, it convert %40 to the @ sign. Throughout 
RFC 1738, the word "encode" is used, when a character needs to be 
escaped. Like in this - taken from the RFC:


The user name (and password), if present, are followed by a
   commercial 
at-sign 
@". Within the user and password field, any ":",
   "@", or "/" must be encoded."


So "encoded" mean escaping the characters, right? I think, that's 
how I used the word in my comments here. If you think, I got it wrong, 
could you explain it to me then? I would like to get this right.

And please try not to shout. There's no need to shout at me.

yes, no shouting please. Don't forget it is pekr, who has privilege 
to shout here :-)

I smell some problems towards Rebin :-( ... Carl points something 
in Chat ...

Carl states he was working on rebin last week (which is prerequisite 
to host to core code isolation and finally open-sourcing R3 host 
code), but found some problems, especially for Draw, which needs 
to be dynamic ...

This looks like a bug to me...

>> obj: context []
== make object! [
]

>> bind 'a obj
== a

>> obj
== make object! [
    a: unset!
]

>> obj: context []
== make object! [
]

>> bind [a] obj
== [a]

>> obj
== make object! [
]

BrianH: in rebol school channel you mentioned libjit. Is it this 
one? http://freshmeat.net/projects/libjit/Hmm, so it is not related 
to ASMJit or BlitJit?

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!