AltME groups: search

I was just wondering, it there is someone else "who know the internals"... 
I know that Cyphre is waiting for new sources from Carl to do something. 
And of course it's good to have a place where one can write message 
to Carl and with a feeling, that Carl will read it one day.

Right now Carl is busy getting things in place to get the source 
out. Then we can discuss native changes that *don't* affect core 
code. We have already been discussing native changes that *do* affect 
core code, here and in R3 chat, a lot lately :)

It should be pretty easy to write a function that maps an ACTIONS 
block such as the following into a window:

	actions: [
		my-text-list [
			do [set-face ... ]
			"other-event" [ blah blah..]
		]
	]

in case we wish to dynamically insert objects into the display and 
then remove them as they do in Javascript

There is not just general 'do, like in R2, there is now many reactors. 
In order to better understand new architecture, here's some docs 
- http://www.rebol.net/wiki/R3_GUI...

basically no problem if we have different view of this, I just wanted 
to note my vote that not every web-developer thinks UJS is such an 
awesome idea by itself. That doesn't mean I want to do "big grey 
ball of goo" programming either.

First, I think JS is not something we should look at for models. 
It's new enought that it is just going to reinvent what's been done 
before, unless they come up with something truly revolutionary, and 
my gut feeling says that's not going to happen. It also depends on 
what kind of apps you're writing, and what you want the language 
to hide from you.


What's been done before that works, or not?  MVC has seen a resurgence 
with RoR and other frameworks being built on it. 


Now look at a low level approach, where you handle the main event 
loop yourself. Anyone remember writing C programs for Windows early 
on? Maybe some still do. You had a huge switch statement to dispatch. 
On the downside, that was hideous to read and maintain. A benefit, 
though, was that you could hook into it very easily, because it wasn't 
spread throughout the app.

Then there's the whole VB/event-driven model.


R2+VID is wonderful for very simple things, because you don't have 
much to do, actions are right there with their faces, etc. It starts 
getting in the way when you build larger apps that need to track 
relationships between faces and such. And it is not well-suited to 
large apps, just like REBOL itself. It doesn't provide the organization, 
tools, and features needed. Of course, we can build all that ourselves, 
if we have the inclination. RebGUI is the best example of that.

In theory you can force people to walk a path, in the case of the 
task example I just gave, we can't do that, since you can click on 
anything.

Do the styled buttons have keyboard access to them like ^O, ^S etc?

Kib2, likely when the chat server is finished being ported to R3 
on Linux. We were running into problems with Unicode user names on 
R2, since R2 can't do case-insensitive comparisons of Unicode strings, 
even when encoded in UTF-8.

R3 interpreter written in JS? :-) How fast it can be? Besides that 
- don't we have better job to do than to obey stupid Apple's licensing 
policy? Why not to use devices like HTC Touch Pro for e.g. then?

But - the best aproach (because I don't believe someone will port 
REBOL neither to JS nor JAVA), is to imo do dual interface. One in 
VID, other one for web. We will see, how it could be automated.

I expect that my work on some of my todo list will take the form 
of helping others do it - it's more of a to-get-done list :)

i try to load rebDB-203 in R3 .................          but R3 return 
a error when a try to do a "db-create my-table [id date name]"   
   with  >> db-create "my-table" [id date nom]

** Script error: db-create does not allow string! for its 'table 
argument

** Note: use WHY? for more about this error

You got further than I when I triead:
>> do %/Users/peter/Code/Library/Rebol/RebDB-203/db.r

** Syntax error: Invalid "string" -- {"Ashley G. TrŸter"}

** Where: to unless load case applier do
** Near: (line 3) Owner:		"Ashley G. TrŸter"

or perhaps R3 guru would give us a better way to do this ;-)

R3 will not be very compatible with R2. You will almost always need 
some kind of porting process, so this is up to the authors of rebdb 
and rebgui, if they want to do that.

ok seem we must do a real port effot from R2 script to R3 !!!!!

Hrm...  I suppose this might have something to do with it.

>> img: load %/t/1.jpg
** Script error: load-jpeg has no value
** Where: case load
** Near: case [
    string? source [to-binary source]
    binary? sou...

** Note: use WHY? for more about this error

Specialized is good. Let the programmer decide what they want to 
do at programming time, not the interpreter at runtime.

Josh, the issue is that the chat server is running on R2 right now 
for reliability. R2 can't handle Unicode except as binary, and certainly 
can't do case-sensitive searches for user names in Unicode. The web 
client for mobile is even worse, and is also R2 since R3 can't handle 
CGI yet.


Right now we are focusing on getting R3 stable enough to use on the 
server-side. Hence the changes in the newest alphas.

Henrik, do you need help?  Maybe I can get involved - if interested 
- just get me up to speed on it.

Gabriele, I know that R3 handles case-insensitiveness of Latin1 characters 
in Unicode text better than R2 with UTF-8, but beyond that I don't 
know. There is still some stuff to do relative to Unicode. The implications 
of Unicode support on the rest of the system are mostly implemented 
though, with the glaring exception of PARSE.

Why are minimum-of and maximum-of being mezzanines now, instead of 
natives as in R2?

Because we are cleaning down the core in R3, and those functions 
are rarely used. They are fast enough as mezzanines - the FORSKIP 
loop they call is native in R3.


Mezzanines can be better for some purposes too - REBOL is a much 
more powerful language than C for some things, so it is sometimes 
a good idea to write the functions in REBOL instead, particularly 
when it needs to be flexible. This is why LOAD is a mezzanine in 
R3 (which calls native code to parse the REBOL data), and half of 
DO is an intrinsic (a built-in function written in REBOL that is 
called by native code).

AdrianS: some small helper, but you probably know it. What you can 
do is partial word searches. E.g. try:

help to- ; and it will list every to-* function
help pr ; it will list every function containing "pr"

how is that usefull to you? Do you really search for function, which 
accepts some concrete args? Why would you do so? :-) What about searching 
in help string?

well, when learning a language, you need all the help you can get 
- if I know the datatype of the args, I would probably like to know 
all the things I could do with them (append one to the other, multiply, 
union, etc)

BrainH: how would you solve the problem of documenting dialects? 
(having ability to query them for help?) Do you think we can plug 
it in default help? What about loaded modules, will they naturally 
extend help?

If the /search option is OK with you, please add a comment to the 
ticket saying so, so that the developers will do that instead.

REBOL's function documentation model is completely different from 
Smalltalk's, so I had to do some translation.

Adrian, the order of arguments are preserved in the spec, but the 
order of types in the typespec for a particular argument are not. 
That is what I meant. Do you also want to search for functions that 
take multiple arguments, by the types of each of those arguments 
(their names don't matter), in the order specified? If so, why?

as a new user to REBOL, you tend to browse around to discover new 
functionality - least I do. The example I gave before was to answer 
questions like "what can I do with two strings?" or "or "what can 
I do with a block and an integer?". Typically, you tend to have a 
bit of a clue as to the datatypes you're working with, but you often 
can't recall the function names

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

I just visited AGG newsgroup after one year, and some interesting 
projects do emerge. Community agreed that any open work will be done 
to BSD version (2.4), which is a good sign (although RT has probably 
no problem obtaining special license).


Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak 
guys, and one of them is doing rather interesting project. AsmJIT 
and BlitJIT libraries, with MIT licence. Author says about it:


Antigrain is great piece of software with great licence, 
but without 
better acceleration it's quite slow.  So blitjit can increase speed 
of 
your applications in way you can't imagine. For example is there
complete 
MMX/SSE2 extension for antigrain ? No, but don't panic, other
libraries 
also have problems with cpu specific features.


The reason why it might be interesting is, that generally there is 
no good 2D HW acceleration out there, and here is what author of 
LibNUI answered to Cyphre:


I'm the author or nui (http://libnui.net) which is a GUI toolkit 
based  
on OpenGL (and now OpenGL ES / Direct3D). This project was 
started  
some 8 or 9 years ago and I've been working on it and with 
it amlist  
daily for that time. My experience is that it's some 
orders of  
magnitude harder to have HW support for those features 
that to add a  
JIT to your engine in order to optimize your bottlenecks 
(I've done  
some of that for pro audio dsp code). The reason is 
that no two chips  
work exactly the same and behaviour even tend 
to change over driver  
releases. To diferent cards, even sometimes 
from diferent vendors,  
will not give you the exact same scan convertion 
or rasterizing, and  
I'm not even touching shaders diferences...


It seems to be x86 only so far, but maybe guys like Cyphre or BrianH 
or Anton or anyone skilled in those areas should keep an eye on those 
guys :-) Here's a link:

http://code.google.com/p/blitjit/

... as for those another AGG based Czech and Slovak projects:
http://www.rw-designer.com/
http://www.crossgl.com/

Shouldn't we get those guys hooked to REBOL? :-)

how do I post private message to Carl?

I note that in JS we can fade in visual objects ... will that be 
easy to do ?

Graham, each GOB can set its alpha channel with 1 integer directly. 
I don't think this is exposed in the UI yet, but it wouldn't be hard 
to do.

I'm not sure that would be simple to do unless you do it directly 
in DRAW, but then you will need gradients for lines, which we don't 
have yet.

So - where do we write down our wishes for Cyphre to implement? :-)

Question to R3 people:
In R2	>> LIST-DIR %/c	<-- will crash R2.7.6 
In R2	>> X: %/c

 >> LIST-DIR X		<-- will ask a security question to allow, and then 
 return desired results

In R3	>> LIST-DIR %/c	<-- will return desired results (no security 
for alpha R3a.37)
	>> X: %/c

 >> LIST-DIR X 	<-- will give ** Script error: invalid arguement: 
 %X
	>> LIST-DIR :X	<-- will return desired results.

Why do I need to put a : in front of my variable in order for LIST-DIR 
to work properly?  Doesn't seem to be intuitive, does it?

About LIST-DIR:

R3 have some UNIX kinda commands, like ls. I think, Carl was tired 
of typing:
list-dir %script
and just wanted to type:
ls script


But it doesn't work with /c, because it's seen as a refinement datatype, 
and ls doesn't allow that. It's a mistake, as I see it. You can do 
it by:

myls: func ['path] [ls (form path)]
myls /c

Steeve, one of the problems with multiple value replace is that there 
are basically two ways to do it:

- One value/replacement pair at a time (like your FOREACH loop above).

- In order using either an inner loop of FIND/match calls, or PARSE 
rules and alternation.

Neither of those are very efficient, but the PARSE rules tends to 
be more so, at the expense of building the rules. REWORD uses the 
compiled PARSE rules method. Most of its overhead is working around 
bugs in map! or going away with new REBOL features. If we do an inplace 
replacement, we'll have the same overhead. The only solution is to 
optimize the runtime, or hand-write the PARSE rules.

i make a proposal:

Most of the times, we use the same rules several times on different 
data.
reword should be able to not reconstruct the rules if so.

I used the similiar tricks in some scripts, for example:

map-chars: func [
	{replace/all pair chars in a string}
	data [string!] values [block!]
	/local chars pos
][

 ;** if the first value in values is a bitset, do not reconstruct 
 the bitset
	unless bitset? chars: first values [
		chars: make bitset! 256
		forskip array 2 [append chars array/1]
		insert values chars
	]
	pos: data
	values: next values

 while [pos: find pos chars][pos: change/part pos select/skip values 
 first pos 2 1]
	data
]

data: "Hello You"
map-chars copy data values: [#"s" "SS" #"t" #"T"] 
;** the second call is faster
map-chars copy data values

I have some questions regarding timestamps on files.  They look like 
they are all GMT and don't take into account what time zone you are 
in.

To my way of thinking, they probably should default to what the system 
is doing.
For example:
Create any file TEST.r in your what-dir
>> GET QUERY %TEST.r

== [%TEST.r 7329 13-Mar-2009/20:26:42.429 file]		<-- notice the timestamp 
is not CST where I created this at 3pm, not 8pm

If you look at the file through Windows Explorer, you will see it 
is dated at the local time, not GMT.

Do I need to subtract 5 hours (DST) or 6 hours, depending upon my 
timezone and if we are on Daylight saving time?
Do we have some refinements or another way to handle that?

add eyes to do a smiley inside the R  :)

(in that, there may be a different, but just as good a method to 
do it)

I want to get to 't because I'm trying to hack together a GUI for 
DevBase because the console client is painful to use and I thought 
this might be a good way to introduce myself to some of the internal 
workings of the new GUI.  I want to redefine "say" in the chat.r 
to update ''t with the text it would normally print.


To have changed what VIEW returns such that I can't actually get 
to the face produced is unbelievably confusing.  There must be a 
good reason for it though, what is it? 


You do realize that if I have no way creating a pointer to a face 
then I can't use get-face, set-face, etc. on it don't you???

Yes, once modules are done certain internal things will be locked 
away but that has nothing to do with my question here.

I need a solution to a problem and that solution very well may be 
a paradigm shift on my side.  I just need to know how to interact 
with the GUI from outside the GUI code OR I need an explanation of 
why the ability to do has been removed in the latest release of R3's 
GUI.

The truth is, I can hack this 1.6 billion different ways.  I DON"T 
WANT TO HACK IT!!!!!  I want to use the system how it was designed 
to be used.  Simply example hack...


view [t: text "this is a test" button "Mwahahaha!" do [set 'txt t]]

The fact I can use the set trick in a reactor means I could prolly 
do the same thing in an actor, on-make, for instance.  It's not an 
issue of not being able to hack it.  I'm not looking for a hack. 
 I can hack just fine.  I want to know how the system is SUPPOSED 
to be used.

Something I did in my code all the time with VID 2 is window: layout 
[ ... ]  then go ahead and connect/modify/abuse the window in any 
number of ways and then show it later.  I'd often set up panels this 
way so that I can have the faces built ready to switch out at the 
click of a button and this would allow me to easily keep different 
areas of the GUI in sync easily but now that Layout is gone I can't 
do it this way.  The real question here is why is view returning 
the gob instead of the face?  Seems on how I actually have the GUI 
source code sitting on my machine, I can hack this to give me what 
I want the problem is, it would be a hack which means that I can't 
hack it to give me what I want because what I want is not a hack. 
 Get it? ;-)

According to Carl there's no correct way to do what I'm trying to 
do yet.  That just might explain why it was so difficult to find 
the correct way to do it...

Managing wrapped lines isn't a concern at the moment.   What I will 
be able to do with the structure I've chosen far outweighs the extra 
cost dealing with wrapped lines if I ever decide to add that functionality.

Steeve, I think one gob per character may operate fast enough, if 
it's a modern machine. But then you have to do your own paragraph 
flowing etc.

That's how I did my editor replacement in R2. But then I started 
wondering how to do my own flowing and I decided multiple gobs per 
line is the way to go. Needs some clever way of indexing lines and 
caching gobs so small near-constant number of gobs are produced and 
reused per window of text.

Yes, you would have to do the flow / wrapping algorithm yourself.

; pasting this code into the console seems to be just fine but if 
you

; do read clipboard:// it fails on the first or second attempt causing 
the above error...

blk: []
str: to string! to char! 0
repeat i 256 [insert str to char! i]

rdm-str: has [txt] [txt: copy "" repeat i random 80 [insert txt random/only 
str]]
repeat i 4020 [insert blk rdm-str]
probe length? blk
probe length? rejoin blk

I was going to put this on CureCode but when I go to the Add Ticket 
link it tells me to pick a project.  Project?  What Project and how 
do I pick it?

Steeve, I'm writing it up now. It's probably possible to do with 
a series of mezzanines, but it would not be very elegant.

Eh Ammon ! how do you manage selection over several text gobs ?

I'm trying to do it currently, but i'm not sure to have the best 
design

Again, what a big word. I do that too to have a more readable, and 
compact code. 

I don't like to pass thousand of parameters. But nothing is related 
to a state machine to my mind

Hmm, isn't jus alpha transparency enough? Why to do any shape detection? 
We just need the ability to define level, which will let events to 
go to underlying faces, just like Amiga DE did it. And if you look 
at Cyphre's irregular window shape, you will see, that it simply 
is not rectangular, or is it?

do http://www.rebol.cz/~cyphre/trans-gui.r

Cyphre can't do nothing yet, as Carl did some changes to the code, 
and Cyphre's version of R3/View is not compatible anymore. Of course, 
rebin isolation should help, and in month or two, we get there - 
modules are bing worked on right now, plug-ins and rebin are next 
one. Then some source-codes get released finally. In the meantime, 
Carl also updates docs - very important ...

Icarii, i don't see the interest to do such a mess.

Basically, when i have to get the size of a text , i just do a size-text 
on it.

Steeve - just a simple way to get font-metrics for layout planning 
where you cannot rely on richtext in AGG working (eg it doesnt wrap, 
doesnt do bounds in Draw mode)

Guys, there is some missunderstandings since a while.

Size-text is not usable on draw gobs, only on text gobs (that what 
we call rich-text gobs).

A multi-line text system should handle several text gobs (one per 
line).
It's the most simple and fastest system (it's what i do).

So that we don't need to calculate the size or the position of each 
chars in the line. 
And we don't need to manage a text wrapping mechanism.

The process now is to clean up the skin, making it as simple as possible 
first (no gradients or prettiness for now), so Carl will be able 
to approve it and so I've started from scratch, fetching in the styles 
one at a time. During this process, I've exposed a few problems and 
solved those, so it was a good idea to do that.

Accessors allow you to provide your own functions to how the code 
interacts with (accesses) the object internals.  typically you have 
get/set/print/convertion accessors.

the range and flexibility of accessors is largely dependent on the 
language and the speed considerations of implementing "public" accessors. 
 


most modern oop languages  implement accessors.  some languages, 
like python, let you change all the accessors which the language 
itself has access to.

one of the things accessors allows is to create or simulate custom 
datatypes (depending on how complete the accessor interface is).

so as an example, we could do this:

float-pair: object [
	x: 0.0
	y: 0.0
	set: func [value [string! pair! decimal!][
		switch 
	]
]

float-pair: context [
	x: 0.0
	y: 0.0
	set: func [value [pair! decimal!][
		switch type? [
			pair! [ x: to-decimal value/x y: to-decimal value/y]
			decimal! [x: value y: value]
		]
	]
]

then you would be allowed to do:
float-pair: 3.4
float-pair: 5x7


obviously, this is just a very simple and incomplete example but 
it should give you an idea of the concept.

[ This whole post is mainly in the R2 mindset, but is somewhat relevant 
also to R3. ]


The technique of setting words directly into the global context like 
this:

	context [
		set 'o ...
	]


I do not like, because this code is modifying its environment - it 
has side-effects - thus, it is non-modular, and does not scale.

Being non-modular means large software systems can't be built up 
reliably, because the cumulative effect of all those side-effects 
will eventually cause name-clashes in the global context, so that 
some word exported from one context will be overwritten by the same 
word exported from another context.

For example, suppose I've seen two graphics demos by two different 
authors. They each have an awesome graphics processing routine and 
I decide that I would like to combine both routines into a single 
program. They each wrapped their code up in a context and exported 
a word 'process-image, like so:

	; From author #1
	context [
		set 'process-image does ...
	]

	; From author #2
	context [
		set 'process-image func ...
	]


You can imagine that each of these "modules" also has a large amount 
of supporting code, local variables and functions, and each is in 
a large file on the respective author's website. Somewhere in the 
middle of each of these files, in the CONTEXT body code, are the 
SET lines which export the words into the global context.

When I write my program to combine both of these "modules", I will 
probably write code like:

	; Acquire all dependencies
	do %image-processor.r  ; By author #1
	do %super-gfx.r  ; By author #2

	; Create an image and manipulate it.
	my-image: make image! 400x400
	process-image my-image ...


and here I realise that there is a name-clash with the 'process-image 
word, which is set only to the value exported by the second author.
So what do I do?

Here are some theoretical approaches, which have their own problems.

1) I could reload each file just before use:

	do %image-processor.r  ; By author #1
	process-image my-image ...
	do %super-gfx.r
	process-image my-image ...


  Each "module" is not expecting to be used this way, so this has problems 
  like:

  - "Static" locals which are intended to remain in memory will be 
  lost each time the file is reloaded.

  - Performance could suffer; each file could be large, and many calls 
  to 'process-image might be done.


2) I could set the first imported word to my own chosen word before 
importing the second "module". eg

	do %image-processor.r  ; By author #1

 process-image2: :process-image  ; Create an alias, as 'process-image 
 will be overwritten next line.
	do %super-gfx.r  ; By author #2

	; Now use
	process-image2 my-image ...
	process-image my-image ...


  But this means that a line of code has been created in the dependency 
  acquisition stage which has a complex interdependence between the 
  two "modules". They are not independent, and so individual dependency 
  acquisition lines can't be easily copied from this code and pasted 
  into a new script and expected to work right away. If copy/pasted, 
  the code will have to be examined, probably in great detail, to discover 
  what's going on and how to make it work. This will lead right back 
  into each source file, where the SET lines which export words to 
  the global context must be found. What great fun that will be in 
  a large software system built using many modules.


Another approach could be to try to bind each module code to a new 
context which contains the exported words, so they are isolated from 
each other... but this is complex.


All the above approaches are attempting to work around a single problem: 
that each "module" is exporting words where and when it likes, without 
consideration for the environment (other "modules", other global 
words etc.) This is "global namespace pollution" and the approaches 
above just introduce more problems in trying to work around it.


The solution to all this, is, in my view, for modules to declare, 
in the script header, the words that are intended to be exported, 
but for the module code not to actually perform the exports. This 
should be done by the user code, at its option. If a large module 
provides an API of 10 functions, then those function words should 
not be forced into the global context. The user script should be 
able to choose which, if any, of those words to import, and into 
which context it would like to import them. Additionally, the exported 
word value should be importable to a differently-named word, which 
can solve the name-clash problem we have above.

If modules do not use SET, but instead declare their "export" words 
in the script header, then digging through code to find side-effects 
should no longer be necessary. In R2, this requires that all module 
authors adhere to this type of module system, and declare their "export" 
words in a standard fashion.


In R3, I'm hoping the module system will develop into one which can 
enforce the modularity of modules, so that a user script can be sure 
that there were no side-effects introduced by loading any module.

So why not do something like this?
REBOL []
[
   process-image: func ....
]
................
image-processor: make object! load %image-processor.r
super-gfx: make object! load %super-gfx.r
image-processor/process-image foo
super-gfx/process-image foo


Static locals stay in memory, there's no extra steps to deal with 
conflicts, no special voodoo..  And, whenever process-image is called, 
it's obvious from where.

Izkata, that's not a bad approach, but it has these problems:

1) LOADing a module is not quite the same as DOing it. DO sets up 
the current directory and system/script object correctly. LOAD doesn't, 
so the module might not be able to inspect itself and know about 
its location etc.

2) In trying to avoid setting words in the global context, you're 
setting words in the global context. Now you must use paths to get 
to what you want. This should be at the option of the user script. 
Obviously, you're exercising that option in your example. You could 
also do it this way:

 process-image1: get in context load %image-processor.r 'process-image
	process-image2: get in context load %super-gfx.r 'process-image

I wanted it by default, but the REBOL standard is to do the easy 
thing by default and the advanced thing with /only.

we could do code inspection, but its pointless cause its easy to 
circumvent anyways.

load: func [
	{Loads a file, URL, or string.}

 source [file! url! string! binary! block!] {Source or block of sources}

 /header  {Includes REBOL header object if present. Preempts /all.}

 /next    {Load the next value only. Return block with value and new 
 position.}

;	/library {Force file to be a dynamic library. (Command version)}
;	/markup  {Convert HTML and XML to a block of tags and strings.}
	/all     {Load all values. Does not evaluate REBOL header.}
	/unbound {Do not bind the block.}
	/local data content val rst tmp

][  ; Note: Avoid use of ALL and NEXT funcs, because of /all and 
/next options
	content: val: rst: tmp: none ; In case people call LOAD/local
	
	; Retrieve the script data
	data: case [
		block? source [ ; Load all in block
			return map x source [apply :load [:x header next all unbound]]
		]
		string? source [source] ; Will convert to binary! later
		binary? source [source]
		; Otherwise source is file or url
		'else [
			; See if a codec exists for this file type
			tmp: find find system/catalog/file-types suffix? source word!
			; Get the data, script required if /header
			content: read source  ; Must be a value, not unset
			case [
				binary? :content [content] ; Assumed script or decodable
				string? :content [content] ; Assumed script or decodable
				header [cause-error 'syntax 'no-header source]
				block? :content [content]
				'else [content: reduce [:content]]
			] ; Don't LOAD/header non-script data from urls and files.

  ] ; content is data if content doesn't need copying, or none if it 
  does
	]
	;print [1 "data type?" type? :data 'content true? :content]
	if string? :data [data: to-binary data] ; REBOL script is UTF-8

 assert/type [data [binary! block!] content [binary! string! block! 
 none!]]
	assert [any [binary? :data not header]]
	if tmp [ ; Use a codec if found earlier
		set/any 'data decode first tmp :data

  ; See if we can shortcut return the value, or fake a script if we 
  can't
		case [

   block? :data [if header [insert data val: make system/standard/script 
   []]]

   header [data: reduce [val: make system/standard/script [] :data]]

   (to logic! unbound) and not next [return :data] ; Shortcut return

   any [next any-block? :data any-word? :data] [data: reduce [:data]]
			'else [return :data] ; No binding needed, shortcut return
		]
		assert/type [data block!] ; If we get this far
	]
	;print [2 'data mold to-string :data]
	
	if binary? :data [ ; It's a script
		unless find [0 8] tmp: utf? data [ ; Not UTF-8
			cause-error 'script 'no-decode ajoin ["UTF-" abs tmp]
		]
		; Process the header if necessary
		either any [header not all] [
			if tmp: script? data [data: tmp] ; Load script data
			; Check for a REBOL header
			set/any [val rst] transcode/only data
			unless case [
				:val = [rebol] [ ; Possible script-in-a-block
					set/any [val rst] transcode/next/error rst
					if block? :val [ ; Is script-in-a-block
						data: first transcode/next data
						rst: skip data 2
					] ; If true, val is header spec
				]
				:val = 'rebol [ ; Possible REBOL header
					set/any [val rst] transcode/next/error rst
					block? :val ; If true, val is header spec
				]
			] [ ; No REBOL header, use default
				val: [] rst: data
			]
			; val is the header spec block, rst the position afterwards

   assert/type [val block! rst [binary! block!] data [binary! block!]]
			assert [same? head data head rst]
			; Make the header object

   either val: attempt [construct/with :val system/standard/script] 
   [
				if (select val 'content) = true [
					val/content: any [:content copy source]
				]
			] [cause-error 'syntax 'no-header data]
			; val is correct header object! here, or you don't get here
			; Convert the rest of the data if necessary and not /next
			unless any [next block? data] [data: rst: to block! rst]
			if block? data [ ; Script-in-a-block or not /next
				case [

     header [change/part data val rst] ; Replace the header with the object

     not all [remove/part data rst]	; Remove the header from the data
				]
				rst: none ; Determined later
			]
		] [rst: data] ; /all and not /header
	]

 ; val is the header object or none, rst is the binary position after 
 or none

 assert/type [val [object! none!] rst [binary! none!] data [binary! 
 block!]]

 assert [any [none? rst same? head data head rst] any [val not header]]

 ;print [3 'val mold/all :val 'data mold/all :data "type?" type? :data]
	
	; LOAD/next or convert data to block - block either way
	assert [block? data: case [
		not next [ ; Not /next
			unless any [block? data not binary? rst] [data: to block! rst]
			data
		]
		; Otherwise /next

  block? data [reduce pick [[data] [first+ data data]] empty? data]
		header [reduce [val rst]] ; Already transcoded above
		binary? rst [transcode/next rst]
	]]
	
	; Bind to current global context if not a module
	unless any [ ; Note: NOT ANY instead of ALL because of /all
		unbound
		(select val 'type) = 'module
	][
		bind/new data system/contexts/current
	]
	;print [6 'data mold/all :data 'tmp mold/all :tmp]
	
	; If appropriate and possible, return singular data value
	unless any [
		all header next  ; /all /header /next
		empty? data
		1 < length? data
	][set/any 'data first data]
	;print [7 'data mold/all :data]
	
	:data
]

you can't really catch all possible variations of things like: do 
reduce [ to-set-word "tadam"  44]

I guess a lot of what load used to do is now in the transcode native?

No, to-block and transcode make unbound words. If you *don't* specify 
LOAD/unbound, LOAD won't bind the words, which it actually has to 
do explicitly with that BIND/new statement.

I think VAL has a right to exist (with that name), because just after 
it is first set, you don't know whether it's a header block or not. 
You have to check. At the moment you have determined that its value 
is a script header, then you can do:

	hdr: val


which does mean you now have two locals, HDR and VAL, but I don't 
know any other way of preserving the clear and unambiguous meaning 
of a variable.

Anton, is there a reason COMPOSE won't do what you need here?  If 
the objective is to avoid creating a temporary block, compose does 
it.

The lowers levels should then have been tested better, before going 
into higher levels. When you fix a bug on a low level now, it could 
have significal influence on higher levels, so more tests and probably 
new bugs. Problem is the low levels are hidden from us.


Memory problem on OS X concern me a lot. Also today I wanted to do 
some test on issue! datatype, and get strange results. Like doing:

i: #
insert i "abc"


If low level series handling like this has bugs, then I'm very concerned.

Henrik, when I made Canvas RPaint, you helped a lot with testing. 
And I didn't move ahead, before everything worked completely. That's 
the way to do large projects.

Geomol - I have to object. Before complaining about the way the projects 
is run, please check the following:


 - do you really understand, how the project is being run at all? 
 Because quite frankly, you are not using fair arguments here imo. 
 I can agree, but only to some extent, that things are being done 
 in a chaotic way. But - being close to Carl and trying to listen 
 to him and COMMUNICATE with him, I can understand the aproach he 
 takes. 


- one of your false arguments is, that putting things into CureCode 
is not helpful - CureCode was chosen by Carl and the community as 
a streamlined channel for bug reporting. Now please don't tell me, 
that even some low level bugs are not reported? There is a changelog 
which simply proves you being wrong.


- Before some releases Carl asks BrianH to change CureCode items 
rating to fix most important stuff - so how comes that our aproach 
does not work? Please post bug reports, talk to Carl or BrianH to 
raise the importance - doesn't following section show we finally 
got our requested - release early, release often?
http://www.rebol.net/wiki/R3_Releases


- and to be honest - you are one of persons being added to the r3-gui 
world. Some time back Carl had to add even lamer like me to the list 
:-) - and you know why? Because he was not getting much of response. 
He nominated top community gurus to help with the GUI. Actually, 
the same happened during the Gab's VID3 project - only me, Henrik, 
and BrianH commented. It seems to me that some ppl prefer to chat 
about science and belief systems instead of helping to develop R3 
;-) (I am not dismissing anyone's right to come here to chat about 
anything - this place is really a rebol pub where we meet, but the 
other worlds were specialised, yet lacked the input from community, 
even if asked for help)


- in order to get more ppl involved in R3 development at native level, 
it is clear where do we need to get - we've got R3 chat to be base 
of new Altme, new BBS, new DevBase. In March plan Carl clearly outlined, 
that in order to get sources out, we need rebin, plugins. They are 
now postponed due to modules, security, but still a high priority. 
How do I know? Because I was not lazy and asked Carl the specific 
question.


- we also get improvements on other fronts - we have got new streamlined 
Docs. I suggested Carl to add community section, then also new R3 
section to rebol.com page and to produce detailed changelogs. These 
all are small steps, but steps which make a difference.


Now please tell me - how complaining here can make situation any 
better? How many bugs have you posted, how many rebdev messages you 
have asked to Carl? Why don't you talk about your concerns with Carl? 
He will respond to you, like to me or anyone else - either via chat, 
or via a Blog article.


As for me, I am quite fine with how R3 is progressing last few months. 
Yes, we are slow on the whole project, but we are still doing a good 
progress imo.

Responding to Pekr's comments:


- I've communicated with Carl privately before. Starting on the OS 
X port more than a year ago is one example. Lack of info back to 
me made me stop. It's in a group in r3-alpha, you don't have access 
to.


- About CureCode, I didn't argue, it's not helpful. I don't care, 
what bug report system is used, as long as it works. Curecode is 
one of the best such systems, I've seen. Yes, low level bugs are 
reported. That's not the problem. It doesn't make much sense to me 
to work on a building (in lack of better metaphor) at the 123 level, 
when the basement isn't stable. Question is, how long this situation 
will last, before I see a stable version across platforms. My guess 
is years, therefore my concerns.


- r3-gui. Again it doesn't make much sense to me to work on GUI, 
if the core has many bugs.


- You list many topics in monthly plan. Development is going on at 
all levels of the building. I would start by making a solid basement, 
then make my way up. Making any level finished, before going to the 
next. It's just another way of doing things. I have good experience 
doing it the way, I try to describe.


- About docs. It's about time, something is done with the docs. I 
had huge problems figuring out, even how to test R3 back in the r3-alpha 
days. Docs were confusing, lack info, etc. Some months ago I tried 
to figure out, if I could port Canvas RPaint to R3. I stopped quickly, 
when I couldn't find the docs to do even simple things.


Well, you ask, why I complain. Initially I just said, how I felt. 
Loosing faith in the project. I really hope, it'll happen one day. 
But as I see it, it'll take years. I feel like sharing this view 
with others. Then you can use it as you wish. I need to figure out, 
what I'll do with my own development.

I have access to all worlds I know development went in - r3-alpha, 
r3-gui, and I of course remember your effort. It is not the time 
(yet) to do solid porting to another systems by ourselves. So far 
only Carl does some ports, bu those should be regarded being experiments.

It is not the time (yet) to do solid porting to another systems by 
ourselves.


Good info! I should have known that 1.5 years ago, when porting was 
a topic.

Do you think, the time will ever be right for people doing such ports 
to all different kinds of OSs? A situation, where the OS-dependent 
parts of R3 will be open source and documented. I have my doubts.

I do remember myself panicking xy times in the past. Other panicked 
too - we all arged Carl to get back to finishing Core first, then 
move forward. But Carl thinked otherwise - that R3 is good enough 
to attract new users via GUI. You all surely know, how difficult 
it is to change Carl's mind. But OTOH Carl listens to what we say.

So the answer to your question is - yes, I really think we are months 
at max away from the source releases and real porting efforts. In 
the meantime, do what Maarten suggests - just sit and watch, and 
accept things being just an alpha, not a beta ...

Pekr, I just started my old r3-status.r from the r3-alpha world.


One of the top priority bugs in that is #60 division by zero. I went 
to Curecode and read about the bug dated 4-Jun-2007, and I tried 
it in latest R3. It's still there.


Another high priority, #115 dated 11-Jun-2007 has status waiting. 
Waiting for what?


A third is about money! datatype, #250. Currency now seem to be removed 
from R3, so it can't be tested anymore. So R3 will not have currency?

etc...


So you see, there are lots of things to put in rock at the lowest 
level. So no need to discuss all the higher level things (from my 
viewpoint), before those lower levels are fixed.


An example of backward development or bad planning or whatever. The 
issue! test, I just wrote about. It seems to be because of unicode. 
So the plan for all this wasn't made, when the issue! datatype was 
programmed? Now what? Do we have to roll all back and do heavy testing 
again at the lowest level?

I made r3-status.r script based on that list from Carl. So no, not 
ignored.

I also worked with someone in r3-alpha to do tests, that would make 
all those low levels a green ok in r3-status.r.

I hope, I'm not complaining too much. I see my comments here as just 
stating, how I see the situation. How long, I feel, it'll take for 
R3 to be, as I would like to see it. It's just my opinions. I would 
love to see e.g. my paint program on all platforms. I realize, I 
don't get that using REBOL. So I have to figure out, what to do then.

You should also note that for ppl who do care, and are trying to 
help, such comments are really frustrating.

Geomol - ppl who do nothing for R3 do wait. Others try to help here 
or there, as their time permits ....

But - one thing worries me anyway - R3 http scheme is out for how 
long - 2 years? And we don't even have proxy for it. Not to mention 
other protocols. So if we (community) can't find some time to do 
other schemes, where's our help then? The thing is, that schemes 
stuff is really difficult. I can imagine myself doing some easy styles, 
but surely not complex thing as network protocols :-(

Geomol - new http 1.1 scheme was done by Gabriele. And the only reason 
I mentioned it is, that it is an example of open-sourced stuff, where 
community could help, yet nothing like that is happening. Now what 
does it have to do with how deep is such stuff on Carl's list? - 
it is open sourced. And once again - see your arguments. So you DON'T 
know there are any networking related bugs, yet you claim you are 
not willing to work on it, as you suppose there are some "first levels" 
related bugs :-)

Anyway - no point for me to participate in that discussion. I stated 
my opinion clearly - ppl either do want to help, or they don't. Choose 
your side ...

I wish, people wont see my words as complains. I'm not complaining. 
I'm just stating the facts and how I see the future of the R3 project. 
I would love to be proven wrong. In the meanwhile, I will have to 
figure out, what to do with some of my developments. I love R2, and 
will continue to use it daily, because there's nothing better out 
there for many things. But not all things.

R3 is a work in progress it's normal to not already do heavy things 
with it. But at same time not using it doesn't help to find the problems 
it has to solve them