AltME groups: search

hehe.  if you look at the demo files, you will see how to specify 
a polygon primitive... its dead simple... a list of vertex... and 
a list of faces (which are indices to the vertices)

btw notice that I included your last release of the r3_gui.r3 in 
the cgr-apps to make sure I stay forward complient... though you 
may want to do a diff on the version included and yours in order 
to patch crashing events when they originate from a gob which isn't 
a face.

ok, but I suspect many changes and additions are coming. I'm not 
sure if it will be a problem for you.

henrik yes.  the openGL CGR use the "container" rendering mode which 
allocates a windows control from scratch and adds it to the window.


then when you call show, it gets notified of the change in size and 
automatically updates the control and gl viewport & camera

notice that I do not call show on it in animation.  I call refresh, 
which bypasses view and makes it *much* faster.

I hope Carl and I will agree on some definite way to allow some kind 
of custom data extension.

I need an extra pointer in the C gob structure.  cause basically, 
all the renderer data is gob-centric... right now I'm allocating 
an array and iterating through it which isn't very optimal, though 
this makes it 100% safe in the current host-kit.

Two consecutive runs cause following:

>> do %opengl-complex-tree.r3
Script: "Untitled" Version: none Date: none
Script: "Untitled" Version: none Date: none
IMPORTING LIBS
CANNOT SET CGR LIB MORE THAN ONCE (cgr_opengl.dll)
====================================
OpenGL CGR initialization:
registering polygon primitive
register-primitive() [
        valid-prim?() [
        ]
        cgr-name() [
                OpenGL
        ]
]
====================================
Script: "Untitled" Version: none Date: none


then it stops for a while, then it shows window, and outputs other 
stuff to console ....

if you are showing the tree-heavy, its a 170000 vertice model which 
ways 15mb on disk and 50mb in ram !

on my system tree-heavy averages 8fps at any window size. 


the reason its this slow is that I'm not using any kind of smart 
opengl video ram caching atm.  this will obviously be done in time... 
for now I still need to implement things like a real camera primitive, 
lights and materials.

I don't think it's caused by fan and I'm sure it's not good for hotebook's 
health:)

yep, I read the whole MSDN section on the differences between queue 
and MM timers, they both have advantages.

Cyphre and I prefer to use timer setup funcs rather than merge them 
within the gob infrastructure.

so its probably going to be something like:

timer/cycle 'my-func-timer 0:01:01 my-func
and to stop it just use timer/stop 'my-func-timer

That should be discussed elsewhere, as well as discussed with Carl, 
along the lines of tasking and IPC model, etc. I think that timers 
could be usefull outside the GUI too ...

honestly, I know carl doesn't care about such a trivial issue... 
if we build it and it works why would he argue?  he does listen to 
our ideas when we have tests and code to show.

Maxim, it works for me now, cool. Some notes:

-The usage/interface seems to me too clunky. Better would be something 
like:
append win make gob! [
	offset: ...
	size: ...
	data: context [
		renderer: 'opengl
	]
	draw: [trinagle ... sphere ... whatever] ;your 3d dialect here
]
And that's it IMO there is no need for other 'bloat' around.

-Since you are proposing the CGR philosophy:

1.is it possible to use more than one gl-gob ? I tried just a quick 
attempt but it failed for me.

2. is it possible to compose normal gobs together with the gl? I 
had no luck with this either.

Regarding the performance:

I don't think there is anything to comment at the moment because 
you are just using the raw/built-in OpenGL abilities (same stuff 
we did with Ladislav and Cal 5 years ago in R2). So talking here 
about FPS or number of polygons has the same information as saying: 
"I have older/newer gfx card" The fps is not related to the current 
code...everything is just direct HW executed calls.

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

btw it is working with multiple CGR gobs, the issue is just that 
I'm having a bit of trouble determining exactly what coordinates 
to use  and they are currently always at 0x0 offset.

I'm working on this right now.

FYI, your latest release works for me, Win 7 64 bit, Radeon 5770 
with 10.10 drivers, in the sense of not crashing, but the actual 
3D shape being drawn is not really visible. It is vaguely visible 
as the drawing surface is rendered and you see flickering bits of 
the surface, here and there

as for a screen grab, I think I'd probably capture a black window 
- the actual shape is seen very intermittently, just a flicker now 
and then

yeah, tried to capture and all I get is black

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

I've used this card with a bunch of other 3D demos and with Processing 
(processing.org) and the OpenGL support seemed to be very good - 
must be something specific to the way you set things up, I would 
think

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

I'm using double buffering, and use swapbuffers at each refresh.

Just downloaded the release from yesterday and unzipped over the 
old one.

The zip is a different size, so I don't think so. Complex and Torus 
are dated yesterday, the others for the 25th and 26th.

Max, the AA settings seem to be the cause of the problem. The card 
was set to "Use application settings" and this resulted in the problem 
- guessing that you're not doing everything you should be to set 
AA up. When I uncheck the option (basically have AA globally set), 
your demo works.

Max, I'm expierencing the same flickering as Adrian does, I'm running 
on a 3/4 year old Sony VAIO with Win7. I can't supply any further 
detail, I'm don't have access to the machine right now. I see a flickering 
torus , a flickering  simple tree and no complex tree at all. When 
I'm back at the machine, I'll try with the AA settings which Adrian 
seems to have identfied as the source of the confusion in just this 
moment.

The ulimit sets standard Linux resource limits for the process and 
its REBOL child process that gets started afterwards

The license is BSD, anyone can pick it up and improve it.

Or Montenegro:  only once "organized" business at  https://invizi.organized.ru
 moves off Windows-based pseudo-accounting/audit/governance/non-transparency 
slopware will we have cause to worry.  But the EU forensic auditors 
use Windows, so as long as they are still looking for where millions 
of Euros end up, there will be work to do on Win64, Win128 ....  
And then comes Macedonia ....

nve:          rebol-view-277-3-1.exe  and  rebol-core-277-3-1.exe. 
         Windows version of REBOL

yes... sick.  but back on track and with a successfull showing of 
my 3D R3 to the potential customer.  so the CGR system will continue 
to be evolved after the holidays.

the current version handles multiple 3D view ports and interactive 
dragging of 3d gobs while they are being animated with practically 
no performance loss a part for the 2d gob handling.  I'll check out 
Cyphre's OpenGL tests so see how they can be integrated with CGRs 
so that the complete solution is hardware accelerated.

I'll probably be using my holiday free time to finally release R2 
glass and make a preliminary release of Remark which is tightly coupled 
to cheyenne.

I was getting the impression that R2 glass was out and r3 glass dev 
was on....

to get glass for R3 is a big endeavour, but after the holidays, possibly 
starting in february, I will be working on this.  


right now I've got a very stable glass for R2 which just needs to 
get its last touches applied to current skin and refurbishments for 
the tutorial I had already started building which is now a bit out 
of date with current state of glass.

I parse the fmod.h file and generate the commands... but in some 
cases it require manual overview so that's why some of the functions 
are still missing (and some may not work.. like the CMD_FMOD_Channel_SetSpeakerMix 
where it requires more than 7 args as an input, so I must probably 
manualy modify it. Also it's just the functions exported to REBOL, 
so it may require some more work to be more usable in real life.. 
and I must learn how to do callbacks (my next lesson)

So far I can say, that R3's extension are much more better than R2's 
dll support. At least when you want to do something real. And it's 
usable for C newbies like me.

Robert, Yule is held at different dates, but just like Christmas 
and many other light fests, it's originally the feast of the returning 
light, widwinter. So technically, it would normally be at December 
21

Anton - can't find the comlib group here.


Can you pass a decimal to Excel?  Or do you format it as string and 
pass it as %s ?

I also tried %D for date and got an error .. but %s works fine

Is Orthodox and Eastern rite churches Christmas on Jan 7, 2011  [ 
see discussion on Announce thread ;-)  ]

I have an old one here, will be published soon... seems I need to 
search for the extensive version on my HDs and backups.

Shadwolf: {If I had better relation with Robert and RM-Asset I could 
have updated MDP-GUI the only browser of MakeDoc Pro documentation 
made  in rebol/vid 2. :)} - interesting, what exactly it is you announced, 
then?

If I had better relation with Robert and RM-Asset...

 - few lines of code instead of tens lines of comments can change 
 it in seconds.

It will seamleslly integrate to my Custom Gob Renderer so the same 
GLASS style will be able to render in any renderer for which a compatible 
style was built.   


this means the same layout and interface for a button will be useable 
in a normal AGG render up to a 3D game representation of that button, 
with no user code change.  just a swap in the skin being used.

shadwolf, I'm confused .. you seemed to be working again on area-tc 
and now you're leaving again?  May be you need to take that Lithium 
:(

I am now planning a weekly release cycle.  It will contain all the 
"in-progress" stuff, so will allow people to help in adding new stuff 
if they want.  


If anyone wishes to contribute new styles, new modules, new documentation 
and/or tutorials and  apps, I'll be very happy to include your stuff 
within the distro and properly attribute it.  the only constraint 
is that it has to be BSD and will obviously go through my prying 
eyes, in order to keep consistency with the whole package.

And is it possible to get rid of the library manager so that it can 
be encapped?

and no we cannot remove the library manager.

Thanks. By the way, thanks should also go to Tomas Bonte for the 
bounty, to Tomas and Oldes for testing, and to you, Andreas, and 
Brian Hawley for debugging

I do want to continue with that, but I need to focus first for a 
while on SylCon next week and ReBorCon in a month

I've upgraded the Fossil server for my Red and REBOL repositories 
to version 1.21

Hi all, Andreas created:

    https://github.com/rebolsource/rebol-syntax

and I committed the initial %syntax.r file. Be warned, though:
- it is just a start, many datatypes are missing
- not tested extensively, likely to contain bugs
- CARET-NOTATION defined as in R3

While rebuilding the cloud server that runs this world, somehow the 
old Core group file became corrupted. I have no idea how it happened. 
The tar backup showed the correct datestamp, but the extracted file 
was shorter than it should be.


Anyway... Using a copy of the file from my client, I fixed most of 
it.... but there are quite a few message in that group, so I've renamed 
it, and created this new one to take its place.

How do you get:
newob: make object! [
    catalog: make object! [
	book: [make object! [
	         author: make object! [
	          value?: "Gambardella, Matthew"
	         ]
	       ]
	]
    ]
]

from:

ob: make object! [
    catalog: make object! [
        book: [make object! [
                author: make object! [
                    value?: "Gambardella, Matthew"
                ]
               ]
        ]
     ]
     extra: {don't want}
]


What I really need is the set-word "Catalog:" to be present and not 
just a make object! [book...] which is what I get if I do something 
like newob: ob/catalog. 
Thanks in advance.

Is this what you want?  (newob/catalog and ob/catalog now reference 
the same object, so changes would update both..)

newob: make object! [catalog: ob/catalog]


For them to be entirely independent, it's a bit more difficult (or 
just a long line/multiple lines of "make xxx") - I can't think of 
a simple way to do it.

Thanks Izkata. How simple. And yes, that's fine.

and did you have to manage namespaces yet  ;-)

I think we need to consider what the MOLD output looks like, though 
I'm not sure about Oldes's suggestion of a /heredoc refinement. And 
while I like Ladislav's serialized rebol syntax, I wonder if there 
are other possibilities. Could we leverage the << heredoc standard, 
and would that be better or more confusing with the tag! type as 
a close relative. It also makes me think more generally about where 
it fits in the rebol lexicon. Is it still just a string!, or are 
there wider implications? What do we call it? Is its main purpose 
to make dealing with curly-brace languages easier, and is that just 
a vague "nicer thing" or are there specific cases we have in mind 
(e.g., test cases :-) ? If rebol is still at its heart a messaging 
language, how would we leverage this type of "payload"?

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

...so it has to use escaping for #"{" and #"}"

(that is exactly what you proposed in the Testing and Tools group, 
every test could be)

#[[test
; this is my test
test]]

REBOL is not just a language allowing computers to communicate (if 
it were, escaping would be enough for every string), but also a language 
allowing humans and computers to communicate. And, I do not find 
escaped strings to be easily writable/readable for me, that is why 
I prefer to have the heredoc syntax available.

#[[Graham

Why can't we redefine chars eg. in some sql dialects you can define 
the terminating character.  So, why can't we redefine the another 
character temporarily so that has the same functionality and then 
{} become ordinary characters?

Graham]] - I do not understand how would such a proposal work. Can 
you be more specific, showing an example?

Generally spoken, I do know what the advantages of the heredoc syntax 
are, and I hope I succeeded to communicate that to you. The syntax 
is used in other programming languages, making them more comfortable 
for humans. Not having the syntax in REBOL is not good, especially 
taking into account, that REBOL, as opposed to the above mentioned 
languages, is not just a programming language, meaning, that in REBOL 
you can write more than just programs.

#[[Carl

Although it can be used for programming, writing functions, and performing 
processes, its greatest strength is the ability to easily create 
domain-specific languages or dialects.
Carl]]

I presume the idea of this is to easily generate javascript and the 
like

You as in the generic person and not you as in Ladislav

#[[Graham

I presume the idea of this is to easily generate javascript and the 
like¨
Graham]] - I presume, that I wrote above, that this is not true

Oh, and not just ASCII; full Unicode.

I don't think we can throw away the meta info about it being a heredoc 
string, unless we want to use Oldes's idea of adding a refinement 
to MOLD. And then you have to choose when to use it. While we can 
say that it's easy for MOLD to add escapes to curly braces, that 
doesn't mean it will be easier for humans to read generated strings 
that contain them.


I can't say I've ever needed it personally. The { } syntax works 
well, and is as much support as TCL has for heredoc strings it seems 
(we even have TRIM/AUTO to help with indenting issues).  


I want to like the idea a lot, but I only like it a little so far. 
Mainly I wonder if it's worth adding for the sake of just the curly-brace 
chars. I understand the usefulness for the curly-language and test 
dialect scenarios, I'm just not sure of the cost/benefit ratio.

And once it is loaded, it is a string. There is no escaping in memory.

The proof is in the pudding - even now we do have two syntaxes for 
strings, and no string contains any information specifying which 
syntax was used (it is even possible, that none, since a string read 
from a file was not defined using any of the two.

Because it's complicated? Heredoc is enough for me and I'm lucky 
I'm not alone who found it missing.

Three reasons:

- The { and } are not chosen at random, they are the consequence 
of using those characters to delimit strings themselves.

- There aren't many characters or character sequences that can be 
optional without conflicting with other stuff in the grammar.

- Syntax processors with user-defined stuff in them are much slower 
than ones without them.

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.

Regarding the syntax name - if we want to use a scientific one, we 
can call the syntaxes "single-line syntax with escaping", "multi-line 
syntax with escaping", and "multi-line syntax without escaping".

I do the same thing as Ladislav with tests and comments, and having 
a separate HEREDOC func makes much more sense than a MOLD refinement. 
I'm still not keen on the name, but the scientific options are a 
bit long for func names. :-)

I'm fine with the tag being optional as well.


The discussion here, and comments on curecode, have addressed my 
current questions and concerns. Thanks to all involved for that, 
particularly Ladislav. I think it's absolutely worth a trial run 
to see if anything comes up in acutal use that isn't easily addressed 
with docs.

This also gives me more to think about with regard to how and why 
location markers might be done.

Please stop fussing over the name and just stick with heredoc, which 
is a widely used and well-established notion.

Ultimately, Carl will choose. All we can do is weigh in with our 
votes, and cite what we think justifies our postiion. ;-) I will 
only say that "heredoc" brings to mind the following scene from Young 
Frankenstien:

Inga: Werewolf! 
Dr. Frederick Frankenstein: Werewolf? 
Igor: There. 
Dr. Frederick Frankenstein: What? 
Igor: There, wolf. There, castle. 
Dr. Frederick Frankenstein: Why are you talking that way? 
Igor: I thought you wanted to. 
Dr. Frederick Frankenstein: No, I don't want to. 
Igor: [shrugs] Suit yourself. I'm easy.

And finally, it doesn't matter what we call it. The names of these 
syntax types won't appear in code, just in docs. So stick to the 
standard.

Actually, I think a pre is closer to heredoc than CDATA.
CDATA is strictly speaking for XML or XHTML. not HTML.

And CDATA only, in effect, protects unescaped <, > and & from being 
interpreted as mark-up.

Perhaps, more importantly for the heredoc issue, whitespace is not 
guaranteed to be left as-is in CDATA:
   http://www.w3.org/TR/html4/types.html#h-6.2
But it certainly does not matter to me what we call it :)

o: context [test: 123]
append h o
n: context [n2: context [h]]

Above is just a concept of what I want which is to create an object 
with an object that contains the object(s) held within h block. I've 
tried compose/deep binds and just about everything else I could think 
of.

The context of this is I have created objects which are held in a 
global block represented by h. I then have to  put these all together 
as one object. I just can't get rebol to do that. I always get a 
rather empty object.

Thanks Sunanda. I'll try that. Carl was just here looking at the 
code (How humiliating) and telling me why mine wouldn't work. OOPs.

On Windows 7, is there a known reason that REBOL, doing a read %., 
would not return all the files in a dir? I can only think security/permissions 
are at play somehow. I need to test more, but as a quick test, you 
could open windows/system32/ in explorer and look at its file count, 
then do a READ on that dir and see if you get a different result.

The reason for this is I am converting deeply nested xml into rebol 
objects and I don't know what the final object will turn out to be 
....

Yes, that is what I was afraid of. (this is problematic, if you are 
not allowed to create new files) OK, Robert and I have agreed, that 
we keep INCLUDE case-insensitive (for file comparisons), and put 
the information into the documentation.

Ladislav, how about reading the root directory, find a camel-cased 
file, lower/uppercase it and ask if the file exists?

not if the includes are grabbed from a network resource, such as 
when running your R3 in a VM inside another OS and the source is 
stored in that other OS.

you write two files with different case, using different data.  then 
read the first one, and making sure it doesn't give you the value 
of the second.

Ladislav: I was going to suggest something similar as Sunanda, except 
by using [sort read %.] instead of [what-dir], then checking the 
first file with alphanumeric characters.  That way, if both upper 
and lowercase do exist separately, they'd show up in the list and 
can be adjusted for

Can you not assume, Ladislav, that you will have read access to user.r?
And use reads/info? for variants on that to check?

Graham, did you figure out the object issues? And are you using or 
have you tried the xml-object.r script?

Steeve, that's sweet. "Case" doesn't show up in the dictionary and 
I had no clue we had such a thing. Very cool.

The help says this:
    -- args          Provide args without a script

There's a space between the -- and the word args, so I tried this 
and it worked:

   rebol --do '? system/script/args q' -- 'arguments here'

The help should probably say something like:
   -- <args>
to make it more obvious