AltME groups: search

Maxim wrote: "gfx will be a little different pixel wise"


Do you mean, 2D graphics will look at bit different, if using OpenGL?

I would wait a bit - maybe someone builds some R2 kind wrapper as 
an extension, so that producing extensions is easier :-)

I've used the R2 /library often and a part from mapping a few of 
the simple windows MAPI functions, I've never gotten it to do anything 
usefull and fantastic because there are simply so many discrepancies 
in types... callbacks crash notoriously and things like arrays and 
pointers are fudgy at best.


A part from the suggestions above, it is ALSO possible for us to 
build an extension which does dynamic library binding on the fly. 
 But that will require a bit more research to get working.  basically, 
we could build an extension which mimics and improves the /library 
system.

so, Robert, not sure if you understood all of these replies as even 
I had a bit of a tough time to "get" them.


Right now, Extensions only allow REBOL to call functions from a dll. 
  What I would like is to simply improve the extension model so  
it can also call REBOL code, as a callback or something else, but 
there are a few issues which make this a non-trivial thing to do.


So far there seems to be a generalized idea that there should be 
a different kind of extension which allows this, but I see no reason 
why it should be another, different. api.  having one DLL   for  
REBOL -> DLL  and another for  DLL -> REBOL  makes absolutely no 
sense to me.   IMHO we need a single DLL able to do both.  Even if 
it means a little bit more work to design it.

Ok, so I've not yet provided everything that you'll need to do it. 
I divided the
 extensions release into a few stages:

1. simple - 
just simple access to commands and args
2. series - access to series 
values of various types
3. objects - access to objects (of all types)
4. 
codecs - support for codecs
5. host-lib - ability to bundle extensions 
with the host-lib itself.

So, I need to get you a bit more... in 
fact along the lines that you mention.

I know you are really chomping at the bit for callbacks, and were 
really hoping that the host code would allow you to hack them in 
yourself, but you're out of luck there. Your callback proposals didn't 
take tasks into account anyways. You're still going to need device 
extensions. Fortunately, you can probably help design the model for 
those :)

but the coupling with the core run-time is practically abscent.  
there is only one function I can use to have the run-time do anything 
and thats a pretty simple... do_rebol_string() which basically runs 
a block of code in the global space... beyond that I've only got 
network/file like ports, which basically are streamed I/O.  


I can't create data directly and leave it at the port, in a block, 
like I'd do for a proper event queue.   This is currently my pet 
peeve about the host... 


but let's not be judgmental... I'm VERY happy I have the host, so 
I can at least try to rig something up with bailing wire, duct tape, 
pliers, a bit of string & epoxy glue.  


 Extensions & the core allows me to hide this under a nice fiberglass 
 body  ;-)

yay!  real event model in place and functional for the OpenGL extension... 
its not a permanent solution but it will do for now.f


now the tedious job of creating stubs for a few hundred functions 
begins!


and hopefully by next week the first applications to show this off 
will be demoable  :-)


currently, including callbacks which create an object at each refresh, 
I can't  resize the window faster than the engine can redraw it (up 
to 1440x900, in 32 bit color, with a few shaded polygons ) , and 
this includes hundreds of lines of rebol being printed in the DOS 
shell.

yeah but unsigned could be a bit in the integer.  it would help for 
many things... MANY values can't be negative.  I would love to have 
an quantity! type. which is just like integer but without possibility 
for negation.

when I said "a bit in the integer" I meant in the integer's internal 
datatype... but a quantity! type would be even better.

I think that some users and especially novices might still welcome 
a bit improved /library interface to the full fledged Extension possibilities 
...

pekr, read Ladislav's DLL document a bit, and yess, it provides usefull 
information ...  gotcha's mainly which point out a few things, not 
to forget when defining the struct! dialect and other details.

... and if it will a bit more powerfull, than R2 version, even better 
(referring to Ladislav's proposed enhancements)

$ file ext/sample.so 

ext/sample.so: ELF 32-bit LSB shared object, Intel 80386, version 
1 (SYSV), dynamically linked, not stripped

There won't be 32 and 64 bit builds on the same platform, in theory; 
32bit builds get one platform number, 64bit builds another.

so I've been looking into this a litle bit, and it seems like a portion 
of the /library extension might be a pain to implement... so far 
it seems like I will have to add in-line assembly, since I haven't 
found any C routines or macros which handle the puch/call/pop aspect 
of the program stack (not saying it doesn't exist, just that I haven't 
found any).

I'm still looking for a definitive dll calling convention example... 
AFAIK this has to be pretty set in stone... or dlls would quickly 
be incompatible between vendors.  

Then again, its possible the DLLs contain some calling convention 
parameter...   if anyone has a bit of experience in this (and can 
point me to understandable docs) I'd welcome a few pointers (pun 
intended ;-).

for windows, the calling conventions used by the OS seem to be pretty 
standardized and simple.  which is nice.  So far it seems to be a 
bit more sprawled for linux.


first release of the /library extension will be 32 bit only, but 
when we have a 64 bit REBOL it will be pretty easy to adapt... in 
fact, MS/intel did their homework for 64bit, it seems, and there 
is only ONE calling convention for that platform.

so you can work like draw, keeping just the rebol version and convert 
it at every call, or manually convert it once, and then reuse it 
over and over.  

this will allow us to chose between ease of use or raw speed (with 
a bit more management in our code).

I'm officially a geek... I actually laughed when I read a bit of 
ASM that had the   lea   instruction in it.. and instantly remembered 
what it meant hehehe  


three little characters, pop up 17 years later and my mind does a 
180 degree shift    :-)

Maxim did a bit of research into a non-task-safe workaround to create 
callbacks.

we are talking an expert PARSE user, and so far , this would be his 
main reason to move to R3, but then all his prior code isn't upgraded 
so its a bit daunting to just plunge right in the middle of a project.

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

Here are two functions I created to handle strings a bit simpler:

continuing Request for object lookup within host/extensions here....



Here is a proposal (using example C code) for OBJECT access within 
extensions  this uses the EXACT same API as commands, and with just 
a little bit of work on the extensions API by Carl and a single hook 
within the r3core, we could allow callbacks within objects.


the advantage is that we re-use the same safe sand box as commands, 
and don't require to do much coding to enable it, AFAICT.


since object lookup is performed on demand, we can very rapidly supply 
an object to the command, and it doesn't cause any heavy-handed conversion 
at each command call if the object isn't needed.  more fine-grained 
control could be added so we don't need to frame the whole object, 
but it would be usefull as-is already.

RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	i64 i;
	
	// objects are frames, exactly like command arguments.
	RXIFRM *obj;
	

 // return values are also frames (with one argument), for type-checking 
 purposes.
	RXIFRM *rval;
	
	if (cmd == 1) {
		// ask the core for a frame which represents object.
		// attributes are returned in order they appear in object
		//

  // the command frame doesn't include the object frame, only a handle 
  to the

  // object which the core can understand. we then ask for the object 
  frame on-demand.
		obj = RXA_OBJ(frm, 1);
		
		switch (RXA_TYPE(obj, 1)) {
			case RXT_INTEGER:
	            i = RXA_INT64(obj, 1);
				break;
			
			// we could build a frame for supplying arguments to the eval
			case RXT_FUNCTION:
				rval = RXA_EVAL(obj, 1);
				if (RXA_TYPE(rval, 1) == RXT_INTEGER){
	            	i = RXA_INT64(rval, 1);
				} else {
					// return error
				}
				break;
			
			// wrong type
			default:
				// return error
				break;
		}
		
		// do something with the value
		my-native-function(i);

	}
}

so what do you guys think?

and my tests (with a fix or two)  and successfull builds probably 
helped him be a bit more confident.

utility functions like  synchronise would be nice. but they would 
be something you call manually.   I find its always better when the 
code actually implements the paradigm, rather than trying to hide 
it.   a bit like Apple's GDC.  you explicitely create little tasks 
which you launch and wait for completion.  its simple, obvious and 
highly scalable.

Agreed, with the goal of gathering information, though I'm also a 
bit hesitant as he may have strong feelings and ideas already. 

I'm good with a wiki though. Where?

I have no idea on how date values are stored in C, all that the docs 
say is that date values are 32 bit encoded date and time zone values, 
so I mainly tried with value.int32a but tried other members too. 
I have no idea about how the encoding is done and - as Anton said 
- I really don't want to reverse engineer it.

There are things that have to be cleaned up a bit first, Graham, 
but I hope I can publish it very soon (counting days, not weeks).

Yes, I saw the ticket ... maybe it gets fixed in a110, but not sure 
it is a cause. BrianH discussed it a bit today ...

Yes, a bit. There may be a simpler way. Or we could bundle a few 
such helper functions into a support library (as Max did in his OpenGL 
work).

ah, I did a little bit of searching and I think I understand... 

try using RL_PRINT() instead.

Than you mentioned the wrapper you're going to write. Let me think 
about that a bit.

but it a little bit complicates the automatic building of wrappers 
for functions like that. btw... at this moment I can build imageMagick 
extension by parsing it's doc (~4500 lines of C code:).  Just must 
solve a few functions where it's using this approach to return multiple 
values and add some validity checks to make the extension safer.

For one thing: system/options/default-suffix. For another thing, 
platform-specific stuff doesn't go in the mezzanines, it goes in 
the host code, as a (really strict) rule. For most code that needs 
extensions there is assumed to be a bit of platform-specificity, 
due to the nature of extensions. Nonetheless, this is why LOAD-EXTENSION 
is implemented in the host code, and why we can reference functions 
by word name.

Doesn't necessarily have to be IMPORT. I agree with Brian that we 
probably want to have extension loads "stand out" a bit.

Unfortunately, there's an error in its fallback behavior that makes 
it a bit difficult to use. In its docs, section 3.7:

 If there is no applicable REBOL datatype to contain a SQL value, 
 the value will be returned as a string.

The binary data is returned in a value of the string! type, rather 
than of the binary! type, which results in a corrupted string that 
you can't do anything with. If the value was returned as a binary 
then we could perform the conversions ourselves. I ran into this 
problem when returning SQL values of the tinyint and text types.

most of R2 GUIS did not rely on timers...

, why should they? R3GUI can be perfectly functional without timers, 
only bit boring.

Returning (with some effort) to serious consideration of your argument; 
I'm in agreement (how could I not), but I would like to point out 
that it's a bit like a slippery slide argument: if I accept to add 
just a few more characters (? -> -of) then I'm on the road to creating 
the API with the most unwieldy extra long function names as found 
in other languages (without the utility of Rebol contexts at their 
disposal).

Win Vista, 32-bit. RMA A110 build, tried with downloaded and also 
on-line r3-gui.r3 populated using load-gui function. Do the script 
once, press some button, close it, do the script the second time, 
press the button - crash ...

I think that talking a graph style, if we don't have tabs, tree, 
grid, is a bit preliminary. We need imo basic styleset, usefull to 
work with general DB apps, then we need more modern skin, and only 
then we need additional styles. We still can't see even concepts 
as accelerator keys being displayed, etc. :-)

Shadwolf - this is not the right group to discuss advocacy/strategy 
kind of things. But here's my take:


- RMA is a commercial entity, and Robert made it clear enough - they 
develop GUI to the point, when it will be usefull for their business 
apps. The chances are, that if it is good for them, it will also 
be good for others


- Robert is a good guy! He pays several top community guys, and - 
he gives result of such work - FOR FREE!


- RMA guys are VERY open, to listen to other's opinion, it is just 
they will accept only REALISTIC proposals - trying to convince them 
to change to differet underlying toolkit CAN'T work at this point. 
Even if such a toolkit would be good time solution, there are no 
free resources to make such a big change


- RT (Carl), plus the community, should be gratefull, to have at 
least RMA's GUI, if there is not other gui in the spot, and RT itself 
is not active in that regard.


- If I should name at least something what I am not considering so 
optimal, then it is a bit of a closed nature of development. I mean 
- I might wrongly understand initial impression of a SCRUM model. 
I missed the big picture, plus particular reports ... but - ANYTIME 
I was not lazy to ask, my questions were answered. Anyone but me 
can do just the same - ask. This is called - communication :-)

So much for RMA and their relation to development of R3 GUI ....

that may not help, I probably have a bit newer code

It works. But it was not enough to just change the view-show.r3 code, 
and call it after do %r3-gui.r3, as the initial redirection will 
remain. A bit tricky, as there is no script to build new r3-gui.r3 
from sources, and sources are collapsed, but I managed it to change 
:-)

The reason we didn't allow object! for options was the 'inconsistency' 
of:
make object! object!
vs.
make object! [block! | map! | none]


in R3. We might add support for object!s but it will make the function 
a bit more complex.

yes, sorry, wait a little bit, I am at our subsidiary. But maybe 
I could discuss it personally with Ladislav, as I am in Turnov, some 
20 km from Liberec :-)

that's rather easy, but not easy enough. Still a different concept. 
You guys act like button is a text, and it is not :-) If I will have 
whole screen of the same buttons, I might use stylize, e.g. for the 
calculator widget, as an example, becuase constantly repeat button 
30x30 is not convenient for me. But it still does not mean, that 
ocassionally wanting to have button a bit differently sized does 
a damage. Do you think users are crazy and will make each button 
differently sized, just because they can? :-) (Well, as for MS Word 
files, some users are able to create completly twisted texts, bu 
still - that is a text, difficult to restyle ... while we are talking 
GUI here.

Ocassionaly having bit differently sized button sounds like inconsitent 
UI to me.

Guys, I just read through all this and I'm confused a bit why it's 
so complicated.

Cyphre - you misinterpret me a bit - on one hand, yes, I think those 
are usefull to have for occassional GUI hackers, for the fun factor. 
If user is an idiot, and wants to define each button differently, 
so be it - there is analogy with inline CSS style. But if we allow 
it, the behaviour should deliver it ...

Yes, no problem. But just to get a different init-size it's a bit 
overkill, or am I missing something?

Brian, correct. Pekr, either you as user will understand and agree 
the rules or you need to lear a bit more and become 'style tweaker'.

I am going to work on it a bit today, and tomorrow, then I can release 
what I have ...

Rebolek - will it not complicate a bit design/syntax of style? so 
instead of facets [size: 10x10 color: blue  text: "test"] we will 
see maps? Or will it be hidden in some lower level?

Henrik - am I right thinking, that 'materials do affect only area-fill 
parameter in the draw block? I am a bit confused - I can see various 
colors in styles, hardcoded. So what actually material system abstracts?

So to follow point 5. above here is some update:


The next public release will be postponed to the end of the next 
week (current estimation). As we need to do some 'major' changes 
to the resizing concept. We need to add more flexibility to the system 
internals to be able implement proper column/row resizing (also used 
for dividers)  etc.


Our current internal version have lot of improvements but it will 
be better to wait a bit to not confuse developers with 'obsolete 
methods' that will be changed in the planned major update.


We are also preparing much more documentation to make things easier 
to understand.

hmm, interesting :-) I am curious what others think. It kind of adds 
another level of possibilites into the system, but maybe it makes 
it a bit more complicated too? :-)

By 'you are wrong' I meant your understanding whe 'cascading styles' 
really are is a bit blurry...if you check the 'selectors' section 
you'll see that this topic can be a bit more complex.

I've done a few quite complex CSS setups working with jquery, and 
at some point, CSS selectors become very brittle because the priority 
rules become a bit hard to properly prioritize.   


To reflect this, in some setups not all browsers actually match the 
same CSS selection rules.

But - it might be a bit different anyway. If you make b1: button, 
it is a set-word, a name. And now how do you use stylize, to refer 
to such a name? Stylize creates new style name, e.g. b1, but that 
is direct name for the style itself

Panel example #35 - I just wonder, how many ppl will feel lost the 
same way as I feel. The naming terms in regards to results are difficult 
for me to resolve. As for alignment, there is several way of how 
to name things:

halign, valing


left , right, center (vleft, vright, vcenter, hleft, hright, hcenter)


left, right, center, top, middle, bottom (or the corner alignment 
-  top-left, top-right, buttom-left, bottom-right - if those would 
be used, I would immediatelly understand it)


But - let's try to think about it a bit - we have some alignements 
in various GUI levels. If possible, let's stay consistent (e.g. it 
is enough that low-level text handling uses MS Word like terms, which 
don't relate to the rest of the gui)

frame name works better for me than box-model, although it suggests 
a bit - frame - yes or no? frame-type would be more descriptive, 
but longer. I would be ok with frame, frame-type (mode), draw-mode 
- all better than box-mode imo ....

The question is, if we can please all users. Some will like borderless, 
backgroundless clean style. Some might want frame around the panel, 
and I can imagine users wanting just a bit different color or gradient 
to distinguish the panel from the surrounding.

Ladislav - I know, but imagine user will just want above mentioned 
variant - panel, which will be distinguished by a bit brighter bg 
color, not a drawn frame.

Cyphre:

box-model:
---------------


Few notes. Certain systems use FLAGs, which could be thought about 
as kind of switches, or representing certains states, etc., used 
in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging 
- it is used mostly to mark particular face as behaving some way, 
belonging to some area, etc. And in that regard, I wonder if box-model 
type could be done just by using TAGs? 


What I think about TAGs in GUI in general is, that we don't use the 
concept to the max. I mean - if tags were not be flat block, but 
block of blocks, it could be used even more, e.g.:


tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] 
resizing-mode [.....] ....]


Of course that might not work for us in all cases, because as you 
could see in above example, it would be difficult to distinguish, 
if something should be a facet, or a tag. E.g. if we would move DRAW-MODE 
into TAGS, then why not moving MATERIAL there too, etc. My question 
is - is there any rule for me to remember - what should be a facet, 
and what could be a TAG? (I expect the difference in how you work 
with them underneath)


My general problem is, that FACETS block is becoming long and messy, 
so what to do about it? There were following suggestions to think 
about:


1) close particular settings in subobjects/maps (whatever). There 
are settings belonging to the areas of resizing, colors, box-moderl, 
others, etc. The question is, if we want to refer to such values 
by face/color/bg-color for e.g.?


2) the simplest solution is to at least use some source code conventions. 
E.g. Carl introduced comments to particular ACTORS, desribing what 
arguments are supported for the function. So my idea is:

facets: [

   ; colors
   bg-color:
   other-color:

   ;resizing
    resizes: 
    init-hint:
...
]

ALIGNment:
----------------


It is probably not wise to change all subsequent areas to halign, 
valign. But anyway, we are a bit chaotic here, unless someone tells 
me, what's the rule here - to stay compatible to html/css, or to 
be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, 
then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL?


My comment is just food for thought, not a claim to change anything.

Robert - OK, then lelt's keep the organized a bit by spacing (new 
lines) and comments, as I suggested ... that might be enough imo 
and grouping certain areas together helps users to faster identify 
particular related facet?

I guess I'm not seeing how it is any more confusing in code, and 
in docs you can be explicit. But I'm obviously missing something.

Back in a bit.

Well, this is really a bit longish :-) Having fever, it is a bit 
difficult to think for me, but :-):

1) ATTACHED
2) ATTACHING

Hmm,not clear after few secs .... so:

1) ATTACHED-FROM
2) ATTACHING-TO

?

ok, I think I got it a bit backwards, so maybe #3 is OK.

The current overview of all styles:

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

Some more images here:

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

A bit of status:


- Cyphre has recently fixed a bug in the hostkit with the display 
of some unicode characters. Will see if there can be a release.

- Cyphre has been working on fixing various low level issues in the 
R3 GUI source

- Cyphre is working on testing scheme for GUI and some documentation

- Bolek is working on styles and a TODO test application, called 
"Notation" for Robert

- We still need Carl to fix one particular bug, which is prevents 
creating complex layouts

So, I see no one is really interested in this R3 GUI stuff... I'm 
wondering a bit but anyway... I think doing public releases might 
not be worth the effort.

Well, that contradicts a bit expectation, that RMA's GUI is RT's 
officially endorsed GUI to be bundled with R3. OTOH there are no 
official R3 releases anyway, so ....

I understand that you are focusing resources as much as possible, 
otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept 
changes during last year. Anyone eventually willing to give it a 
try once time permits will think twice, as recent public release 
could be pretty much outdated in few weeks, API wise, etc. There 
should imo be a way, that upon some request or bunch of requests, 
public release is done e.g once in few months?

I don't know... it was after some heavy real job made in console. 
I'm using R2 instead.. it's a little bit slower, but stable.

I have a list of fixes and improvements in mind, so I'll see if there's 
some time by the end of this week to put together a patch file. I'm 
sorry that I haven't documented the module system well enough to 
make it practical for anyone other than me to patch it at runtime. 
Improving its documentation is on my todo list, though I've been 
a bit busy at work lately.

I've done quite a few html analysers and with a bit of experience 
I have found that going with a brute force parse on pages ends-up 
being very effective.  I did a font downloading script for www.acidfonts.com 
a few years ago and it took more time to actually download all the 
pages than build the script.  :-)

My approach was, instead of doing what many others do (try to remove 
things from the HTML that are known to be "bad", eg. use regexps 
to remove anything that starts with "javascript:" or anything between 
<script>...</script> etc.), was to only pass what was known to be 
good, and ignore everything else. This is a bit more limiting but 
I consider it to be safer (you don't have to play a game with attacker 
where every time they find a new vector, you have to add it to the 
"bad" list).

just thinking out loud a bit while browsing the host-kit here..

I really just think that maintaining several repos is currently to 
much work since it changes sooo oftern.  once the hostkit stabilizes 
a bit (within two or three releases is my guess) he should get around 
to concentrating on getting other distros their .so  


The amiga port was probably a good exercise in making the core lib 
even more cpu/platform agnostic.

It's become a bit more complicated because R3 is now using the dynamic 
loader, but the Linux library still works on Syllable Desktop

doing a bit of stress-testing... I've just loaded a 15MB polygonal 
model of a tree in my 3d system ... it has ~350000 polygons and ~180000 
vertices.

a bit slow using the current unoptimized Old-school OpenGL commands, 
but I'm still averaging about 10 frames a sec on my 4 year old mobile 
nvidia GPU (which is like 16 times slower than an average desktop 
card of today ).

And as you obviously want to maintain the closed-source nature of 
libr3, that step will already require a bit of work.

Win Vista, 32 bit, Dell Latitude D830, 2GB RAM, Intel Core 2 Duo 
1.8:


Script: "Host-Kit Graphics: Basic gfx benchmark" Version: 1.0.5 Date: 
none
GFX benchmark result
0:00:08.044 49.726 FPS

I blogged a bit about the FreeType implementation in the host kit 
at http://solie.ca/


Besides the bold/italics issue I also noticed the line length is 
not being calculated correctly or similar because the text is rendering 
beyond the window bounds. If we can fix both of these issues I think 
the FreeType implementation should be as good as the win32 implementation.

Christian, what are your hardware specs? Your unaccelereated speed 
is higher than my accelerated one and my video card should be pretty 
good. I'm getting the following stats with a Core 2 Duo @ 1.8 GHz, 
Radeon 5770 (slightly overclocked), Win 7 64 bit:

0:00:08.846 45.218 FPS | 0:00:05.125 78.048 FPS
0:00:08.45   47.337 FPS | 0:00:05.037 79.412 FPS
0:00:08.498 47.069 FPS | 0:00:05.024 79.617 FPS

AdrianS, I measured on a Vaio with a NVIDIA GeForce GT 330M graphics 
card, 8core Intel i7CPU Q 720 @ 1.60GHz, Win 7.64 bit, 8 GB RAM.

wait a bit ... I'll try to redownload Carl's HostKit

Second, the temporary R3A110 repository is even more unsupported 
than usual. Unless you want to work on distribution and building 
of the hostkit itself, it's probably better to stay clear of this 
and  wait until things settle down a bit.

I'll get to that when I start porting View to the Syllable GUI, but 
that project is still a bit in the future

I modified text-test3.r3 script from the host-kit to use normal sized 
font (12) not anti-aliased and used a little bit longer text content 
(but not extremely much. just two lines with length cca 1400 chars)... 
the result is:

Good news: I do not notice any difference between ansi/unicode content.

Bad news: in both cases R3 uses almost 23% of my CPU time when I 
just move mouse over the text, which is pretty much:/

without a 64-bit r3lib, you won't get 64bit builds of r3 any time 
soon :)

I think many people have gone to use SVN and will resist a bit using 
something new.

(The CLI has improved quite a bit in 1.6.)

-O1, 64 bit files, vis=hidden, no-ptr-sign, strip result

yes, in such a sense (expensive change), I understand.  


I will wait for brian to step up and get his opinion.  I know we've 
spoken about this somewhat before, but not as head-on, for myself... 
 With the recent talk about naming, IMHO it has put a new light on 
the possibility for this to be a bit more appreciated, adding ? at 
the end would now mean something concrete.


let it be known that I do like errors, I am not against errors, I 
have been putting less and less error recovery in my code to make 
sure it crashes and I fix bugs early.


its just that I can see many if not most ****? functions (my own 
included) being truthy and this is very usefull to facilitate  control 
flow.  This, as oposed to always putting error handlers in places 
where the error is only used as a negative reply, for which we can 
supply, IMHO, a reasonable value/standard.

anyhow... we are a bit off topic from my original post.    I now 
understand why GC is very slow on large datasets.

In the case of LENGTH? and INDEX?, we are only allowing them to return 
none when passed none, using none as the equivalent of SQL's unknown, 
not N/A. And even those are a bit iffy - we are only planing to allow 
those to have fewer intermediate none checks when doing none pass-through 
on FIND and SELECT return values. However, the disadvantage is that 
errors aren't triggered close enough to the source of the error. 
Hopefully they will be triggered later by ASSERT calls.

obviously, since the GC is a "stop the world" system, I can't fix 
everything, but I might be able to help it along a little bit.

If you want I can write up your reshuffled hierarchy as a CC ticket. 
I think Carl would like it, ans the binding issue has bit him in 
the past.