World: r3wp

i'm not saying the crash bugs should not be fixed. i'm saying that 
in the current situation there are not enough resources to fix them 
unless there's a simple way to reproduce them. hopefully, after r3 
is out, there will be more time to give to r2 and we'll be able to 
fix those misterious bugs too.

Is it easy to switch off gc inside a wait?

For Carl that is.

Sunanda, IIRC that bug was in RAMBO and was fixed some time ago (maybe 
2.6.2 or something like that)

http://www.rebol.net/cgi-bin/rambo.r?id=3259&

Thanks, Gabriele.....My collection of REBOLs are a point release 
or two behind

It does not crash 1.3.2 here.

I started using 2.7.6.

It's great to be able to "call" external apps without the dos window 
popping up. I have alot of use for this. 

I noticed, however, that when calling wmplayer in windows the file 
will play in the background which I also find appealing but there 
are times I might want wmplayer to open. Is there a way to force 
this with call?

black console window and freeing library component were my two only 
tickets I screamed for :-)

new refinement to 'call called /show maybe?

amacleod: library is free now! you should be able to use this http://box.lebeda.ws/~hmm/rebol/libShell32.r

is this at rebol.org? If not, it should be :-)

There does seem to be a problem with 'call that wasn't there before.

Lots of apps no longer open with call and need call/show or call/shell

regarding your example in R2-Beta - Bugs (Problems that need solving.)

This seems to be a windows behaviour. It works with the complete 
path;
 call "%windir%\explorer.exe C:\"

>> call {C:\Ghostgum\gsview\gsview32.exe}
== 0
>> call/show {C:\Ghostgum\gsview\gsview32.exe}
== 0

The first does not work, the second does.

Seems to be different for different programs.

Indeed. 

This is really curious and problematic, as the process is running 
in the background without an open window.

Not sure, but maybe they're trying to get a console handle, and can't.

Output handle rather.

does call /info refinement really work?  Shouldn't it return the 
PID number for the ID?

Ok, not going to affect anyone else except those of us in the New 
Zealand and neigbouring islands

>> rebol/version
== 2.7.6.3.1
>>  to-date "20/Mar/2008/10:16:56/++1300"
** Script Error: Invalid argument: 20/Mar/2008/10:16:56/++1300
** Where: to-date
** Near: to date! :value
>> to-date "20/Mar/2008/10:16:56/++1200"
== 20-Mar-2008/10:16:56+12:00

These were date strings being returned by an IMAP server in the rebelBB.cgi 
script.  And because parse-header-date barfed on this format, it 
kept returning today's date.

i put this on rambo a while ago (same reason, imap servers)

i worked around the problem in my imap parser. it's ugly though. 
i hope it gets fixed. :)

Should we ask Carl to fix this for 2.7.7 ??

http://www.rebol.net/cgi-bin/rambo.r?id=4302&

Graham I didn't know you were from New Zealand.  I always say to 
myself if this country (US) goes to crap (and it might if any of 
these democrats get elected) then I'm heading to New Zealand.  I 
don't know why I say that as I know very little about New Zealand? 
lol.

Yep, born and bred in NZ :)

Cool, then when the ?#!* hits the fan here in the US - you can be 
my tour guide.

:-)

I don't think we're immune from recession, but we do less trading 
these days with the USA and more with Asian countries

Not a problem.  Just here the country is out of wack.  Justices are 
now making laws.

How exactly does call/shell differ from just call on windows?

My guess: it calls via the shell (cmd under e.g. WinXP) instead of 
a directly Windows call.

Were you allowed to do like this in previous versions of Rebol?

bl: ["block"]
print switch type?/word bl [ block! bl object! ["object"] ]

Now it seems like you have to write something like:

print switch type?/word bl [ block! [get 'bl] object! ["object"] 
]

There's a page on differences between 2.6 and 2.5

http://www.rebol.net/cgi-bin/upnews.r?view=0008

Is anyone else having this occur:

When ever I start a script now I get an empty "public" folder created 
in that directory.

Confirmed for 2.7.6.3.1 on Win XP.

REBOL's installer hasn't worked at all since the 2.7 series, and 
it never worked correctly before that, though the 1.3 series improved 
directory usage. Fixing the installer is on the list for the next 
version.

By next version, I mean next version in the 2.7 series.

That is why the public folder is getting put all over the place instead 
of in the REBOL home folder where it belongs.

It seems running with -s does not create the public dir from my tests. 
 I thought  -i or -v would be the magic switches, but it's -s   ??? 
  Too bad, as -s is also the danger danger switch.

Oh, +s seems to fix it as well.  Better.

Little bit more playing around, to see if +s was taking ... doesn't 
seem so.
rebol []
probe system/script
change-dir %..
list-dir
ask "waiting"

c:\tools\rebol\appdata\rebview +s testing.r

...
    words: none
]
waiting

** Script Error: list-dir expected dir argument of type: file url 
unset
** Near: list-dir
ask "waiting"
>>

The ask is evaluated before the list-dir error     And if  list-dir 
%.  is used, it lists the dir, without a security box.

That's natural. list-dir expects an argument.

just the same as:
	1 + print "hello"

There seems to be a difference in CALL/SHELL (at least under Windows). 
Earlier versions open a shell window, the latest doesn't. I can see 
it, when I run my OpenGL stuff.