World: r3wp

and they are dirt cheap. I have though heard from a friend who bought 
the latest version, that his is equipped with VXWorks, not Linux

Linksys have a tendency to revise their products over time, give 
them the same name, but with cut down hardware and software. therefore 
it's always preferable to get older access points

imagine a beowulf-cluster of these :))

yeah, well I don't think they are ultra fast (and there is only one 
ethernet port on mine), but I think you can do some bizarre stuff 
with them, such as cron scheduled downloads to an ethernet harddisk. 
I've always thought that REBOL could really do a lot for hardware 
at that level.

a /base needs <1mb AFAIK.

it's kind of sad to see its standard firmware version only have the 
possibility to load stats up slowly on a webpage. I did something 
that could poll it through telnet for signal strength in realtime. 
Way more useful.

basically it's stuff that can easily be done to increase the value 
of the access point. Linksys could easily sell a fully pumped up 
version of the same access point with loads of bells and whistles 
(firewall, VPN, realtime stats, SSH access) for 3-4 times its current 
price and still be cheaper than competition. the hardware is really 
underutilized

there is a third party vendor who provides alternative firmwares 
with these features. the only limitation is the amount of RAM and 
the ROM space isn't big enough to hold all the features simultaneously

rebol could download the code from the client. could be signed maybe.

and display stats in some dashbopard-thingy. Maybe if CArl makes 
another holiday and sees this thing accidentally :)

someone ought to send him such an access point. I can't imagine that 
it would take more than a days work to compile it for that hardware

somebody do something! :-)

Personally I think the wireless market and the networking market 
are very difficult to takle correctly. It is a commodotized market 
which means people don't care for the features and they don't pay 
too much extra for those, they just bargain best price. Which keeps 
going down. At least that is our experience with our routers.

How can I add a value to a read/custom post query?? ie.. 

xyz: "bob"


read/custom http:/theurl/x.cgi [POST "fname=bob&lname=jones&value= 
XYZ"]

where XYZ is the word??

use 'reduce

or compose

or ...

I think Linksys have moved away from Linux now as it was GPL.

I get errors with [POST.. ] no matter what I try

reduce [ 'POST  join "fname=bob&lname=jones&value=" word! ]

ahh, ok.. didn't use the ' with post

this works.. 

result: read/custom http://squigglz.com/update.php[post "user=&pass=&squiggle=sandbox-ip&val=23.43.234.000"]

but this doesn't??
user: ""
pass: ""


result: read/custom http://squigglz.com/update.phpreduce ['post 
"user=" user "&pass=" pass "&squiggle=sandbox-ip&val=2
3.43.234.001"]

Ok.. figured it out.. needed to 'rejoin' the query first, then 'reduce' 
it with POST later.. see the ~Framewerks~ group for the Squigglz/Rebol 
Dynamic Naming System..

My example did show that join or similar was required.

Jaime, why not treat the marketing differently.  Instead of marketing 
as a wireless router, market as a wireless chat server, or mp3 server 
with router facilities ?

I lot of people don't have the technical savy to do these things 
.. so you create a wireless appliance for specific purposes.

hmm... I can't seem to figure this out:

>> w: copy reduce [make object! [test: 27]]
>> set [y] w
== [make object! [
        test: 27
    ]]
>> probe y
make object! [
    test: 27
]


This part is ok. Now I want to add new keys to the object. How do 
I do that while keeping the reference to the W block?

I can set existing keys:

>> set in y 'test 35
>> w
== [make object! [
        test: 35
    ]]

>> set in y 'test2 127

** Script Error: set expected word argument of type: any-word block 
object
** Near: set in y 'test2 127

Can't do that.

>> set y make y [test2: 127]

Then I lose the reference to the W block.


Y is a point I use in a large object which I traverse. It contains 
smaller objects and these smaller objects must sometimes be updated. 
The position is remembered with Y. I want to MAKE objects there without 
losing the reference to W.

Well, to start with, your original REDUCE is already doing a copy 
for you - so no need to copy again.

Maybe you meant:    w: reduce copy [make object! [test: 27]]

(either way, actually makes no difference here...) 
You can't currently extend an existing object.

We were talking about adding that to rebol recently, though.

The way to extend an existing object is not to use an object. :) 
 Use a block, instead. (Or a block inside an object.)

What are you using this for anyway ?

You cant extend objects in place. sadly. Carl says its only a little 
change in the code, but is unsure if it is a good idea. switch to 
blocks or keep the objects in a hashtable and reference them by name. 
Or use a mix, some fixed fields and a block for the extensible part.

crap... oh well


anton, W is really a big object block with many nested objects. I'm 
building a list of relations, so I can relate words and numbers to 
eachother in a database

can't you use the object as a template to create a new object with 
the new field and then copy it back again?

Well, that's what I do when I need to extend an object .. though 
it's not in place.

the point is, I need the position to copy it into. The position is 
automatically and elegantly referenced by Y and can be a lengthy 
calculation, if I need to find it again, but I may need to do that 
or make some other position marker which contains the block that 
holds the object I need to change.

You could do it indirectly. 
obj: reduce[make my-object]
and always access with obj/1 .
then extending with 
  obj/1: make obj/1
not really nice too. We write a RAMBO-request?

volker, that doesn't work here? I lose the reference immediately 
when doing obj/1: make obj/1

its not my typo? must be with block,
obj/1: make obj/1[]

i test it.

I anticipated that

thought so. was to easy :)

!>>obj: reduce[context[a: 1]]
== [make object! [
        a: 1
    ]]
!>>obj/1: make obj/1[b: 2]
!>>probe obj/1
make object! [
    a: 1
    b: 2
]

But the obj/1 must be on every access, and bindings are still lost.

yes....

>> w: reduce [[test 1][test 2]]
== [[test 1] [test 2]]
>> set [y] w
== [[test 1] [test 2]]
>> y
== [test 1]
>> y/test
== 1
>> y/test: 100
== 100
>> w
== [[test 100] [test 2]]

>> c: context [test: none]
>> b: reduce [in c 'test]
== [test]
>> reduce b
== [none]
>> c: context [test: 1]
>> b: reduce [in c 'test]
== [test]
>> reduce b
== [1]
>> c: context [test: 2]
>> b2: reduce [in c 'test]
== [test]
>> reduce b2
== [2]
>> b
== [test]
>> reduce b
== [1]
>> reduce b2
== [2]

The first of the two examples above shows how to use path notation 
to select and change values in a block.

The second of the two examples above shows how to use a "throwaway" 
context to store new words in, then to reference these words from 
inside a block.
Both examples are showing how to use blocks instead of objects.

One of the advantages of objects is the convenient path syntax to 
get to a value. Hopefully, the above examples show how this can be 
done with blocks.