World: r3wp

Sadly no Win7 here, testing system is deleted ....

BrianH: are you going to incorporate your module changes now? :-) 
Or waiting for some answers, regarding extensions first?

I am going to wait for answers to the questions in R3 chat #5126 
to finalize my changes. I've already worked out the integration, 
but a few policy/informational matters need to be addressed.

Just tested Sunanda's number on Win7 64bit - same error as Vista. 
Reasonable to assume that Vista 64bit is the same.

Some of my module changes involve shuffling code from one function 
to another. It's possible that Carl's added code in IMPORT should 
be moved to LOAD, for stability and flexibility. I also integrated 
extensions into the module checking and override model, but need 
to know whether there will be problems with doing LOAD-EXTENSION 
more than once with the same extension (necessary to see if it is 
already loaded).

BrianH: what are options to get e.g. SQLite driver running? If I 
understand it correctly, you can 1) include C source code of SQLite 
into your extension 2) wrap SQLite DLL from your extension ...

You can also statically link SQLite into your extension DLL, and 
just export your extension wrapper code, or the whole of SQLite if 
you want to do the trick like tclsqlite or System.Data.SQLite. The 
real trick is making a proper database access model that fits into 
R3. This might be tricky with extensions v1 because we don't have 
device support yet.

With extensions v1 it's much easier to make a compiler than it is 
to provide SSL or database access.

Really? Why?

If you look into R2 SQLite driver, then it is scheme around few calls 
to wrapped DLL functions. I am not looking for something more. Lack 
of DB drivers is what imo holds guys back from turning into R3. There 
is less and less reasons, to use R2.

I thought I'd need user-defined function types to make a JIT compiler, 
and those are much further down the road than devices. It turns out 
tthat the command! type is sufficient, today. I could start adapting 
a JIT next week.

So I just thought, that as an excercise, someone could "port" the 
SQLite driver, even if architecture might not be ideal. Why Device 
should be needed here? I know it would be better to be async non 
blocking, but we did not have it with R2 either, no?

what? Really? What kind of JIT would it be? What exactly would be 
"jitted"? I don't expect normal REBOL code here, but some kind of 
limited dialect?

In R3, async non-blocking is essential - in R2 it was optional.

So you think that next logical step for RXI is to support device 
model?

Yes.

What needs to be done here? Carl making some low-leve exposure of 
Device commands to RXI interface?

OK, then push Carl to go that way :-)

The problem is, that both Device and RXI models are not much practically 
tested, no? Or does R3 uses Devices internally already for IO?

I'm not sure how devices will be integrated, but know they must be, 
and soon. R3 uses devices internally and  they work great. The trick 
is integrating devices with plugins.

there is no spoon
 ... :-) there are no plugins, just extensions, RXI for short :-)

Google tries to propose unified way for browser extensions. I wonder 
if R3 could become such an extension, if we would benefit from such 
situation? Probably different model than having browser plug-in ...

I've traced through the RX code (there isn't much of it - extensions 
are *simple*). It's a great model. I have a few low-level questions 
and one or two requests, but the overall model is pretty solid. There 
are GC considerations that still need addressing though.

Google browser extensions are written in Javascript - if you want 
to use REBOL, you'd either need to compile to Javascript or be a 
plugin (which is supported by Chrome). The closest thing in R3 to 
Google's browser extensions is the module!.

Have you looked to the LUA model? I posted you a link privately - 
seems similar ...

What? I read some topic called - Google native extensions ...

As for the JIT, I could write the compiler in REBOL and generate 
the intermediate code of the JIT, then pass that intermediate code 
to the JIT with a command. The JIT would then generate a function, 
add it to its list, and return the list index as an integer. That 
integer can be  used to create a new command!, which RX_Call can 
dispatch to the internal JITed function.

Since extensions can't be statically linked with R3, I can wrap a 
LGPL JIT like libjit. It should work great. I'll be stuck with the 
RX data model, but that cold be plenty for the types of functions 
you wold write just for speed.

So we've got Rebcode replacement? :-)

What, did you think Carl was going to be the one to replace rebcode? 
:)

Sunanda: I get invalid integer too under XP under VMWare.

no, it is just the damned thing is possible finally :-)

Henrik, yeah, XP seems to do the right thing, throwing an error - 
it's only Vista and 7 that fail and return the wrong number.

a 64-bit issue?

OSX reports bad numbers too instead of invalid integer.

under a76, that is

Not a 64bit issue, a Vista+ issue.

I wonder about Linux now too, unfortunately I can't test.

Anton, did you miss the "I'd rather" part? Did I say "Robert should" 
or even "Robert must" anywhere? LOL. :) I even suggested syntax, 
#[{ ... }]# though I don't like the idea at all.

Brian, how likely it is that you will find the three characters }]# 
in JSON text?

Gabriele, I probably worded my last comment a bit strongly. (I don't 
want to enflame the situation..) Of course I highly value your judgement, 
opinions and suggestions. I should say, though, that I read your 
previous comment as somewhat dismissive of RobertS concerns / problem.

With your #[{ ... }]# suggestion, I think it looks pretty good, and 
could be extended with specification of an end delimiter. With so 
many computer languages of all different syntaxes, having a way to 
specify the delimiter allows it to flex to any situation. 
We could add a second string to the block, eg.
The end delimiter is END:
	#[{END} {... END}]#
or a simple newline char:
	#[{^/} {... ^/}]#
or a secure hash:
	#[{92838929838} {...92838929838}]#

The R3 docs for extensions display an example for reversing a string. 
I wonder if it's the same code as used internally for the built-in 
REVERSE function?

I see that the en wikipedia has an article on verbatim strings in 
PHP under "here document" which in PHP documents for print and echo 
is acalled the "here document" syntax (of course PHP calls print 
and echo constructs and not functions or procedures ... ) http://en.wikipedia.org/wiki/Here_document

My PHP page has no escaped characters becuase I can use the so-called 
"here document syntax".  That is critcal for my templating needs. 
 If your templating will only be done by rebol developers, it is 
of course a moot point: Rebol developers do not need heredocs/  But 
are all users of rebol going to be rebol developers?  That is the 
dialect issue.  And in the case of PHP (jsut an example) many PHP 
users are not PHP developers.  The wiki page has examples from python 
or ruby if the mention of PHP offends purists .. ;-)

not to vex, I hope, but I just saw that PHP 5.3.0 added so-called 
"now docs" which are what I call literal strings or verbaibm strings 
in that no substitiutions occur so no escaping is done.  I believe 
this how at least comment {should behave in R3 if I use a { as in 
just print {this} { to get the effect you want }  which comment is 
not the same which has to explain that you do whis without the escapes 
- which is fine if thosei are the only and very  escapes in question 
...

The PHP restriction on HEREDOC and NOWDOC is that the closing identifier 
( a label, if you like) must appear after a nl and there must be 
ONLY a nl immediatly after its ; terminator  - a restriction  which 
seems not at all onerous in practice now that I am using them

In Firebird's sql language, we can specify the delimiter and then 
restore it  after dealing with a bunch of code/text.

Wouldn't that be more useful?

It would.