World: r3wp

(in near real-time, using thousands of liquid nodes  ;-)

but the main limiting factor is still view refresh speed (view and 
AGG that is)

Maxim, how long do your apps run?

but a part from async http closing of ports, I have not had a single 
crash of rebol in many months... a year? maybe.

it depends... retask is a very graphics heavy app and it can run 
for days without being ended.

but most apps I use are punctual in use, but that will change with 
elixir in a few weeks

altme can run a long while too... without crashing.

About crashes, I submitted 4267, 4238, 4167, 4137, all crashes, and 
I found them on my own. Besides I've bumped into recycle crashes, 
port crashes/hangs and also other crashes, that I can't put my finger 
on, when using Rugby with secure network transfers. I get a crash 
about 1-2 times a day.

yes... there is something weird with the port management.  as I said 
a part from that I've had no bug a part from a few AGG problems.

when I said crash, I really meant... random bang!  like it used to 
happen every week!

there still are some specific things which explicitly crash rebol... 
 especially in Draw.  :-(

I do have very small apps that can run for weeks and weeks and never 
make trouble, but as soon as the apps grow in size, the crashes get 
more frequent.

but something in view still is eating MB of ram when opening windows 
and grows.  :-(

humm  I'll be more observent with elixir, which is now at 400kb source 
when linked (without SDK sources) and about 25MB of ram when running.

that is sad to hear, Henrik. RT should either dedicate their time 
to fix those nasty issues, or forget 2.7 cosmetic release altogether 
...

I did put a word with Carl about the tcp port instability of R2 at 
one of the informal late nite meetings some of us had. Gabriele agreed 
to some extent that there was some port strangeness so if that gets 
any real overview by Carl probably remains to be seen, but at some 
level he knows we are having some oddities with it.

4267, 4238, 4167 all seem reasonably easy to work around Henrik; 
not that I'm saying they aren't important, or shouldn't be fixed, 
but we don't know RT's internal development setup, so we can't really 
say what they should do. We all have different priorities. 


I would like to see a large set of public tests, to help RT nail 
bugs and catch them when they sneak in.

I still have a Rugby app that runs away once in a while, too. I don't 
know if it's Rugby, REBOL, or something on that specific machine, 
because it never did it before this new machine was set up.

double port close crash has been fixed in 2.7.6

please guys keep in mind we can't fix all bugs at once. and we can't 
usually fix two "big" bugs at once (big means it takes a lot of time 
for Carl to figure it out). so we fix one big bug and many small 
ones (bugs that can be fixed in a couple minutes always have precedence 
because there's no point in making them stay for years on rambo).

also... "sometimes rebol crashes" is something that's not going to 
get fixed. there needs to be a way to reproduce the crash - otherwise 
carl would need to spend many days on it.

Then again, it isn't always easy to lift the bug from  [long running 
 / large volumes of data / 1000s of lines of script] applications, 
and set it into a small example.

I once tried to produce a small script that relicated the block-manipulating 
logic of an app I have. I was hoping that running it over night would 
create a "should not happen" bug. It never did.

By way of compensation. I did find this one-liner that will crash 
(without warning) every version of REBOL I've tried it on:

     a: copy [] b: copy [] insert/only a b insert/only b a same? a b
(I think I reported that, but it was before RAMBO)

You will fix the Linux side right?  "Sometimes rebol crashes".  Sorry. 
 :)  I'm still 
attempting to find a short piece of code that trips the segfault.

does not crash on REBOL/View 2.7.5.3.1 18-Mar-2007

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 ??