AltME groups: search

There is nothing standard when it comes to ascii.. bin version, hex 
version, oct version, binary version, windows 2k version, windows 
XP version, IBM PC version, and many others, no doubt.  I have more 
lines of code dealing with ascii, then all the rest combined :(

Didn't rain on Sunday, so Vancouver was one day short of a new record.. 
of course, it's pouring today, and probably the rest of the week 
at least.

One thing is clear - our world was not available, wifi node was down. 
So at that time, there might be some check, and the rest depends 
on engine at Safeworlds. It is just that upon the description, the 
world name should be reserved for 10 days, while it was not even 
24 hours. But it was not a problem to renew. We just re-registered 
the world, and it mapped to the data of our world, without any problem 
...

After 4 worlds are conquered, well only the rest of the universe 
remains for me... "The world is my oyster"  Roxy Music

So - do we move to Wave now, as apparently the rest of the world 
sucks? :-)

form-decimal: function [num][tmp main rest sign base][

     either found? find tmp: to-string num "E" [

              parse tmp [
                 copy main to "."
                 skip
                 copy rest to "E"
                 skip
                 mark: (sign: copy/part mark 1)
                 skip
                 copy base to end
               ]


        either sign = "-" [

                tmp: "0."

                loop ((to-integer base) - 1) [insert tail tmp "0"]
                insert tail tmp rest
        ][
                tmp: copy ""

                insert tail tmp join main rest

                loop ((to-integer base) - (length? rest)) [insert tail tmp "0"]  
                    
                           
        ] 
     
      tmp                 

     ][num] 

]

form-decimal: func [num /local tmp main rest sign base][

     either found? find tmp: to-string num "E" [

              parse tmp [
                 [copy main to "." 
                  skip
                  copy rest to "E"
                  |
                  copy rest to "E"
                  (main: copy "")  
                  ]
             
                 skip
                 mark: (sign: copy/part mark 1)
                 skip
                 copy base to end
               ]


        either sign = "-" [

                tmp: copy "0."

                loop ((to-integer base) - 1) [insert tail tmp "0"]
                insert tail tmp rest
        ][
                tmp: copy ""

                insert tail tmp join main rest

                loop ((to-integer base) - (length? rest)) [insert tail tmp "0"]  
                    
                           
        ] 
     
      tmp                 

     ][num] 

]

cons: func[left rest][
 head insert/only copy rest left
]
subst: func[new old slist /local left rest][
 if tail? slist[return head slist]
 (cons 
  subst-in-symbol-expression new old first slist
  subst new old copy next slist
 )
]
subst-in-symbol-expression: func[new old se][
 if not any-block? se[
  if equal? se old [ return new ]
  return se
 ]
 subst new old se  
]
print "10 9 8 7 6 5 4 3 2 1 0 ??"
probe l: first[ ((b c) (b () d)) ]
probe subst 'a 'b l

But together with the rest it works.

cons: func[left rest][
 if all[ [] = left [] = rest ][ return copy [] ]
 head insert/only copy rest left
]
car: :first
null?: :tail?
cdr: func[series][ copy next series ]
subst: func[new old slist /local left rest][
 if null? slist[return make slist 0] ; same series-type please
 (cons 
  subst-in-symbol-expression new old car slist
  subst new old cdr slist
 )
]
subst-in-symbol-expression: func[new old se][
 if not any-block? se[
  if equal? se old [ return new ]
  return se
 ]
 subst new old se  
]
print "10 9 8 7 6 5 4 3 2 1 0 ??"
probe l: first[ ((b c) (b () d)) ]
probe subst 'a 'b l

I think this CONS could be added to the mezz.

cons: func [left rest [series!]][

    if all [series? left empty? left empty? rest] [return copy rest] 
    head insert/only copy rest left
]

Latest CONS it takes into account that rebol has different types 
of series!

cons: func [left rest [series!]][
	if all [
		series? :left 
		equal? type? :left type? :rest
		empty? :left empty? :rest
	] [return copy :rest]
    head insert/only copy :rest :left
]

Research suggest, that intelligence and memory are mutual exclusive. 
If you remember too much, it'll have a bad influence on your intelligence. 
On the other way, the ability to forget information will mean higher 
IQ. This is in agreement with, how Claude Shannon defined informatin 
in 1948 at Bell laboratories.

The trick is to remember only the absolutely crucial information 
and forget the rest. ;-)

The work above was mostly ladislave on the call-routine and the rest 
is mine. I will probably post it to rebol.org after a few changes 
and additions to make it work in all platforms. Maybe Carl will like 
to include it by default in rebol.

Purely a matter of opinion.... or raather a couple of opinions...


Should now be immutable?  Of course not unless you want to reset 
the time on the machine for testing.


Can a timeone take the value 8:01 - not in real life at the moment 
- I  came across this odd behaviour when investigating the difference 
between mydate/zone: and to-date. I found out that there are a few 
:30 minute timezones and a couple of 0:15 (or 0:45) time zones, the 
rest were all hours.

And that of course doesn't work. The datastructure has to be like 
this in REBOL:

vdata: [	
	[- X 0.0 Z] [X 0.0 Z] [- X 0.0 (- Z)] [X 0.0 (- Z)]	
	[0.0 Z X] [0.0 Z (- X)] [0.0 (- Z) X] [0.0 (- Z) (- X)]	
	[Z X 0.0] [(- Z) X 0.0] [Z (- X) 0.0] [(- Z) (- X) 0.0]
]


Maybe it's time to make a new group about this. I'm not home the 
rest of the day (beer festival going on), but I should have something 
for others to try out tomorrow (those who's interested).

rest: [1 + 2 button 3 + 4] 
out: copy [] 
while [not tail? rest] [
    either find [button] first rest [
        append out first rest 
        rest: next rest
    ] [
        set [res rest] do/next rest 
        append/only out res
    ]
] 
?? out 
comment "or parse" 
rest: head rest 
out: copy [] 
parse rest [
    any [
        set word ['button] (append out :word) 
        | rest: skip (
            set [res rest] do/next rest 
            append/only out :res
        ) :rest
    ]
]

funny because all the rest of Linux apps works ok

ok, is it also intentional that the first line in a poly must be 
drawn by dragging the line with the mouse button down while the rest 
don't require this?

Yes, that's the behaviour in DPaint. Think of it, as a line is fixed, 
when you release the button. Then it is same behaviour with all points. 
You can also drag the rest of the lines, as the first.

ICarii, please replace "...." with the rest of what you had in mind.

>> source array
array: func [
    "Makes and initializes a series of a given size."

    size [integer! block!] "Size or block of sizes for each dimension"
    /initial "Specify an initial value for all elements"
    value "Initial value"
    /local block rest
][
    if block? size [
        rest: next size
        if tail? rest [rest: none]
        size: first size

        if not integer? size [make error! "Integer size required"]
    ]
    block: make block! size
    case [
        block? rest [

            loop size [block: insert/only block array/initial rest :value]
        ]
        series? :value [
            loop size [block: insert/only block copy/deep value]
        ]
        any-function? :value [
            loop size [block: insert/only block value]
        ]
        insert/dup block value size
    ]
    head block
]

Something I have learnt today...

I have been looking again at some of the examples I have been given 
here & now I have a bit more understanding of Rebol I am able to 
reformat the examples into multiple lines and indent them appropiatly 
which makes them more understandable for a noob like me. I needed 
enough understanding to see where one complete statement part ended 
& the next one began before I could do this. What I have learnt is 
that I should have tried harder, sooner to do this & it would have 
speeded up my learning...


I am looking at graphics today & giving parse a break for the rest 
of the weekend.

space works on elements from when SPACE is stated and then the space 
will stay that way for the rest of the layout description or until 
it's changed. If you want specific spacing between elements, PAD 
is used.

I wonder why there are no datatypes specific for networking?

In general we like our types to be more widely applicable. However, 
we have tuple!, url!, and port!. The rest can be handled by functions.

So, its just as confusing as for the rest of us, but at a smaller 
scale.

It might be easier to get this than it is to get Lisp. Lisp says 
that code is data, but it isn't necessarily so. Code realli *is* 
data in REBOL, at runtime, and the whole language is bilt around 
it. Once you get that it's amazing how easy the rest gets.

Reichart, CHAT shouldn't be a barrier to entry. We are trying to 
make it more accessible.


The key to me here is once Carl "ok"s this one thing, then the rest 
of us can "help".

It may not matter that much, but for my case that may come from years 
of using R2 and I find it easy to switch between the two. The differences 
are mainly in dialects, ports, graphics, and extensions, while the 
rest of the language is more fine tuned and more functions are available. 
Syntax differences: There are very few basic differences here.

Most of R2/Forward was added to R2 itself with the 2.7.7 release. 
The rest was added to 2.7.8 (release pending). There are some limits 
as to what R3 functionality can be retrofitted into R2, but you'd 
be surprised. Also, look at the source - it's also meant to serve 
as documentation about differences between R3 and R2, although it 
can be a bit on the advanced side here and there.

todun, I would work on learning about the design of REBOL, since 
this is one of the primary features; It's generally well designed, 
very deep and ignores conventions of other languages in that it was 
not designed to be a "satellite language" for java or some such. 
It was developed on its own merits by a person who is very difficult 
to outsmart. I've used it for a decade and there are still concepts 
in it that are beyond my intellectual reach. Once you get the basic 
design, the rest comes on its own.

then I found a very simple way to convert a unicode file to ascii 
in DOS,
TYPE my-unicode-file > my-ascii-file


This line converts the file to ascii, just non-convertable characters 
looks wierd but rest is ok.

Your example still doesn't seem to jive with the documentation.  
Reading the docs, I would expected two strings in the output block. 
 "my string" and the rest, in braces.  It has something to do with 
a double quote starting a parse sequence.   {"abc"def} parses as 
["abc" "def"]  { "abc"def"} parses as a single string as expected 
[{ "abc"def}]

ch_section: charset "0123456789."

parse/all "2.1.3 line" [copy section some ch_section copy rest to 
end] probe reduce [section rest] ;== ["2.1.3" " line"]

or something like that:
ch_digits: charset "0123456789"

r_section: [pos1: some [some ch_digits opt #"."] pos2: (section: 
copy/part pos1 pos2)]

parse/all "2.3.4 line" [r_section copy rest to end] probe reduce 
[section rest] ;== ["2.3.4" " line"]

space: charset " ^-"
spaces: [some space]
chars: complement charset " ^-^/"
digit: charset "0123456789"
digits: [some digit]
section: [digits "." some space]
sub-sec: [digits "." digits spaces]
sub-sub-sec: [digits "." digits "." digits spaces]


rules: [heading some parts done] (where heading is the first line 
of the text file]

parts: [newline | section format_section | sub-section | sub-sub-section]


format_section:   copy sec section copy rest to newline (print reduce 
[sec rest])

Any reason that the headings with one number have a trailing period 
and the rest don't?

THE docs come from pdf's that I have converted to text and tried 
to reformat by hand to hte similest form whilepreserving the structure 
of the doc. In addition to sections, sub-sections and sub-sub-seections 
there are nubered lists, letter lists, photos/diagrams, and tables 
to deal with. I thought I start with sorting out the sections and 
tackle the rest later.

in the above code the following will work:
format_section:   [copy rest to newline (print reduce [rest ])

but this fails: 

format_section:   [copy sec section copy rest to newline (print reduce 
[sec rest])

Notice, after the remove that I have reset the parse index to the 
beginning of the removed part, ready to continue parsing the rest 
of the data.

Yup. We've been working on the Parse Project article a lot today. 
The last 2 things from the REP that might make it are the THROW and 
INTO-STRING proposals, though both will need some changes first. 
The rest are covered or rejected.

I am the editor of the PARSE proposals.


It was decided that I perform this role because Carl is focused on 
the GUI work right now and someone qualified had to do it. With Carl 
busy and Ladislav not here, I am the one left who has the most background 
in parsing and the most understanding of what can be done efficiently 
and what can't. When the PARSE REPs of old were discussed, I was 
right there in the conversation and the originator of about half 
of them, mostly based on my experience with other parsers and parser 
generators. Because of this I am well aware of the original motivation 
behind them, and have had many years to think them through. It's 
just head start, really.


I am also the author of the current implementation of COLLECT and 
KEEP, based on Gabriele's original idea, which was a really great 
idea. It is also really limited. Collecting information and building 
data structures out of it is the basic function that programming 
languages do, and something that REBOL is really good at. I am not 
in any way denigrating the importance of building data structures. 
I certainly did not mean to imply that your appreciation of that 
important task was in any way less important.


The role of an editor is not just to collect proposals, but to make 
sure they fit with the overall goal of the project. This sometimes 
means rejecting proposals, or reshaping them. This is not a role 
that I am sorry about - someone has to do it to make our tool better. 
We are not Perl, this is not anything goes, we actually try to make 
the best decisions here. I hate to seem the bad guy sometimes, but 
someone has to do it :(


PARSE is a portion of REBOL that is dedicated to a particular role. 
It recognizes patterns in data, extracts some of the data, and then 
calls out to the DO dialect to do something with the data. It doesn't 
really do anything to the data itself - everything happens in the 
DO dialect code in the parens. It is fairly simple really, and from 
carefully designed simplicity it gets a heck of a lot of power and 
speed. That is its strength.


The thing that a lot of people don't remember when making improvements 
to a dialect like PARSE is that PARSE is only one part of REBOL. 
If something doesn't go into PARSE, it can go into another part of 
REBOL. We have to consider the language as a whole when we are doing 
things like this.

Here is the overall rationale for the PARSE dialect proposals:

- All new features need to be simple to explain and use, and fast 
at runtime.
- A good feature would be one of these:

  - An extremely powerful enhancement of PARSE's language recognition.

  - A fix to a design flaw in an existing feature, or a compatibility 
  fix.

  - A serious improvement to a sufficiently common use case, or common 
  error.


The reason I didn't want to put COLLECT and KEEP into PARSE is because 
it is a small part of a much bigger problem that really needs a lot 
of flexibility. Different structure collection and building situations 
require different behavior. It just so happens that the DO dialect 
is much better suited to solving this particular problem than the 
PARSE dialect is. Remember, PARSE is a native dialect, and as such 
is rather fixed.


There are some PARSE proposals that make parse actually do something 
with the data itself: CHANGE, INSERT and REMOVE. We were very careful 
when we designed those proposals. In particular, we wanted to provide 
the bare minimum that would be necessary to handle some very common 
idioms that are usually done wrong, even by the best PARSE programmers. 
Sometimes we add stuff into REBOL that is just there to solve a commonly 
messed up problem, so that a well debugged solution would be there 
for people to choose instead of trying to solve it again themselves, 
badly. (This is why the MOVE function got added to R3 and 2.7.6, 
btw.) Even with that justification those features might not make 
it into PARSE because they change the role of PARSE from recognition 
to modification. I have high hopes, though.


Another proposal that might not make it into PARSE is RETURN. RETURN 
is another ease-of-use addition. In particular, the thing it makes 
easy is stopping the parse in the middle to return some recognized 
information. However, it changes the return characteristics of PARSE 
in ways that may have unpredictable results, and may not have enough 
benefit. The proposal that has a better chance of making it is BREAK/return, 
though I'd like to see both (we can hope, right?).


Most of the REPs from Gabriele's doc have been covered. Most of them 
have been changed because we have had time in the last several years 
to give them some thought; the only unchanged ones are NOT and FAIL, 
so far. Some have been rejected because they just weren't going to 
work at all (8 and 12). THROW and DO are still under discussion - 
the proposals won't work as is, but the ideas behind them have merit. 
The rest have been debated and changed into good proposals. Note 
that the DO proposal would be rejected outright for R2, but R3's 
changes to word binding make it possible to make it safe (as figured 
out during a conversation with Anton this evening).


There are other features that are not really changes to the PARSE 
dialect, and so are out of scope for these proposals. That doesn't 
mean that they won't be implemented, just that they are a separate 
subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, 
Henrik), REBOL language syntax (sorry, Graham), and port parsing 
(sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, 
while discussing the subject with Anton here I figured out a way 
to do port parsing with the R3 port model (it wouldn't work with 
the R2 port model). I will bring these all up with Carl when it comes 
to that.


I hope that this makes the situation and my position on the subject 
clearer. I'm sorry for any misunderstandings that arose during this 
process.

paul asked: "Question for you regarding parse.  How do you force 
parse to return false immediately without processing the rest of 
the string or block one it evaluates a paren?"

convert-input: func[input [string!] /local stops rest opened-tags 
b e][
	probe input
	
	space: charset " ^-"
	stops: charset "-+^/"
	rest:  complement stops
	opened-li?: false

	parse/all input [
		some [

   () ;<-- to be able escape from the parse loop if there is any infinite 
   loop
			b: #"^/" e: (
				if opened-li? [
					e: change/part b "</li>^/" 1
					opened-li?: false
				]
			) 
			:e
			b: [
				#"-" any space e: (
					e: change/part b {<li class="minus">} e
					opened-li?: true
				)
				|
				#"+" any space e: (
					e: change/part b {<li class="plus">} e
					opened-li?: true
				)
			] :e
			| to #"^/"
			| end
		]
	]
	if opened-li? [
		append input "</li>"
	]
	input
]

probe convert-input {
- line 1
+ line 2
+ line 3
- line 4
+ line 5}

Now I see that the above example will require newline at start of 
the input. And that I'm not using the 'stops and 'rest at all:)

but is you use something like: any rest  it will give you any chars 
which are not defined in the 'stops charset

so the rule is :

headers start on new line, stop at first ":" 
all the rest is content?

The rest should/Could be spaces or PATH

I got it working. I use the following trick - I identify DOMAIN\USER:(RIGHT) 
or (RIGHT) sections first. Then I put weirdly markers around and 
catch the rest with the skip. The file is "clean", so actually what 
do I skip is either spaces, or path. I do check in emit function:

emit: does [
 if find tmp: trim copy/part p-start p-end ":\" [path: tmp]
 print [path domain user rights]
]

;--- rules - spaces, tabs, newlines

spacer-chars: charset [#" " #"^-" #"^/"]
spacers: [some spacer-chars]

;--- user-rights rules
;--- would be easier, if filesystem would not allow () ...

right-char: charset [#"A" - #"Z"]
right-rule: ["(" 1 2 right-char ")" ]

rights-rule: [r-start: some right-rule r-end: (rights: copy/part 
r-start r-end)]

;--- rule to identify user part

user-chars: complement charset {".,;:\/*}
user-rule: [copy user some user-chars ":" ]


;--- rule to identify domain - I expect it being typed in CAPITAL, 
can contain "-"
;--- the exception is "NT AUTHORITY" - contains space

domain-chars: charset [#"A" - #"Z" "-"]
domain-rule: [
    "NT AUTHORITY\" (domain: "NT AUTHORITY")
    |
     copy domain some domain-chars "\"  
]


;--- rules for combinations of: rights only (RIGHT), or DOMAIN\USER:(RIGT)
domain-user-rights: [
     rights-rule 
    |
     domain-rule
     user-rule
     rights-rule
]


parse/all str: read from-file [p-start: any [ p-end: domain-user-rights 
(emit) p-start: | skip ] to end]

I hope we get rest too ... USE, OF, LIMIT look all interesting.

Yes, that's unlikely to be implemented. He says it doesn't fit in 
with the rest. Same with n FAIL.

All PARSE needs is a few final decisions. I expect that it won't 
be too difficult to do the rest, at least the rest that won't be 
put off.

I expect that PARSE release features will be done in a89 - the rest 
will be bug fixes.

Another way to look at it is that only a few percent of our code, 
like 1 or 2 %, is ours. The rest is all ported and adapted, so for 
an operating system in its development phase, made by a handful of 
people, it's amazingly stable

It's only details that need to be improved for the new netbooks. 
For the rest the issues are the same: Syllable is simply not finished 
yet

The third release of Syllable Server has been published. This is 
an important release, because it is the first one that focused on 
making the system actually usable as a server. A number of popular 
servers were added and configured, and also several innovative REBOL 
software stacks. Out of the imaginary box, Syllable Server is now 
ready for such things as accepting remote SSH log-ins over the network, 
running a web server on the Cheyenne REBOL server, running an FTP 
server and several more. Special attention has been paid to programmability, 
with support for developing Model-View-Controller web applications 
in QuarterMaster and networking applications with the REBOL/Services 
Service Oriented Architecture. The Genode Nitpicker windowing system 
is also included. Read the rest in the full changelog. An extensive 
manual was also written, which is easy to follow. As usual, both 
a BitTorrent download (preferred) and a regular download are available 
(80 MB 7-Zip archive). Please use the torrent if you can.

The rest is just tens of kilobytes

Kaj: ok, just reading the rest of the article. i wont bother with 
this olpc guy then, probably, unless he is really enthusiastic and 
willing to figure it out on it's own mostly :)

Graham, you simply SET-SIZES MY-UNIT-SIZE and SET-FONTS/SIZE MY-FONT-SIZE, 
RebGUI does all the rest. If you then unview and redisplay you'll 
see the changes.

The other trick is telling whether a specific user has View set up 
on a multiuser system. There are still some multiuser-unfriendly 
bugs in the REBOL/View installer, mostly for backwards compatibility 
with View 1.2 registry settings. At least the file handling has been 
made multiuser safe - we'll see if REBOL 3 solves the rest of the 
problems.

Ok, I finally made it to publish all our RebGUI changes. I hope this 
helps the rest of the community. We did change a lot:

the rest is guru-stuff. cu, trying to find the diff in my ftp-client 
;)

did you incorporated all changes or are there some left out?

 I left out the number-field widget and all references to it (as per 
 Cyphre's note in the widget source). Your button changes, especially 
 the addition of a click? word, were incompatible with mine so I left 
 them out as well. The rest of the changes were merged in pretty much 
 as they are; I have not had time to review/optimize the code in depth 
 ... although I fixed a few incompatibilities that prevented tour.r 
 from working. For your reference these were the minor changes I made::


 - instead of drop-list generating an error if it doesn't get a block 
 of strings, I changed it so it forms values within a block
	- radio-group does a reduce on the data block

 - rewrote panel widget so it works consistently and doesn't require 
 /origin changes to layout

 - the detect up feel in rebgui-display was failing with requestors 
 and an invalid mouse-down-offset so I added it as an extra condition 
 of the all block

 - tool-tip-time was incorrectly initialized to now, changed to now/time/precide 
 so it works on Mac/Linux

 - renamed tooltip-bkg to tooltip-fill and made tool-bar widget use 
 these new tooltip color settings (3 in total)
	- updated tour.r radio-group labels to strings
	- added panel and input-grid examples to tour.r
	- added place-holder entries in Trac WidgetList


My primary objective was to merge these changes ASAP before the code 
had diverged too much more. I'm happy with the merged result (it 
works and there are 5 new widgets), but it's probably not well tested 
or stable enough for a bundle yet.

So no magic rebol wand to make it better than the rest ? :)

Correct, and this is why I now understand. As a new comer to rebol, 
I just find that the Word Browser should not use the term 'range' 
but something else, like 'position' in its definition. Anyways, you 
answered my question that unlocks the rest of the docs for me in 
this regards.

off putting: some parts that can be off putting for me are parts 
in REBOL 2 that are not completed, such as the GUI system (for which 
several replacements exist) and some lack of tools for debugging, 
but REBOL 3 will solve most of these problems. The rest is a joy 
to use.

But the trick is that with ANY it will only evaluate the expressions 
until it finds the first TRUE? one, not the rest. With OR both the 
expressions are evaluated. ANY and ALL are used as control structures 
too.

the wake-event function needs a few other functions which are all 
in the glayout module, but it should be easy to keep just what you 
need and run that before the rest of your script.

no, the opposite: the source code would provide the operation of 
parse in a way that makes sense to have as a model in your head. 
it would be the same as learning how the steering wheel of your car 
is connected to the wheels. if you know that, the rest comes on its 
own and you don't need to learn by rote.

I did read it, because, if you recall: I wrote half of it. The rest 
was replaced, as it turned out to be wrong and I had misunderstood 
large parts of it.

No, I don't lose the ability. I just get a much better impression 
of it. It doesn't matter how it's connected, but if you know how, 
it's much easier to figure out the rest.

don't you see all you do is endless talking about thing that don't 
mean a thing ? who cares if r3 split splits ,,, carl is gone  for 
mounth now And I won't let you rest until you take some position 
and  do something

rebol is all about carl's working 2 moth for it his ass off and letting 
the rest of the year pass by  unfortunatly for the people her  2 
moth of of carl's work is worthwhile

As for the hash (or assoc) index and list data combo, it has some 
advantages. When you are inserting and removing data a lot lists 
have a known speed benefit but the real advantage as far as indexes 
are concerned is in how lists handle series offsets (I'm using the 
word offset here because I'm using the word index to refer to the 
external hash/assoc index).


Blocks encode their offsets as a number offset from the beginning 
of the series:

>> a: [a b c]
== [a b c]
>> b: skip a 2
== [c]
>> index? b
== 3
>> insert next a 'd
== [b c]
>> b
== [b c]
>> index? b
== 3

List offsets are pointers to the associated list element.

>> a: make list! [a b c]
== make list! [a b c]
>> b: skip a 2
== make list! [c]
>> index? b
== 3
>> insert next a 'd
== make list! [b c]
>> b
== make list! [c]
>> index? b
== 4


If you are indexing your data and your data in in a block, you need 
to update your index with almost every insertion and removal because 
the references to latter positions of the block in the index will 
be invalid. With list insertion and removal, external references 
are likely to still be valid unless the referenced elements themselves 
are deleted. If you are sure to delete the reference from the index 
(or replace it with nones) the rest of the index should be OK. New 
index references can just be tacked on the end, or put into the first 
empty entry. This makes live indexes a lot more practical.


On the down side, if you are using lists and they are long enough 
to make linear searches impractical, you really do need an external 
index for them to be useful. Also you need to balance the overhead 
and complexity of keeping the indexes updated against their benefit. 
This technique is not for the faint of heart unless you can get some 
guru to do algorithms for you.

I understood it as follows - R3 will be componentised, RT keeps language 
(merely a dll), the rest is nearly open ... now the question is, 
how much is "the rest" :-)

Brian, if you are going to use a get-word for safety with the first 
value, ie.  [form :local] , then it's probably consistent to be safe 
with the rest of the data too ? eg. instead of
	insert local first data
use:
	insert local pick data 1

I'll look at the rest later. Good catch on the pick.

I would normally be on the side of dynamic break - it would be easier 
to teach, and the rest of REBOL follows that model. What would be 
the major advantage of lexical break in a non-compiled language? 
REBOL code blocks aren't really lexically associated with their control 
structures in the DO dialect, as my conjoin and delimit functions 
above demonstrate. This isn't rebcode you know.

I will agree that varargs is not the most needed for me the two that 
rank above the rest is that all functions are closures, second tail 
call optimization, and finally continuations.

the issue with learning Parse is that you have to implement everything, 
from scratch... just escaping strings is not trivial for many parse 
newcommers... so all the rest becomes such a mountain.

REST & XMLHttpRequest: This question vanished yesterday. Is Cheyenne 
REST compatible?


And, has anyone done a simple way to request an RSP page and put 
the returned content into the DOM of a current page? Or, which JS 
framework would be best to take stuff and put it into the DOM?

I don't know what is REST but I see no reason why XMLHttpRequest 
should not be possible. And I would use JQuery.

REST uses not only POST and GET but UPDATE, DELETE and INFO (IIRC) 
in HTTP requests. And I don't know if the other two need special 
treatment in the web-server or if everything is just routed to RSP 
Page and that's it.

Robert: maybe this? http://rebol.wik.is/Cheyenne/Mod-rest

Robert, that's as far as I got with mod-rest ...let me know how you 
get on.

REST: Graham's module is the only known attempt to support REST in 
Cheyenne. To be able to accept other HTTP methods like UPDATE, DELETE, 
INFO,..., its mod-rest module needs to be extended by implementing 
the 'method-support callback (to override the default 'method-support 
in mod-static).

REST: Ok, I will give it a try and let you know.

How about just creating the SID and do the rest as soon as session/start 
is invoked?

This is in -vv mode. Should I post the rest of the logs forr that 
request?

All kidding aside, BA would be useful .. it's also needed for mod-rest.r

DELETE: Is it hard to add? Adding HEAD too and Cheyenne would be 
a really nice REST application sever.

Is it possible to load a SSI page from a RSP script? I have the following 
situation:


A RSP page is triggered by a link using a virtual  REST URL. Now 
I need to return a page to the client in a way that the URL bar of 
the browser shows the virtual REST URL. The page I want to return 
is a SSI page.

ok, that is what was killing uniserve earlier... now I can rest in 
peace with that issue.

pekr, who cares if there are 2000 versions of compiled rebol out 
there.   RT's is always going to be the default, and all the rest 
will be purpose built.  at least now we can play with any other tool.

I have the following problem. Depending if I send via POST or GET 
the CONTENT is different.

1. POST: [paymethod "paypal" rest "payment"]
2. GET: [rest "payment?paymethod"]

Why this? Where is the VALUE part in the GET request?

Yes, I just checked the LOG files. My normal HTTP server gets:

[24/May/2009:06:01:36 -0500] "GET /rest-cart/payment?paymethod=ueberweisung 
HTTP/1.1" 200 56

Cheyenne gets:

127.0.0.1 - - [24/May/2009:12:58:33 +0200] "GET test.rsp?rest=payment?paymethod=ueberweisung 
HTTP/1.0" 200 56

I have a problem, that after some running time Cheyenne seems to 
get into an unstable state and my REST shopping-cart isn't working 
any longer. I got this error in the trace.log, which seems to be 
Cheyenne internal:


5/6-10:09:48.142823-## Error in [task-handler-40014] : Make object! 
[                                                                
                 
    code: 501                                  
                                                                 
                                      
    type: 'access         
                                                                 
                                                           
    id: 
'not-open                                                        
                                                                 
            
    arg1: "Port"                                    
                                                                 
                                 
    arg2: none                 
                                                                 
                                                      
    arg3: 
none                                                             
                                                                 
          
    near: [parse/all current: fourth entry [          
                                                                 
                               
            any [                
                                                                 
                                                    
            
    end break                                                    
                                                                 
        
                | "#[" copy value to #"]" skip (        
                                                                 
                             
                    append out reform 
[                                                                
                                               
                 
       " prin any [pick cat"                                     
                                                                 
   
                        locale/id? value                     
                                                                 
                        
                        mold value #"]" 
                                                                 
                                             
                   
 ]                                                               
                                                                 
 
                )                                              
                                                                 
                      
                | "<%" [#"=" (append out " 
prin ") | none]                                                  
                                          
                copy value 
[to "%>" | none] 2 skip (                                        
                                                          
      
              if value [repend out [value #" "]]                 
                                                                 
              
                )                                 
                                                                 
                                   
                | s: copy value 
[any [e: "<%" :e break | e: "#[" :e break | skip]] e: (          
                                                     
           
         append out reform [" txt" index? s offset? s e #" "]    
                                                                 
         
                )                                      
                                                                 
                              
            ]                     
                                                                 
                                                   
        ]]   
                                                                 
                                                                 
       
    where: 'confirm                                      
                                                                 
                            
] !                                 
                                                                 
                                                 
5/6-23:01:46.501455-## 
Error in [task-handler-40014] : Make object! [                   
                                                              
  
  code: 501                                                      
                                                                 
                  
    type: 'access                             
                                                                 
                                       
    id: 'not-open        
                                                                 
                                                            
    
arg1: "Port"                                                     
                                                                 
                
    arg2: none                                  
                                                                 
                                     
    arg3: none             
                                                                 
                                                          
    near: 
[unless no-lang [                                                
                                                                 
          
            id: locale/lang                           
                                                                 
                               
            locale/set-default-lang 
                                                                 
                                                 
        ]      
                                                                 
                                                                 
     
        out: make                                          
                                                                 
                          
    ]                                 
                                                                 
                                               
    where: 'confirm 
                                                                 
                                                                 

] !

probably some "kind of request" is making it problems..  do you have 
any special types .. because you mention REST (PUT DELETE maybe?)

I am trying to make mod-remark as consistent and integrated as possible 
with the rest of cheyenne.  the end goal being that you remove the 
rsp from your modules and drop-in remark instead.

10/7-15:13:14.250992-[RSP] ##RSP Script Error:                   
                                                                 
                    
                                            
                                                                 
                                         
        URL  = yogalinks.rsp?rest=addtocart 
                                                                 
                                         
        File = /var/www/cheyenne/yogalinks.rsp 
                                                                 
                                      
                          
                                                                 
                                                           
     
   ** Script Error : Invalid argument: o                         
                                                                 
               
        ** Where: to-integer                     
                                                                 
                                    
        ** Near:  [to integer! 
:value]                                                          
                                                      
          
                                                                 
                                                                 
          
                                                      
                                                                 
                               
Request  = make object! [        
                                                                 
                                                    
    headers: 
[Host "www.yogalinks.eu" User-Agent {Mozilla/5.0 (Macintosh; U; Intel 
Mac OS X 10_5_7; de-de) AppleWebKit/525.28.3 (KHTML, like Gecko) 
Ve
    status-line: #{                                           
                                                                 
                       
504F535420796F67616C696E6B732E7273703F726573743D616464746F636172 
                                                                 
                    
7420485454502F312E300D0A                    
                                                                 
                                         
}                      
                                                                 
                                                              
  
  method: 'POST                                                  
                                                                 
                  
    url: "yogalinks.rsp?rest=addtocart"       
                                                                 
                                       
    content: #{          
                                                                 
                                                            
70726F647563745F69643D596F67616D617425323045636F25323050726F2671 
                                                                 
                    
75616E746974793D6F26636F6C6F723D626F72646561757825324667726175 
                                                                 
                      
}                                         
                                                                 
                                           
    path: "/"        
                                                                 
                                                                
 
   target: "yogalinks.rsp"                                       
                                                                 
                   
    arg: "rest=addtocart"                    
                                                                 
                                        
    ext: '.rsp          
                                                                 
                                                             
   
 version: none                                                   
                                                                 
                 
    file: %/var/www/cheyenne/yogalinks.rsp     
                                                                 
                                      
    script-name: none     
                                                                 
                                                           
]