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

World: r3wp

[!REBOL3]

Kaj
13-Jan-2011
[7088]
Don't remember AGG related fixes
BrianH
13-Jan-2011
[7089]
Carl is not the only one to go over the tickets, the rest of us go 
over them too. But yes, there's new stuff there that needs his attention.
Pekr
14-Jan-2011
[7090x2]
Elan Goldma registered to R3 Chat ... isn't it Elan, who wrote the 
first book on REBOL years and years ago? :-)
Goldman
shadwolf
14-Jan-2011
[7092]
it's amazing to see that in 2011 it can take so much energy out of 
someone just to tweet a "I'm away for 6 month please don't let a 
message after the bip"
Pekr
14-Jan-2011
[7093x2]
yes, Carl does not handle communication well. We should not start 
advocacy here though, but in advocacy channel ...
there is some indication from some guys here, that Carl might be 
back to R3 now, just looking into the situation, and deciding upon 
what's next ...
shadwolf
14-Jan-2011
[7095x4]
Pekr I heard that too ... But that's like the rebol GC we don't know 
in fact :)
but hey maybe carl will come with another super grate stuff ... But 
my point is rebol is already super great stuff that just need to 
be  upto dated one every 6 month ...
sorry I got the last sentence wrong ... But my point is rebol is 
already full of super great stuffs (desktop, console, web plugins, 
 etc...) that just need to be upto dated once every 6 month. Some 
of them maybe needs a redefinition.
for example I would prefere a webplugin rebol/view  for only firefox 
but available on all OS... Maybe basing rebol VM on non hardware 
related  langagues would allow to speed up things ...
Pekr
14-Jan-2011
[7099]
R3 can't read and write back source file, to correct platform terminators? 
I used such aproach in R3 - just read, and write back to the same 
file. In R3 I even tried read/string, but it does not help when I 
wrote file back ....
shadwolf
14-Jan-2011
[7100]
terminators ? you mean the robots from the futur that are tracking 
down sarah conor and john conor ?
Andreas
14-Jan-2011
[7101]
Pekr, just tried
write %foo.r read/string %foo.r
on Linux. Converted DOS (CRLF) line endings to LF-only for me.
shadwolf
14-Jan-2011
[7102]
sorry ...
Pekr
14-Jan-2011
[7103x2]
I tried RMA's source under Windows, and no luck ...
R2 turned out being handy, though :-)
Andreas
14-Jan-2011
[7105]
Ah yes, WRITE does not do any conversion, but READ does. So you'll 
always end up with LF-only.
Pekr
14-Jan-2011
[7106]
Well, shouldn't R3 under Windows turn line terminators (Johns and 
Sarahs :-) into Windows compatible ones?
Andreas
14-Jan-2011
[7107x2]
Use ENLINE for that.
The full sequence for line terminator recoding is:
write %foo.r to-binary enline deline to-string read %foo.r

- READ/string is a shortcut for "deline to-string read"

- WRITE auto-converts string! to binary, so is a shortcut for "write 
to-binary" in this case.

So it can be just:
write %foo.r enline read/string %foo.r
Pekr
14-Jan-2011
[7109]
Thanks - that is a gem - should be docced :-)
Gregg
14-Jan-2011
[7110]
Is there a home for R3 one-liners and idioms?


reline: func [file] [write file to-binary enline deline to-string 
read file]
BrianH
14-Jan-2011
[7111x3]
reline: func [file] [write file to-binary enline read/string file]
reline: func [file] [write file enline read/string file]
(whoops, missed one)
Oldes
18-Jan-2011
[7114]
New bug: http://issue.cc/r3/1830
BrianH
18-Jan-2011
[7115x2]
Sorry, that one's intentional.
It's all part of the plan to make SELECT treat blocks, objects and 
maps more alike.
Maxim
18-Jan-2011
[7117]
I've always felt that doing so was dumbing down select.  now I can't 
use select with/within parse, cause the different types will not 
be identified.   

has switch suffered the same fate?
BrianH
18-Jan-2011
[7118x3]
Nope.
Now that I have internet again (it's been out for possibly a week) 
I'll check with Carl about this, but I remember code from 2007-2008 
that depended on this change, even from before SELECT was extended 
to objects and maps. It's used to make blocks that look like spec 
blocks for objects or maps act like objects or maps. SELECT does 
EQUAL? comparison, and SELECT/case does STRICT-EQUAL? comparison. 
So you can make it work by using SELECT/case. Note: Words now support 
case-sensitivity in blocks too, letting them be searched with FIND/case 
and SELECT/case.
>> select [a 1 :a 2] quote :a
== 1
>> select/case [a 1 :a 2] quote :a
== 2
Oldes
18-Jan-2011
[7121]
fine!
BrianH
18-Jan-2011
[7122]
I'll add this info to the ticket in a comment and dismiss it. It's 
actually more powerful than R2 :)
Oldes
18-Jan-2011
[7123x2]
but not perfect as the case-sensitivity may cause problems...but 
I can live with it.
but not perfect as the case-sensitivity may cause problems...but 
I can live with it.
BrianH
18-Jan-2011
[7125x2]
Not when you realize that this is consistent throughout R3, and just 
don't mix case when you don't need to.
The trick is that objects and maps are case-preserving rather than 
case-sensitive, so their fields get the same case as the first instance 
of the word. Plus, case-insensitivity is a little broken for a lot 
of languages right now (Unicode case is a complex problem).
ChristianE
19-Jan-2011
[7127x2]
Characters are case-sensitive

 is a pretty misleading description of the difference you've pointed 
 out between SELECT and SELECT/CASE, Brian. 


I would appriciate SELECT/STRICT over /CASE, /STRICT would even be 
usefull to imply case sensitivity, at least it seems better suited 
to express the semantic difference between the refined und the unrefined 
function call .
Same for 

>> find/case [a :a] quote :a
== [:a]
>> replace/case [a :a] quote :a quote a:
== [a a:]
>> alter/case [a] [:a]
== true


DIFFERENCE, UNIQUE and other "set-functions" obviously haven't been 
subject to change when the treatment of blocks, objects and maps 
converged:

>> difference/case [:a] [a:] 
== []
>> unique/case [a: a :a] 
== [a:]
>> union/case [a] [:a] 
== [a]
>> intersect/case [a] [:a] 
== [a]
>> exclude/case [a] [:a]
== []


In all cases, /STRICT would read at least as well as /CASE, if not 
better.
Andreas
19-Jan-2011
[7129]
Christian, please report the latter cases as bug.
ChristianE
19-Jan-2011
[7130]
I'm not sure if it isn't by design, at least I wouldn't be surprised 
if being told so. Anyways, I'd prefer it being a bug, so, added it 
to CureCode.
Andreas
19-Jan-2011
[7131]
Given the above discussed behaviour, I would very much prefer /STRICT 
instead of /CASE as well. But I fear the chance for such thorough 
naming improvements has long passed.
Ladislav
19-Jan-2011
[7132]
hmm, you should post it as a separate CC item (wish?)
Maxim
19-Jan-2011
[7133]
yes, using /CASE for strict word comparison is VERY ugly. the only 
reason I can think of is that Carl didn't want to add a refinement 
just for this.
Andreas
19-Jan-2011
[7134]
Well, if there's sufficient backing in the community, we really should 
manifest that in the form of a CC wish.
Ladislav
19-Jan-2011
[7135]
No problem with me
Maxim
19-Jan-2011
[7136x2]
I'd bet /CASE is not used that much for word comparison in the R3 
mezz code.
(if at all, maybe in r3gui)