World: r3wp

hehe... well in the last  blog, carl says he is  actually working 
on the face side of things  :-)

it wasn't me .. it was Volker!

one other month since last R3 blog update. Any news here?

I would like to know more about these optimized graphics objects 
or whatthey'recalled.

interesting part is, that imo if Carl and Cyphre work on new View, 
then hopefully Core R3 is ready to some extent?

otherwise I would not understand it. Because I would prefer Core 
alpha release, allow ppl to study new plug-in architecture, trying 
to wrap few libraries etc.

but who knows - Carl promissed to post "bigger picture" diagram of 
R3, but maybe he forgot ....

I wonder, if tasking model, timers, event system, are already decided 
...

Uhm, as I posted in Linux group, many systems are targetting its 
future towards vectore usage. Co-author of KDE 4 blogged about how 
fast Qt 4 based vector pipeline is, and it seems other engines can't 
stand the competition. Of course he generated some noise, as Cairo 
fanboys did not like it :-) http://zrusin.blogspot.com/So I looked 
at http://www.antigrain.com, to see what is new with AGG. It seems 
to me, that it is not good for RT - they are changing licence for 
any new version to GPL

Also if I understand correctly, Maxim has now full time job, non 
AGG related. I wonder what the future of AGG is for us, and if we 
should not look into something else ....

petr, Carl did not forget. :)

Core is not ready, but this doesn't mean we can't start on View.

Pekr: The 'old' licence for AGG 2.3 and 2.4 remains. GPL is for 2.5 
which is at the moment at the same leve as 2.4(regarding functionality). 
So far noone from the AGG comunity(or at least at the ML) don't know 
why Maxim decided to change the licence.(everyone is waiting for 
his reply)

Maxim also wrote "Current AGG users who are willing to continue using 
AGG under the old terms and conditions are encouraged to contact 
me and I will consider their requests." so nothing is lost if we 
would like to use 2.5.

Anyway, even the AGG2.3 framework is very stable and have 99% of 
the features same like 2.4 and up. The whole code quality is very 
good so it is possible to enhance it...so this shouldn't be a big 
problem for Rebol.

Another thing is that in the 'worst case' current AGG users/developers 
who don't want or cannot use the GPL version are planning to continue 
with improving the 2.4 codebase separately.

cyphre, very simple question: does it support smooth downscaling 
of bitmaps? Is is something that can be turned on?

Sure, ieven AGG2.3 (which Rebol is using) supports high quality downscaling 
of images(among other types of image filters). As I know lot of Rebolers 
would like to generate quality thumbnails ;) I'll try to talk with 
Carl about including this in future versions of Rebol.

That would shave off a lot of development time for an app, I'm developing. 
Just this one feature. Thanks.

I'd just like to be able to select transform filters on the fly.

Gabriele - so if Carl did not forget, then the whole picture of architecture 
is not clear yet, or is it? :-)

Pekr: AFAIK Carl is also working on some diagrams so you will see 
the design soon.

ok, good to know, thanks. I think that many ppl here are waiting 
for R3 already. I believe some would prefer incomplete alpha (complete 
to some degree), to already start testing for bugs, testing interfaces, 
ports, etc.

Maxim: yes, this is already in current DRAW but only two filters 
are supported. (NN and bilinear)

pekr: I'm sure Carl release the testing version ASAP (ie. when he 
decide it make sense to test it externally)

your answer implies it is under testing "internally", right? :-)

I'm always wondering why people depend on the next release to start 
their app... take what you have and do it. There is always a way. 
It's like with a team. You got the people you have and good management 
is, to get to the goal with your team you have. Winning with a dreamteam 
is no art.

Robert, I don't any of us is waiting on R3... we are just waiting 
on it, to test it, as Pekr says.   There are things we cannot fix 
for RT, like view performance, draw crashes, etc.

I'm always wondering why people depend on the next release to start 
their app... take what you have and do it.
 <--- Precisely!

Some planned things have to wait for features to be implemented. 
But there is so much other stuff that can be done while waiting there 
is no reason to be idle.

I mentioned "waiting" in another sense though - it was wrong word 
choosed on my side probably, I just meant "awaiting", not "waiting 
for", sorry. And my argument was, that in MY opinion, devs would 
welcome more often, incomplete early alpha releases, than inhouse 
only testing of R3, late release. I very much liked days of Rebcode 
development - I found it very vital cooperation, and it clearly showed, 
that some community folks had very good influence on RebCode architecture 
itself ...

rebol [
	purpose: "Demonstrate how to use the findany function."
	note:  {This is a function I would like included in Rebol3.
		One of you experts (I don't remember who) made this function 

                for me, and I use it all the time. Do you see any ways it can
		be improved before I submit it? --- Louis
	}
]

s: "findany will return true if it finds in this sentence any of 
the strings you enter in the request box."
print [s newline]

forever [

 bs: copy parse (request-text/title "Enter the strings you want to 
 find separated by a space.") none

	findany: func [ 
	     "Searches string x for any substring found in block ys."
	     x [string!] "string"
	     ys [block!] "block of substrings"
	    /local pos
	] [
	    foreach y ys [
	         if pos: find x y [return pos]
	     ]
	]

either findany s bs [print true][print false]

]
halt

rebol [
	purpose: "Demonstrate how to use the findall function."
	note:  {This is a function I would like included in Rebol3.
		This is my function. Do you see any ways it can
		be improved before I submit it? --- Louis}
]

s: "findall will return true only if it finds in this sentence all 
the strings you enter in the request box."
print [s newline]

forever [

 bs: copy parse (request-text/title "Enter the strings you want to 
 find separated by a space.") none

	findall: func [
		"Seaches string s for all substrings find in block bs."
		s [string!] "string to search in"
		bs [block!] "block of strings to search for"
	][
		findit: func [
			s [string!] "string to search in"
		        b [string!] "string to search for" 
		][
			if find s b [either find s b [true][false]]
		]
		foreach b bs [either findit s b [true][break/return false]]
	]

either findall s bs [print true][print false]

]
halt

Functions like these are very useful to have. I could have used them 
recently while doing file searching.
However, I wouldn't like to see these functions included as is.

- Not very efficient. That's ok  for searching small strings or the 
contents of short files, but bad when searching large files for many 
strings. 

- Not generic. The name suggests many datatypes are supported. Better 
names might be find-any-string, find-all-strings
- The above FINDALL does not keep FINDIT as a local.

- The argument names are too short, so they are not distinct or descriptive 
enough.

- The return values are not defined clearly in the function doc strings. 
The above issues are fixable, but it will take some time.

(Actually, the efficiency issue will take the most time to resolve.)

(... but, most important is defining the user interface and functionality 
clearly, as well as eliminating undesireable side-effects.)

Who can make these functions the most efficient, and display them 
in a benchmark program to prove it? And correct all the other problems 
mentioned by Anton.

Yes.... "who ?".... :-)

The above find-any suffers from this problem, which needs at least 
to be documented in the function description.
	>> pos: findany "hello cat dog license" ["dog" "cat"]
	== "dog license"

("cat" appears before "dog" in the input string, but because "dog" 
was searched first, it was returned first.)

this is the same limitation as in parse which is not optimal, IMHO.

the 'ANY in the name implies any of the options are equivalent, so 
its the first in the input which is the desired return value, as 
anton points out.

Louis, the way I benchmark in REBOL is to do a trace count.  In other 
words if the execution of the trace generates more output than another 
method then I assume that method is less efficient.

Stayed up all night, and succeeded in making a parse rule generator, 
so if we want to search a string for any substrings:

string: {Hello there Anton. Arrow in the box. What nice antlers you 
have.}
substrings: ["ant" "antler" "anton" "arrow" "bar" "box"]

rule: [start: [["a" [["nt" action ["ler" action | "on" action]] | 
"rrow" action]] | ["b" ["ar" action | "ox" action]]] | skip]
Found at: 13 Substring: "Ant"
Found at: 13 Substring: "Anton"
Found at: 20 Substring: "Arrow"
Found at: 33 Substring: "box"
Found at: 48 Substring: "ant"
Found at: 48 Substring: "antler"
true

So you can see the rule is built from the substrings.

Thus we are able to search large files for any number of substrings 
in a single pass parse. :)

(very happy about this..) I'll clean it up and publish it probably 
later tonight.

Nice job. Anton.

Thankyou, Jerry. I wonder if anyone else made a parse generator like 
that ?

Maxim and Anton, what difference does it make which value is returned? 
It is the true or false that I am looking for. If any of the strings 
are found, why look any farther? I'm sure you guys have a reason, 
but I want to know what it is.

is returned = is returned first

If you keep looking after already having an answer, how can that 
be more efficient?

Well, that functionality works perfectly for your case, but there 
are many other cases where the position of the match(es) is also 
wanted.

.. and a name like FINDALL suggests that it returns those matches.