World: r3wp

:)  My concern for readability would be avoiding REBOL code starting 
to look like perl, where you have to decipher while reading.  Coded 
code is fine for things like C, J and R but REBOL has a very nice 
quality of being grok'ed at a glance.  Losing that would be sad. 
 ICarii said it best already ... let's not go there.  So I'd almost 
like to restrict the new feature to last-console-expression just 
so we don't go overboard with short-cut expressions in scripts.  
Thinking along those lines, perhaps system/console/last-result would 
be fine.  Developers could add .: or `: or ~: to personalize for 
console work.  Then again, system/console/last-result wouldn't want 
to be set for evey expression.  Just when needed, so it'd have to 
be an action, not a data set.


Ingo;  Wow.  As I was typing...you were echoing the same thoughts.

Right, I was thinking about what you said about system/console/last-result, 
too, but was too lazy to add it to my post ;-)

Well, REBOL is all block/series based .... and series is a "queue" 
of values. I would like to have stack of values (block of values), 
series, which we can pick-up from, sort, move, remove - no ackward 
one only value!

then define your function as you wish. Via pick, select, whatever, 
call it whatever you like .....

Petr; A lot of this comes down to what is going to cost the REBOL 
evaluator.  I don't know, but have a feeling that a lot of intermediate 
results are discarded.  Could be wrong.  But if so, I wouldn't push 
for anything that will slow down current execution speed.  If the 
values are there on a stack today, great.  But II'd guess that only 
the last may easily (and zero cost to current run-time) accessible. 
 And with some fancy expressions, what goes on the stack in what 
order may be optimized differently than reading code left to right. 
 I'll ask while pointing out the interest that has been shown here 
by the group.  If coders want a pickable list of expressions today 
we have reduce and friends.  I'm more aiming to get at the last result 
from the console as I'm always forgetting to put a var: in front 
of test code, especially code tthat returns an object! that I'd like 
to probe.

I was kidding of course about readability - don't want Rebol to become 
write only like Forth :)

I guess we need to know what we can get before we start naming things.

I'd suggest sticking with system/console/last and then set up your 
own %user.r shortcuts around that -- everything in its place...

I'm leaning toward agreement with that Chris.

Ditto, and I'd like to limit the number of "console-only" words we 
add to the global context.

I suggest 'bike-shed

Kaj;  :)

The request for this feature has become more formal.  Mr. Hawley 
put in the ticket.  He has an excellent grasp of upcoming security 
and threading issues and worded the request accordingly.  The request 
went   in as system/console/last.  That could change and it's still 
only a request; but there it is.

so, it's only console?

not usable from within a script?

That's still a question, but I'd guess console, as part of the display 
result sequence...maybe?

usable within a script

 would just slow things down, as there's no reason to use it at all.

to save allocating a local variable ?

It might affect readability?

1 + 2
4 - result

Then can't you just compound the two lines and save a carriage return 
as well ;-)

Just wondering if there is any point in having a result stack we 
can push results onto and then use?  Is that faster than using local 
variables?

Dunno. But then, does it help readability?

there must be a penalty in creating variables in terms of memory 
allocation, and deallocation

if readibility were so important, Carl woudn't use one letter variables 
in his code :)

the stack would have the same penalty as variables

also, if it's the last expression, no variable is needed.

I wonder when this "wine" period is over for RT :-)

Does the new draw have a concept of current position on the canvas?

Which is also accessible to the user ...

only within the shape commands as per R2

pity

it would make it easier to do typesetting if we had a currentposition 
command as in postscrip

you can always store it manually i guess and process the draw block..

could probably make a type setting dialect around that. many new 
dialects are possible.

there is currently a dialect extension to make draw drawings automatically 
resizable.

graham, do you know if there is such a dialect for R2?

Nope.

I see that Apple plan on releasing an SDK for the iPhone in Feb ... 
let's hope R3 has some way of being ported to this platform.

http://www.apple.com/hotnews/

porting to the iphone/ipod is one thing i would try :) (my brother 
has an ipod touch). but, i'm not sure apple would allow a programming 
language in...

It'll be interesting to see what exactly they allow. Not being specific 
enough in this area worries me a bit, so we can't tell whether it's 
going to be completely free, but has to be approved by Apple, or 
if only the big boys with the big money are allowed to play.

Are there going to be any interrupts that are based on absolute times?

Or, are we going to have to run our own timers and count the time 
ourselves?

I have the need for long running server applications to do house 
keeping at night ...

Generic timer events will come, since this is needed for animation 
in VID3. I think you can use them for that, but Gabriele knows more.

I could post my little cron dialect for R2. It's been doing backups 
for months without trouble.

I used Bo's cron script some time ago and that seemed to work ... 
I'm just interested in knowing how the timer events will work.

Forinstance, my Cerebrus anti-spam script regularly ran out of resources 
and crashed after a week or so, so I was wanting to reboot it once 
a day as it were to prevent that happening.

I'd also like my emr script to start processing various tasks after 
mid-night - like sending out email reminders to patients etc.

I have the same need Graham, so I'll push for good built-in support 
too.

a bit more progress on DevBase today to allow uploading of many files 
in bulk. still a few more bits to do. DevBase will hold the code 
to itself, so we can help updating it along the way.

there are now a few extra useful mezzanines that haven't been added 
to R3 officially. perhaps they will go in there as well.