World: r3wp

Are there any news about  #3869 CRASH (Should not happen)  - Invalid 
string width 16 : type 41 ?


A few weeks ago I got the same error randomly with the new beta command 
version.


I was now able to boil it down and it seems to be a general problem 
in all new versions.

REBOL [
]       		

On_Data: func [
	port
] [
	msg:  copy port
		
	if any [none? msg  empty? msg] [
		remove find port-list port
		attempt [close port ] 
		return false
	]
	append port/locals/buffer to-string msg
	insert port { }
	false
]

On_Listen: func [
	listen
] [
	conn: first listen
	conn/locals: make object! [
		buffer: make string! 4000
	]
	conn/awake: :On_Data
	sockets: sockets + 1
?? sockets
	append port-list conn  
	false
]


sockets: 0

port-list: reduce [
	listen: open/direct/no-wait/binary tcp://:13011 
]
listen/awake: :On_Listen


forever [
	error?  try [
		conn: wait port-list
	] 
] 
close listen

Just send as many messages as you can from other computers and sooner 
than later it will crash .

Anton: it is not a bug for me.

What do you should like to happen?

Perhaps an error would be a better behaviour.

i got version REBOL/View 1.3.1.3.1 30-Aug-2005 Core 2.6.0 and my 
async ports are not working, open has no refinement called async 
a bad build ? somthing missing ? help

ok i've dowloaded REBOL/Core 2.5.53.3.1 ALPHA VERSION (Aug 17 2004/22:43:09) 
(note both, this 2.5.53 and the last 1.3.1.3.1 are win x86 versions 
running on XP SP1) and works okay ! what wrong here ?

/async is only in alpha releases. official releases do not have the 
async core (it is still considered somewhat experimental)

Gabriele - isn't 'request-date somewhat unfinished?Try 'help request-date 
and look how is /offset described, what it says it accepts (any type) 
and what it really allows to accept (pair) ... Maybe this could be 
improved ...

i guess all request-* require some refinement.

besides that I wonder, if e.g. request-date as an example, works 
with locale element? I think not ... REBOL locale support is really 
terrible - nonexistant, and I wonder why, if system/locale/months 
is available ...

yesterday I got request of my friend Bobik here, asking how to localise 
it  :-) I suggested him to look into RebGUI calendar instead ...

ah, now I tested it, RebGUI works with system locale - besides that, 
the week starts by monday ;-) btw - could RebGUI code be reused in 
official rebol distro? e.g. as far as request-date is concerned, 
or even request-dir, it is of a much more quality than rebol's built-in 
ones  ....

I had done some enhancements to request-date in the days of "View 
1.3" project (2 years ago).

The result is in RAMBO, but not the code http://www.rebol.net/cgi-bin/rambo.r?id=3058&
So you can find it here with some demo code :
do http://membres.lycos.fr/didec/rebol/request-date-enhanced.r

It use locales and can start on monday or sunday, show today with 
red circle, has today button at bottom, and can be initialise with 
a date shown with a red square.

shoul i spent my time on /async ?  i mean im not shure about using 
it it's experimental but will some day applied ?

it will most likely be implemented, but we'll have to wait and see 
if it will be exactly that implementation.

Romano, I was expecting TRUE to be returned from the function.

Maybe this makes it clearer:
>> do func [][while [true][return 'from-body]]
== from-body
>> do func [][while [return 'from-cond][return 'from-body]]
== none

I am expecting the second example to return 'from-cond.

Im really worried about this alpha thing, personaly i belive rebol 
is a great tool and i use it all the time, 

i know there is the time factor in development, but i belive there's 
no priority and the policy about TODO's 

it's crazy, on one side, services, view and graphics, sound formats, 
and on the other, multitasking, async ports, 

OSX support, and so many, many others... all taking place at the 
same time... 

We don't know what's first on the list, rebol changes as fast as 
developers type their code, 

(i dont  mean it in a bad whay, but still worries me) so todays 100 
lines may be tomorrows 10 

and so on ... why to spend time writing code on some issue will never 
leave alpha state, or even workst, be droped down 

some code will loose compatibility with newer versions and refuse 
to work, 

some other cobe, may become obsolete and old as soon we put it on 
the market, i think rebol has loose the KISS strategy. 

i know we love our 600K amazing tool, but don't be fool, this 600K 
don't mean is an easy and standarized 

development tool it's more like an other thing... ok it still is 
a cool tool, bla bla, but we must know 

there's a line conducting rebol upgrades, not just the crazy 600Kilobytes 
limit, 

it would not mind to my even if it whas 600 megas at this point this 
limit has loose the sence to be. 

i think here ideas come and go to fast, development has, in the last 
years, been embeed with the fashion of some lenguages, 

leave out the top then fight, we dont need it, just make it simple, 
i know rebol will reach maturity only if a srtight line traces his 
development

let's wait what Carl will say at devcon on friday - his keynote is 
"Accelerating REBOL improvements"

please note that i know rebol is been maintened by a small goup of 
developers, and with a small budget,i know a LOT of 

work has been done now and in the past, the reach today rebol state 
of development, and there's too many thing to do to make us all happy

You are not alone waiting for what comes, because while View 1.3 
was nice example of how things could/should work, nothing public 
happened since then and it is not a good sign. That is why I suggest 
to wait one more week - but to be honest - for me it will be deciding 
point if I start to take REBOL more seriously or not, because I don't 
want last devcon promisses to happen once again - none of the promissed 
stuff was actually delivered ...

may be here thing are getting to big for such a small goup of people 
and budget, rebol development need's to take place in another context 
that's somthing we all know

anyway - chatting in wrong group ...

what goup should we chat ?

whatever - Chat for e.g. - RAMBO is bug reporting related group ...

Anton, the first block of while it is not the body of loop, it has 
a special meaning, for example it must eval to an any! value:
>> while [][]
** Script Error: Block did not return a value
** Near: while [] []

I see many solutions:
 while [return true] [] could be considered like
	- while [true] [] 
	- an error!
	- return from while with a value (like break/return value)
	- return from the outer function (your proposal)

i am not sure about what can be considered the best

Perhaps your proposal can be the best: eval the first block like 
the second one.

Anton: I support your proposition too. Carl once corrected a similar 
issue with BREAK from WHILE condition block.

Romano, yes I think to be consistent, it would be better that RETURN 
should exit the while loop and return from the function, and BREAK/RETURN 
should only break from the while loop.  That way we don't have to 
think when we can and cannot use RETURN.

probe system/version ; 1.3.1.4.2   

sec: [lroot [allow read] ldir/test allow %/home/volker/webconsole/data/cgi/ 
[allow read]]
lroot: %lroot/
ldir: %ldir/
probe reduce/only sec [allow]

this crashes reliable here

(on linux) can somebody confirm

>>  probe system/version ; 1.3.1.4.2
1.3.1.4.2
== 1.3.1.4.2

>> sec: [lroot [allow read] ldir/test allow %/home/volker/webconsole/data/cgi/ 
[allow read]]

== [lroot [allow read] ldir/test allow %/home/volker/webconsole/data/cgi/ 
[allow read]]
>> lroot: %lroot/
== %lroot/
>> ldir: %ldir/
== %ldir/
>> probe reduce/only sec [allow]
08526730 2F000000 C0FC5108 00000000 00000000 /.....Q.........
08526740 00000100 00000000 00000000 00000000 ................
08526750 2A000000 B0D75208 00000000 00000000 *.....R.........
08526760 2F000000 D0D65208 00000000 00000000 /.....R.........
08526770 60095208 20D95208 00000000 00000000 `.R. .R.........
08526780 16000000 68010000 23020000 889C1608 ....h...#.......
08526790 2A000000 10D75208 00000000 00000007 *.....R.........
085267A0 2F000000 20D75208 00000000 00000000 /... .R.........
085267B0 00000000 00000000 00000000 00000000 ................
085267C0 5B616C6C 6F772072 6561645D 5D0D0000 [allow read]]...
 
** CRASH (Should not happen) - Corrupt datatype: 96 at 201

on linux

ax: make struct! [fnc [callback!]]none
ax/fnc <---- this hangs up rebol with a GPF error.

rebol callback
 -> http://www.rebol.net/article/0141.html

sorry, wrong group.

that damm article,  yes i've read it too many times maybe... ok what 
about this  

a: make struct! [x [integer!] y [integer!] z [struct! [ xy [integer!] 
yx [integer!]]]] none 
length? third a 

== 12 <--- it has 4 integers thats 16 not 12 !  what about 0141.html 
now ????

xy is a pointer to a struct, nt the struct itself.. sadyl we lack 
nested structs.

yes it's a pointer to the struct, a workaround my be done because 
you can know how many intems are including the nested one's, and 
as far i can see rebol assigns 4 bytes for all datatypes meaning 
strings and nested structures ar also pointers

you can use size: (length? second a) * 4
it may fail :-)

yes, all pointers. workaround for amll structs is: z [integer!] z1 
[integer!] ; in the main stuct. for other things you can try binaries 
and deal with offsets. or write a wrapper in c.

yes that's execly what im doing ;-) i send a number to C it read 
n data from the pointer and then passes to rebol as a string the 
i use Romanos's wraper to cast that into a structure; but i get ocational 
crashes when reading fron a crazy pointer :-) i consider this a hack, 
but still may work ...

attention: pointers in structs are considered strings. they are copied 
back *until* a 0 is found.