World: r3wp

I see.   perhaps RT and Carl himself need  more  money  to support 
the development.. or Carl enjoy   this matter.  So I feel  a little 
 disappointment ,OTOH keep understanding.

It's his hobby ...

.... the vineyard or Rebol ?

I don't think money is an issue either. The harvest is a yearly event 
and he'll be back in a couple of weeks.

both  ;-)

:-)

If you call your hobby your work, you never work a day in your life. 
:-)

it usually takes about 2 weeks of full time and then its part time... 
but Carl really likes meddling on Rebol stuff... so I'm sure he's 
thinking about many R3 issues while he's doing the wine...  


meaning, when he goes back to the code... a lot of stuff will be 
resolved and just need implementing...


many new questions will most probably surface based on all of that 
meditation.

Carl has a multicore brain like quite a few of us here.  He doesn't 
have to be in fron of the screen to be programming....  the typing 
is the most trivial aspect of programming !  ;-)

WuJian, I love that you thought that was something like a metaphor.



No, he really has a vineyard on his sprawling estate overlooking 
the city below him...  he does this as his pleasure, and way to stay 
sane.

As long as those pesky fires stay away.

Indeed, I just lost about 50K hectacres only 10km from my LA Ranch. 
 It was pretty bad.

Wow, that's a lot of property to burn. Sorry to hear that. It would 
be an enormous job just to redo the fences. Hope you didn't lose 
any good buildings or trees.

(Actually, I do hope that trees were there, because they would have 
been doing a good job - at least before the fire came.)

(off topic sorry - move to ~Chat).

We lost ALL the trees....there were no fences...


Of note....................Carl "tends" to be 10x more productive 
after a break.... all and all, always assume this is a good thing 
that he tends the vines...

Maxim; Forther brain.  One word at a time.  Write a word, test a 
word.  Write second word, test both.  Write third, test three. Write 
fourth.  Too confused now.  Give up and start over.  :)


The REBOL console is so close to allowing this type of tighly wound 
interative development that I have to whinge and whine for the good 
old days of the polyFORTH block editor every few months.  But, typing 
and evaluation are not the same head space (yet).   Chuck needs to 
sit down with Carl someday, so they can arm wrestle on a few issues.

tighly wound = tightly wound

Ashley;  RebDOC feature request.  How hard would it be to add a Keywords 
tab to this uber handy app?  (Second part of the request being a 
please please if it won't take too much of your time)

oops

Carl calls for prioritising parse enhancements, I posted wiki parse 
REP link for him. BrianH - time to step in? :-)

http://www.rebol.net/wiki/Parse_Project

Pekr good idea that  documentation

Putting in some priorities now...

Maybe you can ping Carl on Chat on that, because otherwise he might 
get scared to read the doc :-) Curious about what you choose for 
the priority ...

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 ?