World: r3wp

...people are used to constructors and destructors

 - that has nothing in common with automatic delegation, though, at 
 least I feel it that way

Well, we were only wandering, discussing about how things could be 
done. There were no complaints in such.

In fact, there is complain. My whish is to read a statement from 
Carl to undestand which advantages he sees and the phylosophic choices 
made for REBOL.

*there is NO complain

Regarding the: "...why automatic delegation is ... not used in REBOL." 
- that looks as a question I could answer, though. Reasons (as I 
see them):


* the present system of independent objects is safer (no need to 
worry about somebody changing the prototype used to define your object)

* the present system of independent objects is simpler (no need to 
worry about such things as multiple inheritance)

There may be other factors as the ease to implement such a feature, 
or the speed of the interpreter, etc.

Ladislav, I have another question: why there are no SET/GET accessors 
in REBOL objects ?

SET works with objects in R3 (if that is what your question was about)

Similarly for GET

(may be handy)

How ? Could you make an example ?

>> o: make object! [a: 11 b: 12]
== make object! [
    a: 11
    b: 12
]

>> p: make object! [a: b: none]
== make object! [
    a: none
    b: none
]

>> set p get o
== [11 12]

>> p
== make object! [
    a: 11
    b: 12
]

(It was not the question, I guess)

In fact, it was not the question.

I mean as GET the automatic function called by an object  to return 
its value..

using the path notation ?

(back the topic)

There was a lenghty discussion in OTHER LANGUGES from 3rd of MAY 
of this year.
It led to http://www.rebol.net/wiki/Objects_enhancements

Giuseppe, part of the reason that there are no set accessors (what 
I called "properties" above) in REBOL is that there are no classes 
either, so such accessors would need to be defined on a per-object 
basis. This makes them quite a lot less useful. The other part of 
your question is that we *do* have get accessors: We use the same 
syntax for variable getting as we do for function calls, so you can 
just assign a function to a word and it will act like a get accessor. 
You only need real get accessors in a language that puts parens around 
arguments or in some other way distinguishes function calls. However, 
let's for the moment assume that you mean get-word accessors, functions 
that will still be called even if you use the GET function, a get-word 
or get-path to access the value.


But one of the main reasons is to avoid hidden unexpected overhead 
and security issues. Assignment is fast in REBOL, because it does 
basically the same thing every time (with some variation in set-path 
assignment). If we had properties, that would add overhead to every 
single assignment statement whether to a property or not just because 
we would have to check for that every time. In languages with native 
properties their compiler makes this determination and generates 
the underlying function calls. With REBOL that overhead is at runtime 
because we don't have a compiler. We could compile our own dialects 
to make set-word accessors - Gregg's COLLECT, or R2/Forward's APPLY 
or MAP-EACH do this - but it is slower.


The security issue is that at the moment assignment and get-word 
access is safe. Set-path assignment and get-path access is at least 
safe with the built-in datatypes. Accessor assignment is not safe: 
it can have side effects or unexpected overhead. If we had accessors 
then you could not safely use words that you got from unknown locations. 
We wouldn't even be able to screen for functions, which a lot of 
the mezzanine code does now. Combined with get-word arguments and 
that means that there would be no way to avoid code injection exploits, 
and thus no way to make even a secure subset of REBOL. 


Now with path syntax the behavior is (apparently) type-specific, 
so with the appropriate datatypes we can do accessor functions; .NET 
object wrappers would benefit from this, for instance. But that requires 
utypes, because there is no point to making built-in types have that 
behavior. Then for security we could just disallow utypes from a 
function that might otherwise be exploitable.

Ok Brian, I have understood.

Somethimes I think that we should add this clarifications to DOCBASE 
for further referencing.

I suppose Utype will be address sometime in the future.

It's planned, but not likely to be in 3.0 afaict.

There is a placeholder type and a lot of the constraints it will 
have are known already because we already figured it out (no literal 
syntax, for instance).

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)