World: r3wp

btw it's really strange.. I would thought that that's a basic thing. 
To be able easily define a string.

Some compilers might be.

Usually, MSVC is the problem, in such cases.

C90 requires compilers to support _single_ string literals (i.e. 
one quote "...") of at least 509 characters.

(C90 ~= C89 ~= "ANSI C")

C99 raides that minimum to 4095 characters.

And MSVC doesn't support C99.

Then there's also a limit how big concatenated strings can get (i.e. 
"..." "..." "..."). Which is 65k in MSVC, IIRC.

So, if you don't do extremely long lines and a 65k+ init string, 
you should be fine with string literals even in MSVC.

Which is why I don't care either :) String literals ftw!

Btw, here's my variation of a header generator script:
https://github.com/earl/r3-zmq/blob/master/make-ext-header.r3


It has the nice advantage that it automatically generates a dispatch 
table for your commands, enabling a clean and concise RX_Call like:
https://github.com/earl/r3-zmq/blob/master/zmqext.c#L31-35

For example, take the zmqext extension specification:
https://github.com/earl/r3-zmq/blob/master/zmqext.r3

This is the header file generated by above generator script:
https://gist.github.com/e22a35049ae56324004a

rebol.org the script library is so well done that everyone use github 
:P.

I vaguely recall that someone was working on ODBC support for R3. 
Did that ever become usable? Is there a link to this work?

http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html

Thanks! I've been using R2/Command to do the database access and 
R3 to process the data. All in the same script, using a trick I'll 
post to the Windows group.

There's a couple bugs in the REBOL portion of the ODBC extension 
mentioned above. I'll try to make a patching wrapper module.

This module loader for the odbc.dll extension handles the bug in 
its open handler that prevented it from using block specs with a 
target:

REBOL [
	title: "ODBC Extension Patch"
	type: module options: [private]
	needs: [%odbc.dll]
]

odbc: import 'odbc


system/schemes/odbc/actor/open: func [port [port!] /local result] 
bind [
	port/state: context [access: 'write commit: 'auto] 

 result: open-connection port/locals: make database-prototype [] case 
 [
		string? select port/spec 'host [ajoin ["dsn=" port/spec/host]]
		string? select port/spec 'target [port/spec/target]
		'else [cause-error 'access 'invalid-spec port/spec]
	]

 all [block? result lit-word? first result apply :cause-error result] 
	port
] odbc

Unfortunately, there's an error in its fallback behavior that makes 
it a bit difficult to use. In its docs, section 3.7:

 If there is no applicable REBOL datatype to contain a SQL value, 
 the value will be returned as a string.

The binary data is returned in a value of the string! type, rather 
than of the binary! type, which results in a corrupted string that 
you can't do anything with. If the value was returned as a binary 
then we could perform the conversions ourselves. I ran into this 
problem when returning SQL values of the tinyint and text types.

I love the method for triggering errors from the native core though 
:)

core -> code

It just occured to me that the import statement above could have 
potentially unwanted side effects on the user context. Replace this:
	odbc: import 'odbc
with this:
	odbc: import/no-user/no-lib 'odbc

I love the method for triggering errors from the native code though 
:)

 - Brian, can you elaborate on this? I'm interested in what you there?

The method is pretty simple. Normally the functions return data in 
a particular format. Upon an error though they just return a block 
with 3 elements, the first two of which are lit-words, the last could 
be anything; this is passed directly to apply :cause-error. The error 
block can be recognized and handled easily with this code in the 
REBOL functions that wrap the natives:

 all [block? result lit-word? first result apply :cause-error result]


It's similar to the way error handling is done in the low-level sys 
load functions, particularly sys/load-header. Upon an error, instead 
of a block the function returns a word! value, which can be passed 
to cause-error by the calling function, using code like this:
	set [hdr: code:] load-header/required data
	if word? hdr [cause-error 'syntax hdr source]

Word values are easier to handle safely than error values. Note that 
the argument provided to cause-error in this case is different from 
that provided to load-header: This lets you trigger errors with information 
that load-header isn't provided, giving your errors more context 
that is useful to the programmer. Not exactly the same thing as the 
ODBC driver, but close.