World: r4wp

As far as compatibility between REBOL-like languages, it's a similar 
situation. Being able to load most values into compatible datatypes 
is the foundation, and being able to build mezz-level compatibility 
code will let us build things at the next level up that can work 
across languages.

SQL is more than the language, it's a storage and execution model. 
As long as we support the storage and execution model we can let 
the SQL servers/libraries process their own scripts. Our own model 
can just translate the R3-style port model (if we decide to do this 
as a port) into SQL operations, with the ability to send SQL code 
directly as a fallback.

Compatibility: Yes, that is why I am more concerned with syntax compatibility 
than semantic (unless it's so low-level and obvious that not being 
compatible would be stupid). Dialect compatibility can be done with 
dialect processors, in the Rebol way :)

For instance, there is no reason why a Rebol-like language couldn't 
have two separate DO dialects at the same time. They could even share 
some of the same functions.

Wait, I remember, delay-loading was one of the features Carl wanted 
for alpha 108. Private modules were the feature that existed since 
alpha 80.

The main problem with Unicode whitespace delimiters is that R3's 
syntax parser isn't actually a Unicode parser at all, it's a byte-oriented 
parser.

This means that the difference between an ASCII character and a higher 
Unicode codepoint is significant. ASCII characters can be detected 
with a single byte of lookahead. Higher codepoints require multiple 
bytes of lookahead. That means that for most parsing models any rules 
that require multi-byte stop sequences are quite a bit more complicated, 
slower, and for some parsing models impossible. So I'm hoping we 
can fix this.

Bo, did you ever work out why the smtp protocol has those issues 
on Arm?

No, I haven't had a chance to work on it yet.  Tomorrow's not looking 
very good for programming time, either.  Maybe Sunday I'll have a 
chance to take a look at it.

Question (not sure if this is the right group): do R3 tasks work, 
and if so, hwo to use them?

>> t: task [] [wait 2 print "Done"]
>> do t print "Go"
Begin Task
Go
>> Done
End Task

Tasks sort of work. They actually do start, but there are a lot of 
unresolved problems in the internals, and some of what is supposed 
to make them work properly hasn't been done yet, and some stuff like 
the synchronization and sharing models hasn't even been designed 
yet. So it's not really recommended that you use them yet.

Is this the expected / required result of a JOIN on two TYPESET!s?

    >> join to-typeset [pair!] to-typeset [integer!]
    == "pair!integer!"

I think so. Word! values turn into strings as well. You can use UNION 
to join typesets though.

Thanks....It seems odd though, given the different (and for me unexpected) 
results here:
    join  to-typeset [integer!] []
    join  [] to-typeset [integer!]

Yeah, sorry, the fake typesets in R2 are actually blocks. The real 
typesets in R3 aren't series at all.

I faked them well enough in R2 to use them in most cases in an R3 
style, but not well enough to make them fail to do the stuff they 
are supposed to fail to do in R3. Same with closures.

As long as your are happy.....Without looking at the code, I assume 
typesets in R3 are specialised bitsets.

Still, would be nice for the behavior to be a little more consistent.

They are specialized bitsets, so specialized that they fit within 
a value slot rather than being an external structure. But JOIN forms 
non-series, so they are consistent with bitsets in that JOIN does 
the same thing with them.

However, you can't use bitsets to fake them in R2.

Hi all. Is this an appropraite room for discussing an R3 patch?

appropriate*

Hi Marc! Yes, it certainly is.

Neat. Before I get to that: is task launching working on POSIX systems?

No.

Okay, good to know.

Right, here it is: https://github.com/0branch/r3/commit/5493e97c1afaa3848bf448cb49ccf03a1632302d

Hopefully the commit message is gives a clear explanation (and explains 
the motivation).

s/ is //

Brief restatement: BROWSE isn't working on OSX -- the current implementation 
tries two system() calls: xdg-open and x-www-browser

This patch uses /usr/bin/open on OSX, maintains the previous handlers 
on other platforms. In addition, I replaced the system() calls with 
fork+exec to avoid firing up another shell; one byproduct of this 
is that exec errors no longer print to the console (though this could 
have been hackishly solved by adding some redirects to the system() 
call string in the existing codebase).

Did you test this on Linux as well?

Not yet, can do so now.

Please do.

Firing up the VM, give me 5 mins.

No hurries :)

Look here http://issue.cc/r3/1921before you do this. Make sure the 
security constraints mentioned there are taken into account.

(Works on my Fedora instance.)

Thanks for testing that.

Basically: looks fine, thanks a lot for working on this.

BrianH: I don't think this change is an ideal solution, but it seems 
to be an improvement on prior behaviour.

If you can find a way to be more specific on OSX, so that _only_ 
URLs get handled, that would be great. OTOH, xdg-open is already 
rather versatile as well (only I fear that OSX's open is even more 
featureful).

One problem with the existing implementation is that xdg-open and 
x-www-browser are searched for in the PATH, so executables with the 
same names in a PATH directory that takes precedence will yield different 
behaviour.

Andreas: yeah, file:/// will open in Finder with this pathc.

patch*.

(So it's not constrained to the browser.)

That's the same with xdg-open.

Right.

Yeah. It looks like it just calls open, which can be a bit of a hole. 
It's better for now but we need to come up with a better solution 
in the long run.

Agreed.