AltME groups: search

%opengl-test.r3 ran fine.

%opengl-simple-test.r3 crashed after a few seconds:

@** Script error: cannot access window in path event/window/data

** Where: all -apply- wake-up loop -apply- wait forever catch either 
either -apply- do
** Near: all [
    obj: event/window/data
    obj: select obj 'handle...

Same error for complex tree.


Happened on torus too, then I figured it out. The error occurs if 
I move the mouse over the animated area. Other than that, it looks 
very cool Max.

the gui combo announced fails with  

** Script error: path styl/faced is not valid for none! type     
              which I posted in the wrong place (how I have come 
to loathe altme ...)

new zip file now online... same path:
http://www.pointillistic.com/open-REBOL/moa/files/glass-r003.zip

Continuous improvement is the only path.  Either Carl does this, 
or this product will be abandoned.

The font issue could be fixed easily if AltME would allow to specify 
font name or path to font in its settings.

Grebox 0.2.3 is out !  

A bug appeared after intalling MingW GCC as paths were relatives 
the whole compilation stuff was messed up. 

So now path are set to Static and and compilation should work perfectly.

for those interrested: http://shadwolf.free.fr/grebox.0.2.3.zip

; fails with  
** Script error: path styl/faced is not valid for none! type

http://www.fm.tul.cz/~ladislav/rebol/include.r

has been updated. Main changes:

INCLUDE-PATH became INCLUDE-CTX/PATH
INCLUDE-LOG became INCLUDE-CTX/LOG
GET-INCLUDE-DIRECTIVES became INCLUDE-CTX/GET-DIRECTIVES
SET-INCLUDE-DIRECTIVES became INCLUDE-CTX/SET-DIRECTIVES


For other changes see the updated documentation (the Changelog section) 
at

http://www.rebol.net/wiki/INCLUDE_documentation

Sorry for any inconveniences caused by the "context adjustments"

Ogre3D is the probably the best open source 3d rendering engine there 
is .. I followed it's path a long time..  his simpler "follower" 
is irrlicht .. maybe there are some new ones now I am not sure , 
since I am not actively following this area any more

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

If you are willing to give up support for MAKE, MOLD, built-in reflectors 
and path access, you can implement structs as handles. You would 
access them through accessor commands, and struct and routine declarations 
would be a dialect that would be compiled to calls to extension code.

Apple is moving rapidly to LLVM because they can't get the GCC project 
to cooperate. They already use it for iPhone development and OpenGL. 
Having a path to get to LLVM would be a good thing.

After adding MinGW\bin and msys\1.0\bin to the windows command path 
and also copying rebol.exe to msys\1.0\bin folder, I was able to 
build it from a normal command window without modifying the makefile.

Direct word access is faster than path access, but some words are 
logically grouped (like enums).

LOAD-EXTENSION doesn't do lookup beyond the current directory, so 
if you want to have it use some library path you have to add that 
in the host code, or %rebol.r. Either way you can add extensions 
and modules programmatically to the R3 runtime before the script 
you're running starts. If you want your scripts to be cross-platform 
then you probably shouldn't use a platform-specific file extension 
for the files, but if they are loaded or delayed in the host code 
or %rebol.r then it wouldn't matter.

Kaj, here's an example %rebol.r for your scenario:

REBOL []
use [sys-path] [
sys-path:  %/some/safe/directory/full/of/extensions/
sys/load-module/delay map-each x read sys-path [sys-path/:x]
]

BrianH: isn't having just one name going to be a problem for us? 
I like the .rx extension very much. But think about distros. You 
can't have one storage of extensions for various platforms. Dunno 
if such use case would exist. Something like big directory of extensions 
somewhere on the fileshare. In the same path. If the suffixes would 
be different, then those files could co-exist. Hmm, maybe not, because 
.so works for Linux, other Unixes, and those might require different 
extension binary anyway? How would you solve such a case? Subdirs 
per system? e.g. /amiga, /win32, /win64, /linux, /syllable?

Kaj: No need. You can import the extensions by filename. We want 
the initial import of an extension to be really clear, distinct from 
the import of a module. If you say that LOAD-EXTENSION looks up the 
file in the system library path, that shoul;d be all the searching 
we would need.

I'd prefer using system names, only not the system load path management. 
  Rebol, should only look for R3 extensions withing its path configs... 
whatever they are... the R3 extensions *will* use the OS loading 
path, which is normal, since the extension is in fact a bridge between 
the OS and rebol.

my only issue is that the interpreter musn't look for extensions 
in OS paths cause that will invariably lead to library management 
issues.   


many extensions are simply stubs for real OS libs.  furthermore, 
some stray lib could be picked up and cause dangerous side-effects 
when run by the interpreter.


if an R3 os package is built, any extension packages which are built 
for it, should dump the files in R3's own unique search-path setup.

Properly manage the loader's search path.

Those are problems mitigable by many approaches, such as library 
search path management or proper distribution.

yes, I know... what I want is for R3 to control the lib search path 
not the user ... I'm sure all OSes allow this.  R3 would only load 
extensions in a single place it expects.

Btw, there are two places where a "user" could control the search 
path. From within R3 or from the outside.

no difference on windows.  they all do the same basic path searching. 
 local and then system paths.

I want to be able to setup a R3 config file that says:

extensions-dir:  %/some/path/


and then R3 will only ever load extensions from there.    the extensions 
can do whatever they want, but we have a controled point of entry 
within REBOL.

afaik, systems allow paths on dlopen.    rebol would simply always 
ask for libs with paths... 


in fact, on windows, that is how you are supposed to do it, probing 
the registry first to get proper paths for libs.

An extension search path should be consulted first, that's what you 
really want to say :)

no... only.  I really don't want rebol to start playing around in 
the OS, looking for extensions, if I set up a unique path.  really.

by portable, I mean install path independent.

My whole point is: you want those paths _preferred_, but ultimately, 
if you don't find an extension in those paths, you should just fall 
back to the OS loader's search path mechanism.

though the install path may change from one user to the next, so 
absolute paths in the application might not make sense.


I just providing these examples, cause they have actually hapened 
to me in a 100+ employe setup where we had applications being setup 
on the fly on login.

myself I have about 10 different rebol installs, they are all setup 
differently.   some I'd like to lock down, but I can't unless I build 
a special version of R3.


If we want REBOL to allow strong security on all platforms, it has 
to be *able* to manage the search paths on its own.   cause all platforms 
will have different working models.


another example is for a web plugin that allows extensions.  we don't 
want it to look for its extensions anywhere else than in a path that 
its managing.


I don't want to have to invent this system everytime I build a new 
system built with R3

I don't agree. I've built quite a few styles in R3 now, and I've 
not once mixed up FACE and FACET, particularly because the path FACE/FACETS 
exists. I find it to be a pretty natural word to use.

It's nice that face names aren't global, but hiding them like this 
a pane, I never remember the correct path.

You aren't supposed to have to remember a path - there's supposed 
to be accessors.

I don't want to use the path from the window root, as the face object 
may be the only reference you have.

yes. it tries just to get the path, which doesn't exist.

path are evaluated by delect, they can't be used as parameter.

lit-path works

strangly, get-path! works too

I didn't think that it wouldn't work, since this is inside the dialect 
and so the path shouldn't be evaluated.

From rm-asset.com website - "# R3-GUI Library: Our internal extended 
and enhanced VID. We add a persistent layer so that GUI elements 
can be stored into a database backend. Further we added element-tree 
traversal code to simplify accessing GUI elements. Beside this we 
develop a bunch of GUI styles like TABLE, DROP-LIST, DROP-TREE etc." 


What's persistent state for GUI good for? And also - why the element 
traversal code, if we can use path in gobs and their "panes"?

i like the path thing in cairo ...

using the  cairo path layer you can imagine multi layer drawing  
something like photoshop's "calques" (sorry it's french lets say 
masks)

yes - still not solved problem of occassional wrong path dispatch 
of Apache in ClearOS :-(   .... Cyphre, you better put it directly 
onto rebol.cz domain ....

this is a problem that needs to be solved. I don't remember the exact 
path inside the GUIE context to the faces.

inside the layout, you are fine:

view [f: field button do [set-face f "boo"]]


Outside, you need to go through the GUIE context, but I don't recall 
the path.

found the path. not in GUIE, but from what's returned from VIEW:

l: view/no-wait [f: field]

l/data/faces/1/faces/1 ; the field, but not with variable name

** Script error: path space/1 is not valid for none! type

** Where: applier apply use show unless show-now do-event either 
applier wake-up

 loop applier wait do-events if view either create-dialog do switch 
 applier appl

y if foreach if do-face if actor all do-style if do-event do-event 
do-event eith

er applier wake-up loop applier wait do-events if view catch either 
either appli
er do
** Near:

>>

** Script error: path styl/faced is not valid for none! type
** Where: make make-face make-panel make-window-panel case view
** Near: make guie/face [
    options: opts
    facets: make styl/fac...

I got the new exe and dll, the re-downlaoded r3-gui.r3, dialog and 
validation too, but get this error when clicking on a button in the 
dialog demo:

** Script error: path win-gob/text is not valid for none! type

** Where: any view either create-dialog request-user do switch applier 
apply if

foreach if do-face if actor all do-style if do-event do-event do-event 
either ap

plier wake-up loop applier wait do-events if view catch either either 
applier do


** Near: any [opts/title win-gob/text "REBOL: untitled"] ds: screen/s...

Maxim it looks great but it's too open ... in my idea what you show 
with elixir should be part of  it  the "free to add thing" part but 
the other part is we have a set of ready made boxes/items you just 
need to set an execution path and give them some related information 
like position size text etc...

Also the nested tabs allows me to refer to a particular screen by 
a path notation

It is clear this path is not suitable for our project. We should 
look at Java.

Add this to your configuration, and you will be able to use Ctrl-5 
to run rebol3. Change the path as needed.
command.name.5.$(file.patterns.rebol)=RunRebol3File

command.5.$(file.patterns.rebol)="C:\usr\local\rebol3\r3.exe" "$(FilePath)"
command.subsystem.5.*=2
command.is.filter.5=1

fails for me on any test of mine with  
** Script error: path styl/faced is not valid for none! type

Throw in enough conditions and it becomes faster to just use an ASSERT/type 
[gob/data/gob object!]. Or just use a get-path :gob/data/gob and 
just accept that errors will be triggered if the function is applied 
to inappropriate gobs.

Put the path last in the function, or use a get-path, and there won't 
be any code injection possibilities.

If I change the last line, I get this error :

view/options win []

** Script error: cannot access event-port in path system/view/event-port/locals/
handlers
** Where: handle-events unless if view
** Near: handle-events [
    name: 'view-default
    priority: 50
   ...

I will not participate to any bug tracker, bug correction, or testings 
regarding R3/GUI until we don't have a full detailled schematic of 
R3-host-kit, while we don't know where we are going with this project, 
and while we don't know if a better path can be found to avoid this 
project to fall in porting maze.

Even Pekr's dog knows, that a better path can always be found!

A last note for ROBERT: I have read that r3GUI stiles will be developed 
until they are functional to the project specification the where 
created for. 

A clear, written, specific, development path to further develop these 
style and the missing other would be good to have a clear global 
view about the final goal apart this project specific development.

There doesn't need to be a specified development path from RMA for 
styles that are being developed outside of RMA. Independent cooperating 
projects are fine. We don't have to bog down the development process 
with too much management overhead.

Used MDP to generate docs. Not optimal, but at least something. What 
I did was:

- replaced =image-code by =image
- shortened path, as images are just in the same dir as doc

- gui-panel-sizing-3.PNG should be renamed to gui-panels-sizing-3.PNG
- gui-panels-visibility.PNG is missing

I think that every novice, when trying to change e.g. button color/border, 
find himself in a situation, when he influenced all buttons, etc. 
It was because direct path modification vs using make for subobjects. 
That is why I welcomed the move to declarative style definition, 
where the distinction could be made ...

Hmm, so I did some tests, and here's my observation:


- I still have to complain, that in order to MAKE PANEL, I have to 
use function MAKE FACE, even if function of corresponding name exists, 
and was made useless for such purpose :-( Easy things SHOULD be easy 
to do


- The suggested code of pan: make-face 'hpanel [columns: 1] is self-explanatory, 
but then SWITCH-PANEL function does not work. And the possibilities 
are:
                     - this function is obsolete
                     - this function was not adapted to new stuff

                     - make-face does not create sufficient/expected output


The problem is in the following code - I have two panels - m = main, 
p = child:


view [m: hpanel [text "test"] options [init-size: 200x200] button 
"switch" do [switch-panel m p 'fly-right]] 

p: make-face 'hpanel [columns: 1]
insert-panel-content p [button "hello"]
view p ;- check it ....

It crashes on switch-panel, because:

>> p/gob/offset
== 571x384

>> margin: get-facet m 'margin
== [0x0 0x0]

>> p/gob/offset: get-facet m 'margin
** Script error: cannot set offset in path p/gob/offset:


So - does make-face create incompatible structure? Is 'switch-panel 
supposed to work? And if not, how do I support those fly effect for 
switching panels? Just don't push me to manually use insert-panel-content 
and tonnes of similar functions?

** Script error: cannot access faces in path panel/faces

** Where: exclude-faces -apply- apply if foreach if do-face if do 
do-bind-actor

actor all foreach do-style until if do-event do-event do-event either 
-apply- wa

ke-up loop -apply- wait do-events if view catch either either -apply- 
do
** Near: exclude-faces face name

I don't want to hack styles in the R2 way, going style/path way. 
I can see, that those layers are wisely designed, but not allowing 
any size button is imo oversight, and it does not imo break the rules 
you describe in your MS Word TOC example. User is simply not hacking 
it. All I wanted was to "export" max-size, not the init-size.

** Script error: path filters/:index: is not valid for none! type

** Where: function! switch -apply- apply if foreach if do-face do-popup-parent 
function! switch -apply- apply if foreach if do-face -apply- apply 
use if actor all foreach do-style switch actor all foreach do-style 
either set-face switch actor all foreach do-style case do-event do-event 
do-event either -apply- wake-up loop -apply- wait do-events if view 
catch either either either -apply-
** Near: arg :face :value :actor-arg

you would have to access them by path, not sure how it would look 
like in the source-code, as in draw block? e.g. pen color/pen-color?

We are currently discussion an option how to write GUI dialects. 
The thing is how to access face stuff. At the moment you write it 
like this: get-face/field my-table [cell 2x3]

Whereas I like path notation more: my-table/cell/2x3


Using path notaion is not possible but we could enhance the dialect 
in a way that: "get-face my-table/cell/2x3" would be converted internally 
to: get-face/field my-table [cell 2x3]


So, what do you think? I'm not sure if supporting the path notationis 
worth the effort.

I like path notation better, too

How one distinguis obfuscated path notation from the real one? I 
have headache because of path notation usage from VID2, where one 
could cause "unexpected" changes :-)

We found a way to support both without big effort. The non path version 
is better if things are script generated.

It would be possible and in keeping with the metaphor to have an 
out-of-bounds INSERT pad blocks with none values, but since strings 
and binaries don't have a way to have inline nones, that would make 
the behavior of blocks inconsistent. That is why INSERT behaves the 
way it does. If you want INSERT to trigger an error in that case, 
like POKE and set-path modification, that would make sense too.

Or we could just say that INSERT, APPEND, SKIP, AT and LENGTH? are 
constrained to bounds, while PICK, POKE, and the ordinals and path 
accesses that are based on them are not.

Here is the trace log (R2)
>> s: [a b c]
== [a b c]
>> trace on
Result: (unset)
>> insert/only s skip s 2
Trace:  insert/only (path)
Trace:  s (word)
Trace:  skip (word)
Trace:  s (word)
Trace:  2 (integer)
Result: [c] (block)

But then, the internal pointer changes because of the insert.
>> head s/1
Trace:  head (word)
Trace:  s/1 (path)
Result: [[...] a b c] (block)

>> index? s/1
Trace:  index? (word)
Trace:  s/1 (path)
Result: 3 (integer)

>> s/1
Trace:  s/1 (path)
== [b c]

>> a/weekday: 2
** Script error: cannot set weekday in path a/weekday:

>> a/day: 12
== 12

Here is my short list (I am sure I forgot to mention a lot of things 
other people may find important)

Advantages of R3:

- new datatypes

-- map!, money!, percent!, closure!, module!, typeset!, command!, 
get-path!, 
- enhanced objects
- enhanced errors
- support for UNICODE strings
- enhanced bitsets (support for UNICODE)
- enhanced pairs
- 64-bit integers

- better conversions (to binary! and back)

- enhanced PARSE
-- new keywords added
- enhanced MOLD
-- improved MOLD/ALL
- enhanced LOAD
- some functions became natives
-- native APPEND
- more complete set of comparison functions
-- EQUIV? added
- much better RANDOM

- enhanced loops (CONTINUE)

- enhanced debugging capabilities (call stack)
- enhanced protection (PROTECT)

- improved GC

- more open (the host-kit is open source)

Disadvantages:

- missing list! (the demand for the datatype was low)

- missing hash! (for the majority of applications map! should be 
faster and more comfortable)

- no adequate substitute for the [throw] function attribute exists 
yet
- missing struct! (for substitute, see extensions)

R3 PARSE rules can reference charsets and rules from path references, 
so they don't even have to be exported as raw words.

When I trace it, it "sees" the error but returns the path:
...
Trace:  return (word)
Trace:  path (word)
Result: (error)
Result: (error)
Result: (error)
Result: %.../ (file)

you are missing os_to_local_path and os_to_rebol_path

it being the CGR path to host-kit... its still an infant, but I think 
its promissing already... just worked out a few issues with Andreas 
and its working fine on windows now.

arg... path= patch.

The charts will help. I didn't have a problem with /isolate and /only 
as names. The new ones sound rather clunky at first glance, but I 
may grow to like them. Most important, I think, are small examples 
demonstrating why we have the various options. I hope the charts 
are the first step on that path.

Thanks Brian!

This is my attempt at a function that returns the object or value 
at the end of the given path.  If there is nothing at the given path, 
it returns none.

  get-obj-value: func [ obj [object!] path [path! word!]
        /local id 
    ][  
        if word? path [ path: to-path path ]
        either not empty? path [
            either all [ 
                id: in obj path/1  
                obj: get id 
            ][
                either 1 = length? path [
                    return obj
                ][
                    either object? obj [
                        get-obj-value obj remove copy path
                    ][
                        return none
                    ]
                ]
            ][
                return none
            ]
        ][ obj ]
    ]

improvements appreciated

What I meant to write was:

all [exists what-dir? exists? uppercase what-dir exists? lowercase 
what-dir]

Plus then you need to check if info? is the same on all three.

I think that covers your case......But is not perfect either .... 
It fails If the what-dir path happens to contain no case sensitive 
characters.

It's tricky!

get-obj-value: func[o [object!] p [path! word!]][attempt[do append 
to-path 'o p]]

Not optimized for speed though...

There may be better ways:
   first do to-path reduce ['a get 'd get 'e]

This does it without using a temporary word....and it should work 
even if the counter name is not amenable to Cyphre's path notation 
(ie you are using something more exotic that strings for counter 
ids, or are using an older version of /Core).
   b:  next find/skip head b "a" 2 b b/1: b/1 + 1
Just remember to reset ....
   b: head b
....once in a while:)

I know, but that does not solve my case where I had to build path 
from external sources, which could contain the backslash. Like:
>> dir: %test/
== %test/
>> file: ".\LIBRARY\something"
== ".\LIBRARY\something"
>> dir/:file
== %test/.\LIBRARY\something

What's the technical explanation for this question/answer ?  http://synapse-ehr.com/forums/showthread.php?151-Help-with-Script-error-Cannot-use-path-on-none!

Is it the way Rebol evaluates as it builds functions?

In that error there are only 3 path roots that could be none: db, 
db/:counter and FN. If the db is empty then db/:counter would be 
invalid even in the layout. That leaves FN.

If there are no rows returned then that makes sense. Looks like the 
database access needs some work. And even if the path succeeded, 
the SQL at the end of btn-save would fail because the database is 
disconnected. Plus, the create statement at the beginning just creates 
a database, not a table.

OK, so I still get an invalid path but looking at the code I can 
see why.
 [TTL_IN: make block! reduce [

                    make object! [status: make object! [value?: "" value: "1"] value: 
                    "0"] make object! [status: make object! [value?: "" value
: "1"] value: "1"]

So it was making a block of objects. I didn't notice that before.

Thanks for your help. I should have looked more carefully before. 
It was always working.

as to why you need append/only: a path! is also a series!, with the 
path componenets being the elements. whitness:

>> type? 'a/b
== path!
>> series? 'a/b
== true

Which is why just APPENDing a path! to a block! separately appends 
each component of the path, just as for other series:

>> append t: copy [1 2] [3 4]
== [1 2 3 4]
>> append t: copy [1 2] 'a/b
== [1 2 a b]