World: r3wp

Let's see: Grapes, hacks, router problems, private channel communications 
still up, and he already announced after a82 that he was going to 
take some time off to work on the plan for a beta release, soomething 
that involves more than just code.

And all that you are asking abouut are either actively being worked 
on (callbacks), or have already been deferred to later (user types, 
concurrency). I don't get it: What is different, that you would complain 
now?

BrianH: I know Carl, and I know what I am talking about. You'll see 
- it happened several times already in the past. The group discussing 
stuff xy, and RT rushing things into "final stage". And you are wrong 
- there was no single public reaction to either user-types or concurrency, 
and as for callbacks, we can only guess by reading between the line 
of one single Chat msg.

As for me, I am not more than occassional REBOL user in comparison 
by many, but I would really like to see official reaction to beta 
blog. There are some questions raised by many. I hope answers come 
sooner before we see beta stick on R3.

User types and concurrency were deferred, partly because there wasn't 
a consensus on how theye should be implemented - not enough information 
to decide.

As for callbacks, that is what devices were supposed to be for, but 
I expect that something similar to Maxim's proposal, cleaned up, 
will be adopted. Probably adapted to implement devices, but we'll 
have something soon I bet.

pekr, threads are VERY tricky to implement for a plethora of reasons. 
 I'd rather have a beta first with extension callbacks.


This will allow many of us to start working in parralel with Carl, 
testing stuff and possibly giving out working code to carl.  things 
like precise timers could be in an extension using callbacks .

sound support, video encoders,  DirectX, OpenGL whatever...

.net using mono  :-)

Grapes harvested, winemaking begins again. Cabernet and Merlot fermentation 
started. It marks the years... and stores them in the bottle.
Carl means  it's time to harvest in beta3 ?

No, it means all development stops while he tends his grapes and 
wine making activities.

wujian: Carl has a vineyard on his ranch, in case you didn't know.

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