World: r4wp

@BrianH, when you say "And any loop construct that requires any kind 
of manual reducing of its arguments in order to have it take the 
result of an expression is a definite no-go.", does "manual reducing" 
mean having the user do it? e.g., if I get a spec passed to my dialected 
LOOP func, and I REDUCE it or DO/NEXT internally, is that a no-go? 
If so, where should I look for the reasons and guidelines about it?

e.g., in order to support Sunanda's example:

    loop [i ser skip ser 5 2] [print mold i]

Can I do this in my func:

    spec: repend reduce [spec/1] next spec

Provisional SHA-2 implementation, https://github.com/0branch/r3/commits/sha2-experimental

I haven't committed an updated Makefile, so even if you're on Linux 
be sure to 'make make' first.

Tested on Linux and OSX, interested in hearing whether it functions 
correctly on Windows.

Usage,

>> checksum/method to-binary "A simple SHA-2 test." 'sha256

== #{E57EBDB51368F9A7ACE63E115193AEAD5E377742E0B4CD6B735CF5AAD49E67EB}

SHA2_Series could switch on width (224, 256, ... -- perhaps defined 
in an enum) rather than a symbol, but this made the logic in N_checksum 
cleaner.

Anyway, this is just a draft.

Thanks for your activity, Marc much appreciated.

No problem; thanks for saying so.

Arnold wrote (Red group): "R3 should follow this. " - I guess it 
might make sense to write it as a CC ticket (wish). Otherwise, I 
am neutral on this, not needing a shortcut for quit, but a user poll 
(opinions, please?) my reveal that preferences are against Q being 
a shortcut for QUIT.

Also, Marc, I think you can use Announce for your new pull requests. 
(but they can be here too, no problem)

Oh, sure; sorry if I've been misusing this room.

No, you have not, in fact (at least IMO).

MarcS: cool stuff! I planned to add SHA256 myself to enhance TLS 
scheme so your work will be useful, thanks!

Neat, glad to hear it. Again, this is just a test; feedback appreciated.

I use q in the console a lot.

q should not be set by default.  anyone can add shortcuts for such 
stuff easily in their %user.r   

maybe we could even add a function which define all the "command-line" 
shortcuts, thus allowing them to be undefined by default.

@MarcS:  I'll try sha256 with Amazon AWS - very helpful, thank you!

Q is not necessary in scripts but it is very useful on console.

Continuing the discussion from "Rebol School". What if we changed 
(simplified) R3 functions to have O(1) variable access? I have got 
an idea how to do it sacrificing some of the features. That should 
not be painful taking into account that closures are available.

I think we should consider this heavily. Ladislav's points, and Brian's 
analysis in http://issue.cc/r3/1946make it clear that we need to 
understand the differences, and that we can probably get a large 
gain with very small tradeoffs.

The average user shouldn't know. R2 users will need to know about 
behavior differences, but I think the long term benefits are worth 
the small pain it may cause.

Hello, here you can find a user that have difficulties to build Rebol3 
on Solaris, please mayyou help him?

http://rebol.informe.com/forum/rebol-3-f9/building-rebol-r3-on-solaris-t40.html

tell him he shall use r3 for r3-make, not R2 (but, maybe, r2-forward 
would help? )

otherwise, he could probably make make on a different machine, where 
he can get an r3 interpreter

Important message for all R3 graphics fans:


I have finished IMAGE datatype(including all image codecs and other 
related code) change so it uses 'standard' alphachannel values (ie. 
0-trasparent 255-opaque)to be compatible with the 'rest of world'.

Without this change we would have problems to connect r3 with graphics 
systems on misc platforms/graphics frameworks etc.

This change will be in the upcoming revised R3 graphics code which 
is being worked on. So that is just FYI to avoid any duplicated efforts(in 
case you wanted to work on that in the feature).

Cool news ideed!

Cool!! Great work Cyphre!

cool :-)

Really glad to hear progress!

Where will you publish it?

Go Cyhpre Go!

Nice.. it was my request :-)

http://issue.cc/r3/2006

Interesting idea. It seems like it would work natrually most of the 
time, but could create subtle issues that have to be explained. e.g.

repeat i j: 100 []
or
repeat i: j: 100 []

I would love to hear Carl give his opinion on it.

I parsed out a username @C\u00E1ssio so what do I need to do to show 
this as Cássio on a web page?

We're missing UDP scheme in R3 http://stackoverflow.com/questions/15700937/how-to-implement-udp-scheme-in-rebol3

It is a great now coming from a great man Cyphre !

*Great  news !

I have an updated SPLIT-PATH, modeled on Ladislav's implementation 
where it holds that

   file = rejoin split-path file


This does not match current REBOL behavior. His version arguably 
makes more sense, but will break code in cases like this:

	%/c/test/test2/ 
	REBOL      == [%/c/test/ %test2/]
	Ladislav's == [%/c/test/test2/ %""]


Ladislav's func only seems to go really wrong in the case of ending 
with a slash an that's the only slash in the value which return an 
empty path and entire filespec as  the target.

Schemes (http://) don't work well either.


REBOL also dirizes the file path if it's %. or %.., which Ladislav's 
does not. e.g.

	[%foo/ %../]  == split-path %foo/..

split-path: func [

 "Returns a block containing a path and target, by splitting a filespec."
	filespec [any-string!]
	/local target
][
	either any [
		; It's a url ending with a slash. This doesn't account for
		; formed URLs. To do that, we would have to search for "://"
		all [slash = last filespec]
		all [url? filespec  slash = last filespec]
		; Only one slash, and it's at the tail.
		all [target: find/tail filespec slash  tail? target]
	][
		reduce [copy filespec  copy %""]
	][
		target: tail filespec
		if slash = last target [decr target]
		target: any [find/reverse/tail target slash  filespec]
		reduce [copy/part filespec target  to file! target]
	]
]

The above matches Ladislav's REJOIN requirement, and handles a couple 
edge cases better. I have about 35 tests here, if people want to 
see them for discussion.

It leaves open the question of what the best results are in cases 
where the target is a dir. Should it be part of the path, returning 
no target? Should it be the target? Should it be the target if there 
is no traliing slash, but if there is a trailing slash it should 
be part of the path?

And could/should it be generalized by adding a /WITH option to specify 
a path delimiter other than slash?

Well, it really is worth it to find out what the preferences are 
and whether people like the "invariant" I proposed.

why not use %.  as the last element of splitpath in case of a directory?
true = dir? %.

It makes sense to me Anton. I don't know why SPLIT-PATH does what 
it does today, by automatically dirizing that result. If everyone 
agrees, then the next question is whether a trailing %. or %.. should 
be returned as part of the path, or as the target. That is, do we 
presume that they are directories?


SPLIT-PATH, today, returns the last dir in the path as the target, 
if the path ends in a dir. Here are some example values, and what 
SPLIT-PATH returns today.

;	%/c/test/test2/ [%/c/test/ %test2/]
;	%/c/test/test2  [%/c/test/ %test2]
;	%/c/test        [%/c/ %test]
;	%//test         [%// %test]
;	%/test          [%/ %test]
;	%/c/            [%/ %c/]
;	%/              [%/ (none)]
;	%//             [%/ %/]
;	%.              [%./ (none)]
;	%./             [%./ (none)]
;	%./.            [%./ %./]
;	%..             [%../ (none)]
;	%../            [%../ (none)]
;	%../..          [%../ %../]
;	%../../test     [%../../ %test]
;	%foo/..         [%foo/ %../]
;	%foo/.          [%foo/ %./]
;	%foo/../.       [%foo/../ %./]
;	%foo/../bar     [%foo/../ %bar]
;	%foo/./bar      [%foo/./ %bar]