World: r3wp

ok, thanks. Hopefully Carl notices it ....

I really hope we go through the CureCode tickets soon and collect 
all of the ones that make minor changes to core semantics, so we 
can do a rip-the-bandaid-off fix-them-all release soon. Before too 
much code is written that might depend on the unfixed behavior.

Not a98 though - we don't want to delay the new extension model.

it depends on Carl. I hope we get to more frequent R3 releases again. 
And - A98 will contain only partial Extension model implementation 
...

Yes, but enough to get the code into the hands of testers that can 
work out the kinks.

re:Python's operators. I've always liked AutoIT's assignment operators, 
some of which (especially concatenantion) would be quite useful in 
REBOL.

	=	Assignment. e.g. $var = 5ÊÊÊÊ (assigns the number 5 to $var)
	+=	Addition assignment. e.g. $var += 1 ÊÊÊ (adds 1 to $var)
	-=	Subtraction assignment.
	*=	Multiplication assignment.
	/=	Division assignment.

 &=	Concatenation assignment.Ê e.g. $var = "one", and then $var &= 
 10ÊÊÊ ($var now equals "one10")

Except for the concatenation, these are C language operators.

These make sense in C or Python syntax, or other languages where 
assignment is a syntax thing, but I'm not sure that it works that 
well with a language with word values, and assignment that doesn't 
use =. I don't see how they'd fit in REBOL syntax. That is not to 
say that the functions that these operators represent wouldn't be 
useful to have - just that they would fit in better in prefix form. 
Just an opinion though.

We have &= already though, it's called APPEND.

As long as the first argument is a series ...

All of the operators above are modifying, and the only things you 
can concatenate to in R3 are supported by APPEND. So yeah.

Series, or map or object.

is there a function which looks like find but return true here:

Type desktop to start the Viewtop.
>> a: ["111" "222" "111"]
== ["111" "222" "111"]
>> b: a/3
== "111"
>> same? find a b b
== false

otherwise this HAS to be added to R3

something like FIND/EXACT

or even better  FIND/SAME

it would also be a hell of a lot faster  :-D

no native of this kind is available yet AFAIK

or index? being extended, to return you a pointer to the originating 
series? But such information might not be available to interpreter 
after the assignment?

(but I wrote a corresponding function to the Identity articticle)

its a shame cause looping a large list manually and comparing with 
same?  is VERY slow  :-(

on a 10 million sized series. 


my fastest FIND-SAME loop is 20 time slower than FIND, which would 
be much faster, since all it would have to do is compare a pointer.

did you time it vs find?  maybe its faster than mine?

No way, I did not optimize for speed

can't you wrap the items of the list inside objects ?
In that case, it will be a find/same

here's my fastest one yet... I tried two so far...

	;-----------------
	;-     find-same()
	;-----------------
	find-same: func [
		series [block!]
		item [series! object!]
		/local s i
	][
		i: 1
		repeat s series [
			i: i + 1
			if same? s item [
				break
			]
		]
		unless i > length? series [
			at series i - 1
		]
	]
	

using until was slower probably because REPEAT is faster than UNTIL 
(no exit condition or series index to increase).

steeve no... its a database like flast list of labels with corresponding 
data items.

Hey it's your choice, nothing is unchangeable :-)

its for the list style... hehe would you rather do

fill my-list/aspects/list ["Steeve" 1 "Max" 2 "Lad" 3] 

or


fill my-list/aspects/list reduce [context [label: "Steeve" data: 
1] context [label: "Max" data: 2] context [label: "Lad" data: 3]]

note the multi-column list will use the same data interface


IMHO it gets even less fun if you are using DB queries to populate 
the list.


it also generates a lot of useless & SLOW binding everytime you change 
the list

How about combining find with a loop
find-same: func [
	series [block!]
	item [series! ]
	/local s 
][
	while [s: find series item] [
		if same? first s item [return  true]
		series: next s
	]
	false
]

that's a hell of good a idea  :-)

thanks why didn't I think of that

to close to the tree to see the forest   :-/

yep much faster.   :-)


still /SAME has to be added to FIND.  the search would be almost 
instantaneous (Relatively speaking, of course) if done natively.

the same goes for /first (find first occurance in a block of multiple 
targets ... a long planned feature)

you mean as in deep searching a tree of blocks ?

should be a little bit faster

while [serie: find/tail serie item][
	all [same? serie/-1 item return  true]
]

Optimization is a never ending story

Steeve, I think your major contribution to GLASS can be in optimising 
various things.

Or port it to R3

because of liquid's lazyness, very few things are actually optimised 
(really need to)... but right now I have a problem on initialization 
where there is so much linkeage being done, it does create a nagging 
pause on startup.


I already know a few things that will greatly optimise liquid itself, 
and will implement speed minded plugs specifically for GLASS, but 
your input will be invaluable.


you've spent sooo much time on this specific aspect of REBOL coding 
that it will come naturally to you.

Well, It will a pleasure :)
Optimizing scripts is my hoby

in the last 6 months, I've allready optimized liquid's kernel by 
a factor of at least 50 times I think I can speed it up at least 
10x more.  on specific points, I can probably improve it even more. 
 that will probably come at increased memory use for some plugs though.

Propably some inspectors could be added in the flow  to do some JIT 
compilation of your plugs ;-)

for example, I am thinking of building a !node and !container base 
plugs which cannot mutate into different processing mechanisms.... 
will all the removed overhead, that will make a BIG difference.  


it will require a bit more experience in handling liquid... but within 
controled environments like glass and glob, this can be a non-issue.

yes.  it would be exceedingly easy, since you have state information 
about things being clean or not, and liquid is 100% class based OOP 
(as opposed to prototype) so once a node has been defined, it can 
be freely JIT, since every reference to the instance is referenced, 
not bound.

which is why it used at least 100 times less RAM than it (and is 
200 times faster) than would be under traditional REBOL object use.

with R3 I want to replace every part of the kernel with commands, 
but for that, we need access to the object! datatype within extensions 
(or host-kit).

AFAICT the next few extension release will allow some acces to context, 
so that might be the green light for me to go ahead and adapt my 
dataflow framework to R3.

I wouldn't say We MUST add /SAME to FIND, though it could be useful 
in special cases. Another posssibility, though I want to think about 
it more before standing behind it, would be to allow AT to take an 
index value that is a reference. Hmmm, no, maybe not. It would then 
have to return NONE if the item wasn't in the block. Nevermind.

lol