AltME groups: search

they could not have taken vista and fixed it.  there was nothing 
good to salvage ... expect for aero, which is simply the api running 
over directx.

(and about time too)

directX and a lot of the core windows stuff is VERY well designed... 
its just how its used by the desktop and all the crap they add which 
mucks it up.

OK, back to R3 and a bit to Advocacy ... I am a bit disappointed 
by Carl's aproach so far. Maybe I am mistaken and harvesting the 
grapes is the culprit, but I can see our latest requests being ingored 
so far - callbacks, user-types proposal, and probably more - no single 
comment yet ...

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.

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

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 .

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.

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.

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.

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.

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.

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.

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 ....

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

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
]

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 ?

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.

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?

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

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

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

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 
...

That and NOT, needed for Unicode at first.

In other words (heh), USE gives us total and explicit control over 
that, which is good. I hate that in R2 parse.

Dunno if related, but I did recursive parsing with backtracking, 
and I needed to store stuff at each nesting, and it took me some 
time to find out, how to isolate the stuff. If I can have control 
upon what is local for my purposes, then it is very welcomed feature 
...

I really wish OF  was implemented for 3.0


this single rule makes SOOOOO  MAAANNNNYYYY   parse rules simpler 
for beginners.  even if its slow, its like the entry-point to parse... 
If you can make make it work with this, at least you get people into 
the band wagon, and then they will get better at it.

are the TO and THRU with multiple values on the table for 3.0  ?

R3 console is substandard, at least under Window. Dunno what you 
mean, but I have some problems when I start it - sometimes there 
is busy indicator long time even after console is launched, sometimes 
it starts and does not get its focus ....

... getting better and better, heh? :-)

its definitely going to make it easier for people to learn it and 
for advanced users to debug complex rules  :-)

When I read the initial EITHER proposal, I gave it a maybe. It didn't 
act like the EITHER function, and that would be confusing.

sorry... we clamour about parse not being RE and here we are making 
it possibly even more obscure... with implied branches... by using 
a "+" no less.... sorry.

And they're not implied branches - it's an explicit statement. If 
you don't like the name + that's fine, it's the changed semantics 
I like.

& would be infix, a replacement for STAY (originally called AND, 
then AT).

STAY was a bad choice. AND was better - the only reason I picked 
AT is because I thought infix was impossible.

but what's the point of AND   everything is already AND by default. 
just put them in a block, so they are and.  when you read & it doesn' 
appear that the parser isn't moving forward.

EITHER doesn't work like EITHER, and it needs to be prefix, and use 
the semantics of Carl's + proposal or it won't work. Suggest a name 
to be used instead.

And I can tell you - if I - the occassional parse user can't easily 
decode the meaning by just looking into the examples, there will 
be many such users ...

... and - I don't buy arguments like - it is a GTDPL concept. Our 
(parse) users will not care about such statements. We are not here 
to adhere to any academic theories, but to make things usefull. If 
we wanted to adhere to what the world uses in parsing area, we should 
go the regular expressions route ...

Do you get that the concept needs a name, and that obscure concepts 
also need names? The standard syntax for this concept won't work 
in REBOL, and the only other comparable parser is the one in Perl 
6, and we can't use that syntax either, or its semantics either (it's 
compiled). This *is* guru stuff - people get PHDs about parsing. 
Carl's proposal for +'s semantics is the way that this has to work 
given how REBOL parsing is implemented.

I don't mind the possibilities, I do care of naming and how long 
does it take for me to interpret it. If we go + route, we can change 
NOT to !, add &, II, >, -->, etc. :-)

Pekr, no, Carl was thinking of changing AND to STAY, but decided 
against it when he figured out how to make it infix.

Maxim, "everything is already AND by default" is not true. Everything 
is "and then" by default, which is AND with moving forward. What 
we need is AND without moving forward. An infix & handles that nicely, 
and is the opposite of the infix | meaning OR.

Ladislav just cheared to how Carl is precious about naming, and he 
liked STAY and QUOTE. STAY imediatelly expresses its meaning. Changing 
to to AND makes the situation only worse ....

not in my experience... really it says it should and it works.. . 
until something screws it up... its happened to me COUNTLESS times... 
I've always had to put my rules in blocks to make sure they don't 
get fucked up by "|"

but you see its not an addition.  its "go-over-this-and-accumulate-failure-or-not"

we went too far. We should accept Steeves proposal - allow EITHER 
to be embraced as using condition OR the rule. Single as that. You 
can't beat the EITHER name. Thinking here and there, I can't imagine 
how + could be named, with the used syntax ...

Alright, explain the arithmetical - without usoing the word "subtraction". 
I had switched subjects. Oh, and don't use "hyphen" either.

Symbols mean different things depending on context, and the context 
here is parsing, not arithmetic. We still need to use them.

Max already said it - here's the name :-) "go-over-this-and-accumulate-failure-or-not"

I don't need to explain Carl's + semantics because Carl was quite 
explicit in his own explanation. It made sense if you know parse 
theory, and you won't use it if you don't know parse theory. Maxim's 
term was inaccurate, though he's getting better.

Max - we have to stay with + or some other symbol. If you look at 
examples, there is stuff like [a 2 + b | c | d | e] and I don't think 
any name will fit all usage scenarios.

Only some words can be infix, depending on the semantics of the operation. 
& and | (whatever they are eventually called) can be infix. The rest 
have to be prefix.

I'm sorry, but the |  will just end up being


 [   complex rule with its own  "|" symbols ] | [   complex rule with 
 its own  "|" symbols] | [  complex rule with its own  "|" symbols 
  ]  so really the use of "|" jusy adds clutter and ambuiguity.

When you don't have a descriptive term that covers an idea, you use 
a symbol and tell someone to learn it.

PARSE already has a lot of | symbols, and the operation currently 
proposed to be named | actually ties intto the current semantics 
of those | operations.

| is visually good ... it is like wall dividing slots ... it fits 
... the + is more complex. Guru stuff, which we will have difficulcy 
to explain. Maybe it can't be done the other way. So - user has to 
learn what does it do by examples, get used to it, and then maybe, 
he will understand it, once he sees it in the code. The only question 
is, if eventually naming it, or changing the syntax to achieve the 
same, could be done more elegantly, which I start to doubt.

... you are just using those excuses. Simply put - if you want STAY 
instead of AND or &, then we will throw it back to you, accusing 
you of the need to change already used | symbol by giving it a name 
:-)

Proposed. Originally, Peta renamed & to AND since he (she?) thought 
that a spelled-out word was required by the dialect. Then I changed 
AND to AT since I didn't know infix operations were possible. Then 
Carl changed AT to STAY, since he didn't see the point. Then he realized 
what the operation meant and changed it back to &, what it should 
have been in the first place since it is the opposite of |.

I was always thinking about parse being an alien in the parsing world. 
It was just Peta who introduced us to the TDPL, PEG and other terms, 
trying to fit it to various theories. My opinion is - if such changes 
will not lead to eventual direct usage of already existing parse 
rules somewhere out there, then I don't really care about all those 
theories. We are already unique, and I don't want parse to go back 
adhering to some "standards". It feels the same, like changing feel, 
face, facet and all the naming to fit more general naming convention 
of the outer programming world ...

TDPL wasn't used, and PEG was created to describe parsers like PARSE, 
and 5 years later than PARSE was.

And the reason we are adopting operations from PEG, TDPL and GTDPL 
is because they fit into PARSE's semantics and are useful.

although for "&" I agree, it really is just a single letter symbol 
which means AND, which in this case is right.

Perl 6 has already surpassed PARSE in its own category: their "regex" 
engine is a PEG parser, and has useful stuff we're adding now.

PARSE added OPT and BREAK more recently than 10 years ago, and bugs 
were fixed, but otherwise unchanged.

brian:   post fix ? is  actually not bad... and since condition rule 
is traversed anyways (either its true or false) .... it probably 
doable...

attempts to match a rule, AND runs first rule if it matched OR second 
rule if it did not.

Max - you are NOT in REBOL level, so free yourself from pedantic 
"EITHER uses this syntax" equivalence, or dismiss COPY keyword too 
- it absolutly does not fit REBOL and even today on blog I had to 
fix Ingo's type, where he ommited to provide parse COPY with word 
to copy to ;-)

Today I posted more philosophical topic, and Carl noticed it - we 
ares shooting ourselves in the foot. Here's what I posted:
-------------------

There will always be problem with dialects, if they contain the same 
keyword names as REBOL functions. So we have to somehow live with 
that.


So the question is, where to introduce new name and why, just to 
be different, and where to not. E.g. parse 'copy keyword has already 
different semantics to REBOL's one, or VID's 'at has different semantics 
to REBOL's one. Now can users be confused? It depends.


I try to think about each dialect in the context of the dialect itself 
- so the only measure for me actually is, when reading the source 
code (or trying to understand one's), how quickly I am able to understand, 
what is going on?


But then we could as well replace 'stay by 'save-position, 'of by 
'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning 
to what the keywords are really doing. But we are somehow mysteriosly 
looking for one-word-only-mantra naming convention, and I suppose 
it is already our style, and we will not change it :-)


... so, the topic is a little bit more abstract - it is about contexts, 
and user/programmer switching between contexts, and his/her ease 
of understanding of the code.


In above case, all 'if, 'check, 'either are OK, even if their semantics 
is a bit different to their REBOL counterparts.

your rant towards EITHER not fitting anything breaks the initial 
purpse dialecting was brought to REBOL! And the meaning is - the 
same word, might mean different things in various contexts. We don't 
care for VID to use potentially the same keywords to REBOL functions, 
let we do care somehow mysteriously about PARSE to NOT use the same 
keyword naming as REBOL functions. Let's judge EITHER by its name, 
not by its REBOL level meaning.

not with carl's last  example and syntax, but using blocks it would... 
without any lost in capabilities.

It definitely is not an easy decision. I would proceed as following 
- take Carl's examples, and try to express/describe them in human 
words - simply how you would write a manual for them. The look at 
what you wrote once again, and if you find there is plenty of "either" 
words, then use it :-)

Not in R3, they work fine. And any bugs will be fixed.

and now with carl's example this will be even more so.

i started the port of areatc to rebol 3 ... so far i hate the way 
to stilize gobs all those words to put every where yeeeeeeeeeeeeerk 
... my gob does already more than 10  lines and do nothing on screen 
!!!

i ned some help what is the equivalent of init in R3/VID ? and is 
there a draw: embeded to a gob how can i say my custom face inherits 
from box style ?

The R3 equivalent of VID isn't done yet, and some revisions are planned.

hm ? i'm using VID the demo one and i'm not in a good mood !!! What 
the fuck is that shit is that the improvements i heard about during 
month and month ? 


So to be simple and keep my cool i will not port area-tc or viva-rebol 
to R3 until it's finished

load-gui 



; area-tc stylized gob -custom widget-

areatc-obj: context [


	stylize [
	
		 area-tc: box [
		
			about: "Area displaying in color keywords in text"
			
			facets: [
				size: 400x400
				max-size: 2000x2000
			]
			options: [
				size: [pair!]
			]
			faced: [ 
			]
		; internal face funcition:
		
		; empty draw block ...
			draw: [ fill-pen red text 20x20 [  "test" ] ]
			
		; events handler
			actors: [
		
			]	
		 ] ; fin area-tc style
	] ; end stylize
]; end areatc-obj
view [
    area-tc
]


 to draw in the end a black text over a background default colored 
 with a shape and color i didn't choosed that's not not not cool at 
 all  too much code for a useless thing and a wrong result.

Carl has some new ideas that will help fix the resize model, and 
we will be working on those when work on the GUI resumes.

yeah around 2012  and meanwhile I wait ... pfff ok since carl is 
actually working on parse to make it more friendly to idiots like 
me I will say i will wait.

I'm frustrated max ... i saw carl working on parse i wanted to take 
that opportinuty to start adapting area-tc to r3  and VID just is 
unfinished not even exploitable to do a starting of a begining of 
a test work ....  i though text instruction as been reformed last 
time carl working on GUI  and that we could use thing like text pos 
[ color1 "string1" color2 "string2" color3 '"string3" etc ...]

hum apparently the sting arguments in text draw is able to "rejoin" 
strings given in a block and you can't give strings to text instruction 
without embeding them to a black

It took a while to even propagate the Unicode and moduule changes 
across the core, let alone the GUI.

we where not talking about VID... just the gob... and did tell you 
that unicode was not yet part of the GUI  :-)

Yead, VID is supposed to make gobs easier to use. Working with gobs 
directly will be verbose and tricky.

yeah but what is the relation betwin the unicode and the fact that 
text instruction draws a text in black when i request it to be red 
?

Howerver when you don't know what you can put and what you can skip 
you end with a ugly code full of useless things

and the path to acces them is lighter too ...

The overall design is good, but it needs some changes and debugging 
:(

I mean the design of the gob system and infrastructure, not the dialect.