World: r3wp

I am a parse beginner. I always proposed to/thru [a | b], but then 
I took Gabriele's suggestion to my mind and started to construct 
parse rules different way. What caused biggest problem for me as 
for beginner, was nested/recursive calls, and not separated local 
contexts ....

Priorities section updated - take a look.

btw, this parse doc is FABULOUS  :-)

Peta did a great job on the theoretical stuff, though the discussions 
got a little heated at times. Once thee proposals phase is done we 
should raid these for the official DocBase PARSE in-depth docs.

yes, definitively.  and use the same style for in-depth tutorials 
too  :-)

R2's parse was killer, R3 parse will be, em, killerier (parse that!). 
 It's a shame we can't retrofit this into an R2 build to allow for 
testing while only modifying parse syntax...

killerier ... mass murder?   ;-)

Some of the new rules could be backported to R2 with a rule compiler, 
that translates from the R3 rules to R2 workarounds.

I believe Gabriele already did something similar.

here goes parse on steroids!!!  

http://www.rebol.net/r3blogs/0243.html

Anyone remember a long time ago, when I talked about counters? That 
would be a kind of a tuple that you can count with. I still think 
there is something pretty fundamental missing in regards to creating 
and using counters.

I was just looking at the makedoc source, and when you count up section 
numbers, Carl spends about 15 lines of code doing that. You have 
to manually build the mechanics for counting section numbers. Now, 
this wasn't like the counter I was originally suggesting, because 
it was based on providing elaborate specs for the counter. Having 
to do that, might be why the proposition didn't live, as it's too 
complex to do natively.


But, still, what if you could count section numbers in a single line 
of code?

He is my advanced and totally robust tuple incrementor.


you can set base for tuple fields and can even increment larger than 
the base safely.

it auto-detects the size of the tuple for you, or you can set the 
increment precision, if you need.


;-----------------
;-    tuple++()
;-----------------
tuple++: func [

 {Increments tuple fields from their Least Significant Field, carrying 
 over when any Field hits base.

Note that you can use tuples as BIGNUMs if you want, using this function 
to add them together.

in Base 256, this means you can store a number up to 1.2E+24 safely.}
	value [tuple!]

 /at precision [integer!] "LSF (Least significant field) the increment 
 occurs on."
	/step amount "Add this amount to LSF at each increment"

 /base n "Each field carries over when this value is met.  Overflow 
 error raised, if MSF field tries to go beyond base(range 1-255, default 
 255) "
	/local carry
][
	precision: any [precision length? value]

 if none? value/(precision) [value: value + make tuple! head insert/dup 
 copy [] 0 precision]
	
	carry: 0
	n: any [
		max 2 min 256 any [n 256]
	]
	amount: any [amount 1]
	
	until [
		if carry >= n [
			amount: 0
			; we looped due to carry-over
			value/(precision): to-integer (remainder carry n) 
			carry: to-integer (carry / n)
			precision: precision - 1
			if precision = 0 [
				to-error "tupple increment overflow"
			]
		]
		
		value/(precision): value/(precision) + carry + amount
		carry: value/(precision); + amount
		any [
			carry < n
		]
	]
	value
]

ex: 

>> addr: 0.0.0.5
== 0.0.0.5

>> loop 10 [ probe addr: tuple++/base/step addr 10 12  ]
0.0.1.7
0.0.2.9
0.0.4.1
0.0.5.3
0.0.6.5
0.0.7.7
0.0.8.9
0.1.0.1
0.1.1.3
0.1.2.5

Hmm... what the purpose Max ?

changing color on a background ..... i go to check if it possible 
to use it to create psychedelic effects

Tuples,experimentally, have been given a Spinal Tap makeover in R3, 
so Max's code gives us a bignum up to 2.9e26
http://www.curecode.org/rebol3/ticket.rsp?id=1110

xavier - as for psychedelic effect, aren't some mushrooms better? 
:-)

steve, if you want to manage versions in an application, you want 
to increment versions, but there is no way to so in rebol... this 
allows you to increment a tuple so that version after v0.0.9 automatically 
becomes v0.1.0.

if you want to cycle through IP addreses, etc.

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.