World: r3wp

Yep, that'd be the surest...

oups, to late

Searching for tabs and newlines would not be necessary in this case, 
but yes.

Be concise Steeve :)

Wouldn't work for the Rurl value though...

huhu

seems this works... parse/all test  [thru "area=" copy new-area some 
terminator to end (if debug? [print new-area])]
where   terminator: complement charset ["?" "&" " "].
In my earlier tests I didn't use the complement!!

Go thru the GET, thru the first ?, then process every variable seperately, 
especially of you allow unencoded strings for some variables.

The value of the Rurl parameter is an unencoded string by the way.

yes, that was another issue I was going to need to tackle... I did 
some searching and couldn't find how to encode it easily.

If it's consistently the last value, that makes it easier...

If you require that the argument value that is not url-encoded be 
the last, you can just do a to end or whatever the string terminator 
is.

In this case that would be "

Be sure to parse the whole get line - otherwise you might miss (or 
catch) maliciously crafted calls to your site.

@ Chris:  trying to accomodate variable placement within the string, 
but I can see that this can be a problem with the Rurl parameter.

thanks for the input guys.

I'm pondering attempting a PARSE lecture here on Altme;  It'd be 
run twice, 9am EST, 9pm EST (or somesuch)  Topic would be dialecting. 
 I want to see if it would work, but I'm no where near a professor 
level rebol.  So, think of it as a kindergarten lecture, as a trial.


Plan;  Post this message - see if there is feedback.  Allow for some 
Q&A time for specific topics of interest.  A week or two later, run 
a hour (probably less) of monologue (interruptions allowed for stuff 
that is just plain wrong ... but other than that participants would 
be asked to hold off on questions).  Followed immediately with a 
Q&A, complaint, correction session.  Then a DocBase page created 
with a merged transcript of the two timezoned lectures, things learned 
and hopefully something along the lines of a simple file management 
(or some such) dialect source code file.  R2 related - for me the 
R3 DELECT still hasn't sunk in.  If it works, then perhaps it could 
become a semi-regular activity...there is going to be a lot to discuss 
come "link to the rebol.dll" time.

sounds good

If it is not supposed to be interactive, you could as well prepare 
it in a form of DocBase article, and then run the session ...

Petr; true.  It is meant to be interactive, but after a monologue 
phase.  I worry a little bit as I have a sad tendency to be "almost 
right" with REBOL so I'd want the material vetted over before unleashing 
it on the innocent.

As 'the'  newbie !! I'd 'Pay' for that! ;-)

That would be great.

Ok; I'll accept a class size of as least three as enough to make 
it worth continuing.  please be advised; The teacher can be a complete 
moron every second or third minute so the participants will be asked 
to take any knowledge gained as "maybe correct".  :)  I hope and 
expect that any semi-correct information will be fully corrected 
by the community before the information leaks too far afield.  Raising 
parse takes a village.

Can you let me know what time in th UK the lecture may be ?? Ta

Yeah; I'll work out two time slots;  still leaning toward 9am EST, 
-5 hours on GMT, and 9pm.  On a Saturday/Sunday.  
More to come.

Poll re lecture;  How many people "get" pattern matching?  The whole 
success, fail and backtracking over alternates thing?  Does the class 
start with that level of description or right into parse?

I would be most interest in parse info.  My big interest is how parse 
can be used in conjunction with domain specific languages, but realize 
that might be scope creep.

Nope on the creep;  A DSL will be the outcome of the lecture.  I'm 
leaning either toward a password management dialect or a (simple) 
file management command set.

great, looking forward to it

A bit related, which might be a help in understanding parse in any 
way:

I want to know. how fast rebcode is at emulating CPUs, so I'm developing 
a 6502 assembler using parse and want to emulate the 6502 CPU using 
rebcode at a later time. When the assembler is more finished, I'll 
release it with a GPL license. It's basically a bunch of parse rules.

James is getting into Forth, and I was just looking at some old notes 
I made on ForthR (play on "further"), where the machine primitives 
are actually a little REBOL VM/emulator, rather than ASM for a specific 
chip. Easier to get started, though not real Forth.

I've always thought we should have examples of how languages can 
be implemented in REBOL.

I have the figforth assembly code for the 6502  ... so you could 
run fig forth on your 6502 emulator ?

Yeah, let me see where I put that... :-)

I'm not really sure. First I do a general 6502 assembler and emulator, 
but I only have an emulator of the BBC homecomputer to test up against, 
so I probably have to deal with some Operating System stuff too. 
I operate with a 64k address space, and on the BBC writing to some 
certain addresses made something special for that platform happen. 
But let's see, what we can do.

slightly off topic: who was it that wrote a z80 emulator with embedded 
space invaders?

Steeve, and it was Galaga.

there should be some follow up on it. it's been forgotten a bit

I'm not sure that it would be a good idea to make new rebcode projects 
until rebcode is reintroduced, unless the purpose of the project 
is to provide reference data for the redesign of rebcode.

yes something like that. I wouldn't expect it for a second to run 
on R3, even if Rebcode goes in. but I think it makes a good chuck 
of code for rebcode testing.

I had the impression, that it was most the names of the rebcodes, 
that would change. Then it should be too much work to port existing 
rebcode over.

shouldn't

Remember: Rebcode redesign. Lots of legacy code is not a good idea 
unless noone has a problem with it not running on the new version. 
There are a lot of problems with the current design, and it seems 
likely that there will be changes to the semantics, not the names.

The current design doesn't provide that much of a speedup over regular 
R3 code, mostly because of the stack variable change.

ok

I'm on the parsing assembler part, so no rebcode yet here.

So... the trick in RebCode for using it in R3 is how to efficiently 
access variables.

In R3 variables are more protected than in R2.  But, perhaps we can 
do something with temporaries on stack that require fewer tests, 
but have limited usage patterns.

But weeee want RebCode. Hopefully it comes. Even if slower than R2 
version. We will see - maybe C based plug-ins and proper porting 
efforts have more sense, dunno ...

I finished v. 1.0.0 of 6502 assembler: http://www.fys.ku.dk/~niclasen/rebol/language/asm6502.r

It defines the asm6502 function, which take 6502 assembler as text 
input and produces 6502 machine code (opcodes). Might be a good example 
of parsing in REBOL.