AltME groups: search

I like 'found? as-is, but it is true, that I sometimes thought, that 
it would perform 'find for me too .... found? find series value - 
simply that 'find is redundant here ....

as to found? select ... dunno if it is valid thinking - you are not 
searching the series, altough reading the expression "in english" 
might suggest it - you are performing found? on the result of select 
function call ....

I didn't think it could do time series ...so I didn't persue it.

http://hostilefork.com/2008/09/05/the-flexible-series-as-a-core-concept-of-rebol/#more-77

I saw a little of a cartoon tv series some time ago, that I can't 
remember the name of. I think, it was called "Afterlife" or something 
like that. It was mostly still pictures with very little animation, 
but lots of atmosphere. The story was kind of confusing but something 
like after a nuclear war (maybe), and we followed this guy, who was 
on a run and met some strange people maybe in the countryside in 
USA. One was kind of a hunter. Anyone knows, what I'm talking about?

Gabriele; no sorry; I guess I obfuscated my point too much with the 
money! example.  I don't want REBOL to figure out all the possible 
human combinations of money.  I want REBOL to load a value that we 
humans commonly use as a format of money, without a syntax error. 
  The make phase would create a foreign data value and keep going. 
  Let the gurus that write general applications worry about the math 
operations on junk and account for it.  But let a professor load 
his book and use the uber powerful series operations of REBOL for 
ad hoc analysis.   No AI involved here, just a feature of the language 
that "if a piece of source does not match one of the lexically strict 
57 datatypes, it floats in a REBOL block as foreign".    And foreign 
is similar but not quite exactly the same as quoting the text as 
string!, without need of quoting the text.   I see great power in 
this feature.


Excuse the poor example;   I misdirected my intention when I mentioned 
that arg1 had a good hint, my mistake (but I would if I had brains, 
include this hint as a subfield of foreign! data, just because, why 
not, the current lexical parser already made a guess).  Our good 
Mr Hawley has a plan for a LOAD refinement /else with a type spec 
that looks very promising, but then it leads to being able to distinguish 
actual quoted input from coerced input, so I still lean toward foreign.


My plan (and I place burden of foreign! management for CODE blocks 
to the gurus) would let normal people load any data and run with 
it.  Even it they only use 4 or 5 REBOL functions at the console, 
the potential userbase becomes orders of magnitude greater than what 
we have today.   That it turn opens up a few that will write concise 
clear time lasting code that could analyze books or the sum of human 
knowledge using our favourite thinking environment.  No?

Ok, fine two minutes then.   ;)   "bad data" would be a new foreign! 
datatype.  No longer "bad".  It'd be no more a code hassle than doing 
email! + url!      Take the hit then.  But you still have a "valid 
REBOL series!" to play with.  Even with a $$10,000.00\\  floating 
around in the series ... semantically equivalent to email! or file! 
 out of context for those functions that require particular datums.

The following code: 

unicode-to-ascii: func [ from to /local fs ts sz] [
    fs: open/binary/direct/read from
    ts: open/binary/direct/write to
    sz: size? from
    fs/1 fs/1 ; discard the first two bytes, FFFE
    for i 3 sz 2 [
        append ts to-char fs/1 
        fs: skip fs 1 ; SKIP is the problem
    ]
    close fs
    close ts
]
unicode-to-ascii %/c/Unicode.txt %/c/Ascii.txt

In REBOL/View 1.2.7.3.1 12-Sep-2006 Core 2.6.0
** CRASH (Should not happen) - Expand series overflow

In REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3
** Script Error: Not enough memory
** Where: do-body
** Near: fs: skip fs 1

Henrik.   

Andrew created Tally.r    It wasn't exactly what you asked but maybe 
there's some value there "Tallies up the values in a series,  producing 
a block of [Value Count] pairs"

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=tally.r

Ladislav, looks like pairs are treated differently. (not a series, 
even though they really should be ?)

right, pairs differ from series (are not mutable)

Mmmmmm "/deep - Also copies series values within the block."  I cant 
say thats a realy clear eplenation ;-) never the less it works...

unfortunately, it doesn't copy all series:
>> a: ["aa"]
== ["aa"]
>> b: copy/deep a
== ["aa"]
>> same? first a first b
== false

I understand your issues trying to sort out all of the variations. 
 remember that most series handling functions return the series at 
some point (its head, its tail, or somewhere in between).

most series handling functions modify the series "in place" instead 
of copying them.  This simplifies series manipulation by breaking 
down each step into little functions.

a common trick is to do this to unify a series as a block! which 
might also accept a string! :

val: compose [(val)]


this way, if val was originally a block, it stays that way, but if 
it was a string, its then inserted within one.  Note that the above 
actually creates a new block... so that the original val (if it was 
a block) and the new one are not the same

the simplest way I come up is:
	FORSKIP series record-size [
		APPEND result COPY/PART series
		APPEND result new-value
	]


But this copies the series. Is there a nice inplace extension solution?

parse series[any[ record-size skip p: (p: insert  p new-value) :p 
]]
but that  shifts  a lot.
would use
 insert clear series  result

and for speed there is insert/part to avoid all the small temp blocks.

I have a DELIMIT function that will do it, changing the series in 
place, with the exception of the trailing element. So the final result 
would look like this:

	append delimit/skip series new-value record-size new-value

The basic idea you want is this:

	series: skip series size 
	series: head forskip series size + 1 [insert/only series value]


My DELIMIT func also works with list! and any-string! types correctly, 
which simple code above doesn't account for (the +1 part is simplified).

Wait, I haven't shown you this yet.
	; my second version, more like Chris's version, using FORALL
	use-foreach: func [
		words [block! word!]
		data [series!] "The series to traverse"
		body [block!] "Block to evaluate each time"
	][
		use words compose/deep [
			forall data [
				set [(words)] data/1
				(body)
			]
		]
	]

; my fourth version, using WHILE
	use-foreach: func [
		words [block! word!]
		data [series!] "The series to traverse"
		body [block!] "Block to evaluate each time"
	][
		use words compose/deep [
			while [not tail? data][
				set [(words)] data/1
				(body)
				data: next data
			]
		]
	]

...because the index attribute of REBOL series is not volatile.

as I said: you cannot change the index of a series, so the only possibility 
is to share the variable

actually the error lies in the fact, that many users think, that 
SKIP changes the index of a series. It actually doesn't:

b: "1234"
index? skip b 2 ; == 3
index? b ; == 1

BACK versus past-tail indices. Every index (except for 1) may become 
past-tail during the execution of a script (when its block/string 
"shrinks") and "legal" again (when its block/string grows sufficiently). 
Let me mention the SAME? function as an example of a consistent behaviour 
- no matter whether the index is past-tail or not, the SAME? function 
takes it into account when comparing series. The BACK function, however, 
handles past-tail indices differently than the "normal" ones. any 
wishes/notes/proposals?

try this:

foreach': func [
    "Evaluates a block for each value(s) in a series."

    word [word! block!] {Word or block of words to set each time (will 
    be local)}
    data [series!] "The series to traverse"
    body [block!] "Block to evaluate each time"
] [
    foreach :word :data :body
]

yes, e.g. padding in the middle of existing series - pad-left, pad-right 
:-)

>> series? []
== true
>> trim [] 
** Script Error: Cannot use trim on block! value
** Near: trim []
>> ? trim
USAGE:
    TRIM series /head /tail /auto /lines /all /with str 
...

Is this not kind of inconsistent?

>> help trim
USAGE:
    TRIM series /head /tail /auto /lines /all /with str

DESCRIPTION:

     Removes whitespace from a string. Default removes from head and tail.
     TRIM is an action value.

ARGUMENTS:
     series -- (Type: series port)

for some reason, it seems that binding does not handle sub objects 
very well.


strangely, it seems that in a circumstance I cannot determine (and 
cannot reproduce)  when you have a series of nested objects at some 
point, even if you remake all parts of the inner objects, you still 
end up with functions which call previous bindings, thus calling 
the wrong functions!


I had to explicitely call the paths from the supplied outermost object 
back to the current object in order to reach my own local function:

ex:

within the body of a function in objc, I had to call this:

instance/ctx/other-function 


instead of only 'other-function. yet they are defined in the same 
make !

If you have a series of nested objects, how do you get the value 
of say, the nth nested object?


is there something like : get in object 'obj1/obj2/obj3/obj4/....objn/parameter

I have a deep question, when we use clear, does it clear the pre-allocated 
space (shrinking back a series) or does it only set the series termination 
to the specified index?

I believe it keeps the allocated space, so it's more efficient to 
reuse a series, rather than always starting a new one with copy.

however, random/secure on a series might produce more than 2^31 combinations 
- in principle the generator should be able to, but if it's used 
or not i don't know.

some things cannot be "undone" and such behavior unless it is switcheable 
is dangerous... I've had many problems with memory useage since Carl 
switch the object model so that it copies all series at each new 
instance... the old way was simple to copy... but now, its almost 
impossible to share data amongst peer instances. 


I know why he did it... but I think more explicit documentation where 
the feature was causing some unexpected effects for newbies would 
have been a better solution. and we still have many of the string 
sharing side effects in View anyways... so it didn't explicitely 
fix the main issue in the first place!

icarii, copy/deep copies series inside blocks, where copy only copies 
the blocks and series inside are referenced, like in the original 
block.

not copying deep is a common mistake, when series inside blocks or 
objects don't behave or suddenly change contents where they shouldn't.

tested and working fine here now :)  i generally use copy/deep with 
complex series but never stopped to wonder why..

something like the following would be useful for new people:
;given the following series
a: [a b c [d e f]]
;perform copy
b: copy a
probe b
>> [a b c [d e f]]
;b contains [a b c [{and references a/4}]]
;this can be seen by appending to a/4 and checking b again
append a/4 'g
probe b
>> [a b c [d e f g]]

;now on copy/deep an exact copy with no referencing of internal series 
is made
c: copy/deep a
append a/4 'h
probe c
>> [a b c [d e f g]]
;c does not have h but b does.
probe b
>> [a b c [d e f g h]]
append a 'i
;and neither b nor c will contain 'i as it is in the outer series
probe c
>> [a b c [d e f g]]
probe b
>> [a b c [d e f g h]]

I situations with strings (or series in general) like that, I use 
to put the function and the variable in a context and do
clear a

when it's needed. That way I reuse the mem area. Would I need the 
after function? hmm ...

clear head blk
 doesn't reset 'blk to the head of the series. If you do:

blk: head blk
clear blk

you should get what you expect.

Another thing to consider is that this is a general need, so FOREACH 
(e.g.) may be used, but you can hide it in a wrapper func, maybe 
called SELECT-ALL, that works like REMOVE-EACH. I have different 
variations, based on how other langs do it, e.g. select/inject in 
smalltalk. Here's a very quick way to leverage REVMOE-EACH.

    filter: keep-each: func [

        "Keeps only values from a series where body block returns TRUE."

        'word  [get-word! word! block!] "Word or block of words to set each 
        time (will be local)"
        series [series!] "Series to traverse"

        body   [block!]  "Block to evaluate. Return TRUE to collect."
    ] [
        remove-each :word series join [not] to paren! body
    ]
    comment {
        filter x [1 2 3] [x = 2]
        filter x [1 2 3] [odd? x]
        filter res [1 2 3] [odd? res]
        filter [x y] [a 1 b 2 c 3] [all [odd? y  'c = x]]
    }

** Script Error: difference expected set1 argument of type: series 
bitset
** Where: do-boot
** Near: difference now d

you lose bindings and it won't work on series inside the blocks inside 
the block.

ALSO;   instead of  
    tmp: first series  series: next series  tmp
   also  first series  series: next series

No tmp required,  ALSO  will return the first result of the two expressions 
 BUT in this case why?   :) 
FIRST+;   instead of the (now) useless example I just wrote;

    first+ series    ;; return value at current reference and then advance 
    reference
No tmp, no next required.  All in one expression. 


Note:  SOURCE ALSO   it's cool and will make a lot of sense when 
you see it.

;Here is a handy skip function:

skip+: func [
    {Returns a series matching the skip sequence}
    series [series!] "Series to return skip values from."
    interval [integer!] "Skip interval"
    start [integer!] "Series index to start skipping from."
    /local blk][
    blk: copy []
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series
    if empty? blk [return none]
    blk
]

It allows you to start at any index position in a series and begin 
returning values that match the skip interval.

much easier to do:

to-block skip+ a 2 3 


then to determine if a none is an actual value being returned of 
my series.

but... anyway, it's just two different principles. I prefer to do 
the error checking before doing operations in the series:

a: [1 2 3 4]
b: 7
either tail? at a b [print "whoa!"][extract a b]

Paul, the changes to EXTRACT are part of a whole series of subtle 
changes to REBOL that are based on 3 ideas:

- NONE is a value that denotes no value, like UNSET but not an error 
- sort of like SQL NULL.

- Out of range isn't necessarily an error - you can choose to treat 
it as such as you like, or not. Boundaries are really an implementation 
detail in a language with autoexpanding series. The choice to have 
fixed boundaries is left to the developer.

- There is no difference between a NONE in the middle of a series 
and a NONE off the end. It's a missing value either way.


REBOL worked this way already in many cases, so we're making it more 
consistent.

I just don't like it Brian.  Like Henrik noticed I have a problem 
with it because it returns none as a value inside of the series. 
 I rather have it report none as a none! When it is reported as it 
is currently in extract it isn't a none! datatype it is a 'none word 
value.

Sorry, I don't get something. Are you saying that EXTRACT is returning 
the word 'none rather than the value #[none], or that you are using 
the word 'none in your series for something else?

Sometime I use the value none to specify that position in the series 
doesn't currently have a value.   I'm sure many have done this.

Re "Both": You said that you treat #[none] as no value, even in the 
middle of a series, and that is what EXTRACT does, so no, that is 
not your problem.

I don't Brian.  But I might want to know if the series was out of 
range to my request.

You have to use additional code to check if your series will be out 
of range if your going to use EXTRACT.  I don't have to with SKIP+.

SKIP+ is a lot more taxing on the stats/evals, actually. There is 
more code in EXTRACT but that code is mostly error checking code 
that is run only once per call. The code that actually does the extract 
is more efficient:

    forskip block width [append/only new any [pick block pos value]]
versus
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series

Brian if the block supplied as the series argument to EXTRACT is 
allocated dynamically it could easily create an out of bounds situation.

I mean, the biggest problem I saw in SKIP+ was that start parameter. 
By using a seperate index you are just asking for out-of-bounds errors. 
Remember, series references include a position - you can just generate 
another series reference in the new position by using AT.

EXTRACT is generally used with series of lengths that are even multiples 
of the width parameter. Are you using incomplete series?

Gregg: probably you noticed it already, but when one presses the 
up or down arrow buttons while in the search field in the Word Browser 
it crashes with the following statement:


** Script Error: index? expected series argument of type: series 
port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first
>>

so it's not possible to navigate the words via the coursor keys

first question, is how can i get the first text field to accept mouse 
click events?
Use the original feel
can i update the position of the text curser in the number field

cursor is in system/view/caret. points to the text in your face, 
use series-functions to move cursor


recycling of feel: either dump and patch as shown here, or use traditional 
inheritance/super-call as shown in http://polly.rebol.it/test/test/extend-engage.r

:-)

You're dealing with objects. A face is an object. The WITH block 
assign values to the attributes within the object, or extend the 
object with new attributes. Just like:
o1: make object! [a: 0]

o2: make o1 [a: 1 b: 2]	; the attribute a gets the value 1, and a 
new attribute b is created and gets the value 2.


Some data types in REBOL are references, when used in objects, some 
are not. (Remember that data types are grouped as scalars, series, 
etc.)

Sorry, Robert. There is something I want to announce. :-)


http://hmkdesign.dk/list-test.png<--- a picture of the list view 
I'm building.


Currently about half done and quite usable at this time: It's resizable. 
Values are stored as blocks of blocks. All columns can be sorted. 
Input columns can be filtered so you can show only some columns. 
Columns can be freely reordered (but not in the GUI yet). One arbitrary 
column can be resized.

It has the normal range of series manipulation functions available 
in REBOL. There is also possibility for inline editing, by doubleclicking 
a line. Changed values are automatically stored in the list. All 
such operations are "bundled" in the list view VID code and you only 
need to provide whatever functions needed to store the list data 
in an external place. If a text entry is too wide, it'll be neatly 
cut with ellipsis (...).

Filtering function, to filter input by rows. Also has a scroll-to-selected-line 
function.

It's about as fast as the current LIST in VID, since it really is 
LIST with just a whole bunch of extra functions to make general list 
views easy. There are functions possible for clicking and double 
clicking and functions for retrieving rows and columns.


Current limitations: No mouse over indication (can't make it fast 
enough). Only one resizable column. No keyboard navigation. No horizontal 
scrolling. No scroll-wheel support. It doesn't integrate 100% with 
VID yet. I'm using some of my own widgets and bitmap graphics from 
a pretty big GUI library. Stripe look, font and coloring is locked. 
No standard settings yet for the list view.

All code is about 250 lines.


Planning: Reordering columns via drag'n'drop. Column resizing, if 
I can figure it out. Format the font object conditionally from list 
input (make this line bold if the age column is > 45 years, etc.). 
Grid drawing. Images in list rows. And if I can get around to it: 
Single cell in-line editing ala spreadsheets. :-)

Oldes reports this error in my chat client 

make object! [
code: 303
type: 'script
id: 'expect-arg
arg1: 'index?
arg2: 'series
arg3: [series! port!]
near: [index? find out-cols sel-col]
where: 'attempt

Hi Anton, about the list bug with sqlite. We were both right. It 
_is_ a series copy bug. And it _is_ an sql problem ... sql reuses 
the series it has given as a return value on the next call :-(

I think a separate function such as ACCESS should do that. SELECT 
should be left alone to do its series operations as usual.

One can say that FIND limits its input to series! to eliminate errors 
as early as possible. Imagine if FIND accepted NONE and we had some 
intricate series of FINDs on a single block 'a:

find find find/reverse find a 'e string! 'f integer!
== none


If 'a is a dynamic block (not known when you write the code) where 
is the error?


It's not a great example, but it raises the question of how forgiving 
you want your functions to be, when you write them. I consider that 
you generally want to catch errors as early as possible, to avoid 
having to write "forgiving" code that can take up space and complicate 
things and worst of all, make the code much harder to debug. But 
it's only one school of thought.

unlike a series of and/or  any/all will stop evaulating conditions 
at the first condition that deternims the result

Next discussion:  The Multi-dimenssional parsing proposal.
(to allow the parsing of 2 series at once with parallelism)

Gab, is there any document that has that info?  Besides reading the 
source? 


One additional quesiton.. How does Rebol know for sure that some 
internal strings are 8-bit? If strinds are manipulated (as they are 
series), what point they become 16bits?

what I do is normally wrap such code in an ALL block. NONE can mean 
so many things and it's best to trap a NONE where you know it appears 
during an operation that requires a series as input.

I''m trying to understand this language, sometimes getting it, sometimes 
not. Anyway here's my question.

In VID, I have a layout.  I want to put random images in 3 columns 
with 5 rows.  The images are stored together in a single binary file. 
(this is a mod of the card game on Nick's tutorial site).


So I read in the images into a series,  after I set the layout. But 
how do add those to the layout?

Here's my current code:
do %cards.r

the-tableau: layout [
	size 320x480 backdrop 0.170.0
	across
	at 30x20 tc1: box 80x100 teal 
	tc2: box 80x100 teal 
	tc3: box 80x100 teal return
	at 30x130 tc4: box 80x100 teal
	tc100: box 80x100 coal
	tc5: box 80x100 teal return
	at 30x240 tc6: box 80x100 teal
	tc200: box 80x100 coal
	tc7: box 80x100 teal return
	at 30x350 tc8: box 80x100 teal
	tc9: box 80x100 teal
	tc10: box 80x100 teal
]

foreach [card label num color pos] cards [
	
	dimg: load to-binary decompress (card)
	append deck-cards dimg ;feel movestyle
	throw-away-label: label
	append deck-cards-num num
	append deck-cards-color color
	throw-away-pos: pos
]

view/new the-tableau

do-events

That does help, thanks!  But still having some trouble seeing what's 
going on.

I see what random-card does, I think.  length? card-images returns 
how many are in the series of card-images.  Then random returns a 
number based on length?.  And pick chooses one of the card-images 
based on the random number.


But what is happening in the foreach?  It iterates over the images 
in the layout, correct?  The c is just an arbitrary variable, it 
could be anything, right?

Ah, OK then. The change in issue! has brought up a lot of issues, 
so to speak. We are hoping to collect them all and come up with a 
set of tweaks and enhancements that can make things work. It should 
be possible to make them work a lot like they did before, with only 
minor changes (like being non-modifiable). You can replicate a lot 
of the behavior of a series type in a non-series type by simply having 
the series functions also work on the other type, as closely as appropriate. 
Good examples of these are SELECT and APPEND on objects and maps.

In R3 you have more options for manipulating objects a little bit 
like series, without having to re-make the object, although I'm uncertain 
that you can remove elements from objects. But then you also have 
the map! datatype, which is more suitable for very quick adding and 
removing of key/value pairs.

Hello again!  Cannot see how to make BrianH's example work in REBOL/View 
2.7.8; hungup on how to FIND a set-word:

>> x
>> probe x
make object! [
    a: 1
    b: 2
    c: 3
]
>> z: make object! head remove/part find body-of x 'b 2

** Script Error: head expected series argument of type: series port
** Where: halt-view
** Near: z: make object! head remove/part
>> find body-of x 'b
== none
>> body-of x
== [a: 1 b: 2 c: 3]
>> find body-of x 'b:
== none

todun - read http://www.rebol.com/docs/core23/rebolcore-6.htmlIt 
shows you how to handle a series.   Getting to the End, backing up 
a character, and removing it might work.   If you just want to remove 
the last character you can always do that in one simple line.  Remember 
to save the full series from the head.    If you are not sure the 
last character is a LF then you need to add a test ... still in the 
same line if you want to scrunch it.

@Henrik, I want to refernce the same series but the modified version, 
at each call to the series.

if by modification you mean, moved index, then simply:

>>b: next a: [a b c]
== [b c]
>> same? b a
== false
>> head? b
== false
>> head? a
== true
>> same? head b a
== true
>> a/2: 'y
>> a
== [a y c]
>> b
== [y c]


The word "modified" is usually used when changing something in the 
series, except for the index. It's important to know when a function 
modifies a series or not, as you then will have to copy it first, 
if you don't want the original series modified.

so, todun, the general mechanism is that you can store a new index 
of a series, by simply by first move the index and storing the series 
under the same word again:

a: at a 4

This works for BACK, NEXT, AT, SKIP, HEAD, TAIL.

The series will not be modified or copied.


Note that when you COPY, COPY will only copy from the current index 
and forward.


If your index is not at head, HEAD is useful to temporarily reference 
the series from the head, like if you use AT several times in a loop 
or something:

at head a 4

@Sunanda,  the tutorial helped me figure out a solution. I made a 
temporary variable to hold the current series then used "back". Then 
simply read the new series.

Is it possible to update a series outside of the button that triggers 
it? I run into the problem whereby my series is being prematurely 
updated.

the display shows a  series that didn't change

Going back to my flash cards problem for instance, which I still 
cannot make work, if I wanted to just apply knowledge on series and 
VIEW to design this, how can I fix it (pastebin) and/or re-wrie this? 
I'm really curious to know if there is a design pattern and or way 
to go about thinking or doing REBOL coding. Thanks.

Implementing a design, you'll be doing series manipulations all the 
time

Todun, just some of my thoughts. I think you are changing the order 
of the cards ito indicate the difficulty of a question. When you 
are saving the %temp-cards.txt, you are at a particular position 
in your series because of the  "qa: next qa"  so when you save/all 
it is saving the series from the current position to the end. If 
you want to save the whole series, you can add  "head qa" which will 
bring the pointer back to the first  item for the save but leave 
your pointer at the current question.
It may help to do some simple tests:
>> a: [1 2 3 4 5 6 7 8 9 10]
== [1 2 3 4 5 6 7 8 9 10]
>> a: next a
== [2 3 4 5 6 7 8 9 10]
>> save %test.txt a
>> read %test.txt
== "2 3 4 5 6 7 8 9 10"
>> save %test.txt head a
>> read %test.txt
== "1 2 3 4 5 6 7 8 9 10"
 move/to a 5
== [6 7 8 9 10]
>> save %test.txt head a
>> read %test.txt
== "1 3 4 5 2 6 7 8 9 10"

etc. 


Also I like to add "probe" as in "probe qa" to different places in 
my code so I can see what is happening internally as I do stuff.


Finally, might I suggest that you actually approach the issue in 
a different way altogether? You can have a block that  has some metadata 
in it so that a question's difficulty can be assessed by other means 
such the word "hard" or some number such as 1 = easy and 10 = hard, 
for example. And allong with that you could keep track of how many 
times the person missed the question.
[ 1 "California"  "Sacramento"  1  1  0  1 ]

where the block above refers to  [ index Question  Answer  difficulty 
 Attempts Wrong Correct]

There's a lot more work to do this but if you can then search for 
the difficult questions, etc. Your program would control the order 
of the questions based on some filter such as difficulty, attempts. 
The user could just mark a question as difficult.

Anyway, just a thought.  I don't want to make your life hard and 
I need to go back to my own mess I started. I am in block-o-rama 
myself.

http://www.engadget.com/2010/03/18/windows-phone-7-series-the-complete-guide/
 Windows 7 Phone actually looks very nice (I am not a MS fan, but 
some things of them still suck much less as people give them credit)

FOLD vs MAP - FOLD accumulates, while MAP applys the func and returns 
a series of results.

Graham, it needs a little context. The set-word in the word block 
points to the current position in the series. The behaviour has also 
been introduced with FOREACH. Before, there was no other way to grab 
the series itself (only its values) at it's current index inside 
the loop block.

yes, that is usefull, especially if you want to change elements in 
original series ....

Well, REBOL is all block/series based .... and series is a "queue" 
of values. I would like to have stack of values (block of values), 
series, which we can pick-up from, sort, move, remove - no ackward 
one only value!

move: func [
    "Move a value or span of values in a series."
    source [series!] "Source series"
    offset [integer!] "Offset to move by, or index to move to"
    /part "Move part of a series"
    length [integer!] "The length of the part to move"

    /skip "Treat the series as records of fixed size" ;; SKIP redefined
    size [integer!] "Size of each record"

    /to "Move to an index relative to the head of the series" ;; TO redefined
] [
    unless length [length: 1]
    if skip [
        offset: offset * size: max 1 size
        length: length * size
    ]
    part: take/part source length
    insert either to [at head source offset] [
        system/words/skip source offset
    ] part
]

>> stats
Series Memory Info:
  node   size = 16
  series size = 20
       5 segs =  409640 bytes (header space)
   11259 blks = 1295568 bytes (blocks used)
    1213 strs =   85112 bytes (strings used)
       3 odds =   73792 bytes (odd series used)
   12475 used = 1454472 bytes (total used)
       0 free /    8005 bytes (free headers / nodespace)

Pool[ 0]    8B   173/  512: 256 (33%)  2 segs,    4112 total
Pool[ 1]   16B   487/  768: 256 (63%)  3 segs,   12312 total
Pool[ 2]   32B  1326/ 2048: 512 (64%)  4 segs,   65568 total
Pool[ 3]   48B  4621/ 8192:1024 (56%)  8 segs,  393280 total
Pool[ 4]   64B  2414/ 3584: 512 (67%)  7 segs,  229432 total
Pool[ 5]   80B  1182/ 1792: 256 (65%)  7 segs,  143416 total
Pool[ 6]   96B   544/  896: 128 (60%)  7 segs,   86072 total
Pool[ 7]  112B   342/  512: 128 (66%)  4 segs,   57376 total
Pool[ 8]  128B   228/  320:  64 (71%)  5 segs,   41000 total
Pool[ 9]  144B   182/  320:  64 (56%)  5 segs,   46120 total
Pool[10]  160B   144/  256:  64 (56%)  4 segs,   40992 total
Pool[11]  176B   137/  224:  32 (61%)  7 segs,   39480 total
Pool[12]  192B   121/  192:  32 (63%)  6 segs,   36912 total
Pool[13]  208B    89/  160:  32 (55%)  5 segs,   33320 total
Pool[14]  224B    77/  128:  32 (60%)  4 segs,   28704 total
Pool[15]  240B    28/   64:  32 (43%)  2 segs,   15376 total
Pool[16]  256B    39/   64:  64 (60%)  1 segs,   16392 total
Pool[17]  320B   170/  256:  32 (66%)  8 segs,   81984 total
Pool[18]  384B    49/   96:  16 (51%)  6 segs,   36912 total
Pool[19]  448B    21/   48:  16 (43%)  3 segs,   21528 total
Pool[20]  512B    14/   32:   8 (43%)  4 segs,   16416 total
Pool[21] 1024B    62/  128:  16 (48%)  8 segs,  131136 total
Pool[22] 2048B    13/   24:   8 (54%)  3 segs,   49176 total
Pool[23] 3072B     0/    4:   4 ( 0%)  1 segs,   12296 total
Pool[24] 4096B     0/    4:   4 ( 0%)  1 segs,   16392 total
Pool[25]   20B 12475/20480:4096 (60%)  5 segs,  409640 total
Pool[26]   64B     1/  128: 128 ( 0%)  1 segs,    8200 total
Pools used 1220708 of 2073544 (58%)
System pool used 483328
== 1454472

'alter is short for  'alternate (ie alternate between two states).

It's a shorthand way to add an item to a series if it is not there, 
or remove it if it is.

I may create strange data structures, but I use 'alter all the time.

Hi Anton, did you 'source 'alter?

alter: func [

    {If a value is not found in a series, append it; otherwise, remove 
    it.} 
    series [series! port!] 
    value 
    /local temp
][

    either temp: find series value [remove temp] [append series value]
]

So, you'd better off with:

if not find block item [append block item]

It cannot be part of ALTER function as ALTER can be used with any 
series. I'm not sure how you could strore the counts in bitsets or 
strings;-)

The general pattern in R3 is that none is the equivalent of missing 
data. Pick off the end of a series returns none too.

Recovering from a none is easier and more efficient than recovering 
from an error. Series bounds are just an implementation detail anyways, 
when you have series that can autoexpand.