AltME groups: search

BTW, (shameless plug) I am using INCLUDE instead of DO from the console 
when doing scripts, since I have an extensive INCLUDE-PATH, so I 
don't have to write the directory of the script, just its name

This is pretty cool ... I am sitting in front of my laptop, and on 
the other side of the room is my 46" LCD screen with my media PC 
attached.  I installed the rebxr xmlrpc server on it .., and I have 
cheyenne installed on the laptop.  I click on a file in my application, 
it gets downloaded to the www directory in cheyenne, and then I send 
a command to the xmlrpc server to browse to that file so that it 
displays on the big screen but is served up by the laptop's cheyenne 
server.

What's the quick way of getting the root directory ?

This seems tortuous 

rootdir: to-file rejoin [ "/" second parse/all what-dir "/" "/" ]

sorry ... I meant I want %/c/   ... and not read the directory

; Aliases copied from R3 mezz-file
ls: :list-dir
pwd: :what-dir
rm: :delete
mkdir: :make-dir

cd: func [
	"Change directory (shell shortcut function)."
	[catch]

 'path [file! word! path! unset! string! paren!] "Accepts %file, :variables 
 and just words (as dirs)"
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? get/any 'path [set/any 'path do path] 
	switch/default type?/word get/any 'path [
		unset! [print what-dir]
		file! [change-dir path]
		string! [change-dir to-rebol-file path]
		word! path! [change-dir to-file path]

 ] [throw-error 'script 'expect-arg reduce ['cd 'path type? get/any 
 'path]]
]

more: func [
	"Print file (shell shortcut function)."
	[catch]

 'file [file! word! path! string! paren!] "Accepts %file, :variables 
 and just words (as file names)"
][

 ; Workaround for R3 change in lit-word! parameters with paren! arguments
	if paren? :file [set/any 'file do :file] 
	print read switch/default type?/word get/any 'file [
		file! [file]
		string! [to-rebol-file file]
		word! path! [to-file file]

 ] [throw-error 'script 'expect-arg reduce ['more 'file type? get/any 
 'file]]
]

as you can rename from one directory to another with a relative target, 
the mv would only need the target to be converted to relative to 
origin and it should work, no?

It was originally used to clean up saved file/directory preferences, 
where the default app behavior follows the portable app model: Data 
and settings going in subdirectories of the app directory. If they 
aren't subdirectories, they're absolute paths.

exists? in R2 seems to ignore a traling slash on a file name. I have 
found that it returns true for a non-existant directory if there 
happens to be a file of the same name. Read does not giving the following 
results:

>> write %test "testfile"
>> if exists? %test/ [read %test/

]
** Access Error: Cannot open /Users/peter/WebSites/public_html/IT-Matters-Consulting/test/

** Near: read %test/

This seems like a bug to me. Should I add it to Rambo?

In R3, dir? returns true for a non-existant directory if the file! 
supplied ends with a /. This is the opposite from R2 but is it correct 
to do so?

Nope - Linux systems are usually much worse with spaces, so they 
tend to not have spaces in directory names.

%
 is the variable begin/end tag. ie:
	C:\> set directory=c:\windows
	C:\> dir %directory%


But in batch file, it's also the begin tag for a "number" variable 
equal to the n'th parameter of the script. %1 for first param, %2 
for second... ie:
	C:\> type mybatch.bat
	dir %1

	C:\> mybatch.bat c:\windows

REBOL []

do %../library-dialect/lib-dialect.r

make-routines [
    lib %kernel32.dll
    def-rtn-type long
    ; returns available drive flags as a bitset (in a long)
    get-logical-drives "GetLogicalDrives"
    get-logical-drive-strings "GetLogicalDriveStringsA" [
        buff-len [integer!]
        buffer   [string!]
    ]
    get-drive-type [drive [string!]] "GetDriveTypeA"
]


drive-types: [
    Unknown     ; 0 We don't know what kind of drive it is
    NoRootDir   ; 1 Probably not a valid drive if there's no
                ;   root directory
    Removable   ; 2 It's a removable drive
    Fixed       ; 3 It's a fixed disk
    Remote      ; 4 It's out there on the network somewhere
    CDROM       ; 5 It's a CD ROM drive
    RAMDisk     ; 6 It's not a real drive, but a RAM drive.
]

drive-type?: func [drive /word /local res] [
    res: get-drive-type join first trim/with form drive "/" ":"
    either word [pick drive-types add res 1] [res]
]

get-drive-strings: func [
    /trim "Return only the drive letters, no extra chars"
    /local len buff res
][

    ; Call it once, with 0, to find out how much space we need in our 
    buffer
    len: get-logical-drive-strings 0 "^@"
    ; Init our buffer to the required length
    buff: head insert/dup copy "" #"^@" len
    ; Make the call for real, to get the data
    len: get-logical-drive-strings length? buff buff
    res: parse/all copy/part buff len "^@"
    if trim [foreach item res [clear at item 2]]
    res
]

;print enbase/base to binary! get-logical-drives 2
foreach id [a b "C" 'c "D" d: %E %F %/F] [
    print [mold :id tab drive-type? :id tab drive-type?/word :id]
]
print mold get-drive-strings
print mold get-drive-strings/trim
print read %/

I think that can be worked around by using REMOVE on the port opened 
on the directory that contains the file... worth testing maybe.

Anyway, yes. Ticket is now #4401.

I think I did that for my directory syncing tool

ie. get-modes can't set directory dates

To use our latest RebGUI version, just create a distirbution from 
projects/rebgui and use this rebgui.r file instead of the one included 
in the test directory.

I think we drift to far away

 ... depends on the extent to which you have changed/enhanced core 
 RebGUI functionality (e.g. rebgui-*.r scripts). If most of your changes 
 are isolated to new/enhanced widgets then there is really no drift; 
 you can plug your widgets into the standard RebGUI engine and it 
 will all work. If you want to keep your changes in sync then I suggest 
 2 simple practices:


 1) If you need a version of a standard widget (e.g. radio-group) 
 to do things that are app or design philosophy specific then create 
 your own widget instance and suffix it with an identifier, say XP 
 for XPeers in your case (e.g. radio-groupXP). Suffixes are preferred 
 over prefixes as the alphabetical sort order of the widgets determines 
 their load order which may affect dependencies ... see text.r and 
 label.r for examples of this.


 2) Only keep and maintain a divergent Widgets directory ensuring 
 that your widgets continue to work with the standard RebGUI engine 
 (i.e. rebgui-*.r scripts). If you need the base engine enhanced (e.g. 
 to support tool-tips or proportional resizing) then let's isolate 
 those changes and get them into the base distribution.


You should be able to create and maintain your own widgets without 
worrying about divergence as most of the design effort should be 
going into the functionality of the widget(s) themselves. If your 
widget needs specific changes/enhancements to the base engine then 
we need to sync those changes at the point you need them. Trying 
to retrofit these after the event, and after multiple divergent engine 
changes, is going to cause problems as you've discovered.


From my end, the 3 major changes you should probably try and work 
back into your fork are:

	1) UI settings: mostly confined to rebgui-ctx.r

 2) rebind func added to all widgets prior to init and rebgui-widgets.r 
 enhanced

 3) tab-panel rewritten to operate significantly more efficiently 
 (tab-panel.r and associated rebgui-edit.r changes)

Ashley, you will find it in the RebGUI directory on xpeers. That's 
the code base we use. Just log in, and take a look at projects/rebgui. 
That's our distribution.

I was on xpeers recently .. didn't see a rebgui directory.

you will find it in the RebGUI directory on xpeers

 ... got it the first time, just making sure I was looking at the 
 most current version. FYI, tooltips had me baffled for a long time 
 (they worked for you, consumed tons of CPU for me) until I realized 
 they were only a problem with the new tab-panel implementation ... 
 which now stores all tabs in a pane and uses the show? attribute 
 to work out which one is visible or not (the original stored hidden 
 tabs in a data block). The fix was simple, change the tooltip code 
 to ignore faces with show?: false.

strip tree widget from drop-tree

 ... the tree widget I'm working on is similar to text-list but with 
 leading triangles (indented by level) that toggle between sideways 
 (close leaf) and down (open leaf). Not sure whether Cyphre's one 
 is based on the same [simple] concept.

Can we somehow align while you do RebGUI 2?

 ... as discussed previously (see post from 10-Mar), with the key 
 points being:


 1) Use (and possible extension) of global UI settings (colors, sizes, 
 effects, behaviors) in %rebgui-ctx.r

 2) Widgets should define a 'rebind func if they need to change a 
 statically bound UI setting (e.g. color)
	3) Use the new tab-panel widget

and a fourth:


 4) Layout uses 'tip (not 'tooltip) to specify the widget's tip string!


Note that the current build has had most widget-specific exceptions 
removed, especially from %rebgui-edit.r; and that /dialog (hence 
popup) code has been rewritten to support true modal dialogs (that 
can in turn call additional modal dialogs). The later improvements 
are courtesy of recent REBOL/VIew popup changes.

Build#73 committed to SVN. Mainly code reorganization with functions 
split off into separate scripts in a new functions directory and 
%rebgui.r preserving carriage returns so 'source works and it can 
be edited & viewed more easily. Increased code size by 8 Kb.

right click on the containing directory and update

Has anyone got a good ellipsis button to use to indicate that one 
can bring up a directory requestors etc eg. button ".."
I was thinking of using the eye symbol in the webdings ie. "N"

let me resync a new directory

We do need a directory selector that can access directories across 
the network.  At present i have to resort to using request-file,and 
selecting a file in the target directory.

directory selector that can access directories across the network

 We're limited to what "read %/" can pick up. Real solution is to 
 have a native request-dir func (and request-color, request-font).

background colour to an info field
 ... how about making it the same color as tooltips?

	field ctx-rebgui/colors/tooltip-fill

Any ideas
 ... looks like a RebGUI bug as I can reproduce it with:

	display "" [
		box tip "Some text"
		button [alert "Text"]
	]


Hmm, also noticed that tooltip and tooltip-time are dynamically escaping 
to the global context. Will look at this later today.

Ashley, thanks for the quick fix. Previously, I've used the files 
from the demo in the Rebol directory via Viewtop. As an end user, 
how can I easily get hold of build#94, not having used SVN before 
BTW.

Cheers.

also note - you have to have rebgui.r in your app directory, as it 
is used by grid.r

I'm running he test app with grid.r and rebgui in same directory. 
Do  I need to "Do" grid.r?

Uploaded build#110.

1) Improved scroll-panel and tree widgets


2) Replaced request-dir with a simpler tree-based version (WARNING: 
it reads the entire tree from the path given so don't use it to browse 
a root directory)


3) Added a new heading widget (basically text at twice the font size)


4) Added prototype of new RebDOC app (still needs to be generalized, 
and the code / data that drives it still needs to be cleaned up a 
bit - but it shows the direction I'm heading with regards to "self-documenting" 
apps / code)


5) Removed a number of unmaintained widgets (due to growing incompatibilities)

the request-dir function has lost the "home" button so there's no 
way of backing upwards in  a directory tree.

was it deliberate decision to remove the functions tab from tour.r

 Yes, RebDOC now covers the same ground. My goal is to pull the content 
 across from %tour.r into RebDOC and then obsolete it (%tour.r that 
 is). In RebDOC the examples will become stand-alone scripts.

RebGUI Core

 ... I like it, and it means we can distinguish general RebGUI app 
 issues from RebGUI Core issues (e.g. keyboard navigation is a core 
 issue, lack of a domain specific "bells & whistle" widget a RebGUI 
 app issue). For me the line is quite simple: if it is an issue that 
 can be fixed by creating a new widget (either from scratch or based 
 on an existing one) then it is probably an app issue; if it is an 
 issue that effects most if not all widgets and / or the fix is to 
 the RebGUI engine itself (e.g. a %rebgui-* script) then it is probably 
 a core issue.

request-dir function has lost the 

home" button" ... yep. The old request-dir function was dynamic and 
only read dirs as needed. The new one, due to the "static" nature 
of tree, pre-reads all dirs. It's also lost the "make dir" button. 
These features maybe important to us as developers, but if users 
need to navigate the entire file system or create dirs to use an 
app then the native request-file is probably a better choice. The 
[new] request-dir is really intended for the simple "which of these 
directories or sub-directories do you want to use" case, and assumes 
the developer will use the /path refinement to start in the relevant 
directory. These changes were requested by one of my clients who 
didn't want their staff "seeing stuff they shouldn't and creating 
directories everywhere".

neat scroll-panel now means I can have enormously wide tab-panels

 ... I had that in mind when I created it! Note that the horizontal 
 and vertical sliders only appear as needed and the space they occupy 
 is given back to the child widget. Also note that the button on the 
 extreme bottom right of scroll-panel toggles between "home" and "end".

Ok, I hacked it this way ... I created a new directory and checked 
out from the new repository.  Then I copied all the files from my 
local copy to the new directory but deleted all the svn directories. 
 I then committed all these files .. and it says it created a 116 
build ... I think it's supposed to be 118 :(

I then published the project http://rebgui.codeplex.com/

- title-group and image RebDoc section depend upon images from /images 
directory, which are now deleted hence not available anymore ....

1. Put your new widget in the widgets directory
2. Add it to %rebgui-widgets.r as an #include
3. Run %create-distribution.r

Just confirmed that btn and chat widgets are included in supplied 
%rebgui.r file but corresponding widgets files are missing in widgets 
directory. I'm sure Ashley will fix it one day. My custom widgets 
work ok now with 213.

Bobik, to create a new widget:

	1. Add your new widget to the %Widgets/ directory

 2. Edit %rebgui-widgets.r to add an #include entry for your new widget

 3. Run %create-ditribution.r which will "compile" a new version of 
 %rebgui.r for you

As append-widget removal was oversimplification imo, especially for 
the widget authors, I created short script, which kind of automates 
the process ....

1) Save the script, e.g. make.r, into the RebGUI root dir

2) create one file, called %my-widget-list.r, containing unnamed 
block, containing file-names. Your widgets can be placed anywhere

3) create backup of %rebgui-widgets.r, call it %rebgui-widgets.old.r, 
in order to be able to easily "remove"  widgets by commenting them 
out in file 2)

Here's the script:
REBOL []

;--- to enable removal of unwanted own widgets, create
;--- copy of rebgui-widgets.r into rebgui-widgets.old.r

;--- remember to do so, when official distro release contains new 
widgets!
if exists? %rebgui-widgets.old.r [
  write %rebgui-widgets.r read %rebgui-widgets.old.r
]

;--- load list of widgets you want to include
;--- file containing un-named block of list of files to include
widgets-to-include: load %my-widget-list.r

template: "^-#include %widgets/^/"

;--- read RebGUI widget list (%rebgui-widgets.r)
tmp: read %rebgui-widgets.r

widget-buffer: copy "^/"

foreach widget-filepath widgets-to-include [ 

   widget: last split-path widget-filepath

   ;--- copy widget to the widget-directory
   write join %widgets/ widget read widget-filepath
  
   ;--- build string containing widget names you want to add ...

   ;--- but only when not already on the list - prevent duplicate entries
   if not found? find tmp widget [

        append widget-buffer (head insert find/tail copy template "/" widget)
   ]

]

;--- append to RebGUI widget-list (%rebgui-widgets.r)
change back back tail tmp (append widget-buffer "]")
write %rebgui-widgets.r tmp

;--- rebuild RebGUI distribution ...
call "create-distribution.r"

Odd, the directory has 755 so should be readable ... anyway the files 
can be accessed directly:

	http://www.dobeash.com/RebGUI/dictionary/American.zip

and:

	British.zip
	Czech.zip
	Dansk.zip
	Deutsch.zip
	Espanol.zip
	Francais.zip
	Italian.zip

You can create the following file index.html:
<?php
  function getDirectoryList ($directory) 
  {
    // create an array to hold directory list
    $results = array();
    // create a handler for the directory
    $handler = opendir($directory);
    // open directory and walk through the filenames
    while ($file = readdir($handler)) {

      // if file isn't this directory or its parent, add it to the results
      if ($file != "." && $file != "..") {
        $results[] = $file;
      }
    }
    // tidy up: close the handler
    closedir($handler);
    // done!
    return $results;
  }
?>

<?

$path = ".";
$dir_handle = @opendir($path) or die("Error opening $path");
echo "Directory content: <br/>";
while ($file = readdir($dir_handle))
{
if($file!="." && $file!="..")
echo "<a href='$file'>$file</a><br/>";
}
closedir($dir_handle);
?>

delete rebdev related files in your directory and let it resync?

In R2, dir? tests the file node to see if it´s a directory or just 
a file. However, in R3, dir? works like file? and only tests whether 
the value ends with a #¨ /¨

This leaves no way to detect an actual directory

Even info?/type is incompatible. ´directory for R2 and ´dir for R3

uh, on Vista and R2 I get:

>> dir? %work
== true
>> dir? %work/
== true
>> file? %work
== true
>> file? %work/
== true


Is that correct? :-) There is a work directory on my system, so how 
is that "file? %work/ reports true?

Isn't a directory also a file?

Graham, if you want to form file paths without checking whether the 
directory portion has a trailing #"/" do this:
    blah: %dir
    f: blah/(file)
instead of
    f: join blah file

Done. Here is the R3 and R2 FILEIZE:

fileize: func [
	{Returns a copy of the path turned into a non-directory.}
	path [file! string! url!]
][
	path: copy path
	if #"/" = last path [clear back tail path]
	path
]

Here is the R3 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	'dir = select attempt [query target] 'type
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	'file = select attempt [query target] 'type
]

Here is the R2 DIR-EXISTS? and FILE-EXISTS?:

dir-exists?: func [
	"Returns TRUE if a file or URL exists and is a directory."
	target [file! url!]
][
	if #"/" <> last target [target: append copy target #"/"]
	found? all [
		target: attempt [info? target]
		'directory = get in target 'type
	]
]

file-exists?: func [
	"Returns TRUE if a file or URL exists and is not a directory."
	target [file! url!]
][
	if #"/" = last target [target: head clear back tail copy target]
	found? all [
		target: attempt [info? target]
		'file = get in target 'type
	]
]

As an alternative to DIR-EXISTS? and FILE-EXISTS? we could change 
EXISTS? so it returns more information.

; R3 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    select attempt [query target] 'type
]

; R2 version:
exists?: func [

    "If a file or URL exists returns 'file or 'dir, otherwise none."
    target [file! url!]
][
    unless error? try [
        target: make port! target
        query target
    ] [

        either 'directory = target/status ['dir] [target/status] ; To work 
        around a current incompatibility
    ]
]


EXISTS? could still be used in conditional code, with the exception 
of AND and OR, but would have more info if you need it.

Sure. In REBOL 2 there are 2 functions, EXISTS? and DIR?, that check 
for whether a file! refers to an existing file and whether the existing 
file is a directory, respectively. Both of these functions wrap around 
QUERY, a low-level native that works very differently between R2 
and R3, mostly because of the port model change. In addition, DIR? 
has a design shortcoming in R2 (mentioned in CureCode ticket #602) 
and both DIR? and EXISTS? share the same bug in QUERY in R3 (#606, 
affects #602 and #604).

All of these combine into a few problems:

- People who want to write file and directory management code that 
is portable between R2 and R3 have trouble doing so.

- Bugs of the kind mentioned in #602 are not likely to be fixed in 
R2, so we have to consider DIR? broken for non-existing directories.

- Using both DIR? and EXISTS? means two QUERY calls, which has overhead, 
particularly for networked files.

- Attempts to get around this using QUERY require completely different 
code in R2 and R3, so wrappers would be nice.


As it specifically relates to 2.7.6, for people who don't care about 
forwards compatibility, there is only one problem:
>> DIR? %nonexistingdirectory/
== false  ; Should be true, unlikely to change

>> a: %directory/
== %directory/
>> trim/with a "/"
== %directory

maybe I understood Brian wrong.. I thought in current situatuion 
you need to call exists? somepath and dir? somepath to know that 
something exists and is a directory (which also means two query calls 
I suppose)

Janko, yes, the current situation is exactly that; to know that a 
directory exists, you need to call exists? and dir?, which causes 
two QUERY calls.

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

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

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

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

The main thing you need system/user/home *for* is to know where to 
look for %user.r - it is not safe to look for it in the current directory, 
and not multi-user-friendly to load it from the same directory as 
%rebol.r. R2 is horribly broken in that.

having user.r in current directory is really simplistic though ...

I would use user.r if REBOL consistently started in the same directory 
everytime.  I end up with %public folders all over the place.  My 
use of user.r will be better handled with a custom host process so 
this is not a request for user.r to be kept just a statment that 
I haven't been able to use it for what I want to in the past.

BrianH:  I use user.r for a few little things, but mainly I get it 
to call my anton-user.r script. I forget when but there were some 
instances  (when I was on Windows) where rebol would overwrite user.r 
(testing a fresh rebol beta?). That's why I decided to get all my 
code out of it and just DO my anton-user.r script from it. On linux 
I also set system/options/home where I want (not the user directory).

I don't change environments much. All new rebol executables are placed 
into the same directory and beaten with a stick until they work using 
the same user.r and my anton-user.r script.

Download R3. Copy it to a directory of your choosing. Run it. Enter 
the "chat" command.

I usually purge the directory when I'm not working on the files. 
Then when I want to work with them I get the specific files I want 
to edit, edit them, test them locally, submit the changes, then empty 
my work directory. If my submission sucks I deny it, if it is good 
I accept it.

If I want to keep local versions to compare to I keep them in another 
directory, then compare to the changes made by others. I only need 
to do this when I am working on the same file that others are working 
on, usually a sign that there is too much in the file (it needs to 
be broken up), or that I need to do a better job of talking to the 
other person.

The mac version appears to be working. At least call "ls" gives me 
a directory listing.

Another drawabck, if an existing user launch the chat from another 
one place (another directory, disk, or computer), the all the database 
is loaded again in local

all files are in the same directory.

R3 file! paths ignore multiple / characters, though the CLEAN-PATH 
function replicates the leading multiple / fill-in-the-blanks behavior 
of R2 file! access, relative to a cuurrent directory.

The problem is that an http server has the option to provite a directory 
of their resources, but there is no generally agreed-on machine readable 
format for providing such a directory, and the human readable format 
(a Site Map), isn't implemented on most sites. If the site you are 
interested in has a site map you can grab and parse that, or you 
can trace throuugh the links on the site and hope for the best, or 
you can make use of an external service like Google that has already 
traced through the links.

Most sites that do provide a site map only include a brief overview 
of their resources, not a comprehensive directory.

Are you on Vista, isn't the "windows" directory a protected system 
directory - perhaps that's causing an issue.

and to get and set the current directory. CD ?

As for your other question, look at this:

>> call "cmd.exe /c dir"
== none

>>  Volume in drive E is APPS
 Volume Serial Number is 7845-7730

 Directory of E:\REBOL\2.100

01/14/2009  03:17 PM    <DIR>          .
01/14/2009  03:17 PM    <DIR>          ..
01/14/2009  03:24 PM    <DIR>          base
01/15/2009  12:17 PM    <DIR>          updates
07/12/2009  03:08 PM                56 blah.txt
02/25/2009  08:09 PM               492 user.r
03/02/2009  10:22 PM    <DIR>          work
04/09/2009  08:41 PM                66 test.r
06/13/2009  12:09 AM                28 mod1.r
06/13/2009  12:09 AM                28 mod2.r
06/13/2009  12:10 AM                47 mod.r
08/10/2009  08:39 PM    <DIR>          plugin
08/13/2009  03:35 PM           613,376 r3.exe
08/13/2009  07:08 PM    <DIR>          extension
08/13/2009  08:46 PM            20,480 ext-test.dll
               8 File(s)        634,573 bytes
               7 Dir(s)   4,893,769,728 bytes free
1 + 1
== 2


I did that 1 + 1 to show that I didn't have to hit enter to get back 
to REBOL. You only have to hit enter to see the prompt. The extra 
>> above the dir outpt is the result prompt that you aren't seeing 
below. This is because CALL on Windows returns immediately, rather 
than waiting for the called process to finish its work, including 
its console output.

Sounds like Pekr is trying to capture the output of a directory listing 
in R3, is that correct?

As for bug#706, it's a file permissions thing. You can set the permissions 
of the directory that REBOL is installed in, so that only authorized 
users can write to it (generally, only the administrator). This means 
that %rebol.r can't be written by untrusted scripts. If you let %rebol.r 
be loaded from just any diirectory, regardless of who has permissions 
to write to the directory, then you have enabled %rebol.r to be used 
as a malware installer.

Then put REBOL in your current directory too.

yes, REBOL in my current directory ...

In the same directory as rebol.exe, yes.

BrianH: re #1210 - "--import path" ... I almost everytime prefer 
the concept of "current directory". I hate systems, which pretends 
to be "installed somewhere", and then, working with stuff in different 
directory, still pretends the current directory is that of user profile 
or installed app. That sucks big time. I always prefer simplicity, 
or at least things to be settable ...

That means that you already had versions of those files in your work 
dir, and that get * didn't overwrite them. If you haven't made local 
changes to any files in that directory, do a purge-dir, then get 
*.

IN-DIR is used for file manipuulation code, when you need to change 
the directory for onne bit of code and then change back.

The old DevBase used to use it to handle its work directory. Don't 
know about the new one.

I fixed my StRIP packer (based on RIP but the result is enbased instead 
of binary data - I had a reason to do this) for R3. Packs directories 
and I added one refinement - /code - you can add additional code 
that is run after unpacking the archive. So you can use that directory 
just as a temp dir and then move files somewhere else or anything 
you want. It's basically  a package manager, a very spartan one, 
but good enough for me. Get form next line (to prevent that extremly 
old and stupid AltME links bug).

I went ahead and built the host build using mingw.  This was a breeze 
in mingw.  However, I suggest updating the documentation to just 
update your path statement to include a path to mingw/bin and instead 
of copying mingw32-make.exe to make.exe just go to your r3 host build 
directory and type mingw32-make.

Yeah, I don't care for the instructions we have for mingw.  We shouldn't 
have to copy the mingw32-make.exe file to make.exe.  We should just 
have to go to the rebol directory and type mingw32-make and be done 
with it.

One of my problems with R3 is that I get this feeling that an R3 
beta is immenant but feel it is still long way off and have concerns 
about the negative impact that will bring.  There is a great deal 
of expectation for the beta and I feel it is going to be viewed on 
Monday morning as a disappointment when it comes.  I'm hoping that 
the REBOL team makes sure that it hasen't left little things undone 
such as being able to change a date on a directory, etc...

Henrik, I started server first, originally I've set the wait to 60 
in server to be able to start client without hassle. Only what I've 
changed else in server was make-dir to not to create temp directory 
each time the server is started. But give me some time to try it 
in other machine.

So, for hylafax which uses the ftp protocol ... I would have to rewrite 
the whole scheme because the ftp scheme assumed the directory listing 
was always in a certain format etc.

However, FTP directory listings are a different issue, protocol overhead 
that needa a lot of special-case code, as I recall.

so I just approached it by supplying a callback to format the directory

Another potential issue is when a virtual-root has the same name 
as a real directory at the default root dir. I don't know if that 
can be warned for, but it caused some confusion here before I figured 
out what was wrong.

Two other issues in the 0.9.19 source:


1. INCLUDE and INCLUDE-FILE do not process paths identically. This 
is not mentioned in the docs.

2. INCLUDE won't include files in absolute paths. It simply changes 
the path to the current path which stores the RSP file that is currently 
being executed. I can't say that I have a fixed include directory 
somewhere at an absolute path. I don't see the purpose of altering 
the path like this.

In the www directory there's a demo file called email.rsp which you 
can use to test the MTA.  Change line 58 to your own from address.

Does Cheyenne produce error log? I can see directory called /log, 
but I can see only default-access file in-there ...

why not in log directory = all in one place?

I'm running Cheyenne as port 8080 on a machine that also runs IIS. 
I want to get Windows logon which IIS can force for a directory. 
  Anyone doing this already?

I've got this really odd situation ... I have Cheyenne and the rebol 
micro web server both running.  Cheyenne is on 8002, and MWS on 8001.
Both share the www directory.

at times I access a file and I get a 404 from Cheyenne but the MWS 
can find the file!

my httpd.cfg root-dir is pointing correctly to the right directory, 
and I have an exception for cheyenne.exe in the windows firewall.

Looks like my application is writing files to a hidden directory 
somewhere which the MWS can see, but Cheyenne can't see.

cause there is a default directory for all incoming file data ...

I am a little concerned.. My entire cheyenne directory is rapidly 
approaching 2.5mb.

This is odd .. I tried calling my batch file using a full path, and 
it did not work.  The only thing that did work was to cd to the directory 
and then call it without the path.