World: r3wp

crashes windows as well

+1  
1.3.2.4.2 and 2.7.5.4.2
Linux

is it recursive?

I'll check RAMBO add if not in there then...thanks Graham...I just 
reduced it to this so far...more experimenting to come.

How about this on your end...just trying to reduce the code for the 
RAMBO report.


foreach a to block! {'word} [print get a]  - this segfaults on Linux. 
too.

Got the same result... 1.3.2.4.2 and 2.7.5.4.2

get first to block! {'thing}  returns an error message  ** Script 
Error: thing word has no context
b: first to block! {'thing}
== 'thing
get b     segfaults.

windows REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3 goes boom

reported.

to block! does not bind. word is not included in system/words. sometimes 
that results in an error-mesage and sometimes in a crash.

Good one.

yeah , it's the normal behaviour for to block! , use load instead 
for binding

what happened to my https rambo report ?? :(

i haven't seen it. worst case it was deleted with the spam (i check 
them carefully, but i may have missed it)

yeah ... I think you nuked it :(

did you re-enter it?

No .. did you want me to ??

if it has been deleted, there's no way to recover it.

2.6.2 and 2.7.5, Windows and Linux (probably others too) : Encmd 
crashes if 'title keyword is used in 'encap header. It works correctly 
with enpro and enface.

Is rhis a bug, or just undocumented behavior?
   trim "  a  ^/  ^/  a  "
   == "a^/^/a"

The help says "Removes whitespace from a string. Default removes 
from head and tail." But in this case it seems to treat the string 
as a set of strings (separated  by  newline) and trims them all.
Compare with the expected behavior here:
   trim "  a  b  a  "
   == "a  b  a"

TRIM behaviour is strange.  Sometimes it removes too much as in your 
case, sometimes it removes too little as in (trim "^/a^/" == "a^/") 
. I would say it's a bug.

I'm beginning to think so too, especially as (from my reading of 
the function), these two should be equivalent
trim/head/trail "  a  ^/  ^/  a  "
trim"  a  ^/  ^/  a  "

Hence why I always use trim/head/tail...  I didn't think it was a 
bug, though, since your first example - trim "  a  ^/  ^/  a  " - 
could be a shortcut for data files..  Trimming each line.

Sunanda, I think, from memory of old conversation, that the default 
TRIM behaviour is particular and just insufficiently documented. 
It's annoying, chuck it in RAMBO to specify exact behaviour in doc 
string.

On windows platforms, you'll get the infamous DOS window flashing 
when executing an external CGI ! It's just a matter of 1 flag to 
correctly set in 'call C source code, if you're really annoyed by 
that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I 
may reimplement completely call command in REBOL, but it would be 
a big waste of time and energy...it should be a 10 minutes fix for 
RT. Addind a time limit to 'call would be a good thing too, it would 
also avoid me the reimplementation of 'call to add such feature....
 - DocKimbel

Anx chance of getting above fixed? Should we rambo it?

wouldn't hurt :-)

I think that it's already in RAMBO

then it's probably been forgotten in Gabriele's priority list for 
2.7.6.

RAMBO lacks a free commenting support...

Re my trim question of a week or so ago....
Thanks for the responses.
From RAMBO it seems this is deliberate (if unexpected) behavior:
http://www.rebol.net/cgi-bin/rambo.r?id=3681

This is intentional and not a bug. TRIM was designed that way to 
work well for trimming LINES of text. 
 [my emphasis of lineS, plural]

DocKimbel, #4288 looks to me like it inserts a molded object into 
the path.

or perhaps form

Yes, it returns the object source and the point is is this useful 
to anyone ? I was hoping the behaviour of :b in a path! could be 
changed to something more useful, like acting as a pass-thru to /c, 
so that, in the ticket example, a/:b/c would results in %path/target.

slipping objects into a path...

>> a: %path
== %path
>> b: context [c: %target]
>> a/:b/c
== %path/c: %target%0A/c
>> a/(:b/c)
== %path/target

Great! I've forgot paren! evaluation in paths.

btw, a/(:b/c) is quite heavy => 3 series instead of 1.

yes, but semantically a/:b/c is a/(b)/c not a/(b/c) which is what 
you want.

Do we still bother reporting to RAMBO?  Is there any expecations 
for a production 2.7.6?  I'd vote; please please please.

[ 4322 ] can be closed

[ 4321 ] can be closed

Norman, could you please elaborate? It might help people noticing 
the same thing.

yes sure... [ 4322 ]  SDl 276 was recompiled for both kernel 2.4 
and kernel 2.6 [DEBIAN] (previously only kernel 2.6 was compiled) 
and they worked here. I cant confirm on ubuntu as its not my flavor 
of yoghurt ;-)

[ 4321 ] this is actualy  a borderliner.. Im not sure this is default 
behavior in windows or not, liinux does not have this problem, could 
stay open..

thanks.

.

Looks like RAMBO needs to be cleaned from spam posts...

I've just run in a bug in enface.exe (2.7.6.3.1). The following code 
doesn't give the same result if run under view  or encapped with 
enface :

REBOL []
probe type? first [#[none]]
halt

rebview => none!  (correct result)