World: r4wp

Still, all of that can be added on or retrofitted, that's the whole 
point of being modular. Having them implemented and available before 
3.0 would be a good idea for marketing reasons (don't knock those, 
they're important), but not having them done before 3.0 won't break 
user code the way not doing core semantic changes before 3.0 would. 
People will be working on these before 3.0 comes out because they 
need them, and the ones that we as a community consider to be the 
most important to include in 3.0 will likely be worked on the most. 
But the great part about that stuff is that it doesn't have to be 
developed as part of R3 itself, just like the GUI is being developed 
separately.

Personally, I want to work on the database support because that is 
what I need the most and have the most experience with. I expect 
that others will need networking stuff more, and yet others will 
need CALL or a better console.

The situation is the same for Red. Kaj or anyone other maight claim, 
that we have CURL networking. But for me, that is not the REBOL I 
want. I want port/schemes abstraction, period, or it is not REBOL 
like environment for me. It does the job, but so does ASP .net. You 
are one of the top developers for R3. I want you to know my opinion 
(maybe I am alone feeling that way, and that is fair enough), so 
- let's use what defined REBOL - ports as an abstraction mechanism, 
schemes upon that, etc.

I agree with BrianH, and I also can see where Pekr is coming from.

I'm not a C developer, so I don't feel like I can do much to add 
to the sources of R3.  However, what attracts me to Rebol, and what 
makes me want to use Rebol, is that I can do just about anything 
with relative ease.

<Complete package ...etc> It's interesting that the fact that REBOL 
would have many schemes was part of the original vision / marketing:

   http://web.archive.org/web/19980530155104/http://www.rebol.com/news.html

There is no such thing as a complete package anymore. Things are 
changing too quickly, and in too many directions. People need the 
stuff they need, and they need to *not have* the stuff they *don't* 
need. There are too many completely different platforms now. We can't 
afford to be monolithic anymore, since that will just mean that we 
won't be compatible with what most developers need to do, since most 
developers need to do stuff that is incompatible with what most other 
developers need to do.

Bo - do you remember first CID? Predecessor of VID? I can remember 
small script, which was showing image from 4 webcams, in rudiculously 
small script. That was - rebollish :-)

For instance, most developers need to have support for either SQL-like 
databases, or NoSQL databases (according to many different data models), 
or both, but they are not compatible with each other even in theory 
once you get out of SQL world.

BrianH: well, as for many scenarios, I can accept SDK like environment, 
where I choose, what to include, but for some ppl, some R3.exe should 
exist, which should contain some agreed upon functionality. If we 
go just with the opinion of let's have bare bone core.exe, and the 
rest via some includes, that scares hell out of me, really. That's 
like other languages, loosing what made REBOL rebolish.

Nope, I want an includes-everything-reasonable prebuilt interpreter, 
even if a lot of it won't actually be loaded by default until you 
choose to import it (from inside, we have delay-loading). But that 
will just be one (official) set of applications made with the greater 
application construction kit, like the R2 SDK.

Pekr: I think what you are proposing is something that any user could 
put together and offer to the community, using what BrianH proposes 
as the foundation.

Just because it's modular doesn't mean it can't or won't be bundled, 
and in many cases imported by default. We can do one-exe builds with 
modules inside, that was the point from the start.

Pekr: I seem to remember programming that webcam demo.  I could be 
wrong, but I know I programmed *a* webcam demo pre-VID.

Those one-exe builds can keep improving forever, especially after 
3.0 comes out. The only thing that *absolutely* needs to come before 
3.0 is any significantly breaking core language semantic or syntactic 
changes. Everything above the core language can keep evolving indefinitely.

BrianH: re delay loading - I remember the various interpreter phases 
- was that implemented, or just defined by Carl?

Mandated by Carl, fully implemented by me in alpha 109.

Actually, implemented earlier than that, but Carl had me redo the 
module system in 108 and that particular feature wasn't fully reimplemented 
properly until 109.

So we've had it for years, but it wasn't until Andreas fixed RESOLVE/extend 
in the first week after the open source release that people could 
use modules properly.

The question of what to include by default is never easy, but can 
be guided to some extent by what is not just popular, but also has 
a well-defined standard that is useful. e.g. HTTP and FTP are standards, 
No-SQL is not. SQL92 is a standard, but is a strict SQL92 dialect 
useful?

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