World: r3wp

make a color cycle from black to white...  there really is many uses. 
  with another function using this one, you can add tuples together.

My original idea was having something like a tuple where you could 
set a different base per number.

just being able to set tuples to any base as a whole (up to 64 unsigned 
bits) would be a great feature... something I will always miss for 
graphics, since many professional apps go up to 64 bits per channel

Submit a proposal to CureCode, or it does not get implemented :-)

About parse enhancement.

What would be the cost to be able to stop a parsing process (ie. 
with a STOP command) and to continue it where it was stopped ?
Huge i guess...

Your attention plz...

I noticed that between r3-a65 and r3-a76 (sorry i didn't test the 
interval).
we lost an hidden feature very useful (to my mind).

>>bin: #{000000}
>>bin/1: 513
>>bin
==#{010200}

Do you see what i mean ?

we could store integers into a binary stream in reversal order (little 
endian) without the need  to use a to-binary conversion (which consumes 
memory by reconstructing a binary and convert into big endian format 
instead).

But in the last alphas, we lost that.hidden feature:
** Script error: value out of range: 513

Any reason for that ?

This was changed in A68, it seems.

http://curecode.org/rebol3/ticket.rsp?id=1057

Harg... it was marked as a bug by Carl.
Am I the only one seeing that liek a feature not a bug ?

one good good point with rebol not being multithreaded able is that 
on the new core i5 750  your rebol VM can be set to work exclusively 
in Turbo boost more ( automatique overclocking)

Maybe just a stupid idea - but would it be helpful to be able to 
execute some code in context of a module? I mean ... we have in, 
in-dir, in-context ... what about in-module?

Don't you wanna use BIND for that?

maybe so ...

BrianH: Carl asked me, that if I want some of following implemented/noticed, 
we should put them to the parse document. I gathered them in R3 chat. 
So - I would like to open short discussion about following proposals:
------------------

I would like to ask, what will happen to proposals, which are not 
part of the do

cument? I mean - I do remember following kind of proposals, which 
are discussed
in parent thread:


1) make /all option be the default parse mode. If I want to get really 
reliable
results, I always use /all, to be safe


2) there was some proposal to add /space, or /ignore, to allow easier 
parsing of

 CSV, etc., but other proposal was, that it might be better to let 
 it to the enc
oder/decoder level


3) there was a proposal to allow quoting of "", to make parsing easier.

/all by default was generally agree on the blogs IIRC.

Carl calls for more opinions on parse, as we have just this week 
for changes ...

where?

Opinions about what ?

in R3 chat is there a way to read through the new posts sequentially? 
 its very tedious to access new stuff when its all spread around.

R3 Chat, type "n" for new messages, and "lm" to list the messages. 
It is generally enough to be able to participate. For reply, just 
type the msg number you want to reply to, and type "p" to post to 
the thread, or "r" to reply to such a message ...

you don't understand... I know that.  when the discussions is spread 
between 10 groups. its VERY tedious to read more than very few messages.


jumping around, hoping you don't miss posts, then listing again... 
over and over.   it would be nice if we could simply skim over the 
list of new posts in order of time.


then if we jump to a post we don't get the context, we just list 
that group... its easier this way.  but going to next mesage would 
still bring us to the "newer" message, not the next message in that 
group.


I'm not saying the current method isn't usefull, I'm just saying 
that another method would make it easier not to miss out on new posts, 
especially when there is a sudden flurry of posts all around the 
place.

It's very inefficient ...

If you read message, pressing enter continuously brings you next 
one in line ... other than that, this is not the topic. And even 
Carl asks, where the best discuss the Parse - blog, AltME, Chat?

But I would say it the other way - either you want to have some say 
into the topic, or not - decide for yourself.

Sometimes it is difficult for me to understand - most devs here are 
gurus being able to handle 100times more complex systems, yet they 
refuse to use Chat :-)

I think that we vote Carl to use blog - at least it is mine and now 
also Max's preference ...

pressing enter brings next message in a single group, until that 
group is at its end.. then you are at a loss in the new messages... 
which one did I see which ones did I miss?

I don't mind the text chat.  its just not really effective at handling 
large volumes of posts.

Don't worry - a chat GUI is planned.

ahah, good how we perceive stuff from different perspectives :-)


Carl's parse 'limit proposal:  Disadvantage - Could make some programmers 
lazy. 

BrianH's parse /ignore proposal: Advantage - It might allow programmers 
to be lazy.

Laziness is a virtue. Creative laziness is the best optimization 
strategy in the world.

The perspective probably also comes from who knows the implementation 
of PARSE (Carl), and therefore is less forgivable about usage.

I actually don't know why he said that comment at all. I can see 
the disadvantage of laziness in some cases, but I don't get how that 
particuular proposal can lead to it. Any ideas?

If used wrong, could it cause a performance issue?

Hmm, so good proposals are down the list ... e.g. of (I would call 
it any-of), do, reverse. Brian - what you think we get for the parse 
update for 3.0? Carl mentioned, that some proposals would require 
some big changes to underlying parse function. I was surprised,e 
.g. 'of being one of them ....

Henrik - in Carl's proposal, imo no performance hit. It simply tells 
parse that new limit for next rule evaluation is XY chars/bytes? 
It just could make you lazy in that manner, that you will not construct 
proper rules, but e.g. knowing that your tel-number is 8 chars long, 
you just limit it, as you can be sure about it.

DO is down the list because it's scary. The number of people who 
could use it without code injection security problems is small.

I proposed adding 'limit keyword to the secure dialect too. It will 
have to come one day anyway :-)

yes, I am worried about the security too, but I know that you discussed 
it with Gabriele extensively, so I don't want to reopen the discussion 
...

REVERSE rule is really cool, but of relatively limited use compared 
to the rest. And Carl says it is *really hard*.

I worked out how to make it possible to use DO at all without it 
being a security disaster. Possible doesn't mean easy though.

How is 'limit used? I set it once, as like we set spacing in VID 
once, and then I have to reset it? Or does it apply only for one 
following argument? I can imagine using limit with multiple to/thru 
...

Brian - what is your "parse ports" proposal like? I noticed you mentioned 
it in one Chat reply, that you might know, how to parse ports in 
future?

btw - will /case refinement stay?

LIMIT would apply to the next rule, but that could be a block of 
rules.

... sorry for having many questions, I am just interested in the 
topic. Although I am lame parse user, I managed to already parse 
several cute challenges here = I will never agree, that parse is 
just only for gurus :-)

/case will likely stay, though case insensitivity in general in R3 
needs some Unicode-related tweaking.

As for PARSE of ports, it's too ambitious for this round. Wait for 
the rewrite - we're just tweaking right now.

you think rewrite will happen? It is in closed-source part of REBOL, 
no?

Even REVERSE is probably too ambitious for this round.