AltME groups: search

I also needed to add the Java folders to PATH manually, I don't know 
what Oracle is doing with its installers...

well, you have Rebol installed and linked to .r ..... I am so much 
used to work with Total Commander, that I launch Rebol from icon 
sporadically. The trouble for me, is the path. So from time to time, 
I place kind of empty run.r script in some dir, which serves for 
nothing more, than just pressing enter upon it, and being run in 
particular directory, which means, in certain directory path

that is why I thought that having red-system.r in the red-system 
subdir, would be handy. Than the examples in docs might be run without 
the proper path obstacles

james & kaj: I have JDK installed too, you should be sure, that you 
can call java, javac from whatever dir = it is in the system lookup 
PATH. And - Rebol was downloading supporting tools, then it hang 
in console, but in fact, there was a dialog box hidden in the background, 
asking me for write permission. Unless you allow that, the tools 
are not going to be saved into requested directory ...

@james_nak, first delete any jarsigner exe you might have downloaded 
or copied outside of the java folders. Then try to run jarsigner 
from the Red folder, if it says it can't be found, then you have 
to add to your PATH environment variable, the path to the java/bin/ 
folder of your installed JDK.

Yeah run against Process Monitor and look for any access denied or 
file not founds or path not found messages.

no, changed path. fixed.

I saw the discussion about windows path names.  If you need to convert 
a path to not have spaces then windows uses a tilde ~ for truncating. 
 To see your path converted just open a command prompt and type dir/x

that gives the path names with conversion.

Some exmplanation:


W->top_of_series is a stack holding the different types of series 
being entered in the lexer, defined as:

#define BLOCK_BEGIN_T		58
#define PAREN_BEGIN_T		59
#define LONG_STRING_BEGIN_T	60
#define PATH_BEGIN_T		61
#define GET_PATH_BEGIN_T	62
#define LIT_PATH_BEGIN_T	63
#define BINARY_BEGIN_T		64
#define SET_GET_PATH_T		65


The code about trace is just, if tracing is on or off in World. W->top_of_code 
is a pointer to where the code for the virtual machine in World is 
being created, and W->code is the bottom of that stack in instructions, 
W->top the top. do_string executes a string of World code.

How far is tasks implemented in R3? It's possible to make them:

>> probe make task! []
make task! [
    title: none
    header: none
    parent: none
    path: none
    args: none
]


, but are there examples of use? Are they supposed to be kinda stackless 
tasklets or some threading thing?

hum, wow.  there always seems to be a conversion path to get the 
numbers do what we want... I'm sure accountants would love rebol 
 ;-)


want a deficit... just turn it into a binary, want a profit, just 
turn it into a bitset first   ;-)

Currently AltME will choke trying to display the log if your path/to/altme 
includes a space anywhere in it though it does create the page...

Proxies are one of those things where every company has a slightly 
different way of  getting bent out of shape about some format, so 
we figured we would test for one path, and then leanr what everyone 
else complained about.

using sort/compare blk func [a b] [a/other/cz < b/other/cz], it will 
survive different location of 'cz field, as it cleverly uses path 
navigation. That is nice. I just wonder about different case ... 
let's say I have object templates, which change once per period of 
xy months ... I also have IOS, so lots of record synced around. My 
plan was, that each object would carry its version info. I wonder 
what to do in case, where new object template version will extend 
object structure, e.g. adding phone-num field ...

I really liked its path understanding - so I don't need to keep fields 
at the same position. I like blocks better than objects :-)

- the other way to do it, is to stick in a dummy cgi-bin in the path 
.. which also tells the cache not to cache it

Thanks.
That looks like a different problem to DideC's.

Your problem seems to be a traditional REBOL annoyance with paths 
that contain spaces....

qml-ed.r is tripping up over those spaces in "Dokumente und Einstellungen 
"
---

Could you try it in a folder whose path and name do not contain spaces 
to test that assumption?  Thanks!

Apologies -- REBOL.org was unavailable for just under a day, it's 
back now.

The problem originated with the ISP, and it took them a little while 
to work out what they'd done wrong.

Using a "non-standard" language seems to have added to their debug 
time:
Extracts from two emails from the ISP's technical support:

<<Hi, Sunanda.  Sorry this is taking a bit.  As I'm sure you know 
you have

a non-standard setup :-)  We aren't familiar with it and are puzzling 
it

out.  Am I right that you have your own scripting language?  And 
that
[snipped] is the [path to the] interpreter?>>

<<Aha!  Our web server rebooted yesterday.  It's a FreeBSD server, 
and for

a reason we haven't determined yet, the Linux compatability module

didn't load.  We loaded it and your site works again.  We'll figure 
out
why that module didn't load at boot.>>

Just a search that filters out string!, file! and url! types would 
be fine. I am only interested in searching the various word and path 
types.

Brianh: <I am only interested in searching the various word and path 
types.>

Try this quick concept code. In REBOL.org's search box, use [b] as 
a sort-of inline refinement to limit script searches to just the 
body of a script, eg
     sing

  -- finds nearly 300 scripts which contain the string "sing"    but
    sing [b]

-- finds just three scripts that have the word-part "sing" in their 
body

Of the various editors / word processors I have immediately to hand:

-- credit.exe -- [my usual editor] shows incorrect chars, and has 
no option to switch to UTF-8

-- open office writer -- works fine if you take the UTF-8 option 
when asked
-- ms word -- claims file is corrupt
-- word perfect -- makes a complete mess

-- R2/View's built in editor ( editor %/c/path to my local copy//ascii-math.r) 
-- shows incorrect chars

For example, don't do this:
text: context [var: none]
layout [button with [text/var: self]]
** Script Error: Cannot use path on none! value
** Where: forever
** Near: text/var: self

I've just noticed a new global word PATH existing since View 1.2.10, 
an undocumented function.

is there any standary way to specify a search path for library kind 
of rebol source files what are tipically imported to end-user programs?

Good question, because the rebol.org script library will need some 
modification to path-thru to handle the url's with the '?' character 
in it. Normand, maybe you just want to change the VIEW-ROOT path 
within rebol. If is used by PATH-THRU, If you care to have a quick 
look at the source. And path-thru is used by exists-thru?, read-thru, 
load-thru... all the functions dealing with the public cache.

For two weeks, we downloaded unpackers for him that were themselves 
compressed in a format that he didn't have yet. It became ever more 
difficult to find combinations that gave him no path to unpack his 
Amiga BBS

They use Debian. I have Fedora at home. What would I like to ask 
is - where to put rebol interpreter on Debian? Where to put things 
like user.r or mysql-protocol.r or whatever other script I produce 
to them? The path is almost always trouble for me. I e.g. start console 
and I have to define set-net once again, as it does not use my user.r 
settings etc. Any insights?

Then they/you can put one binary *anywhere* in the path

If the rpm is for your redhat and has a 2.3, install it? after lots 
of backups maybe, i guess if the lib fails all fails. or unzip it 
and put the library somewhere else and use LD_LIBRARY_PATH. Do you 
have a link to the package?

maybe you can make it work as Volker suggests using LD_LIBRARY_PATH. 
the good thing about linux is that, even though the design is so 
poor, you can still make it do what you want in most situations (however 
this often means hard work)

Robert: like Volker, my prefered path fro a mostly read  dataserver 
would be setup/test/populate new_data_server; stop updates on old_data_server 
switch nameserver to new_data_server

Rebolinth: the fonts are supported by DRAW dialect but you have to 
specify full absolute path to the font at the moment.(we are investigating 
better solution for this)

you need to find a path to your fonts and you can use any ttf font. 
I don't know what YALN(yet another Linux distro) are you running 
;)

the wonderful world of linux... what I had to do was to make scripts 
as shellscripts with the shebang line at the top with the path to 
the rebol executable. there is a mention of this in the Rebol/Core 
manual here: http://rebol.com/docs/core23/rebolcore-2.html

This should work across the various desktops.

ah, yes, of course, I just use it for basic check that permissions 
are ok, that my path to interpreter is ok, simply that cgi mode works 
....

now I get following in browser:


** Access Error: Cannot open /home/web/jablunkovsko.cz/sqlite.log 
** Where: connect ** Near: write/append/lines join log-path %sqlite.log 
reform

Sounds like that. Or the path is invalid. Does the script run as 
another user, and/or run as chroot?

secure[path-to-directory allow]

(the path-to-directory must be copypasted, vars do not work)

if you run with -cs, it has no security anyway. then its some permission- 
or path-problem.

i would set log-path to %/tmp/, make sure /tmp/sqlite.log does not 
exist  and give it a last try.

yes the entire path of dirs to your target  need to be executable 
to get there

To start /Core without the ./ path, you would have to add the path 
to the $PATH environment variable. The ./ current directory is usually 
not in there for security reasons

(local machine)

and it returns:

make object! [
    server-software: none
    server-name: none
    gateway-interface: none
    server-protocol: none
    server-port: none
    request-method: none
    path-info: none
    path-translated: none
    script-name: none
    query-string: none
    remote-host: none
    remote-addr: none
    auth-type: none
    remote-user: none
    remote-ident: none
    Content-Type: none
    content-length: none
    other-headers: []
]

for debugging i would look for
   insert tail script-cache reduce [file-path script]

in webserv.r and comment that out. so that it loads allways from 
disk.
and in the error-catch around it 
  [probe disarm local]
instead of 
  []

what error-message do you get if you do it intentionally really wrong? 
wrong exe-path, wrong header, without permission?

OK. something else to try. clutching at straws. Sometimes illegal 
chars before rebol header. Try removing the blank line between !path-to-rebol 
& REBOL [] line

I think maybe I am the next one going down this path, and somehow 
I stumbled... :-\

Anyway, it works, but I still have a problem: in system/options/cgi, 
both 'path-info and 'path-translated are set to none, which prevents 
Magic! to wrks properly as it can not find the requested file (usually 
a *.rhtml) file. In normal CGI, it works well. Is this a bug? In 
that case, I will put it into rambo. Note that I have configure FastCGI 
in compatibility mode.

With Apache 2.x (normal CGI), we have: make object! [ 
	server-software: "Apache/2.0.54 (Fedora)" 
	server-name: "localhost" 
	gateway-interface: "CGI/1.1" 
	server-protocol: "HTTP/1.1" 
	server-port: "80" 
	request-method: "GET" 
	path-info: "/sample01.rhtml" 
	path-translated: "/var/www/html/sample01.rhtml" 
	script-name: "/cgi-bin/magic.cgi" 
	query-string: "" 
	remote-host: none 
	remote-addr: "127.0.0.1" 
	auth-type: none 
	remote-user: none 
	remote-ident: none 
	Content-Type: none 
	content-length: none 
	other-headers: [
		"HTTP_HOST" "localhost" 

  "HTTP_USER_AGENT" {Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) 
  Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6} 

  "HTTP_ACCEPT" {text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5} 
		"HTTP_ACCEPT_LANGUAGE" "en-us,en;q=0.5" 
		"HTTP_ACCEPT_ENCODING" "gzip,deflate" 
		"HTTP_ACCEPT_CHARSET" "ISO-8859-1,utf-8;q=0.7,*;q=0.7" 
		"HTTP_KEEP_ALIVE" "300" 
		"HTTP_CONNECTION" "keep-alive" 
		"HTTP_COOKIE" "PHPSESSID=7f84fd7766f23e1462fed550ecbbfda4"
	] 
]

With LiteServer and lighttpd (normal CCI and FastCGI) i have: 
make object! [
	...
	path-info: "" 
	path-translated: none 
	script-name: "/sample01.rhtml"
	...
]

And with lighttpd: 
make object! [
	...
	path-info: none 
	path-translated: none 
	script-name: "/sample01.rhtml"
	...
]

With lighttpd and LiteServer, both path-info and path-translated 
are missing, while 'script-name is the name of the originator html 
file instead of the name of the cgi script (magic.cgi).

Gabriele: I meant to put after the exec the path to a script file. 
It didn't work because I wrote it in the wrong way. Now I modified 
it and it work.

most time path-issues then. some folderpath changed i guess.

?? should be be rebol.exe at the end?
?? try an absolute path

And your web server reported the actual path in the 500 server error 
message.

when I upload my script, I don't feed it with full path, just !#rebol 
-cs, if the interpreter is from the same directory ....

Btw content of one of file in the interpreters dir:
#!/bin/bash
if [ -z "$REDIRECT_STATUS" ]; then
  echo -e "Content-Type: text/html\r\n\r
<b>Security Alert!</b> The Perl CGI cannot be accessed directly.


<p>This Perl CGI launcher is configured to require a redirect.  This

means that a page will only be served up if the REDIRECT_STATUS CGI 
variable 
is set, e.g. via an Apache Action directive.</p>


<p>For more information as to <i>why</i> this behaviour exists, see 
the <a href=\"http://php.net/security.cgi-bin\"> PHP manual page 
for CGI security</a>.</p>

 else
  export SCRIPT_NAME=${PATH_TRANSLATED##${DOCUMENT_ROOT}}
  
 export SCRIPT_FILENAME=$PATH_TRANSLATED
  /usr/bin/perl 
$SCRIPT_FILENAME"
fi


As newcomer in linux and apache I can only ques what it mean, but 
I am thinking about this line:
 This Perl CGI launcher is ...

ldd rebol-view-executable

 under Linux could tell you what libraries are needed. If that is 
 not much (e.g. one library being dependant upon other etc.), you 
 could try to upload those libraries to where your view executable 
 resides. The question is, what is Linux OS strategy to look for libraries 
 - current dir, some central libraries storage path, elsewhere ...?

configured library path (usually /lib/, /usr/lib/, etc), or the value 
of the env variable LD_LIBRARY_PATH.

petr, load/library is probably a bit different from what ldd does 
on startup. i suppose ldd wants current dir in the lib path to load 
libs from current dir (same issue as executing programs from current 
dir...)

My understanding is the latter would be slower.  Also, QM (as an 
example) doesn't generally require a get query or post data (primarily 
uses path info).

That REBOL doc should really answer your question. Simply put, in 
External mode, you do something like /path/to/script (that does not 
need to exist) and you direct it to certain, already running REBOL 
process. But - rebol has no tasking, so you have to handle accepting 
connections and multiplexing. It is like with Rubgy - unless you 
are finished, you are not available to other requests ...

I am also adding a routing scheme (dialect) so basically you redirect 
all traffic except static stuff to a fastcgi process, it comes in 
the router and then it checks on extension or path (REST) what to 
do.

Usually F5 works  a hard refresh in Opera.

Otherwise check your setting for tools/preferences/history and cache/check 
documents/always  (precise path may vary according to version of 
Opera)

As programmer not AFAIK. with a dom you can use path-notation. with 
SAX you build that tree yourself. I guess SAX makes sense when you 
convert data, like xml-make-doc. one tag, output something, another 
tag, output something other.

Organizing data - if data is in blocks, you can use path-notation, 
but also runwith a parse-rule through the loaded data.

>> do http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=xml-parse.r
>> parse-xml+ read http://www.ross-gill.com/
** Script Error: Invalid path value: parse-xml
** Where: parse-xml+
** Near: xml-parse/parser/parse-xml code

Chris, you assume wrong. They may be a little awkward but standard 
path and block manipulations can be used on the structures generated 
by those parsers, as long as you stick to the overall structural 
conventions.

One major point wasn't said: We need a library system to handle all 
this. I won't use code, where I need to 'do zillions of single files 
in a specific order, handle path and lookup things, need local sub-directories 
to load images etc.


I'm still using Slim on my xpeers system, because that's the only 
thing I know about that handles all this quite well. And I can tell 
you, it pays off. Something like this is required.

I don't think a good path to learning Rebol is the numerous examples 
and how-tos given. With each, you learn how to program the example 
shown, but they are of little help in helping create referents for 
the learner. One needs to grasp the overall "philosophy" of structure 
of the language at one point.

Ok, so here's my frequency table:
    6 compose 
    5 as-pair 
    5 func 
    4 do 
    3 show 
    2 all 
    2 copy 
    2 find 
    2 form 
    2 get 
    2 in 
    2 pick 
    2 print 
    2 to-image 
    2 use 
    1 * 
    1 + 
    1 - 
    1 <> 
    1 = 
    1 append 
    1 bind 
    1 center-face 
    1 change 
    1 clear 
    1 context 
    1 do-events 
    1 either 
    1 first 
    1 foreach 
    1 if 
    1 join 
    1 layout 
    1 load-thru 
    1 make 
    1 mold 
    1 object? 
    1 reduce 
    1 remold 
    1 remove-each 
    1 repeat 
    1 second 
    1 select 
    1 to-pair 
    1 to-path 
    1 view

If I can engineer such a learning path, even if we never switch to 
Rebol for our classes, I'm sure that it would help enlarge the Rebol 
community. So I'm getting more interested in this project as I'm 
going along. It is not an obvious endeavor.

(By request, relayed from rebcode group) Could you add an APPLY opcode 
to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).

Q: What does the world on Nov-15-2005 look like?


A: Our main goal is to get REBOL into the hands of more users, not 
just programmers and techies.... by the millions over time.  By doing 
that, we create a market for not only handy free REBOL apps, but 
also for commercial apps and entire businesses that are related to 
REBOL.



Q: Given that  window transparency is OS specific, will there be 
a dialect that covers both Windows, Linux and 40+ other OS?  In other 
words, does RT plan on continued support of so many languages, or 
are we entering a new era of specific OS support?


A: Our plan is to make that a window option that is part of the face/options 
for a window.  If an OS does not support this mode, then the option 
will be ignored, but the application will still be fully functional.



Q: I hope it is still valid that cooperation with RT is possible. 
I mean - last few weeks I play with some Win32 functions (thanks 
to Gregg) and I would like we would have proper app behavior in multi-monitor/multi-desktop 
environments .... so I wonder if any SIGs will be created, some ppl 
will be invited to participate, comment etc., or if RT is gonna cook 
it all themselves?


A: Yes, there are many such special interest projects currently going 
on. (Most of them are occurring via private projects in AltME and 
IOS.)  These days 90% of REBOL changes are done in cooperation with 
the REBOL community.



Q: Hi .... with recent Rebcode releases, we can see that internally 
new Core is marked as 2.7 and View is marked as 1.4 Is it just working 
"title" or will those products be marked as that? And if so, can 
we know, what other changes will go for 1.4 View release target? 
Will there be any AGG fixes/additions (to support SVG RebGUI progress), 
or even VID changes? I still think, that VID is missing few fine 
styles as tab, group-box, better list as was introduced on IOS Developer's 
server, (eventually tree, menu), to allow novices to start using 
VID/View more productively. Any chance RT can tell us, what is the 
plan for 1.4 release?


A: Regarding 2.7 and 1.4 question: we change the revision numbers 
(the second number) whenever there is a major change in REBOL that 
may be unstable.  The /core 2.7 kernel (that is in /view 1.4 as well) 
adds new datatypes to REBOL, and they are the first datatypes added 
in several years, so we consider this to be a major change, and marked 
it that way.
Yes, we do plan to be making a few AGG fixes very soon.

Oh, and regarding VID: we plan to be making very big changes there. 
More to come soon.


Q: Could you add struct! support to /Core?

I keep on having situations that would be made much easier by struct! 
when I don't need libraries. For instance, conversions from external 
binary data encodings to internal REBOL values, say for file formats, 
network protocols and so on. Now rebcode has added other forms of 
strong typing like the type-specific opcodes and the vectors. Having 
structs with their constrained field types, their specific data layouts, 
would be a perfect match for the low level operations of rebcode. 
They would be helpful later when implementing your own data types 
as well.


A: On structs: yes, we will enable this feature on core, but it should 
only be used for lower level code.  Objects are more powerful.


Q: Could you add an APPLY opcode to rebcode?

    apply: ["Apply function or path to arguments, save result" word! 
    word! | path! block!]

In rebcode:
    apply x f [arg1 arg2 ...]
Is equivalent to this in REBOL:
    x: do f arg1 arg2 ...


The advantage to doing function calls this way is that the arity 
of the opcode is fixed, even if the arity of the function called 
can't be known ahead of time. The value assigned to the function 
word could be either a function or a path, or for efficiency you 
could have a seperate opcode APPLYP for path values (I'd prefer just 
one opcode for generality but it's your call).


A: I'm not sure what is meant by the path for it. You mean for refinements?
That may actually slow down the apply interface.

A: I'm not sure what is meant by the path for it. You mean for refinements?

Yes, that is what I meant. If it is a major slowdown to check for 
this, add the APPLYP opcode I mentioned for the more general case, 
or have APPLY for the general case and APPLYF to apply functions 
only. Or you could just apply functions and have the refinements 
case be put in a do block or a wrapper function. You can handle refinements 
in rebcode, right?

While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?

I'm not sure, how to make a use of it, but it does have an effect:
>> blk: [a b c]
== [a b c]
>> path blk 3
>> blk
== [a b]

>> x: [a b c d]   path x 'c   x
== [a b c]

Not strange. it does a path-lookup. 
!> a: [b 1 c 2 d 3]
== [b 1 c 2 d 3]
!> a/c: 22
== 22
!> a
== [b 1 c 22 d 3]
!> a/4: 222
== 222
!> a
== [b 1 c 222 d 3]

Q: (note - my view may be influenced by insufficient knowledge in 
the area given) - last weeks I played with wrapping some Win32 functions. 
I started discussion on dll.so channel, to ask developers, if they 
would enhance interfacing to C libraries in some way, and there was 
few ideas appearing. We currently have also rather strange callbacks 
support (limited to 16) and I would like to ask, taking into account 
that DLL interface in Rebol was not changed/enhanced since it appeared 
long time ago, if RT sees any area in which it could be made more 
robust, developers friendly etc.?


A: We are planning to do a lot more on DLLs. In fact, future versions 
of REBOL will expand on the way DLLs are used in REBOL.   For example, 
I would like to see DLL support for media loaders and savers, so 
if we do not directly support a specific type of media file (say, 
TIFF) then an external DLL can be provided to load it.  There are 
a few other DLL related features down the road, but it is still a 
bit early to talk about them.



Q: I realize that the open sourcing of the viewtop wasn't that successful, 
but do you still intend to keep releasing newer versions of it? AFAIK 
the current release is over a year old. I've experienced a lot of 
obvious bugs in the viewtop editor, which I think can easily be solved 
by people outside RT.


A: yes we will continue to release newer versions.  View 1.3.2 fixed 
a number of bugs in the Viewtop editor that were listed in on RAMBO. 
Any fixes and enhancements from the community are greatly appreciated 
(by everyone, not only RT!)  You can post them to RAMBO, and we will 
review and include them (if they look good).



Q: While reviewing the action! functions, I noticed the path action. 
The doc comment says "Path selection.". The parameters aren't typed. 
Does anyone know what this action does, and how to use it? Or whether 
it can be or should be called directly at all?


A: the PATH action is what the interpreter uses to evaluate VALUE/selector 
expressions for each datatype. It is an internal action and has no 
external purpose in programs. These kinds of words often appear as 
a sort of "side-effect" from how REBOL is structured.  Datatypes 
are implemented as a sort of object class, where the interpreter 
"sends messages" to the class to evaluate expressions. The PATH action 
is a message that tells the datatype to perform a pick-like or poke-like 
internal function.


Q: Is rebcode going to support paths and/or some kind of binding?


A: Certain rebcode can support anything we feel is important to put 
into it, but note: many things we add could slow it down, by a lot. 
 For example, if we were to allow paths as variables, I estimate 
that rebcode would be about two times slower than it is now.  Perhaps 
one way to solve this issue is for you to use COMPOSE prior to specifying 
your rebcode body.  Within the compose, you can use IN object 'word 
to "pre-compute" the context references for words. For example:

    add.i (in object 'num) 10


Your question about binding is not clear to me. Rebcode already supports 
binding. Your rebcode can be part of an object context, and rebcode 
function words are bound to the code context.  (Perhaps you are referring 
to an older bug that has since been fixed?)



Q: What do you think about  http://mail.rebol.net/maillist/msgs/39493.html
? Why not say a word in your blog, if you think that it's interessant 
for rebol developpment, and if you want to contact them ?


A: Recently, I had the chance to sit down and talk with one of the 
main people from the One Laptop Per Child project (he is a friend 
of mine from Apple Computer days).  The project has an interesting 
goal, but there are also many difficult issues around it (not just 
in the technical side, but also on the social and cultural sides). 
My current understanding is that the target software is Smalltalk 
based. Yes, it would be very interesting to allow REBOL on that system, 
but if you look at the list of principals for the project, you will 
see that such a revolution is unlikely.  Is it possible that perhaps 
REBOL could provide some additional capability in the future? I think 
so. We have some special plans that I think will bring REBOL to platforms 
like that in the future. But, this is too early to say more.



Q: 1. What is fixed/added in 2.6.2/1.3.2 (change-log, please) ? 2. 
What is planned for 1.4.0 (rebcode, rebservices, rich-text, RIF, 
and last but not least, fixed sound ...) ? 3. When can we expect 
1.4.0 ? Thanks.


A: 1. Gregg is preparing a summary. The document should be available 
this week. 2. We are evaluating a large variety of changes in REBOL, 
more than even the 1.4 release that we've talked about.  I hope to 
be able to say more about these plans soon.

In response to the answer to my question about the path action (thanks!) 
I wonder, why do internal functions like path and native need to 
be assigned to global words at all? Can't they be assigned to some 
internal object fields, or in some way be hidden? I know that encapsulation 
isn't really REBOL's style, but littering the public interface with 
undocumented natives that can't even be used by mezzanine code seems 
a little silly.

As for the question about rebcode binding, let me make it clearer:


It would solve all of the object field retrieval problems in rebcode 
to have an opcode added that would be the equivalent to the IN native, 
or maybe BIND. You wouldn't need path evaluation to be added - you 
could just retrieve an object field word and use setw/getw with it. 
Yes, you can use apply, but it is very slow in comparison with opcodes. 
Working with object fields is a pretty basic operation that doesn't 
have any direct support in rebcode, and some have come to miss it, 
particularly those that use objects in data structures. I often use 
blocks for data structures when I can because of the context overhead 
of objects, but some are more used to thinking in object-oriented 
terms. Plus, there's all of those built-in object-based structures. 
Still, I suspect that many of these questions would go away if apply 
was faster :(

Problems installing Rebol/View latest official release 1.3.2 onto 
Windows 2000 Professional with all the latest Service packs...


Rebol was installed using the default parameters, with the exception 
of the path, it was changed to C:\Program Files instead of C:\Program 
Files\Rebol\View.  It was noticed immediately that the Microsoft 
Quick Launch toolbar disappeared.  After an uninstall  we found that 
the entire IE\Quick Launch folder was erased, but don't know if this 
was done by the Install or Uninstall.  Afterwards, we rebooted the 
PC and found that the desktop image (which was added through IE) 
was also gone.

Initial investigation shows that only the two directories above were 
affected as other folders in the same path have all of their subdirectories 
intact.

what was the data-path set to while installing?

Another victim... <path as above>\UnleashIT,   all profiles removed.

do-uninstall: does [
	attempt [delete data-path/bypass-install]
	if get-face ckd [

  if confirm reform ["Please confirm that you want to delete all files 
  in" to-local-file data-path][
			attempt [delete-dir data-path]
		]
	]
	found? all [
		attempt [unlink-rebol form system/product true]
		attempt [unassociate-file true]
		attempt [unregister "REBOL" form system/product true]
	]
]

So one thing I would like to suggest is that the "Change" button 
in the installer defaults to the folder as indicated in the default 
path provided when you start the installer.  I think this is the 
root of the problem as the text looked like it was fully provided 
but the path field was short and we didn't confirm the full path. 
 In my opinion it should have included \Rebol\View, but believe it 
did not.

maybe using the checksum of a script as the base dir, which is hard-coded 
as the root path of your script.

JoshM - doesn't my private post re how Internet proxy settings in 
control panel influence registry help? IIRC, you set proxy in the 
past according to incorrect registry path. Please revise get-net-info 
:-) I prefer 90% working proxy, than none at all :-)

haven't you meet yourself with requester, which asked for permission 
for file e.g., where path was cut-down? That is the same like no 
requester at all ...

its more like what value it adds ;-)  but the core featues are:
-loading external code, but in a managed way

-path resolution, allows you to put libs in one or many folders, 
a part from code and reuse.
-version verification.

-enforcing of a standard, where all the code is wrapped in one context 
and the use of 'set is illegal (nothing gets bound to global context)

-allowing the user of a lib the choice of exposing what words he 
wants in his code.

first give a solid dev platform, then add some debugging help.  unit 
testing alone is trivial to implement in liquid, so that's a very 
good path for a first pass.

hmm, strange - RSP test app - under Seamonkey, I get mostly uncomplete 
response - even for 4 apps test, three are returned imediatelly, 
one is not loaded, I get busy indicator. Tried in IE, 4 example works, 
16 example - I get RSP error 311 - invalid path value: hits

error is in protected-exec Near [print session/hits txt 244 268] 
- Invalid path value: hits ... like it would not know that session 
object variable ...

With the four and sixteen RSP demo, getting the following error  
 script error !
Invalid path value: hits

For Text CGI script I get:


#!/usr/bin/rebol --cgi REBOL [ Title: "show" File: %show.r ] print 
"Content-type: text/html^/" print {Back

} print ["Script path :" system/script/path "

] print 
CGI Object :" print "

 foreach name next first system/options/cgi [ either :name = 'other-headers 
 [ print [
 name 
: 
] foreach [n v] list: system/options/cgi/:name [ print [
 n 
: " mold select list n ""] ] print "
 ][ print [
 name 
: " mold system/options/cgi/:name ""] ] ] print "
 if system/options/cgi/request-method = 

POST" [ vars: make object! decode-cgi make string! input if not empty? 
next first vars [ print " Variables passed :

 foreach name next first vars [ print [
 name 
: " mold vars/:name ""] ] print "
 ] ] print