World: r3wp

Louis: I solved ths by having a separate Rebol task running that 
manages the file in question. It's a simple databaseserver that accepts 
requests from various clients on a LAN using Rugby. Performance is 
surprisingly good.

The database server manages the data and writes it to multiple copies 
of the database file in rotation (to avoid loss of data on write 
on power failure) every 10 seconds if there are requests from the 
clients.

Anton, I'm using encmdface from the SDK.  I am writing to an object 
database.

Henrik, so the data from different computers is sent to your dbserver 
which saves the records one at a time?

basically yes

Sounds like what I am looking for.  Could you share the code?

I could... but I'm going out the door in a few minutes so it's going 
to have to be later this evening.

advice: Learn Rugby :-)

Yes, I did play around with Rugby a while back, but could think of 
any way to use it at the time. Now I have a use.

cound not

could not

Louis, I'm doing something similar as Henrik with a DB, I made in 
REBOL a couple of years ago. A REBOL task is listening on a TCP port 
and is handling the multiuser functionality. The clients could update 
the data in the DB themselves, or a task could do that too. My DB 
(NicomDB) isn't a product yet, but I could make it a product, if 
you're ready to pay for it?

isn't it a bug that start: now wait 5 print (now - start) returns 
zero?

pekr, it calculates date, not time difference that way. you need 
to:

start: now/time/precise wait 5 print (now/time/precise - start)

there is an interesting "bug" that way: you'll be shifted back 24 
hours if the difference is calculated across midnight.

it would be nice if it calculated the complete time and date difference

Use 'difference

ah... thanks

(but IMHO not particularly obvious)

You pick up these things by talking to people ... not reading obscure 
manuals :)

and then you write them down in wikibooks :-)

Geomol, let me see what I can do myself first. I like to know what 
is happening in my scripts.

Isn't this a bit strange?
>> 3 // 3
== 0
>> 3 // 2
== 1
>> 3 // 2.6
== 0.4
>> 3 // 3.4
== 3.0

Very!

yes, it is, try MOD and MODULO functions, if you need a different 
behaviour

Same behaviour:

>> mod 3 3
== 0
>> mod 3 2
== 1
>> mod 3 2.6
== 0.4
>> mod 3 3.4
== 3.0

right, in these specific cases, otherwise the behaviour may differ.

what would did you expect to get?

I guess, I was just surprised, that it worked with decimals. Then 
it can maybe be argues, if 3 // 3.4 should return an integer or a 
decimal.

argues = argued

the definition is as follows: if r = a // b, then a - r // b should 
be zero

Been thinking about it too....It is surprsing, but does make sense.
It's returning the remainder:
3 // 2.6 --> remainder is 0.4
3 // 3.4 --> remainder is 3

other formulation: if r = a // b, then a = some-integer * b + r

In rebcode, I guess the upcode rem is remainder. It works a little 
different there:
set a 3
rem a 3

now a is 0. If doing this:
set a 3.0
rem a 3

then a is 3.0.

I guess, it has to do with the internal floating-point representation 
of numbers.

rebcode's rem does *not* support decimals.

will it be possible to do easy types conversion with rebcode? regard 
me being stupid, but I regard following being  bug or at least inconsistence:

type? #{77}
== binary!    ; so no excuse it is a string later!

to-integer #{77}
== 119

to-binary to-integer #{77}
== #{313139}

If pure functions which serve datatype conversion work one way, it 
is imo inconsistent that it does not work the same way in the reverse 
mode ....a

If you want to convert a number to binary, number must be enclosed 
in brackets, to binary! [119] , not to binary! 119

so your example should look like:

to binary! reduce [to integer! #{77}]
== #{77}

we are not converting here string of "119" values, but integer!

why?

that's what's written in documentation

I don't know the reason

And you cannot convert numbers bigger than 255

I said no excuses or silly walkarounds. We are converting integer. 
Take your calculator and look how it converts it ;-)

to binary! [256]
== #{00}

This is not a workaround, that's in the documentation :)

Kru - interesting example with integer in the block, but even more 
twisted imo :-)