World: r3wp

There is no standard I know of for mapping data to faces. A number 
of us have rolled our own systems over time, each with our own critieria 
and design aesthetic.


As a simple starting point, consider setting up declarative mappings 
and driving a data-exchange loop. e.g.

face-field-map: [
    lname 2 fname 3 spouse 4 
    email 5 hphone 6 cphone 7 
    addr 8 city 9 state 10 zip 11
]

foreach [face-name field-index] face-field-map [
    set-face get face-name  pick db/:counter field-index
]

Thanks Gregg, as a newbie I was just trying to get an idea as to 
how others are handling this.  I was thinking that there had to be 
a more concise method than the one I was using.

--

You can use rebsqlite with core on windows (it allows dll inclusion) 
but how can you use it on linux? It seems linux rebol doesn't allow 
.so . I used rebpro which does this but now I also need to send an 
email from it and it gives me some strange message "Set-Net not provided."?


Maybe I am doing something wrong/using the wrong tools... how can 
you use rebol with sqlite on linux??

(I have bought SDK btw .. but I don't know for what reason I bought 
it for windows(?!?!!), where I really don't need it so it doesn't 
help me at all in this situation)

hm.. is license transferable between linux/windows or some discount 
for another if you bought the first one?

I am not sure license is transferrable, but license is just one file 
- try to copy it to linux machine. If it is legally OK, I don't know. 
But - I would probably ask Carl ...

IIRC, the latest SDK purchase gives you a license for every platform. 
 might be worth upgrading (50$ is like not going to restaurant once... 
your wife/girlfriend will get over it  ;-).

I don't see it mentioned anywhere that this license / upgrade is 
multiplatform. The select box is the same as before where you choose 
the platform. I have no problem giving $50, but I am running on fumes 
here and $350 shows on my account, especially if I am don't need 
it really, because rebol core/view on windows work with rebol sqlite 
and I haven't seen anywhere that linux version has different logic.

yeah the website seems to indicate that we still need to buy each 
license separately.

(I will gladly buy all rebol versions in existence when I can afford 
it)

hm .. maybe access to dll/so is available only to view and not core. 
and because I use core (cmdline) on linux server it doesn't work

rebpro is the one with dll.

Yeah, for now /Core doesn't have /Library. /Pro does, and can be 
encapped to resemble /Core with /Library; that is the only difference 
between /Pro and /Base.

/View (free) also supports dll-s for very long time now

I really wish Carl would release the various reb*** builds outside 
of the SDK.

they are very usefull as-is, even when not encapping scripts.

Yes, /View/Pro is now free and called /View.

I actually bought /View/Pro back before it was free.

Maxim, the SDK is useful as-is too. That's why people pay for it. 
Don't knock the business model :)

aha, I tried is. it's not that windows supports dll-s and linux not 
but the view does and core doesn't. I guess I am gonna have to buy 
the linux sdk also.

Brian, do you know what's the trick with "Set-Net not provided." 
in rebpro?

I would guess that you have to include %prot-setnet.r in your script 
to use it.

Brian: huh.. I see now I made typo when making file that do-es all 
mezz and proto files .. if I load it correctly set-net works!

Yup. And (on Windows at least) set-net is by default that "Set-Net 
not provided." function in /Base, /Pro and /Face, on purpose. The 
only reason that function is in the encap bases at all is because 
it is called in the startup code of /Face.

thanks, I have one problem less now

Rebol and DSL's are hand and glove. Is there a SQL dsl anywhere? 
I found the driver from dobeash. Is there more?

I'm not sure if that would be worth the effort, SQL can get fairly 
complex and if a REBOL SQL wouldn't implement everything (even specific 
databases prorietary extensions to SQL) that wouldn't be a noticable 
gain in simplicity. Wouldn't it still just be SQL written in REBOL's 
syntax? Actually, I think it's more like SQL already is a perfect 
example of a DSL on it's own (not implying here that SQL is perfect, 
just the example is).

I found this: http://www.rebol.org/documentation.r?script=sql-protocol.r

And this is a snippet:

do %sql-protocol.r
    db: open sql:my-db
    insert db {
        SELECT * FROM a, b
        WHERE a.c2 = b.c1 AND a.c1 = 1
        ORDER BY 1, 2 DESC
    }
    foreach item copy db [probe item]
    close db

Isn't this better than working with strings?

see also

http://www.rebol.net/wiki/R2_projects

I have a REBOL/View application where I am doing SQL calls in a face 
timer to update the face. I am having an intermittent issue where 
the result of one face's SQL statement is showing up in another face. 
I am doing a copy of the result set based on what I've read in the 
Dobeash docs.


It appears that the face timer code blocks and another timer event 
occurs and does a SQL call. Does anyone know how to make a timer 
function finish before another one triggers? I may also be using 
the driver incorrectly.

can't you queue your sql queries?

For now, I've wrapped the SQL calls with "busy" flag logic and that 
seems to work -- but it is a hack. The fact that a SQL function call 
inside a face timer event returns a dataset from a different face 
is shocking to me. REBOL should handle this properly in the background. 
My mental model of single-threaded event handling (rooted in classic 
VB) leads me to believe that this is a bug.


In addition to returning data to the wrong face, the SQLite shared 
object will also sometimes seg fault. It working fine now, though, 
with my busy flag hack.

It does sound like a bug.

Best way to get it looked at / resolved is to add  a bug report to 
RAMBO (the R2 bug database):
    http://www.rebol.net/cgi-bin/rambo.r

OK. Thanks.

I'm not clear what the issue is .. do you have different sql queries 
being triggered by timer events on different faces?

Anyway I use asynchronous database queries and have never seen this 
issue.

Graham, yes, I am triggering queries using timer events, and the 
sql results are being returned to the wrong calling function. My 
classic VB way of doing things doesn't work. How exactly are you 
doing your queries? Putting them in a queue to be serviced by a single 
function? For me that would also require including the face, so it 
can be updated when the sql call completes.

Here is Gabriele's response to my bug report (RAMBO ticket # 4411)


This is not really a REBOL bug. The SQLite driver is doing a WAIT 
1 in the DO-STEP function; calling WAIT inside an event handler (such 
as a face's timer event) is not really supported by REBOL and should 
be avoided. If you can't avoid it, you must be prepared to handle 
other events happening during that WAIT call, and you need to be 
very careful with blocking requesters (SHOW-POPUP, INFORM etc.) as 
they're likely to mess things up (they call WAIT as well).

My suggestions are:


1) File a bug report with the SQLite driver. There needs to be a 
way to avoid the WAIT, though I guess this is going to be complicated 
in R2.


2) Disable other events while you're using the SQLite driver, eg. 
clear SYSTEM/PORTS/WAIT-LIST and restore it afterwards.

3) Use a "global" flag like you're doing.

-Gabriele

Gabriele, when you say "clear SYSTEM/PORTS/WAIT-LIST", do you mean 
setting it to NONE temporarily?

I think he means storing the contents in another var temporarily, 
using CLEAR on it, then restoring the original contents using INSERT 
or APPEND.

Yes, as I use callbacks on all my sql calls

As Gregg said, it still needs to be a block! otherwise WAIT will 
complain (IIRC).

most likely, you'll only have the event port in the wait list, so 
it's just a matter of removing it and adding it back later. I can't 
guarantee this works 100% because I haven't tested it.

another alternative could be:


4) don't use face timers, but rather replace do-events with something 
like:

    forever [
        wait 1
        do-your-sql-calls
    ]


You'll still have other events happening while you're doing your 
sql calls in this case though, not sure if that can be a problem. 
The cleanest solution would be to change the driver so it does not 
wait, but I don't know SQLite so I can't say how easy that would 
be.

Thanks everyone for your explanations and suggestions.

There are several sqlite drivers ... are they much the same?

Also you could try opendbx which doesn't use 'wait

and has a driver for sqlite I think

http://rebol.wik.is/index.php?title=OpenDBX&highlight=opendbx

Thanks, Graham. I'll take a look at that option.

ty