World: r3wp

I wonder if it has something to do with templates. Can't still see 
what exactly it does.

Same a finding a charset, except it's a set of longer values than 
single characters. Position of the first in the set found returned.

Basically the same as PARSE TO multiple (and might use the same code).

oh, so this would be possible:

find/first string ["steeve" "brian"]
== "steeve came first, brian came second"

Yup. And like TO multiple, the alternative is exponential time and 
tricky to program.

find/first/all would be cool :-)

FIND/first/all would be FIND/all.

I guess it would be. Considering that, what about find/into?

Use PARSE.

or maybe it's just as fast to:

append str copy find str2 "something"

I was thinking about the /into for appending the result to a different 
series.

I think that FIND/all would just return true/false, not a block full 
of positions.

I would hate that.

If so, I understand Steeve's suggestion for using parse instead.

I may misunderstand the proposal.

I think he means both. He just talks about TRUE/FALSE for bitsets:


One possible justification would be if FIND/all is useful for other 
series. For example, a FIND/all on a block might return a block of 
results.

FIND/all would definitely return true/false if searching bitsets.

find/first string ["steeve" "brian"] ??? I expected more of find/first 
[str1 str2 str3] value

I thought that it would serve to do lookup on multiple different 
targets ("series" switching) ....

>> find/first "foobarbaz" ["baz" "bar"]
== "barbaz"
Order doesn't matter in the values yo are searching for.

That could perhaps be useful. Generally there has been some level 
of index concurrency control with multiple series missing in R2, 
like being able to do a FORALL on multiple series simultaneously. 
I can't remember if R3 solves any of that, because it's been discussed 
quite a long time ago.

This is difficlt to do efficiently.

I know. I just want less plumbing :-)

FIND/all and FIND/first could save tons of time - exponential time.

So let's be sure to push on Carl in that regard, to get those two 
implemented. I am not sure Carl will implement stuff by the project 
plan.

so, FORALL is native in R3. that might make it harder to change. 
Otherwise I would suggest, since it uses a word for input series 
to use a block for multiple series:


forall [series1 series2 series3] [print [index? series1 index? series2 
index? series3]]
1 1 1
2 2 2
3 3 3
...

The cases where you have to work on many series of all the same length 
are rare.

I run into this curiously often, which is why I suggested it. It's 
useful where you need to get a block of  blocks "turned 90 degrees".

The DB people call that column storage :)

Yes, and you often have to switch between row & column pocessing.

A91 released with some UTF-16 support

A92 you mean :-)

I'm tired :-) Went too late to bed.

Went to bed too late :)

That's part of the Rebol life ...

Reading the bitsets document, says:


Create a bitset large enough to holds bits up to 1000 and set bit 
1000:

	bits: make bitset! 1000  ; note that bit 1000 is set

But in A92:

>> make bitset! 1000
== make bitset! #{
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000
}

Is this right?

added as bug#1290

Another shot at reworking my XML loader for R3: http://bit.ly/xml_rebol
- works mostly, try:

	rss: load-xml/dom http://www.rebol.com/article/carl-rss.xml
	entries: rss/get-by-tag <item>
	foreach entry entries [probe entry/get <title>]

However trips at the first line of the first example:

	html: load-xml/dom http://w3.org

as follows:

	>> do http://www.ross-gill.com/r/r3xml.r
	Script: "XML for REBOL 3" Version: 0.2.0 Date: 22-Oct-2009
	>> html: load-xml/dom http://w3.org

 ** Access error: protocol error: "Redirect to other host - requires 
 custom handling"


	>> html: load-xml/dom http://www.w3.org
	Segmentation fault

On 2.100.90.2.5

Appears to be OK on 2.100.92.3.1

Boiled it down to: parse "^(A000)" [remove #" "]

Added an idea on the bitset complement dilema, worth considering 
IMHO.

its a logical extension of the new bitset notation

Is 'load/next supposed to return binary as the second part of the 
result?

Max - what you are proposing - could it serve to support collation 
mechanism? Because what we still lack is to support specific collation 
sorting - unless it is implemented, I refuse to claim, that R3 supports 
Unicode ...

ah... well, I was just proposing a way to prevent bitsets scaling 
to2^16 bits when you join them in specific ways.

created ticket #1292, addresses a few problems date!  handling of 
time.

if you look at the ticket, what I asked for really is usefull and 
shouldn't be very hard for Carl to address.

Those should probably be split in 3 reports.

I'll let you do that, since you wrote the original report. :-)

ok then....

actually... doing more tests.... I realize that the time is added 
to the date directly, not counting current time... which is actually 
proper, since I'm doing a set... not an addition.