AltME groups: search

Adding more and more natives schemes (like matrix operations on series) 
is the way to get Rebol more and more powerful

the unification of series management is one of the major sources 
of code reduction in rebol.

the other is the fact that series are mutable, and many functions 
edit the input series directly.

'alter is a hard one to name. The operation is:

 *   if the target value exists in the series: remove the first instance 
 of it
 *   if it does not exist in the series: append it to the end.

The "remove first instance"  makes it more generic than rotate/swap/toggle 
when there is more than one instance of the target in the series.

In theory, ALTER is a set function, so the series in question is 
not supposed to have duplicates.

You are quite right -- 'alter is still in R3 ..... My mistake.


Several of REBOL's set operations operate on series. Series are more 
like bags than sets, hence they can have duplicate values. That adds 
value for a programmer, but dilutes academic purity.


Perhaps 'alter could have a purer set defintion by becoming a no-op 
if the target value exists more than once in the series.

foreach will advance to the next index whether or not the series 
was modified:
>> D: [1 2 3 4 5 6 7 8 9]
== [1 2 3 4 5 6 7 8 9]
>> foreach X D [remove find D X]
== []
>> ? D
D is a block of value: [2 4 6 8]

Modifying a series you're iterating over is always risky. Not only 
do you have to make sure you get it right, but there is always a 
possibility that iterators might change their behavior.

yes.. I understand that .. I thought that in such case an error was 
untiuntive .. but I tried and it looks like it should .. ok .. so 
I don't know if anything is wrong with it


>> any-is? empty? [ "asd" "Asdas" ]
== none
>> any-is? empty? [ "asd" "Asdas" "" ]
== true
>> any-is? empty? [ "asd" "Asdas" "" none ]

** Script Error: empty? expected series argument of type: series 
port bitset
** Where: any-is?
** Near: empty? none
>>

I read the article linked from reddit. The author's opinions were 
a bit off sometimes, but the principle is sound. Combining ropes 
with the copy-on-write idea gets you copy-on-write strings that don't 
have to really copy if they don't need to. Only the modified part 
would need new storage - the unmodified part could be referenced 
unchanged. When you combine this with the possibility that PROTECTed 
series may be thread-global in R3, but unprotected series thread-local, 
then functional data structures start to become interesting in R3.

does it build a series without corrupting binary data ??

I want to make sure each item in the block of items occurs in the 
series S

Thanks for the demo script. I did not know ther was that much control 
with the stock rebol drop-down. It did not solve my problem with 
the display of hte full widget. I said the tab-panel was narrow ...I 
ment short. But the other problem seems to be that "tab Panel" seems 
to cut the wiget unless there is soething else occupying the space 
below.  At first I solved it by adding a series of empty text and 
returns but now I fill it with a box and place the drop-down with 
the at statement. Thanks!

hi.  I run View in Win XP.  My script is very simple... 

blk: load %/c/input.txt foreach url blk [if not find attempt [read 
append url "cvap"] "Nothing found"  [browse url]]
and a line in the input file is something like this:
http://website1.com/search?query=
http://website2.com/search?query=


So, I want to search for "cvap", and it appends that to the URL and 
I search the result string and if it DOES NOT say "Nothing Found", 
then I open that URL so I can visually examine it.


It works 95% of the time, but sometimes I get the following error:

** Script Error: find expected series argument of type: series port 
bitset
** Near: if not find attempt [read append url "cvap"]

Any ideas how I can fix this?
thx

James - those aren't time series from what I could see.  Time series 
are fed date values, and are not just equidistant points on an x 
axis labelled with dates.

Is there a way to append an image object (a box for example) to a 
face that has already been displayed. I'm looking to get  simple 
highlight functionality in an app in which a string is scanned for 
in a series of text faces. 


I've been  able to highlight the search word in each face but if 
I click in any of the text faces the face looses the highlight effect 
sort of like loosing focus on normal highlighting. 
I would like the highlight to remain until no longer needed.

I'm trying to create a function that builds radio buttons and checkboxes 
on the fly. Sunanda gave me some ideas about how to do that. This 
morning it dawned on me that I was going about it the wrong way. 
I was trying to build an entire string that represented the rebol 
code for the gadget instead of building a block of code.. What was 
happening was my contexts were all in error. 

I'm wondering now how to append my code into an existing layout block. 
The only working method I have found so far is to append into a non-layout 
block then "view layout blk." I'm still curious if there is a way 
to append/insert into a layout block though. E.g., 
a: layout [ btn "Quit" [unview halt] ]
b: [t1: check [ ] ]   <- this is my generated block
append a b

I get a "Script Error: append expected series argument of type: series 
port"

still error1


** Script Error: copy expected value argument of type: series port 
bitset
** Where: expand-specs
** Near: specs: copy specs
foreach var

by interactive I mean will this be rendered or running live?


with a rendered system you can crank up the particle count and just 
pregenerate the whole data set as a series of images.  then when 
you need to see it, just cycle the image of a face.


usually, people use a few particles for preview... then generate 
"flipbooks" which are just rendered images and include thousands 
of particles with their alpha channel density reduced to practically 
nothing (like 2% visibility)  this generates very pretty effects, 
but at a cost of rendering time.

For my previous snippet:

>> layout [X: button]

X is just a generic variable name I use when I need a throwaway, 
like others use "foo", "bar", and so on.  Layout is just assigning 
the button object to the word X, which I'm exploring in the next 
few lines like Geomol explained.


I explored system in the same way to find view, then VID, then vid-styles. 
 vid-styles is a block containing a series of alternating names and 
definitions, which the foreach loop is simply going over

** Script Error: empty? expected series argument of type: series 
port bitset
** Where: set-focus
** Near: view*/caret: case [

    all [caret in face 'caret face/caret] [at face/text face/caret]
    find behaviors/caret-on-foc...

An error has occurred.  If this occurred with an upgrade, please 
revert to the older version for the meantime, and report the error 
message as documented below.

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'clear
    arg2: 'series
    arg3: [series! port! bitset! none!]
    near: [clear f/text 
        all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0] 
        f/line-list:
    ]
    where: 'clear-text
]

>> display "" [ el: edit-list data [ "1" "2" ] button "Set" [ el/text: 
1 show el ] button "clear" [ clear-text el
]] do-events

** Script Error: clear expected series argument of type: series port 
bitset none
** Where: clear-text
** Near: clear f/text
all [f/type = 'area f/para/scroll: 0x0 f/pane/data: 0]
f/line-list:

here it was:

make object! [
    code: 303
    type: 'script
    id: 'expect-arg
    arg1: 'find
    arg2: 'series
    arg3: [series! port! bitset!]

    near: [s: any [all [s: find/reverse str s next s] head str] set [ns]]
    where: 'current-word
]

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

latest checkout


>> display "" [ sp: scroll-panel data [ field 10 "Hello" ] button 
"get values" [ probe get-values sp
]] do-events
** Script Error: foreach expected data argument of type: series
** Where: get-values
** Near: foreach widget face/pane [
    if find [

        area check check-group drop-list edit-list field group-box password 
        rad...
>>

Certainly possible (creating an image of a display is trivial), but 
how would it be used / specified in practice, and what would we call 
this new widget? Perhaps a grouping widget?

	fan data [
		display "A" [...]
		display "B" [...]
		display "C" [...]
		...
	]


which would create a series of clickable display icons ... click 
the icon and that display comes to the foreground. Is that sort of 
what we are talking about?

I've seen something similar before ... solution was to ensure all 
values were strings ... and to copy/deep the data block prior to 
passing it to the table widget. I think it has something to do with 
either a non-string value (e.g. a block) confusing things, or a shared 
series [value] being modified by soemthing other than the table widget.

RebDOC crashes even separately:


** Script Error: length? expected series argument of type: series 
port tuple bitset struct
** Where: layout
** Near: form length? functions
>>

It's even worse than that, the true "cut-over" for many won't occur 
until we have a stable R3 SDK! ;)


Having 2 versions of RebGUI (b117 and b218) that are each 95% done, 
but each with their own bugs and quirks is not an ideal situation 
... so I'm [again] looking to complete the 2.x series and finally 
obsolete b117 ... but R3, as always, is so close ...

2.x series.

On a Mac, no problem. On WinXP it appears that the events are being 
generated faster than they can be processed. Good test case, I've 
never seen this before! ;)


I don't have an immediate fix, but this is one more reason for me 
to get the 2.x series released. Are drop- and edit-list the only 
roadblocks for you?

Sorry for reporting only bugs, I like the 2.x series so much, it's 
much faster, no slow scrolling, I do really hope this version gets 
stable and usable. Currently it's the only usable GUI for me with 
nice graphic.

b117 is the latest stable release. The b2xx series is a rewrite that 
is 95% complete.

A dictionary is just a series of words. You can make your own

The behavior of map! is part of a general change in R3 to make the 
none value be a placeholder for missing data, like null in SQL. Even 
the series accessors (first, second, ...) now return none when accessing 
indexes off the end - this means that you can now thing of the current 
length of a series as an relatively unimportant detail that you can 
ignore in some circumstances.

can anyone help , im new to rebol. im trying to pass a value to a 
function but i get a path error. why? ex. somefunc: func [x] [print 
series/x]

and use it to read a value in a series somefunc 1

This may be what you want:
   series: ["a" "b" "c" ]
   somefunc: func [x] [print pick series x]
   >>somefunc 1
   == a

This works in recent versions of REBOL:
   somefunc: func [x] [print pick series/:x]
note the ":" before the "x"

series/:x or series/(x)

oops -- remove the 'pic from that second example:
    somefunc: func [x] [print series/:x]

There starts to be series of VID3 blogs. So - those who want to affect 
some design principles, can share their opinion there ....

Many of the series functions are modifying though, and reassignment 
is used a lot.

Ports can't be treated like series anymore. The seek option has been 
moved to READ and WRITE, which correspond loosely to COPY and INSERT 
on R2 ports. The index or offset is an internal property of the port, 
not of the port reference like in R2.

As far as your code is concerned, a string! will be a series of Unicode 
codepoints. Internally, who cares? The implementation of string! 
is likely to be the same as the native implementation on the platform 
is running on, or whatever is more efficient. I think that string! 
is now UTF-16 on Windows, and the symbols behind word! values are 
internally UTF-8.


Still, it doesn't matter what strings are internally because AS-STRING 
and AS-BINARY are gone. All string-to-binary conversions will need 
encoding. REBOL scripts are going to be UTF-8 encoded though, as 
I recall.

Is there any way to get our hands on the latest Alpha build?  I would 
like to start to plan for migration to REBOL3 of some scripts and 
plan for REBOL3 in current work.  Especially regarding ports and 
series handling.

yes... for python its rather easy because the first class values 
follow most of C rules... series are static, for example.

a bit like saying that series is the super type of both string and 
block.

I'm still waiting on an answer about that INSERT of unset! values 
change in the 2.7 series...

what should be the usage of unset! values in series ?

I don't know. I know that if you need to have an unset! vale in a 
series, not being able to insert one would be a hassle. I just don't 
like the wrapper code  that it requires sometimes (as in that MAP 
discussion).

one question I have... does the object type also copy every series 
included like in R2 ?  that, IMHO one of the biggest regressions 
in rebol's history.   reversing the copy is impossible to do perfectly 
(scanning the new object, and attempting to link back the old series). 
plus it slows down rebol in a few ways.

It´s written in a simple style, yet I had to make a series of tweaks

I encountered several bugs and I had to write a series of wrappers 
for READ and WRITE to arrive at functions that act compatible between 
R2 and R3

head clear back tail is much faster than reverse remove reverse. 
All of that reversing is series copying, as is remove from the head 
of a series. If you don't need your function to copy, change reverse 
remove reverse to clear back tail.

Well, my get-block function is an example.  I used it on a series 
of block data and get different results that don't seem to jive with 
my expectations.

The one compare is dwarfed by the copy overhead though. Shifting 
the index only has significant overhead for ports, not series.

We are extending support of many of the functions that people traditionally 
associated with series to objects and maps, without making them into 
series. So that means that APPEND works, but INSERT doesn't because 
of the position stuff.

Well, in some cases to fix, but yes, lots of exceptions. The guideline 
is that maps and objects don't have position, but series do. So the 
position-dependent functions don't work but their non-position-dependent 
counterparts do. Ports don't work like series either, so there is 
another whole set of differences to remember.

Trust me, vector! has bigger problems than that right now. I expect 
that it will not end up 0-based though, even with all of the advantages 
that 0-based vectors give us. It is likely that we will instead have 
0-based versions of PICK and POKE that work on all series.

>> a: []
== []

>> dp [append a 1]
== make object! [
    timer: 32
    evals: 11
    eval-natives: 4
    eval-functions: 1
    series-made: 2
    series-freed: 1
    series-expanded: 1
    series-bytes: 464
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]


as you can see the block has been expanded, which means copied in 
another place

>> dp [a: [] b: []]
== make object! [
    timer: 15
    evals: 12
    eval-natives: 3
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

>>

>> dp []
== make object! [
    timer: 14
    evals: 8
    eval-natives: 3
    eval-functions: 1
    series-made: 1
    series-freed: 0
    series-expanded: 0
    series-bytes: 432
    series-recycled: 0
    made-blocks: 1
    made-objects: 0
    recycles: 0
]

see, a block is always created by dp

No, there are no plans to implement range. The head and tail of the 
series are attributes of the series, not the reference to the series. 
It's like the difference between the position attribute of a port 
and a series: For a series, the position is an attribute of the reference 
to the series, while for port, the position is an internal attribute. 
Still, a subseries reference could be implemented as a user-defined 
datatype as long as it is careful to make up for changes in the underlying 
series.

hmmm... the rebin format will be hudge, cause for series, there is 
2 indirections (2 references) + the value himself

No, just the value and the reference to the value with the position. 
The poisition isn't a reference, just an integer (internally). So 
you need the series, the length of the series, a datatype tag, the 
reference to the series, and the offset. The reference and offset 
would be part of the contents of anotther series. It would take less 
space in binary than in memory or REBOL syntax.

Brian, Vector datatype can't be expanded or appended, ie the size 
is fixed in the moment of creation, for use as fix lookup maybe good, 
practically not, it is kind of series and should behave similarly

there is lot of missing features related to vectors (find, mold, 
to binary!, etc...) It should have the same capabitilies than other 
series...

Or this one:

>> v: make vector! [+ integer! 16 100]
== vector!

>> v/0: 20
== 20

>> v/1: 100
== 100

>> first v
== 100


See? I said that introducing zero based series in REBOL is not good 
idea :)

Yes Pekr, this has nothing to do with zero based indexing. Series 
are still one based:
>> b: [a b c d e]
== [a b c d e]

>> b/1
== a

>> b/0
== none

What we need to worry about is clarity of how each series type behaves 
with the series functions (as uniformly as possible) and fixing the 
bugs for AT on blocks and PICK on strings.

You are right, those functionalities behave consistently. I probably 
need some "rebol philosophy" explanation for such stuff. Why e.g. 
head is at first series element, and why tail occupies one past last 
series element, etc.

Petr, I have been proposing that new PICKZ and POKEZ functions be 
added to do a 0-based PICK/POKE, instead of having vector! be 0-based. 
This would give us 0-based referencing abilities for all series, 
not just vectors, then we could make vectors 1-based like the rest. 
There are real advantages to 0-based indexing so it would be good 
to have it, but consistency is better here.


Carl was not proposing to make a change to PICK and POKE in his blog: 
he already (half) made the change. He was asking us in his blog if 
he should change it  *back* to the old, buggy R2 behavior. I think 
he should finish fixing PICK, POKE and AT instead.


Henrik, INDEX? returns a 1-based index from the *head* of the series 
- that's why it's always positive.

Because the series creatiion builder model is easier for less advanced 
REBOL programmers to use. Buffers need management (as #1789 explains). 
This new model is for more advanced programming, such as mezzanine 
and library code.

I guess, I don't follow.  Maybe, I'm jumping to conclusions about 
what /into actually implies.  To me, /into implies that the original 
series passed to the function is what is modified and not a copy 
of it.

Brian, I read it and the option I believe should be default behavior 
is for the original series to be modified.

That is the difference between /no-copy (which turns a builder into 
a modifier), /copy (which turns a modifier into a builder), and /into 
(which makes a builder insert into a provided buffer instead of creating 
its own series).

Brian, now you say it inserts. Does it clear the series and inserts, 
just inserts or overwrites the existing content?

BrianH, but are we not doubling in size the memory space for that 
function?  If were passing it a huge series to begin with - would 
we not end up with a buffer that is potentially as big or bigger 
than the original series if were inserting data?

Most of the time a function using build/into functions will preallocate 
a series, build some data into it, then return the series. Builder 
functions can use lower-level builder functions. You get a reduction 
in intermediate series creation overall.

; Here's a version of COLLECT without /into, a typical example of 
a builder.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/local output
][
	output: make block! 16
	do func [keep] body func [value /only] [
		apply :append [output :value none none only]
		:value
	]
	output
]

; Here's COLLECT with the /into option.
collect: func [

 "Evaluates a block, storing values via KEEP function, and returns 
 block of collected values."
	body [block!] "Block to evaluate"
	/into "Collect into a given series, rather than a new block"
	output [series!] "The series to output to"
][
	unless output [output: make block! 16]
	do func [keep] body func [value /only] [
		output: apply :insert [output :value none none only]
		:value
	]
	either into [output] [head output]
]


Note that the version with /into also lets you use other series types 
than just block!. This option added to REDUCE and COMPOSE would let 
you create parens and paths as well, even though REDUCE and COMPOSE 
can only take block! specs.

APPLY is good for wrapper functions, and now for using function values. 
From COLLECT:
    output: apply :insert [output :value none none only]
From USE:
    apply make closure! reduce [to block! vars copy/deep body] []
From ACCUMULATE:
    value: apply :fn [:value series/1]

I'm converting GATHER to mezzanine/library code standards now. We'll 
probably put all of these is an advanced series manipulation library 
module.

Mezzanine-quality version of Henrik's GATHER, R3 version:

gather: func [
	"Get the values of a given field from all objects in a block."
	block [block!]
	word [word!]

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	forall block [
		all [
			object? block/1
			in block/1 word
			output: insert/only output select block/1 word
		]
	]
	either into [output] [head output]
]

Final submitted R3 version:

gather: func [

 "Get the values of a given field from all objects in a block that 
 have it."
	block [block!] "A block which may contain objects"
	word [word!] "The field to look for"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	foreach item block [all [
		object? :item
		in item word
		output: insert/only output select item word
	]]
	either into [output] [head output]
]

Here's the R2 version of GATHER:

gather: func [

 "Get the values of a given field from all objects in a block that 
 have it."
	block [block!] "A block which may contain objects"
	word [word!] "The field to look for"

 /into "Insert into a buffer instead (returns position after insert)"
	output [series!] "The buffer series (modified)"
][
	unless output [output: make block length? block]
	foreach item block [all [
		object? get/any 'item
		in item word
		output: insert/only output get/any in item word
	]]
	either into [output] [head output]
]

I apologize, ACCUMULATE is whichever version of fold that starts 
at the beginning and ends at the end of series (left? right?).

Consider if we had a COUNTER! datatype. The counter would create 
a series of integers, each holding a separate base. The trick to 
COUNTER! is that it is a structure that holds more information than 
just the numbers, but also states, in the same way that a block holds 
an index or whether a port! is open or closed.

First the bad things:


- It can be complex and there are many things to consider. Many functions 
would be affected.

Now the good:


- This takes all the thinking out of building trivial counters and 
could greatly simplify it.
- It could be used as an any-base converter.
- No new functions to add specifically for it.

It should be possible to:

- Specify as many numbers per counter as we like.

- Each number would be within the limits of positive integers and 
each number would act as an integer! type.

- Extract information about which digit is currently counting or 
which number was last changed.
- Extract base information.
- Perform basic math (add/subtract).
- Perform base conversion for the entire counter.
- Perform base conversion between a counter and an integer.

A counter would hold four pieces of information:

- The base for each number
- The numbers themselves
- The last changed number as a one-based integer index

- The last numbers that were reset at last count as a block of one-based 
integer indexes

The nature of a counter:

- It would be a number!.
- It would not be a series!.

Specifying a counter:

- The above four pieces would be specified in order
- Each piece is separated by an exclamation mark
- Possible to skip pieces by leaving the field empty

- Syntax: !<base definition>!<number>!<last changed number>!<last 
reset numbers>
- Counter base alone: !12.14.16
- Counter base with number: !12.14.16!0.0.0

- Counter base with number and last changed number: !12.14.16!0.0.0!3

- Counter base with number and last changed number and last reset 
indexes: !12.14.16!0.0.0!3![2 1]
- Number without base: !!0.0.0

There's more, but it's a little much to write. :-)

Steeve, I'm writing it up now. It's probably possible to do with 
a series of mezzanines, but it would not be very elegant.

I'm changing my mind on not needing math and it not being a series. 
Sorry, if that seemed confusing.

the fun things with rebol is that we could potentially have series 
type accessors (insert, copy, pick, etc.)

The lowers levels should then have been tested better, before going 
into higher levels. When you fix a bug on a low level now, it could 
have significal influence on higher levels, so more tests and probably 
new bugs. Problem is the low levels are hidden from us.


Memory problem on OS X concern me a lot. Also today I wanted to do 
some test on issue! datatype, and get strange results. Like doing:

i: #
insert i "abc"


If low level series handling like this has bugs, then I'm very concerned.

It's clear, that most series related bugs are because of unfinished 
unicode implementation.

map! is just an optimized merge between blocks and objects, not so 
urgent to me.

But if you don't have vectors, some programs can't be done because 
of the memory overhead of other series in Rebol

The map! type is not a series, it's more like an object with different 
inclusion rules. No order, no position.

then object should be a series :-)

Resolve is good for assignment of values in objects to other objects 
without them having to be in the same order or even have all the 
same fields. If anything, it makes objects even *less* series-like 
than they were before :)

READ/text seems like a lock, sorry. You may think that text is just 
another data format, but it is the *most common* data format, and 
tends to be processed in large quantities. You say that codecs can 
be chained, but they currently can't - you can apply them one at 
a time, with all of the intermediate forms in memory at some point. 
If we do text the way you ask, then every load of text for processing 
will have the additional overhead of a full duplicate of the ram 
and two series moves, plus a few lines of code. READ/text is a shortcut 
that will save a *lot* of overhead during what may be REBOL's most 
common operation.

Could it mean that we will store complex data structures (nested 
series and object without duplicated values, like MOLD do) ?