AltME groups: search

Quick comment in support of Gregg's last announcement: I've tried 
introducing a number of folks to REBOL/AltME, and they were deterred 
from using it because of the high amount of noise and the feeling 
that they were "intruding" on a series of private conversations. 
So my feeling on the matter is that wide ranging discussions are 
all well and fine for folks who are *already* here but could deter 
some folks who come to the REBOL world thinking it might be a purely 
technical / support forum.

2.4 Ghz with 2400 series. We will have in about a two months the 
5800 series which operates at 5.8Ghz, possibly at 4.9Ghz too.

I get the same as PhilB: "**Crash : expand series overflow"  rvdraw57e, 
 WinXP

I would like that too. but a path! is a series, maybe that is tricky? 
but we could set the last element to unset.

#3687 : bitwise ops - it was submitted at the start of the /View 
1.3 project (2003/2004). 

Both MacOS 9 and Amiga /View 12.1 (big-endian MC 680xx / PowerPC) 
have this bug for bitwise operations on series.

I had to do a workaround for %gzip.r (painful slow byte per byte 
operations) and %rebzip.r (calculations with integers.)

(split-path mucks up when its target argument is at a series offset.)

dont have access to rambo could someone submit an error in the word 
brower for me.  in the find box a down arrow errors with: ** Script 
Error: index? expected series argument
 of type: series port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first

regarding #3912

The newest Rebol version displays a different error message

***Panic (should not happen) -Invalid series width 1 was 16 (type 
44)

How near is RT to a fix ?

I would say that you can't do *anything* safely on a series reference.

Ladislav, yes, these inconsistencies hold back rebol's reflection 
somewhat.

Maybe it's excusable for ports, though, because they are kind of 
"custom series datatypes"... have to think carefully about that.

can I propose this for R3?

fill: func [
	"Fills a series to a fixed length"
	data "series to fill, any non series is converted to string!"
	len [integer!] "length of resulting string"
	/with val "replace default space char"
	/right "right justify fill"
	/truncate "will truncate input data if its larger than len"
	/local buffer
][
	unless series? data [
		data: to-string data
	]
	val: any [
		val " " ; default value
	]
	buffer: head insert/dup make type? data none val len
	either right [
		reverse data
		change buffer data
		reverse buffer
	][
		change buffer data
	]
	if truncate [
		clear next at buffer len
	]
	buffer
]

I think I was more concerned with the fill function itself and its 
range of arguments... I agree that the reverse stuff is not optimal. 
  could 'FILL itself (a faster implementation) be considered for 
2.7 ?  I've had to implement this kind of func so often...?  it handles 
all series, and transforms non series automatically...  so you can 
easily fill any value:

fill 1 3
== "1  "

also:

zfill: func [i len][fill/with/right i len 0]
zfill 1 3
== "001"


/right might be /left depending on POV  I prefer /right in the sense 
where the output is right justified... a /center could also be added 
pretty easily.

If you have ever tried APPENDing a Block to a Block as a Block (ie. 
append ["a"] to [] and have it be [["a"]])  Then you prolly know 
that you have to jump through a couple of hoops to do it.  The same 
goes to append a string to a string.  Now there are a lot of times 
that I need to append one series to another as a "sub-series" it 
seems to me that this should be much simpler to do, maybe a refinement 
to APPEND.  Any thoughts?

Thanks for the strict-greater? idea.  I was hoping there was a built-in 
ability somewhere.

One tiny tweak to the function -- you need to restrict the two values 
to series or you can get strange results:
     >> strict-greater? make object! [1] make object! [0]
     == false
     >> greater? make object! [1] make object! [0]
     ** Script Error: Cannot use greater? on object! value
So:

 strict-greater?: func [value1 [series!] value2 [series!]] [(to-binary 
 value1) > (to-
binary value2)]

Thats what series are about. :) And we can make our own using ports 
:)

about Roberts stack: most of that is inbuild in series, so why wrap/rename 
it?

POP is about the most useful method that isn't built into REBOL. 
It's nice to be able to remove something and have it returned, rather 
than having the series returned.

Looking at 'ALTER.. shouldn't there be a similar word that "If a 
value is not found in a series, append it; otherwise, DO NOTHING?

In other words.. i want to check the series to see if the word exists.. 
if not, add it..

After all a file is just a binary! series

On a related theme......Is there an easy/built-in way to check if 
all values in a series are equal?  I'm using

     all-equal?: func [ser [series!]] [ser = join next ser first ser]
As in:
    all-equal? [1 1 1 ]
    == true
    all-equal? "yyy" 
    true
    all-equal? %xxx
     true

Volker, it should operate on series values as well, like FOR does 
today. My examples are all numbers, because that's easier to do concisely. 
:-)

assume: func [
    {If a value is not in a series, append it.}
    series [series! port!]
    value
][
    any [find series value insert tail series :value]
]

I get the following error when I do this: ** Script Error: foreach 
expected data argument of type: series
** Near: foreach message mailbox [
    print message
    ask "Next? "
]
close

I reversed the series so that you remove them from the end backwards

as otherwise I guess the numbering changes if you remove from the 
head instead

I have that problem all the time with having to write

	first find series val

as:

	if f: find series val [f: first f]

first find series val?

The problem I see is that it complicates debugging.

>> 1 + index? find "abc" "e"

** Script Error: index? expected series argument of type: series 
port
** Near: 1 + index? find "abc"

>> 1 + attempt[index? find "abc" "e"]
** Script Error: Cannot use add on none! value
** Near: 1 + attempt [index? find "abc" "e"]

but when you found nothing, there is no index. 0 would give syntactically 
valid results, letting the rest of the program run. just doing wrong 
things. none will at least led to trapping it.

thinking about it, when using series instead of indices, it bails 
out on using, not immediate too. maybe index? pasing none is k.

I vote to leave it like it is.  It makes the most sense to have Index? 
fail on a non-series value.  I've found ANY to be a very handy function 
for handling things like that.  I initially just used it with EITHER 
and IF but its starting to show up in a lot of places in my code 
because it is just nice and concise. ;-)

Jaime: for INDEX? used alone, that may be true. But asking the position 
of a value in a series and asking the index of a value in a series 
are, IMHO, the same question.

pos: find series value

idx: index? find series value

as gabriele says, we have the same problem with series. can be none 
too and fail then.

since i rarely use index when i can use series, i don't know how 
important thatis.

The only time I've found it useful to use index is when using values 
in one series as a key to values in another series. Kind of rare 
when you have select/skip, but sometimes you don't want to modify 
the data series. All right, since RAMBO says that there are problems 
with select/skip right now, maybe not so rare.

thats one way to see it, which i partly share.

but with series its the same kind of exception, and Gabriele argues 
we could deal with it like we do with series: give none and trap 
on access.

and the "flow" in such cases is to use the patterns i showed, with 
'if or 'any. and not forcing an extra assignment.

Which of the other series functions also work on none, instead of 
just returning it?

Well, if you consider index? find to be another way of saying find/index 
(if such a thing existed) then I can see why you would let it accept 
none. If you consider index? to be a seperate function, then accepting 
none would just be propagating an erroneous condition. Remove should 
definitely accept none because it's not much of a stretch to change 
its meaning from "remove here" to "remove here if there is something 
to remove, no-op if inapplicable", the same behavior it has as in 
 remove tail series.

But Remove Tail Series is programatically different than Remove None 
as Tail returns an apparently empty series, not none.

with blocks, I don't think that'll work with match, because it searches 
for the full element in a series, thus you need to search in two 
levels...

Regarding the question on the mailing list on extracting a series 
of duplicates, I wonder why Rebol doesn't allow us to subtract one 
series from another.  If we are allowed to append one series to another, 
why not allow us to subtract?
But I guess the problem then is sameness.

CHANGE series value

Change seem to have destination first aswell. Didn't Carl write a 
blog about it at some time?

You guys can also think about, how many different colors are needed 
(preferred), when displaying REBOL source. A color for comments, 
values, datatypes, words, etc. Should values be split into numeric 
values, series and others with each their color. Other things?

Hmm... How to do that?
We need to know where a particular
Maybe:
1. Read script *and* Load script
2. Visit each item in the loaded block, recursively.
3. As each item is visited, check its type.

4. Depending somewhat on type, parse (in the READed script) to the 
molded item:
4.1  If it's a series, search for the "opener", eg. block! -> "["
4.2  If it's a non-series, search for it molded.
4.3

It's possible....But may take a while.

For now, you could publish extension code on REBOL.org as an article 
(or series of articles).

the flag is set by each function that modified the series. It's in 
ctx-text (insert-char, edit-text for the most).

caret position is simply the text position (series position) of the 
text.

Yes -- but you need to append, compose or mold it to make it the 
right series of characters for Layout to understand.

Thanks a lot.  It the kind of thing I normally learn the hard way, 
like the first time I was confronted to [ ] instead of copy [ ]. 
 Judging when it is better to use a block or object or structure, 
hash or else is not evident from a new eye.  The small Ladislav tutorial 
on blocks (series) is the kind of thing that helps a lot,, it help 
a newcommer realise how the language is articulated.

Hello all.. I need help!  I am trying to append a series within a 
series..  i.e.  [ [a b c] [d e f] ].  How would I add [g h i] to 
the end of my series so that I would have [ [abc] [ d e f] [g h i] 
], and not [ [a b c] [d e f] g h i ] ?

Tom: Yes, I was aware of read/lines and how it is similar (apparently 
not the same) as parse/all series "^/".  read/lines worked just fine.

I don't know why last night I wasn't happy with read/lines - must 
have been tired!

yeah, each rule stop at a position, not going past it. that way you 
wouldn't be able to reach the tail of the series. THRU will get you 
to the tale

search for a series of capitalised words and strong them

I guess it can't be otherwise we wouldn't need to use 'copy on series

The series copy thing is something different.

firsttime?: true 
parse [1 2 3 4 5][
	any [
		set v integer! 
		p:   ; <-- set P to the current parse position.

       ; (This is the input series with the series index at the current 
       position.)
		
		(
			; Here inside the paren is normal rebol code 
			
			prin v 
			if all [firsttime? v = 4][

    p: skip p -2   ; <-- move the index of the series referred to by 
    P
				firsttime?: false
			]
		) 
		
		:p   ; <-- set the current parse position to P
	]
]

; Try against this, the forskip code with the skip part taken out
forall: func [
    "Evaluates a block for every value in a series."
    [catch throw]

    'word [word!] {Word set to each position in series and changed as 
    a result}
    body [block!] "Block to evaluate each time"
    /local orig result
][
    if not any [
        series? get word
        port? get word

    ] [throw make error! {forall expected word argument to refer to a 
    series or port!}]
    orig: get word
    while [any [not tail? get word (set word orig false)]] [
        set/any 'result do body
        set word next get word
        get/any 'result
    ]
]

No printer support yet. We're planning to port and integrate CUPS 
in the 0.6.x series, which we will start soon. Basic printer support 
will probably happen in the coming year

We're now officially out of the 0.5.x series, which were meant to 
update our base technology and were thus fairly chaotic. We now have 
a good development platform for the innovations that we have been 
planning

Does anyone have any ideas about how to approach a web-based gui 
that allows users to upload multiple files at one time without having 
a series of  "inputs?" I'd like to have users do a ctrl select when 
they are browsing for multiple files to send. Thanks.

I'm not quite sure how to pan this out.  Also, the 'name rule doesn't 
have any set words, it is operating on an unnamed series.  I think 
I want this type of rule to match the content.  In that if [string! 
string!] does not exactly describe the content, 'name throws a bad-format 
error.

Sunanda: I feel from my experience with parse that it's the sort 
of thing that can, if it fits your problem, help you a great deal... 
but it often seems to be just short of the needed functionality. 
 I feel if your task does not depend on knowing the true/false result 
of matching, then series operations are often better.  I've been 
thinking "if you don't use the boolean result of parse, you probably 
aren't working on a task that needs parse."

Need some help...Can't seem to get Uniserv working on my XP laptop. 
 This is my first try...so I don't have enough experience to see 
what is happening.  Do I have the wrong version of core?

>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new
>>

I figured out how to stop the service tying up the 80 port , When 
i run this is what I get: >> do %/c/temp/rebol/uniserve/uni-engine.r
== true
>> uniserve/boot
[uniserve] Async Protocol Admin loaded
[uniserve] Async Protocol DNS loaded
[uniserve] Async Protocol FastCGI loaded
[uniserve] Async Protocol HTTP loaded

** Script Error: change expected series argument of type: series 
port
** Where: install-plugin
** Near: change pos/2 new

SAX apis don't work like that. They generate a series of events, 
not a series of data.

you can just do a mold/all load, that will in effect copy the whole 
tree along with all the series too.

Wow...I don't track laptops the same way.  I'm on this right now 
http://store.shopfujitsu.com/fpc/Ecommerce/buildseriesbean.do?series=P7120D
Very small, but I LOVE it!

Ok thanks. I'll double check the exact number tommorrow, but it's 
the 8.1 series. LIMIT would be a good idea, but the query returns 
only one row. It's the amount of data in the one column that is the 
problem. (Whole HTML reports in one chunk). I was thinking that I 
should split up the report into a set of smaller chunks as it gets 
generated  anyway.


I'll give you some more info tommorrow. I appreciate you are busy 
with Cheyenne, so thanks for your time.

I am trying PGSQL with Doc's protocol and getting 'open pgsql'  error 
"** Script Error: find expected series argument of type: series object 
port bitse
t

** Near: fast-query: either args: find port/target"     This is Postgres 
9.0 recently downloaded.   Anyone having success with it?

it is a series .... [this is what?] - now how can you tell what is 
inside? is it code? or literal data? try to execute it with "do" 
- if it fails, it was not code :-)

hmm, you said it is like lisp - so yes, it is so ... I explained 
to my friend, that everything is a series/block (strings in Reichart's 
post). And you have basic set of commands to operate on strings - 
insert, delete, change, append, remove, find, first ... tenth ....... 
and you have 'do to do the code ...

series and its operations everywhere ... that is how I would start 
....

I will recommend you read the PLT book, or the CTM Book. This introduce 
a lot of the concepts present in rebol, and you can get a sense on 
how to programm with series (lists), how to use func are as natural 
as integers, and how to drive your programs around the data structures, 
and not around the memory management.

Yes, if we have a word set to a value like this:
	word: 123
then there is a series of possible "reductions" possible:
	'word  ->  word  ->  123

Likewise for a function:
	word: func [][print "hello"]
The reductions:

 'word  ->  :word (gives unevaluated function)  ->  word (evaluates 
 the function to print "hello")

Don't forget Forth in the heritage list! Lisp/Logo and Forth are 
key design ancestors, for lists/blocks and words, respectively.

So, the main things I think of as far as basic concepts are:


1) Everything is data; sometimes that data is evaluated and things 
happen.


2) Everything lives in blocks; there are series operations that you 
need to understand in order to manipulate them.

3) Everything is data.


4) Words are very important; not only knowing when they are evaluated 
and other technical details, but also how you choose them so they 
work together well.

5) Everything is data.

Peter, series values are really a pointer to the series data and 
an offset. When you assign a series value to a word, that pointer 
and offset are copied into the value slot that is currently associated 
with that word (until it is bound to another context). The actual 
series data pointed to is unchanged, though.

I think that it would be good to have visual drawing - sentences 
as "symbol that is pointed to by  a word" is kind of abstract for 
newbies. And what bothers newbies? When the series is unique and 
not shared. I know cases where I better use 'copy, because I am not 
really sure, what rebol will do ...

ball part figure, I'd say basic I/O and core series handling.

Although the "choose a task first then learn what needs to be used 
to code it" approach is fine in many circomstances, in a 45 hours 
course, the student ends up knowing how to code a few tasks (hopefully 
more than one, but not necessarily), but often has a very hard time 
transferring this knowledge to other tasks.


So I think a better "generalist" approach would be to categorize 
generic tasks, like "file manip"', "math", "iterations", "series", 
"network sharing of data", ... and identifying just a few native 
words category that are enough to solve all or most problems given 
in those categories.

Strings and blocks are both series, so first, next find etc work 
on both, but when you load you get a block and the units are values. 
When you read, you have a string and the units are characters.

also remember that find, does not copy the series, it returns the 
serie at a different index.

The second one got the right part of the series

On "append append", yes. You could also do it like this: "append 
line join blk/:n tab", the difference being that APPEND modifies 
its series argument, and JOIN does not.


REPEAT is 1-based, not zero, Anton is using "-1 + length? blk" rather 
than "(length? blk) - 1" or "subtract length? blk 1". The first of 
those cases requires the paren because "-" is an op! which will be 
evaluated before the length? func, so REBOL would see it like this 
"length? (blk - 1)", which doesn't work.

First question: what 'instructions' are implemented in rebcode ? 
Seems like series are not implemented.

Series traverse seems to work, but I'm not able to pick, poke or 
change something

apply result find [series value]   :-)

How to traverse with series in rebcode? I wanted to make ucs2 encoder 
using rebcode but found out, that I'm not able to traverse the series 
by 2 chars

Series in rebcode are offset-1 based like normal (except image positions 
in DRAW). Would it be a good idea to make them offset-zero based 
in rebcode? Example: if I wanna read a pixel value at a certain position 
in REBOL, I could write:
image/1
or
first skip image position
(If position was 0x0, I'll get the first pixel.)

If I pick an image in rebcode at offset 0, I get an out of range 
error. It's a tough decision, but what seems most 'correct'?

http://video.google.de/videosearch?q=hp+labs+google+techtalks


This are two of a series of four (2 more to come in the next 2 weeks 
(if I remember correctly)) talks about capability security. I think 
they're highly educational, interesting and anyway important to widen 
ones view on security issues we face nowadays. Highly recommended. 
:-) (best to download the Google Video player and watch them by downloading 
them)

I got an error in the 'sql func ...


** Script Error: length? expected series argument of type: series 
port tuple bitset struct
** Where: switch
** Near: *bind-text sid i val length?

the database is opened with /direct refinement.

The call is:
	sql ["select * from person where guid = ?" guid1]


Where I know, that the dataset with this guid exists, because I have 
just got it from another selsct.
The dataset contains only strings, some of them empty.


Well, this is it: ["h-o-h.org_20060326_182311691_1224" "Urte" "Hermann" 
"Urmeli" "" "" "" "" "" "" "" "" "" "" "Opera ID: 359" "" "" ""]

And I am using the right guid.

Any ideas?

So, the error in one small message: 

>> sql ["select * from person where guid = ?" #"a"]

** Script Error: length? expected series argument of type: series 
port tuple bitset struct
** Where: switch
** Near: *bind-text sid i val length?

From his blogs it appears that Carl is just extracting SQLite's btree 
and indexing engine, but leaving out the SQL stuff that duplicates 
functionality already in REBOL (think blocks and series functions). 
You may be able to access the data (a little unlikely), but it won't 
be SQLite support.

ports - the basic idea is that ports stay as series abstraction, 
and we add device! for things that are not series (think of them 
as AmigaOS devices). no more details are available and this is still 
subject to change so don't take my words as an announcement.

IMHO, more importantly this should happen when used with series: 

f: func [/blk = [] ] [append blk "a" probe blk]
f
==> ["a"]
f
==> ["a"]

If the inserting is the problem, then I might be able to fix that 
with copy to another series in stead. Problem with insert is, when 
you have large series, it has to move the content down the memory.

the dataflow takes care of calling any aspect which are built up 
from linked nodes.  basically, you build up a stylesheet by connecting 
nodes together and can branch off at any point, simply reusing the 
previous styles as a base... the cool thing is that the styles aren't 
absolute, you can define more than one style for a single state, 
so that a series of nodes can handle only the edge, others the color, 
yet you can include both in another style  (in my case, the base 
style has both)

btw, I am now building up a series of sample files for use as a tutorial 
as you guys ask questions and post examples.  so from now on, most 
of the question will be compiled into a great collection, used for 
an eventual tutorial!


so keep the questions comming.  independent and explicit code examples 
like the above are excellent.

I'm thinking this is not a good error to get ..

Script: "Untitled" (none)
## Error in [task-handler] : Make object! [
    code: 316
    type: 'script
    id: 'no-memory
    arg1: none
    arg2: none
    arg3: none
    near: [insert tail series :value]
    where: 'append
] !
/

Oldes, thanks, I've made a minimal url-encode function (due to lack 
of time). I'll wrote a better one for the next release. Not sure 
what approach is faster, changing the argument series or building 
a new one...will test that.