World: r3wp

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?

I just hope he saw that the model wasn't good enough.

(also he apparently listened to my comments :-))

anyhow, with guides we are also no longer depending on MAX-SIZE.

Hello, jumping in

re the %rebol.r and %user.r files:
* I do not use %rebol.r for anything

* I use %user.r to set up my personal preferences on every machine 
so, that it looks like I expect it to: defining my personal "absolutely 
necessary" functions

Ladislav (continued from Rebol vs. Scheme), FUNCTOR currently isn't 
being used by any mezzanine code, so if we want to change it now 
is the time. If we go with your initialization block idea:

- The initialization would have to be performed at function creation 
time, not first call.

- The init block would be only the starting spec for the static object, 
not  the final spec. We'd need to still do the search-for-setwords 
that FUNCT does, or there'd be no point to including FUNCTOR.
- I'd suggest that the parameters be in spec, init, body order.

I essentially support Pekr's opinion about %user.r with the following 
exception:

* REBOL should be unable to overwrite %user.r when started in the 
default security mode (security reasons)

functor: func [

   "Defines a user function with all set-words collected into a persistent 
   object (self)."

    spec [block!] "Help string (opt) followed by arg words (and opt type 
    and string)"
    init [block!] "Initialization block of the persistent object"
    body [block!] "The body block of the function"
][

    make function! reduce [copy/deep spec bind/set/copy body make object! 
    init]
]


We decided to not use the term "static locals" since it would be 
confusing to people not familiar with C languages.

re Functor:

* in my opinion it does not make sense to initialize static local 
variables during function call, since they are static and therefore 
supposed to persist, so the only time suitable for the initialization 
seems to be the function creation time

* the initialization (IMO) can perfectly serve another purpose: all 
initialized (during function creation) variables shall be static, 
while the other variables shall be dynamic IMO

If the terminology does not look good, then we may probably say "persistent" 
instead of "static" meaning that the values persist during calls 
unless explicitely changed

...but if we use the term "persistent" instead of "static", what 
would be used instead of "dynamic"?

Dynamic. Local variable capture is half the point of the function, 
so making the set-words in the body persistent too is a must.

So a functor, with no variables initialized would basically not be 
a functor. You could evolve a functor with many static variables 
gradually towards a normal function with no static variables.

(with Ladislav's initialization idea.)

Ladislav, the reason we are asking about how people use %user.r is 
so that we make sure that alternate facilities exist to do what people 
did with %user.r, but safely. The old behavior of %user.r will be 
going away in R3 for security reasons. However, we have your uses 
covered by our plans:
- Preferences will be handled by the new %user.r
-You can include your must-use functions in a module.

making the set-words in the body persistent is a must

 - let me disagree with this. I think, that the INIT block is a must, 
 since the function cannot initialize the static variables as noted 
 above. OTOH, every variable not initialized during the function creation 
 time should be automatically dynamic, since it does not make much 
 sense to have it uninitialized when using it as static

Back to FUNCTOR, that and FUNCT are most often going to be used where 
the user will only specify the body, not the init or spec.

FUNCT sounds perfectly logical and usable as is, but I really cannot 
imagine the usage of a persistent value that cannot be initialized 
at function creation time

They could be initialized at first call. We already have facilities 
to do what you describe.

it simply does not make sense to me

(You mean *specifically* initialized, with the initialization block; 
they could be initialized to NONE..)

aha, during first call - how does the user find out which call is 
the first one?