AltME groups: search

Also, technically, a given send box should be directly connected 
to the given group, so you can send, and even if it is in transit 
or waiting you can go on and work on other messages.

We do tag messages this way in Qtask, but we have seen this same 
bug, but don't have proof (as I do in AltME) that it is the program 
and not the operator.  But I'm always on the look out for it since 
it can be a very dangerous bug for some people.


This whole class of issue falls to a perceived form of latency, and 
a series of features are needed to suppress it.  For example, instead 
of graying the out going message area, just make it look like it 
was sent, but also instantly add a “message hour glass” in the “New 
message” bar when on that group, and, also create a new tinted empty 
box in the thread saying something like “Waiting for new message 
to post”.


This frees you up to go elsewhere.  If you come back to the same 
group it is clear what state it is in.  If you want to retrieve the 
sent message just click on the “Message hour glass” and it will bring 
it back into the input box.


Lastly, of course, if you try to leave AltME before it is done sending, 
need to offer people a dialog warning them , and giving them access 
to the messages waiting.

There is more, but yeah, it takes a lot to make this work.

@Rebolek: For the sake of the psychological testing, these Code Golf 
problems I'm solving... I'm actually solving *in Rebmu*, mushed form.

and how do you measure the execution?  by accessing some form of 
timing or time information.

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

add a closing ']'. An example app is:

blk: copy []
foreach word words-of ctx-rebgui3/cursors [
	append blk compose/deep [
		text (form word) handler [

   on-over: make function! [[event][cursor (ctx-rebgui3/cursors/:word)]]

   on-away: make function! [[event][cursor ctx-rebgui3/cursors/arrow]]
		]
	]
]

display "Test Window" compose [
	text 83x10 rich [size 36 center red "Reb" black "GUI" leaf "3"]
	after 5
	(blk)
	return
	bar
	reverse
	button "Close" [undisplay event/gob]
	button "Open" [
		display "Alert" [
			after 1
			text 50x5 "Some more text."
			bar
			reverse
			button "Close" [undisplay event/gob]
		]
	]
]

Yes and no. Yes it's going to be as minimalistic and bloat free as 
before ... no as I'm aiming for something that allows seperation 
of form and function. RebGUI has a number of limitations that under 
R2 were problematic to resolve but under R3 are doable.

One shouldn't need to access faces directly. In time, I think GET-FACE 
and SET-FACE will do this, but you might need to pass the window 
face first:

get-face window my-form


Carl already has used a /field refinement, but I'm not sure what 
it does.

I thought that the whole point of Carl's GUI was to allow app developers 
ignore all of the little details about how the app looks and acts 
at runtime and just focus on the semantics. Let the stylist worry 
about the appearance, and let the infrastructre people worry about 
whether the input came from multitouch, mouse and keyboard, whatever. 
Separation of form and function.

We should be shown some liquid usage example, the simple one, to 
understand the concept. Then we should be shown more complex working 
app. If liquid is general flow engine (usefull also to non GUI parts), 
it could be added to rebol as a concept, and maybe even made native, 
but I am not sure if it fits the language or not. Maybe it should 
be available in the form of module/extension, dunno ...

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

In DOS era, when I coded in Clipper, MS Fox Pro introduced so called 
"scatter", "gather". Every language (Clipper, Visual Objects, Delphi) 
then copied naming and the principle ... to get and set values from 
form ...

BrianH, yes, that would be a work around, so I'm not using triggers.


I've written a GET-DB-PANEL function now that fulfill the specs, 
including SKIP, TABLE, _DATA, scoping, etc. This function is custom 
to RM-Asset, so I'm not sure we want it in the R3 GUI other than 
as an extension package.


Also, I've written an EMIT reactor that emits the panel in GET-DB-PANEL's 
object format as an SQLite record (predefined object).

I'm using options for now along with GET-DB-PANEL.

What this shows:

- Writing reactores is easy peasy.
- Using reactors is even easier.

- Doesn't break anything in the R3 GUI, if you GET-PANEL instead 
of GET-DB-PANEL.

An example of how this is used:

rec: make object! [] ; the SQLite database record object

view [
	form-panel: panel 1 [
		id: field options [skip: true]		; write-only field
		name: field				; stored in the object as 'name
		age: field				; stored in the object as 'age

  note: field options [_data: true]	; both these will be stored in 
  the _data map!
		bytheway: field options [_data: true]
	] options [record: 'rec]
	button "Emit" emit 'form-panel
	button "Submit" submit 'form-panel %form.txt
	button "Acquire" acquire 'form-panel %form.txt
]

So when you press Emit, 'rec will be set to:

make object! [
	name: ""
	age: ""
	_data: make map! [
		note: ""
		bytheway: ""
	]
]

If you press Submit, this object is made:

make object! [
	id: ""
	name: ""
	age: ""
	note: ""
	bytheway: ""
]

and is stored on disk with the name %form.txt


If you press Acquire, the above mentioned object is automatically 
loaded from disk and into the form.


Still need a one-liner for loading SQLite data into the form. Going 
to work on that now.

I know that you guys are doing some stuff for real apps, but those 
concepts really seem very preliminary, and kind of high-level in 
relation to GUI itself. Maybe this does not even belong to GUI itself. 
I alway hated, when GUI dictated me, how should I work with my data 
.... it is always like that - you come up with just one method, of 
possible tonnes of other methods of data to form relation handling. 


We don't have tabbing, focusing, accelerator keys support, unicode 
support, layers, transition effect, rich-text and draw probably still 
need some improvements,  etc., we don't have any more complex style 
to prove our GUI allows to be extended flexibly, so I think that 
solving how to handle data from SQL at this stage is very very preliminary 
:-)

This is just my opinion :-)

Anyhow, a form like this:

http://rebol.hmkdesign.dk/files/r3/gui/196.png

can be set in one line of code and retrieved in one line of code.

Nice! Henrik - one question. In Zachary app generator I used in DOS 
era for Clipper, there were basically two options, of how to initialise 
form - 'new, and from DB. Simply put - you set-up new record, and 
you want to have some items to be pre-filled with some default values. 
Is that possible with your concept?

Currently the form is bound to one record. Good question, btw. on 
new item. It's simple to do in principle, but I think it requires 
a clearly defined set of functions (reactors) for simple db operations:

I guess one wants these reactors (names not finalized):

emit - get data out of form to table. Done.
obtain - get data from table into form. Done.
next - next record
previous - previous record
first - first record
last - last record
new - new record
delete - delete record

there is also the case for displaying multiple records in one form. 
I've solved that in the VID Extension Kit, by providing an alternative 
form with fields that are disabled. clicking a checkmark enables 
the field and lets you set a value. when the value is set and you 
submit, the involved records have that value updated.

This is quite this kind of nonsense I thought we could avoid :-) 
You simply often might find the case, where it will not fit your 
situation, and then docs say - you can't do everything, using the 
concept. So then you are left with some usefull, but not-in-100%-cases 
usefull case, and between the raw solution. IIRC Chis has similar 
solution with his system? I don't remember the name .... however 
- this does not belong in the GUI group, and this is exactly where 
I thought your form  abstraction aproach will lead you :-)

the idea is simply not to submit the data until the form is validated. 
I've not decided yet, but validation could be a reactor, the way 
things are shaping up right now.

persistent: If you want to store a form you need to get the relevant 
information from your styles. For example: which ID was selected 
in a drop-down box, sort-order of tables etc.

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issue

 - actually no, they should not be that, and this is quite a misconception 
 that you want this level of control in most apps.


It's what prevents us from creating complex forms in minutes, where 
you don't have to think much about how the form interacts with a 
database.


When you think of it, most of the code you write, when writing boring 
business apps, and beyond writing styles, is writing, and worse: 
debugging and testing such code. Wouldn't it be nice to have this 
built into the GUI, all debugged and tested for you?

Max, yes, we can add different emitters. It would even be possible 
to generate HTML out of a VID form.

exactly - it's there right now, as opposed to VID 3.4 which is only 
going to be fully available some time from now (in a more polished 
form)

Nope, just new form factors. They still only have the 2 mobile OSes.

Committed first form validation prototype and docs for it. That should 
be enough for today. :-)

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

as it is now, the dialog system "forces" some specific routes. the 
intent is that dialogs must allow dozens of different standard dialog 
layouts and standard buttons. combined, forms in layouts would automatically 
be validated and the dialog would behave appropriately, i.e. not 
closing if the form and provide warnings is invalid. this works now 
in the prototype, and the end user won't have to do anything to use 
it in the standard dialogs.

Paul, aha, you do not like the prefix form, and insist on the infix 
form you wrote. Then I have a surprise for you: it isn't REBOL Do 
dialect, since the Do dialect does not allow the infix op to take 
more than two arguments. Nevertheless, you are totally missing the 
point stating, that it would require changing the tokenization - 
that is patently wrong.

View was not developed by Cyphre. Original View was developed in-house, 
by Jim Goodnow (Carl's friend from Amiga days (author of Aztek C, 
or something like that). What Cyphre did was adding AGG in there. 
Cyphre often tested AGG functionality in form of a DLL, externally 
then Carl patched it in into View IIRC.

It shouldn't be hard: R3's module dependencies are statically determinable, 
and the semantics can be translated to one-script form using known 
transforms. The module system was designed with this in mind.

trick is to find a way to parse just a subset... you might want to 
chat with steeve and shadwolf, their rebol editor was pretty responsive 
even with big files, so I guess they have an optimisation that lets 
them just token what is visible, with some form of caching for before 
and after pages of data.

Here I come with a nuclear bomb Ask .... This document requieres 
Viewer Advise if upon reading those line your retina blow up I could 
not held responsible for that.


I was htinking of the possible logical reasons why rebol is  not 
used  widly in today's computing area.


First i can say  compared to other scripting language it's source 
code is not freely accessible.

Second I can say most of the script laguages use now in days is in 
a role where the script source code isn't available to read to the 
client.

And so most of those script use are around Webserver, server side 
so the scripts are hiden to the view of the consumer (the cleint).

And most of  the time when a company needs to broadcast a software 
to their customer (a game, a client software, etc...) then they 

need to hide their source code. So most of the time they use compiled 
or speudo compiled programing language.


On an ideologic side what rebol offers is  "take my blackbox but 
you have to broacast your software source code viewable for all" 

Personnally i like that part .... that's what allowed me to build 
most of my softwares and contribute to most of some of other ones
project.


But I perfectly understand that for the industry they need to hide 
their "know how". So they use java so they use what ever compiled 
language to hide their "know how" 

Next is the fact that most of the time companies choose a langage 
more for the extension related to their project than for any other 
consideration.

Compiled language are faster the script languages most of the time.
So my ask is could rebol be like java compiled like language? 


I'm not talking about rebol/SDK  to me fusing the VM binary with 
 the script and somehow hiding the script is not the right solution 
that's just a cheap way to 
achieve that goal and rebol deserves better than cheap ways.


My point is to have like java does the need to go to the rebol.com 
and install the REBOL runtime environement  -> That strategy 1 rule 
1 modo 1 in spreading your technology 
Why sun Java and  Microsoft .NET  does it and rebol not ? 

And there we fall to what Carl noticed and shared with us some years 
ago while initiating the R3 projet  wich was  "Administrators on 
IT companies doesn"t knows about REBOL so when they see it they kill 
it from running tasks" 

Maybe the whole R.E (runtime Environement) thing was made to make 
most of the people look at the juava or .net dedicated websites and 
so be informed of what is jvm or what is netvm. At taht time when 
CArl tried to talk about us with that the solution Carl proposed 
was -> "Lets change rebol names" and  my reply was cold "If people 
after 6 years don't know rebol they won't know better anyother name 
the problem so i not the name is the way we spread the information". 
So in a way a runtime environement is the best way to populate your 
idea without investing to much.


Next thinking is about the compiled / speudo compiled is faster than 
any possible scripting language.
FASTER ????  IN WHAT ?  those are the questions ...

Most of people whould reply faster in execution ... Ok bu if i remamber 
well what i learn at school (yes i went to school stop laughing ...) 
before running a binary program you need to build the script ...

and that's where most of the work time is bruned up and where the 
need of a IDE (intergrated Developement Environement) is needed and 
most of the time those IDE ends up in being a Click and feel the 
form ... wich is adding a complexity layer instead of simplifying 
the scriptiing. Intents like small talk for example that push this 
aspect to it's core limits were hum not widely accepted as a suitable 
way to build software. Mainly because they make nearly impossible 
to extend easyly their selfves in comparasion of  other compiled 
languages.


So we are then saying rebol is the fastest way to build applications 
in the world. It's a ight weight very well though scripting langages 
with alot of possibilities.

Most of the time in one line of rebol you do as much as  tens of 
lines in any other languga (or even more) and that's because in my 
opinion rebol doesn't need a heavy script 

grammar to exist.   But you can stil make an IDE to help organise 
your work and speed it up and make it easyly more cooperative. But 
this is not the part we are discussing.


So in fact what really  matters in comuting area is less the time 
you spend building you application than the need to hide your 'how 
I did it'  and to then have the closest possible level to your hardware 
for your software. 


And for that my friends rebol need to be speudo compiled able. And 
maybe the step further java in our industry is to have a keep it 
simple language hiding your industrial secrets but allowing you if 
you want to share your work in full view full access like it's actually 
the case. Some will say to me  yes but  with R3 we have new extendsions 
so the industrial secret can be hidden in that layer. that's right 
but then you don't do rebol anymore you do C and what id the purpose 
of embeding rebol into a complexifed C layer ... C layer is to extend 
our language capabilities the fastest way but not to make the need 
of our language to desapear ... Because in the end what we want to 
promote is REBOL  not C language....


It's a long post I'm sorry for that  but I'm thinking about it since 
a long long time and tonight i feeled like sharing those thoughts

but GUI (VID) is exactly our advantage imo, to show the world, how 
easy is it to do basic form apps. There is not much to adhere toGUI 
wise imo. Each app can look totally different, like in old Amiga 
days, no?

3. rebol3 gui: We are working on getting VID to a state that it can 
be used for app development. For this we did a complete new resizing 
system, changed the styles etc. This is not yet ready for release 
because to much flux in the design and code. We will release it either 
in form of the official VID via Carl or as our own VID fork, if Carl 
decides that the official VID should look differently.

No decision taken yet and I hope that we don't need to fork VID.

7. financing / sponsoring: To be able to do it, one needs to have 
something to spend. And yes, making money form projects is the goal 
for us. This gives the freedom to spend money on non-project relasted 
R3 stuff we do. This is the sponsoring and investment we do into 
R3. As long as I can finance the sponsoring parts I will do it.


Again, I follow the golen rule: The one owning the gold makes the 
rules.


Meaning, I set the priorities to the things we need or which complete 
some aspects etc. But it won't be a community driven process.

Ladislav from the browser popup login or the web page form login?

there are two login forms. after the browser popup, a web form appears 
here asking you to log in with your R3 chat credentials

I've created this function many times enough to think it should be 
standard:


; creates a string from a list of strings with human readable comma 
separation
string-list: func [blk /local out] [
	out: make string! 1000
	forall blk [
		append out form first blk

  unless tail? next blk [append out either tail? at blk 3 [" and "][", 
  "]]
	]
	out
]

string-list ["a" "b" "c"]
== "a, b and c"

And you can debug if you have the source. However, some of the process 
will go through your head, in the form of knowledge of where functions 
are defined. Or you can take portions of the source without the protections 
and debug them independently.

How can I remove key form map! ?

I always thought HTTP GET is incredibly anti-intuitive when used 
to send form data. Mapping write to POST feels a lot more logical

Wow, Christian took my advice, and redo ODBC extension into .DLL 
form, and now it uses ports! That is cool. Should be imo reported 
to rebolweek :-) 

http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html

? should stand for :

  is [something] ?

but its also used as:

  what is [something] ?


though the second form could be used on just about every function 
which isn't a process...  so I don't like that we sometimes add ? 
when we really are asking for a process of some data.

that is the second form..... 

 what is [something] of ?

They are quite a complex data structure, or can be.


Perhaps a first step would be for someone to write a parse rule to 
identify/vaidate IPv6 strings and, optionally, translate them to 
a normative form.


Link to someone who has made  a stab at a BNF defintion for  IPv6, 
and then produced a regex:

   http://crisp.tweakblogs.net/blog/2031/ipv6-validation-%28and-caveats%29.html

Be loaded in literal form by LOAD. That is the only advantage of 
a datatype! over a utype!.

Extend is a mezz, so that much be slower.

And I always try to avoid GC overheads due to excessive  usage of 
'reduce


Thats why I think bind/new is more capable especially, this form:
>set bin/new 'b obj 2
instead of:
>>bind/new 'b obj obj/b: 2

Nothing publically released in even commercial form then.

We do miss typical OOP facilities as being able to hook into init, 
pre-init, post-init, access phases ... E.g. Visual Objects I used 
in the past define:


You can prevent a runtime error from occurring when an
instance variable 
name is not found by defining methods called
NoIVarGet() and NoIVarPut(). 
These methods, if present, will
be automatically invoked whenever 
an instance variable cannot
be found. They are called with the instance 
variable name as a
parameter, in the form of a symbol and, in the 
case of
NoIVarPut(), with the value to be assigned as a second
parameter. 
This feature is useful in detecting and preventing a
runtime error 
and also for creating virtual variables
dynamically at runtime.

It's used in mezzanines, for instance. I tend to just write code 
in micro-optimized form in the first place, since it is easy to do 
and saves you the trouble of doing it later. Even if you are macro-optimizing 
the code (refactoring and such) you tend to use the same micro-optimizations 
in the new code. For that matter, many of the changes and enhancements 
in R3 were done to make micro-optimized code cleaner to read and 
write than they are in R2. But I mostly write library and mezzannine 
code nowadays, so micro-optimization has greater impact than it would 
for user-level code.

I tend to just write code in micro-optimized form in the first place

And do you consider that premature optimization, or not?

It is just as easy in theory to write the code in micro-optimized 
form as it is to not, so why not? In practice though, in R2 it is 
harder to write micro-optimized code (for various reasons). In R3 
it is *easier* to write micro-optimized code than it is to not, because 
we have been deliberately been optimizing the language for just that 
effect for a couple years now.

It is just as easy in theory to write the code in micro-optimized 
form as it is to not, so why not?

So that's a "Yes" to my question then? ;-)

But I prefer the compact form, more readable IMHO.

Was talking about the first form only (with the index)

Hasn't the first form always been like that?

In human language, that doesn't require a different form for the 
word, but it does trigger a flag in our language sensibility that 
something odd is being said

It is funny, that it looks, that people prefer

    length-of series

to the form

    get-length series

which is starting with a verb...

In the case of your faces question, "faces" is a collective noun, 
and in function form is a request for a property or contents of its 
argument (don't know which), so FACES-OF would probably be preferred, 
leaving the 'faces word available to be used as a variable. Or GET-FACES 
if you prefer to emphasize the action of retrieving that value and 
have a corresponding SET-FACES function.

The word "binding" is two different nouns (one referring to the act 
of binding, one referring to the result of binding), so it doesn't 
fit the adjective? model very well. The word "bound" is the adjective 
form. See http://issue.cc/r3/1819for details.

In R3 
>> d: make obejct1 object2
should behave like
>> d: append object1 body-of object2

But yeah, the first form is more concise and faster.

Well, if there's sufficient backing in the community, we really should 
manifest that in the form of a CC wish.

I mean... I can do:
>> if error? err: try [1 / 0][probe err false]
make error! [
    code: 400
    type: 'Math
    id: 'zero-divide
    arg1: none
    arg2: none
    arg3: none
    near: [/ 0]
    where: [/ try]
]
== false


but what if I would like to form the error message to look like if 
the error is really evaluated:

>> do err
** Math error: attempt to divide by zero
** Where: / try
** Near: / 0

Oldes, a perhaps simpler version for R2 is: http://www.rebol.it/power-mezz/mezz/form-error.html

I thought FORM was supposed to be able to do the same thing on R3, 
not implemented yet?

You are right... simple FORM err works:

>> error? err: try [1 / 0]
== true

>> form err
== {** Math error: attempt to divide by zero
** Where: / try
** Near: / 0
}

To clarify the SSL stuff:

Since the SSL is a layer on top of TCP the idea was that R3 will 
have all the neccesary encryption algorithms (RSA,DH, DSA, RC4, SH256 
etc.) probably in form of embedded extension as part of the host-kit. 
These algorithms needs to be fast so they will be in C (probably 
ported from the R2 codebase if possible). Then the SSL/TLS protocol 
itself won't be written in C as it was in R2 but just done in R3 
script. This way the protocol code will be:
-smaller in size than the C version

-easier to maintain because it is Rebol language, for example we 
can add 'server mode', certificate validation (simmilar to web browsers) 
etc.
-crossplatform as much as Rebol script can be


So far I did simple TLS implementation in R2 to prove that concept. 
The prototype is ~20KB of rebol script and uses only the build in 
encryption ports in R2. It covers most of the TLS functionality that 
is written natively in in form of 'tls scheme. So the next step is 
to get the encryption math to R3 (which can be useful not only for 
SSL so it is definitely worth doing that) and then try how the prototype 
will behave.

I'm hoping to get a grammar for the whole language. We would then 
be able to convert it to various syntax highlighting engines, analysis 
tools, whatever. Figuring out the R2 syntax will take some different 
tricks though, as it doesn't have TRANSCODE and proper binary handling. 
I eventually hope to be able to write a TRANSCODE for R3 and R2 in 
REBOL source form, for documentation and analysis purposes.

There are a few functions in R3 that take the form of a CASE/all 
followed by a CASE. SAVE is one such function, though it has a series 
of IF statements at its beginning leftover from before that could 
be made more efficient by adding to the beginning of the CASE/all.

As for advantages, YMMV. For me, the improved PARSE, binary conversions 
that make sense, the map! type, the module system, the faster and 
more powerful loops, better error handling, and the increased consistency 
make R3 much easier to use. The extension model makes it more powerful 
- I always hated R2's library access model. But I don't do much GUI 
work in REBOL. R2 has database access that I use pretty often, and 
HTTPS support which I use rarely but it's important when I do. I've 
backported the most important missing functions from R3 to R2 in 
mezzanine form, though there is still some stuff I miss.

Is the ODBC stuff in port scheme form, or a collection of functions?

The advantage to serializing directly in SAVE/all form is speed. 
The disadvantages are:

- The preferences file would be uglier to write by hand than block 
form.

- You would have to screen with ASSERT/type in FOREACH instead of 
PARSE.

OK, just checked, characters are operated on as if they are integers 
of the same numeric values; that will do. We can't implement this 
in string form because we don't support UCS4 internally.

Geomol: I don't understand, why you say
REBOL does not have conditional AND and OR


Excerpt form the above definition of "conditional operator": "...being 
able to combine conditional expressions into more complex conditional 
expressions..."


The demonstration that AND and OR are not able to combine conditional 
expressions into more complex conditional expressions is easy

That last trick would be difficult to do safely though, at least 
as FUNCT is used in the mezzanine generation process. Mezzanines 
are generated with FUNCT but saved with MOLD into the form where 
they will be loaded at runtime. This means that FUNCT can't generate 
code that has inline function or datatype values in it, since they 
won't mold properly. Unless you inline the references to ASSERT and 
NONE!, those words couldn't be used as function parameters or local 
variables in the generated functions. Tradeoffs, I guess.

IMHO converting to string usually is meant to be used more like FORM 
than anything else.

If it is returning anything other than none for an overlong form, 
it is screening for overlong forms.

Other overlong forms are not being screened for, but one form is? 
That would also be worth a ticket.

#{e080af} is an overlong form for #"/", for example.

There was a big debate about this before we hammered down the current 
equivalence hierarchy, including the operators. There was even a 
suggestion to have ~= refer to EQUAL?, making = refer to EQUIV?, 
but we finally decided that the paying attention to binding and exact 
IEEE754 equivalence was too advanced for most uses, so = was assigned 
to the most forgiving form of equality. Many other languages with 
an equivalence hierarchy have made a similar choice, so it shouldn't 
be too surprising.

In general, doing math with char! values without explicitly converting 
them is kind of bad form; it leads to developer confusion. The main 
reason you'd do this is because of the awkwardness of combining operator 
and prefix expressions without parentheses. It's interesting that 
it still works in some cases, but not in others. Considering characters 
to be number-like is a bit weird, a bit too C-like for my tastes.

Regarding the "why the heredoc syntax was proposed" question, here 
is another reason, that is important for me, proving, that even users 
not planning to use other languages than REBOL can take advantage 
of it:


In my REBOL script files, I usually write code examples, or code 
tests, that are meant to demonstrate the newly defined functions, 
or to test whether they work as expected. That code is in no way 
meant to be run every time the script is run. Therefore, I use the 
COMMENT function to ensure the example/test code does not run every 
time the script is run.


Since it is a comment, I prefer to use a string to be able to write 
it "free-form" not being bound by the requirement of loadability 
of the text. However, when the code examples in the comment contain 
special "escaped characters", this would look ugly, therefore I rather 
give up the free-formness of the comment gaining the advantage of 
not being forced to escape the special characters, but being forced 
to keep the comment REBOL-loadable. The proposed heredoc syntax can 
solve this, and similar problems nicely and naturally.

now
to-block form [ [ "xxx" ] [ "yyy" ] [ "zzz" ]]

does not work ... due to Rebol evaluating the contents

well,  I will use the to-block form and if that errors out drop back 
to flatten

well... enbase just converts binary (8-bit) data to a form that is 
ascii printable. it does not say anything about what the 8-bit data 
contains.

What is the best way to form decimal and avoid the E notation?
>> form .02
== "2E-2"

form-decimal ... Gabriele has a version around

In other words, how to get back a functionnal object from a serialized 
form (save/all) ?

I'm not sure it's possible because the literal form for object's 
functions (#[function! ...]) make them evaluated before the object, 
so the binding process might fail in that case.

Using SAVE ensures that you have a list of symbols in unevaluated 
form more suitable for object reconstruction and proper binding.

So to resume, serialized form is not suitable for object!.

do load
 does not work with the serialized form (I tried it)?

Last question, why can't the binding of the save/all form be restored 
by the manual 'bind ?

do load

 does not work with the serialized form (I tried it)?" I'm not sure 
 to understand what you mean there. SAVE/ALL uses MOLD/ALL to serialize 
 values, so binding information is not preserved. If you want to restore 
 correct binding in a object! serialized using /ALL format, you need 
 to write some code to walk through object's functions body blocks 
 and bind object's words explicitely using BIND.

This would be similar to what MAKE does on an object's spec block! 
but a bit smarter as you need to dive into function! values (MAKE 
doesn't do that AFAICT). You need to see the distinction between 
"unevaluated code" (source form) and "evaluated code" (reduced form) 
to get a clear picture on this issue.

You can just form a binary ... to get a string

Why FORMing a datatype! removes the ! char? We cannot get it back 
to datatype without adding a ! to the end:
to-datatype to-word form integer! ;not working
to-datatype to-word join form integer! "!" ;ok


is this a bug, if it is by-desing what is the reason to remove "!"?

I think it's by design. FORM makes values "more readable". You'd 
better use MOLD for what you need.

yes MOLD is better use, thank you. I just curious about why FORM 
removes ! char. I think it prevents to manually remove ! char in 
this kind of situations:
a: 5 reform [a "is an" type? a]
>> 5 is an integer

Yes, I think this is exact user-case for FORM.