World: r4wp

dunno. Just want to avoid R2 mess with binary vs string conversion, 
etc.

We did a lot in R3 to clean up binary vs. string conversion. There's 
probably more work to do, but it's a good start.

I know, so I hope Red follows R3 model :-)

The one thing R3 was bereft in was custom conversion functions. We 
had some ideas, but for the most part didn't get around to implementing 
them.

do you mean codecs?

Well, that too, but I more meant a better replacement for that awkward 
struct! conversion hack in R2.

Hello, I want to use a local database whith no concurency for aor 
the moment I see ndb indexed btree from Dockimbel, another alternative 
is possible and what ca be used  with the future red ?

at the moment there is a Red/System binding to SQLite. But that's 
for Red/System. I would probably wait, till higher level Red is more 
feature complete in upcoming 2-3 months ...

Daniel: welcome! The best choice so far would be SQLite for such 
usage. We might reuse lower level parts of SQLite to build our own 
storage system specifically designed for Red.

Yes, SQLite is a good candidate for that imo. Right licence, relatively 
small, performance is good.

OK, and also dispo in android I think and bbrerry os...

well, as for BB 10 - we should get there imo - QNX based, old Amiga 
friends :-) And maybe it is good to support lower market, than crowded 
iOS developer's base? We will see ...

That will be very good, shure ! :)

We'll spread wherever possible! :-)

If you're thinking of adapting the lower levels of SQLite for our 
use, start with SQLite 4. It's much better suited for that kind of 
thing.

What's the status of that?

All I know is here: http://www.sqlite.org/src4/doc/trunk/www/index.wiki

I suspect that it's in alpha. Still, just due to the system structure, 
even an alpha version would be easier to adapt than the stable SQLite 
< 4.

It is structures as a NoSQL-style key/value store with a SQL engine 
on top. We can put our own engine on top.

We might even be able to implement the API that the storage engines 
plug into, which would allow us to use the storage engines unchanged.

Brian: that last shortest path might be the first thing to try.

Agreed. And it will be easier to keep an API clone updated for future 
SQLite changes, so we can get the benefits of future improvements 
to the storage engines.

SQLite already went through the trouble of extracing and abstracting 
their storage engines, so it's best to reuse their work :)

We certainly have better ways to spend your time than debugging SQLite 
internals, so keeping the same SQLite codebase subset seems the right 
thing to do.

Well, what I would like to see is the ability to have one file per 
table, without artificial limits like having to attach databases, 
to some artificial number of 9, or what was the limit. Second - SQLite 
4 to have encryption storage option ....

Also some record level locking would be nice to have ...

If you want one file per table, pick another engine. For the rest 
of that stuff SQLite is OK.

Yes, it would really help to more easily backup at the file level 
- not just one monstrous file each time, but certain tables ...

there is no other option to SQLite, other embedded databases are 
either not free, or don't use SQL syntax (e.g. mySQL)

With the SQLite 4 storage engines you don't necessarily even need 
tables at all - it's a key-value store. Even SQLite recreates the 
table metaphor on top.

big change in their paradigm. And the one, which fits imo REBOL. 
IIRC Carl always wanted some stronger storage option to load/save 
blocks. IIRC Rebin was needed? He once was considering adding SQLite, 
but found it too big. IMO it would be good if we used SQLite for 
Red, to standardise. I doubt we can find more efficient, powerfull, 
and cross-platform tool with the right licence? Of course more efficient 
solution might be done by pure Red facitilities, but unless we need 
really extra efficient solution, why to reinvent the wheel?

The big advantage of SQLite over other similar engines is that it's 
bundled already in the main mobile platforms (Android and iOS).

MySQL doesn't use SQL syntax?

Kaj - last I checked it was long time ago. It did not use SQL syntax, 
and was not even free IIRC. But I don't follow mySQL for many years 
now ...

Doc - right - that is also important, that the engine is being present 
on such platforms ...

It was always a GPL SQL database, but people complained it didn't 
support as much as, say, Oracle and PostgreSQL

Well, if using an unmodified engine that is already installed is 
the goal, SQLite 4 is out.

Just give it time

Hi guys - I am trying out Red/System and all seems very good until 
I try out Kaj's fibonacci and mandelbrot functions. I downloaded 
the c-library -sorted the paths and locations and tested the library 
on simple things and all compiles well. When I try to compile fib 
and mandel I get the following compilation error:

>> do/args %rsc.r "%tests/mine/fibonacci.reds"
Script: "Red/System compiler wrapper" (none)

-= Red/System Compiler =-
Compiling tests/mine/fibonacci.reds ...
Script: "Red/System IA-32 code emitter" (none)
*** Compilation Error: alias name already defined as: [str
uct! [
        item [c-string!]
    ]]
*** in file: %runtime/common.reds
*** at line: 61
*** near: [
    str-array!: alias struct! [
        item [c-string!]
    ]
    typed-value!: alias struct! [
        type [integer!]
        value [integer!]
        _padding [integer!]
    ]
]

Any suggestions as to what I am doing wrong?

Most probably the binding was not tested for quite some time, and 
Red + Red/System evolves, so there might be some regression there. 
Better wait for experts, though ...

Ken: thanks for giving it a try. We might have left these two scripts 
lagging behind. Anyway, you'll have that fixed during the day (the 
good side of having a fast pace). ;-)

Go Doc, Go! :-)

Thanks guys, for the speedy replies

Doc, I think the work you are doing is superb and Red is a very exciting 
project - thankyou!

I test the bindings and examples regularly, so they should work. 
I'll check, but which version of Red/System are you using?

I am using the version downloaded from Github a couple of days ago 
"v0.2.6-39-gfc5c4a3"

Both the Fibonacci and Mandelbrot examples work with the current 
dyn-lib-emitter branch of Red/System, and I tested them for the 0.2.6 
and 0.2.5 releases, so they should work there, too

Did you install the extra Red-common Fossil repository that the C 
library binding now needs? (See the Announce group here)