World: r3wp

Brian its not a problem. My main concert for REBOL3.0 is about documentation.

Many discussion regarding R3GUI and REBOL3 Core happen here and they 
ar not reflected elsewhere.

We need a skilled person (surely it is not me) that mirrors everything 
to the main documentation.

However I would like a lot to wrap .NET objects and use them.

Is it possible to open UDP port under R3?

-_-;

Carl has forgotten...

An idea of NTP scheme, but servers comunicates only on 123 UDP port. 
overview of time services:

Daytime:  Ascii response,  Graham and Ladislav has written a scheme/tool 
already  port 13

Time: most simple possible server listening on port  37 answer 32bit 
unsigned number of second from 1-1-1900/0:00 (calculation of human 
readable date is not so trivial because of leaping seconds inserted 
to UTC with no rule at all, an Earth is dancing a Jive in fact)

HTTP: use inserted Date-time from any header returned from server 
port 80

SNTP: more precise protocol (contains also fraction of second in 
reply) subprotocol of NTP on UDP port 37

NTP: most precise available to compare more time servers, and calculate 
with computed transport delay and phase shift from evaluated couple 
of handshaking packets.  UDP port 37

The latter two use minimally 12  32bit binary packets for request 
and response, symmetric or asymetric cryptography possible (honestly 
I've no clue why this).

I've got a reply from NTP server via SNTP packet (RFC 2030) almost 
all nulls in client packet (in Rebol 2 UDP port, because it is not 
clear how to do it in R3)

BTW Steeve there is UDP definitions in header files of Host kit, 
so I think UDP should be possible somehow, but TCP scheme is hard 
coded (ie not available to play with other variants)

Say I have a huge file, there are some grabage bytes in its tail. 
How can I truncate it? Remove doesn't work on the file port.

Try CLEAR instead of REMOVE.

Thanks ChristianE. It works.

BTW the file couldn't be truncated from R3 I think (no func option 
available for this) but similarly as udp truncation is mentioned 
in c sources of host kit.

As mentioned by Christian and Jerry, CLEAR works for truncation:

>> write %test.txt to-binary "foobar"
>> print to-string read %test.txt
foobar
>> f: open %test.txt
>> skip f 3
>> clear f
>> close f
>> print to-string read %test.txt 
foo

Interesting

You'd think that would have to map to the ftruncate() operating system 
function

It does.

https://github.com/carls/R3A110/blob/master/src/os/posix/dev-file.c#L357

Good thing we implemented that in Syllable a few years ago :-)

I vaguely remember we needed it for Arch, and later for SaMBa

Ah, and at first I patched it away in Ruby in its build procedure. 
That was a long time ago

I've been away kids.  And the itch is back.  If my goal is embedding 
REBOL scripting in OpenCOBOL, do I dig into a host kit yet?  Can 
I access REBOL data from the C interface?   Plop REBOL data onto 
the stack?  Even bother to think about REBOL as an application extension 
language?  Umm, 64bit GNU/Linux.

Your absence was noted ... we had stand in go-go guys!

Go rebols (vote for doc) go!   ;)

Good to see you back :-)

You definitely need the host kit for those things. You'll have to 
use it in 32 bits mode for now

Then, I shall wait.  I'm still trying to convince the office to lean 
to more REBOL, but hassles on 64bit FreeBSD put paid to that plan 
so far.  The hassles were not insurmountable or anything, just enough 
of an annoyance to foster dissetion in the ranks.    ...  so far 
...

There should be very little problems with using 32 bits executables 
on 64 bits Linux

Well, installing lib32 compat on FreeBSD was the first thing to get 
everyone's kackles up.   ;)   My little propagation routines still 
get to run, but usage pretty much stopped at the first app, as I 
got the 'not so much REBOL' from the higher ups, (having seen the 
kackles - that was all it took)

But you want to use it on Linux, right? That usually comes with 32 
bits support installed

A better solution is to get rid of the higher-ups, of course

Our production servers are FreeBSD.

And, nah, I like my higher ups just fine.   :)

Right, but you just want to get started now, don't you?

The BMW has arrived now. Don't let it pass you by :-)

Too late ... for now ... I wrote the data shuffle code over a year 
ago.  And until I can show a hassle free install (by others), I don't 
want to push for REBOL training again.   When 3.0 gels a bit, I'll 
stop say ... for now ... and ask, now Canwecanwecanwe?   :)  It will 
come.

By that time, you'll still have to go through the same path of creating 
a COBOL interface

Oh, sorry Kaj, two different topics really.   OpenCOBOL is for fun. 
   Getting REBOL (not embedded, but full on REBOL apps) in the shop 
has been a slow starter so far.  Not out, just down. ... for now 
...

Yeah, that has been a difficult proposition for a very long time

I'm only now able to move from Ruby to REBOL myself

Kaj: "I'm only now able to move from Ruby to REBOL myself" ... what 
is the reasong/condition, which allowed you to move to REBOL? Just 
curious ...

I've always needed it to run on both Syllable and Linux. I finally 
got R3 to work on Syllable a year ago, but it had proved buggy when 
porting my CMS

Most things I still can't do with it, because there's no GUI

Then eventually, the open source issue will remain, because I can't 
use it for Syllable system tools

The lack of GUI means only web apps can be made, but there wasn't 
an acceptable web framework for REBOL

I used QuarterMaster in the past year, but I can't take that and 
Cheyenne with me now that R3 finallt starts working

Hence I'm forced to make my own CMS

And I'm forced to keep it working on both R2 and R3, so I can't use 
new R3 features

Not exactly a sales story, is it?

Is there anything like WAIT/ANY [3 read http://www.rebol.com]. It 
would either  return none if 3 seconds elapsed, or the content of 
www.rebol.com ?

as in a timeout?

I guess so. I think it has to be programmed by opening in async mode