World: r3wp

Have I read the blog correctly ? SSL ODBC and encryption added to 
REBOL/View Standard ? This is a nice news !

Indeed, a "YAY!" is in order :)

What is a YAY ?

A cheer. Your team just won, Yay!

I have to use 


call/show "cmd" to see the shell .. is that the expected behavior 
these days?

Yes.

That was a 2.7.6 change Graham. It bit me, so watch out.

Yes, I knew that and I wondered if we were going to revert back to 
the 2.7.5 behavior.

My recollection was that it was always just call until 2.7.6 ..

I campaigned to have it changed when it happened, but I think I've 
ported all my active code to the new syntax now, c'est la vie.

me too

Sorry, the 2.7.6 changes are sticking. In terms of functions that 
have affected existing code, that means the changes to CALL and EXTRACT. 
We're trying to be more careful in the future, but we're mostly concerned 
with compatibility with the previous version. If you have a favorite 
app that needs to keep working, get involved with R2 development 
and testing.

R2/Forward will be trying to backport as much of the current behavior 
as we can to versions as far back as 2.5.0.

Changes to natives are tricky to backport, so CALL is unlikely to 
be fixed by R2/Forward. I suppose that's alright since no platform 
for which 2.5.0 is the current version supports CALL anyways. C'est 
la vie.

Steeve, how's the R2 chat gui going?

Actually, the GUI can get started before the API is - the semantic 
model of DevBase is pretty well set already.

Agree. The project can be separated in two task.
- Working on a gui

- Refine the current chat app to extract a bunch of usefull functions 
(app API).


Idealy it should be 2 separated apps, so that we could write different 
GUIs for the same app.

what about   "dt"  function in Rebol 2.78?

dt: funct [
    {Delta-time - return the time it takes to evaluate a block.}
	block [block!]
][
    start: now/precise
    do block 
    difference now/precise start
]

Yeah, that's likely.

are there any docs about encription functions that are now enabled 
in view ... I could find some rsa-* and dsa-* functions by trying 
in console

http://www.rebol.com/docs/encryption.html

Do you know if the released /View has the "export version" restrictions 
mentioned in the docs, or whether it has the full encryption?

Nevermind, found it, full.

I'll whine quietly again about the name DT. <whine>

I agree it should have a better function name.

thanks doc, I swear I was googling for rebol encryption but didn't 
find it

Hmm... could be mistake there on export vs full. Will need to investigate 
that. Should be export by default. So, don't depend on full for anything 
until we can verify, which may not be easy to do.

On delta-time (dt), I tried to use it in R2 yesterday... Well, next 
time. G: yep, bad name, bad. But, easy.

'delta-time?

Note it is defined:
dt: delta-time: func ....

ah

>> ? delta
Found these related words:

   delta-profile   function! Delta-profile of running a specific block.

   delta-time      function! Delta-time - return the time it takes to 
   eval...

   dp              function! Delta-profile of running a specific block.

   dt              function! Delta-time - return the time it takes to 
   eval...

I note cd no longer requires a file type in R3 .. .can that be ported 
back to r2 console?

as for profiling, Gabriele mentioned, that it might be usefull to 
add timestamps to trace output. Would allow to build profiler ...

(related to R3 trace)

if not time-stamps, line numbers could be useful, if they are not 
already there.

Graham, the file management functions are still on the list to be 
included. I just didn't have the time for 2.7.7, so they'll be in 
2.7.8.

neato ..

Some of the R3 versions still need work, and I didn't have the time 
to review them to see which ones. I'll import the fixes that are 
solid for now, and the LIST-DIR after the R3 version gets some polish.

All of them have been backported already and are in R2/Forward.

Henrik, loaded code doesn't have line numbers, or lines for that 
matter. Lines are a string thing, not a block thing.

BrianH, I was simply thinking of a counter for trace outputs.

so I can point to or find entry 34672 quickly in a debug session 
dumped to a file.

>> s1: "    abc     "
== "    abc     "

>> trim/head s1
== "abc     "

>> s2: "0abc0"
== "0abc0"

>> trim/head/with s2 "0"
** Script error: incompatible or invalid refinements
** Where: trim
** Near: trim/head/with s2 "0"

>> trim/with s2 "0"
== "abc"

if  /with and /head can be combined together , Things will get better

/with is documented to imply /all in R2 (see help trim).  You might 
lobby for /with to be deprecated in favor of a new refinement, like 
/chars, which can be combined using /head or /tail or /all.  I agree 
it would be nicer.

Here's a workaround to remove leading zeroes which can be adjusted 
to remove any leading characters:

>> zero: charset [#"0"]    

 == make bitset! #{
0000000000000100000000000000000000000000000000000000000000000000
}

>> not-zero: complement zero

== make bitset! #{
FFFFFFFFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
}
>> s2: "0abc0"              

== "0abc0"
>> remove/part s2 find s2 not-zero

== "abc0"
>> s2: "000abc0"                  

== "000abc0"
>> remove/part s2 find s2 not-zero

== "abc0"

To Fork: 

Just  use /with  , continue to imply /all with it. ,           Thus 
won't  bring   compatibility problems.
/with means /chars/all
/with/head  means /chars/head


So, /chars

Thus,   we don't  need /chars

I guess you've got all the bases covered if /with/head/tail works, 
but it seems to me that trim/with should behave like trim/with/head/tail 
by default (e.g. how trim behaves when the charset is assumed to 
be whitespace)