r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Janko
16-Apr-2009
[13312]
are there any changes planned in R3 in the way objects work? like 
if you could have some "static" methods or properties that would 
not get copied but referenced when one object is derived from another?
Geomol
16-Apr-2009
[13313x4]
I get second thought about auto encoding. The reason is, if url! 
have auto encoding of some characters, then it would be expected, 
that e.g. file! auto encode too. How do you specify a file named 
% on disk? In R3, you write: %%25

If the % char should be auto encoded, then you should write that 
filename as: %%
But what if your file is named %25 on disk?
It's a bit confusing, but what is the best way? Encoding or not?
Acutally file! does have auto encoding of space. You can specify 
a filename like this:
%"a b"
which will give %a b
So maybe auto encoding is a good thing in general?
url! already auto encode % in R3:

>> a%:b
== a%25:b
But I don't think, it's a valid url according to the standard:
http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax
Oldes
16-Apr-2009
[13317]
Actually the auto encoding was cousing me some problems some time 
ago. I'm not sure if it was fixed. Also with the auto encoding urls 
there is a problem, that for example the second @ char in Pekr's 
url must not be encoded.
Geomol
16-Apr-2009
[13318x2]
Yeah. This seems funny! (Output from R3 console.)

>> %"@"
== %@
>> %@
== %25@

Can you guess the datatypes?
The first ends with a quotation mark also.
Gabriele
17-Apr-2009
[13320]
Geomol: PLEASE NO!!!! The bug that REBOL has is exactly THAT. I beg 
you guys, please NO! Encoding is there for a reason. If it could 
be done automatically, there would be no need for encoding!
Geomol
17-Apr-2009
[13321x2]
Gabriele, so you mean, auto encoding shold be avoided? Should auto 
encoding be removed from these examples:

>> %"a b"
== %a b
>> a%[b-:-c]
== [a%25b-:-c]
>> a<>[b-:-c]
== [a%3C%3Eb-:-c]


My view is, that there is a lot of auto encoding already. If auto 
encoding should be there, it should be done right in all cases. Else 
it should be avoided alltogether. This situation with - some auto 
encoding in some cases but not all - is not good.
I guess, auto encoding is user-friendly, if it can be done right 
in all cases. With auto encoding, you don't have to remember all 
the strange encoding rules for different datatypes (especially url 
and email).


No auto encoding is technical-programmer-friendly. It's for the programmer, 
who knows all the strange rules and want complete control.


It goes beyond url and email. How should a space be represented in 
an issue! datatype? Like:

>> to-issue "a b"
== == #a?b

Today you just see a question sign, but it's a space in there.
BrianH
17-Apr-2009
[13323x2]
That's a bug in issue! formatting.in R3: http://curecode.org/rebol3/ticket.rsp?id=700
Though strangely enough that is still better than the R2 behavior.
Oldes
17-Apr-2009
[13325x2]
Geomol, yes. I would like to avoid auto encoding. It's exactly the 
case where I had the problems. If I write file as %"a b" and it's 
valid file, I prefere to have it samewhen I for example print it
Instead of auto encoding I would like to see such a basic functions 
like official url-encode presented in Rebol. (Of course we have our 
own - another %user.r usage)
Geomol
17-Apr-2009
[13327]
I understand the concern against auto encoding. But without it, and 
with all the datatypes, we have in REBOL, good documentation about 
what encoding, we have to use for every datatype, is required.
BrianH
17-Apr-2009
[13328x3]
I don't mind the ? issue! display in this case, but I'd like MOLD/all 
issue! to return a serialized encoding like: #[issue! "a b"]
In general I prefer simple encoding syntax rules over autoencoding, 
because it is easier to remember explicit rules than it is to remember 
magic dwim patterns.
Gabriele, RFC compliance of url encoding is important and will be 
fixed in upcoming R3 releases, even if I have to fix it myself. R2 
as well if I end up being the R2 release manager (it's possible).
james_nak
17-Apr-2009
[13331]
Back after many weeks... how does one get on the r3-alpha world?
BrianH
17-Apr-2009
[13332x2]
R3 chat. No more R3-Alpha world.
No more real work being done on R3 in AltME worlds.
james_nak
17-Apr-2009
[13334]
Do you mean here, Brian? Or is that a world name?
Henrik
17-Apr-2009
[13335]
james, we use the R3 chat built into R3 now.
BrianH
17-Apr-2009
[13336]
Download R3. Copy it to a directory of your choosing. Run it. Enter 
the "chat" command.
Henrik
17-Apr-2009
[13337]
(but big warning: it's console only)
james_nak
17-Apr-2009
[13338]
Oh, I see.  Yeah, I checked it. I was just trying to follow the instructions 
on the wiki which leads one to altme.
Henrik
17-Apr-2009
[13339]
we'll help, if you have trouble.
james_nak
17-Apr-2009
[13340]
Thanks. I was happy to see the demo gui run.
Henrik
17-Apr-2009
[13341]
Demo GUI is still the first prototype.
james_nak
17-Apr-2009
[13342]
Yes, but to see it running (I only saw your images prior to this) 
was exciting.  Thanks and take care you all.
Gabriele
18-Apr-2009
[13343x2]
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.
Geomol
18-Apr-2009
[13345]
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.
[unknown: 5]
18-Apr-2009
[13346x2]
https://help.ubuntu.com/community/RootSudo
; I do:

sudo -i
sudo passwd yourpasswordhere

; then when your done just do this:

passwd -l root
Gabriele
19-Apr-2009
[13348x2]
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.
Geomol
19-Apr-2009
[13350x3]
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.
Pekr
19-Apr-2009
[13353x3]
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 ...
Ammon
20-Apr-2009
[13356]
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! [
]
Pekr
20-Apr-2009
[13357]
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?
BrianH
20-Apr-2009
[13358]
No, it came out of the DotGNU Portable.NET project, though it is 
designed to not be specific to .NET bytecodes.
Pekr
20-Apr-2009
[13359]
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?
BrianH
20-Apr-2009
[13360x2]
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.