World: r3wp

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.

workaround: use two references: rebol-ref: make binary! 1234 struct/pointer: 
rebol-ref
then access things thru rebol-ref

yes thats why im sending the amount of bytes to read back to the 
C wraper still it gave me a haed hache lol

if I would even understand what you are talking about, guys :-)

so you trying to say, that if there is struct inside a struct, you 
don't use it, you just provide it with "flat" binary, and then you 
compose things back in rebol level? Why is that better than using 
structs in structs?

well realy the thing is... did you remember that windows sometimes 
adresses structures in window messages like lparam or wparam, so 
i get the nasty number, and i've to buil a structure back from this 
*pointer*,..... because i do drugs :-)

well, you cant see what we do, because we crawling under the cars 
engine here ;)
but yes, you are right.

its because rebol has no inner structs. when you declare them, it 
actually allocates a pointer there.

thats fine with own code. but os expects real inner struct, so we 
have to workaround to allocate the right space.

but if you can code c, i would do all the os-coding in c then, and 
use rebol-structs only for pasing between rebol and my c. gives os-includes 
without any pain, much easier.

coding in C stinks .... I don't wanna carry C compiler with myself, 
unless included in Rebol ;-) Librry interface should be enhanced 
then. What about trying to post a wish into RAMBO?

some years ago i've used a realy cool compiler rapidq the bastard 
dident have the posibility to pass structures back that time i used 
this kind of workaround

what do you mean ?

I don't even know what do I mean. The only thing I know is that I 
find wrapping libraries not all that comfort and I would like to 
ask those having experience with Python,Perl or any other language, 
if they have some easier way of how to do that or not ...

c-compiler costs me ~4mb if it is a big one. and a good interface 
needs processing includes. basically that *is* a c-compiler included 
in rebol then ;)

Maybe the trouble is really in me and not being able to properly 
do datatype conversion and all those structure wrappings etc.