AltME groups: search

That forces you to basically build a map of the numbers before you 
start drawing the lines :(

So this line here: "w [j: d ++ n] [ro g [x j y j]]" is that building 
of the initial coordinate map.  It keeps incrementing n, and passing 
it to the "d" function which returns either the coordinate pair where 
that digit resides (or none if the digit could not be found).

So the issue we discussed about needing to build the map ahead of 
time is taken care of right there.  After this step, G is an ordered 
series of two-element blocks... each with two integers, the coordinate 
pair of where that dot is.

Although this bunch is in flux, I tried making [^ foo] map to [to-string 
debase foo].  This means S^"badfjakshdg--" (or whatever) will give 
you the un-base-64'd string.

Oh my, SVG, what a pain...
Some strange bugs, i can't figure...

As you can see here http://sites.google.com/site/rebolish/test-1/lizard-grad-err.png

I've got some problems to map correctly the gradients on the shape 
they are supposed to cover.

i can't figure why the coordinates of the gradients in the SVG file 
are wrong.

It's not clear (http://www.w3.org/TR/SVG11/pservers.html#Gradients) 
where the gradients should start....

Ashley would you be so nice and write a little bit about indexing 
in RebDB? Do it work automatically  for all columns, or may the indexed 
columns be presetted? what in memory representation do you use (map, 
list, block?). Is indexing done automatically during insertion, or 
is it indexed by search? THX IA

how can I remove an entry from a map! in R3? BTW, I use string! (not 
word!) as index here, so I cannot just say:  my-map/my-word: none

Jerry: try my-map/( my-string ): none

like with rewrite module in apache .. I would need to map www.url.com/country/city/place 
to get params for example, or somehow get that directly so that some 
rsp would be called for all such folders and I could parse the url 
to get the data

this solution with 404 also gives me the "exclude" option that I 
needed so I don't have to have some additonal map but only www.some.com/country/city/place

... CSS, database access, acting as a proxy to servers, JQuery, Google 
map integration, Amazon S3, OpenID, AtomAPI and other RSS integration, 
Delicious... man, i HATE that stuff.

Brian: I can't see how my code would be more optimized with map than 
hash (but I'm not a map! expert). For example, mime types lookups 
are made using a 1<=> N flat structure stored in a hash!.

make hash! [
	image/bmp	bmp
	image/gif	gif
	image/ief	ief
	image/jpeg	jpeg jpg jpe
	image/png       png
	image/tiff	tiff tif
	...
]

How can map! handle this easier than hash!? (looking up a mime-type 
based on a given extension)

doc, on windows, its easy because we can load and map functions on 
demand.  the only complexity is to build a proper structure dialect.

I'll think about that in the next release. I have plans to improve 
the 'validate function to be able to specify more constraints. What's 
missing the most currently is an efficient way to map a list of words 
to a database record (especially for writing).

any map example code kicking around?

http://reboltutorial.com/blog/map-reduce-functions-in-rebol-towards-massive-parallel-functional-programming-part-i/

MAP is fairly easy.

Do you have an map-each example to try the problem above Henrik?

that shows key/values pairs using map-each

not sure how to apply that to map-each, though.

ok.. loaded up my map.. anyway to probe this thing?

(back from core :)

some nice results with map!


>> length? n  ; n is a map containing random keys, and a 25 byte 
string value
== 2000000


loadit 1000000  ; loads in an additional 1m key value pairs (same 
as others, and returns execution time
== 0:00:9.27  


test3 1000000   ; test3 is a function that GETS the value of a particular 
key 1M times, returns the last iteration's value (!string),  returns 
execution time
this is a bit of a string
0:00:01.616

That is blazing, nearly 10 times faster than Redis

Terry: map! uses a hash map, you would have similar results using 
hash! in R2. A hash map is as far from a NoSQL database as, IMHO, 
a NoSQL database is from a RDBMS ;-).

A hash map is far from a NoSQL DB.. unless you're magic. I have a 
method that's working fine, now looking for the fastest key/value 
datastore i can find that's easy to work with.

Or doesn't that make sense? It would be MAP, of course

Is the app-init.r file the place to map a template file (.html) to 
a mirror .r file? If so, we could use the response/buffer to have 
access to the dom. I tried to use the app-init.r file yet it did 
not work for me.

What need for clean templeting is access to the html source file. 
I'd use the element ID to match with a backing .r file variable / 
component model. No scripting, no tags in the html file. So the question 
is, how can cheyenne let me map these two files?

/Library component is needed on UNIX (including OS X) to map: set-uid, 
set-gid, chown, kill and get-pid

Carl has introduced 'access-os native in 2.7.8 to map internally 
all those external dependencies, I haven't tested if it was available 
on OS X too, doing it now...

APPLY and MAP-EACH, so far.

yeah, but you still have to put the code behind.   the web-api mod, 
provides an interface automatically based on what is actually being 
served.  you could easily build a little WSDL to REBOL api file converter. 
 just load the XML, extract the methods, the parameters and build 
an equivalent rebol function stub.


Then all you'd have to do is implement the function body....  the 
only detail is the xml datatype which don't all map 1:1 within rebol, 
but that can usually be pretty well cornered within the code itself.

hmm... how can i map a directory under a certain path in vhost? im 
trying this:
yp [  root-dir %~/p/ob/yp  alias "/public" %../public/ ]

then for curl http://yp:8080/public/angular-0.9.15.min.js  i get

HTTP/1.1 301 Moved Permanently
Location: /public/angular-0.9.15.min.js/

wtf?

i remember seeing something like "/some/path" [ options ] in a vhost 
config block, but i can't find anything about it now

which part of this code might cause the - otherwise not very informative 
- error above?

  parties: map-each f read db [to-object load db/:f]

My first though is to have a map (an image) of countries where each 
country has its own color (call it a color-map) and another map of 
the same size that you display (diplay-map).
Then you have a block of pairs [country-name country-color].
So like this you have a relationship in any sense.


Click the displayed map => find the corresponding pixel in the color-map 
=> find the country name in the block.

To know the edge of the country you want to fill, just find all the 
pixels of this same color in the color-map and poke the corresponding 
pixel on the diplay-map.

yes, a precolorized map would make things simpler. thx didec...

map-each

offered by:
	TomBon
Task:

 R3 - Bindings for a KNNL - SOM (Self-organizing map) /Kohonen Network
	http://knnl.sourceforge.net/

	API - http://knnl.sourceforge.net/html/index.html

	Further Readings:
	http://en.wikipedia.org/wiki/Self-organizing_map
	http://www.ifs.tuwien.ac.at/dm/somtoolbox/
	http://accu.org/index.php/journals/1378
	http://www.codeproject.com/KB/graphics/som.aspx

	Alternativ:
	Quick Tutorial on how to construct a SOM.
	Perhaps to create a modul directly in R3?
	http://www.ai-junkie.com/ann/som/som1.html


Amount:
	$350
Valid until:
	01.04.2011
Terms:
	PayPal

Heck, 2.7.7 uses two functions that generate and run code at *runtime*: 
APPLY and MAP-EACH, both native in R3.

Is that if i map a port at system/ports/output, I can redirect all 
the output (print, probe etc...) ?

Maybe adding a strict-map! datatype that would raise an error for 
path accesses could be a solution?

At least in my typical usage scenarios, a get from a map far more 
often than I put into a map.

Not necessarily - most map usage with non-word keys tends to not 
use literal key values. Case-sensitivity wouldn't affect word keys 
(your m/a vs. m/A) so it would mostly affect data that can be kept 
binary end-to-end, if necessary. Still, I wouldn't mind case-sensitivity 
as an option, as long as there was a syntactic way to specify that 
option. No, MAKE can't have a refinement.

I'm in favor of a strict-map! type, if my support counts.

If the number of types is an issue, I personally would rather prefer 
it the other way round. Having a case-sensitive map per default and 
having the user use LOWERCASE on keys if case-insensitivity is desired.

Yeah can't use different case names in map.

Just collected the short name for all the files using dir/x and then 
you can create a map for all of them.

REMOVE-EACH and MAP-EACH already have the BIND/copy overhead though.

Binding: foreach, repeat, remove-each, map-each
Not binding: forever, loop, while, until, forall, forskip

btw, map-each is a burden, adding blocks by default.
Should be an option:  'map-each/only' to insert blocks,
Like other actions creating blocks do.

Not unless the closure has no arguments, but it doesn't hurt enough 
to get rid of it. On the other hand, we should probably get rid of 
'self binding from FOR, REPEAT, FOREACH, MAP-EACH and REMOVE-EACH 
(it's already been reported).

There are two problems we are trying to fix here:
- bug#1528: 'self seems to be reserved in closures and funcs

- bug#1529: 'self is being bound by For, Repeat, Foreach, Map-each 
and Remove-each

What if you want to emulate another language's OOP model? Or not 
do OOP at all? Or use functions like FOR, FOREACH, MAP-EACH, REMOVE-EACH 
and REPEAT in functions that are defined in an object, module or 
script? (That means every single time, btw)

this problem cannot be 

cured" by bind/no-self, since it requires the user to always know, 
how he wants to bind the words in the block, while such an information 
is already "automatically available" (as can be proven in R2)"


This is not true. In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH 
and REMOVE-EACH we don't want the hidden 'self to be bound to the 
code block, but we *do* want the hidden 'self to be there in the 
context. In case the context persists beyond the execution of the 
function, it should be like a normal object context. The same goes 
for closures. Only for functions do the contexts not have indefinite 
extent (in R3) - they are stack-relative, so don't work beyond the 
return of the function.


However, in the case of your proposal to not have the 'self in some 
contexts, there is no way to specify that option in MAKE object! 
syntax, so the user can't tell whether it is the case or not. This 
is similar to the map! case-sensitivity option - we can't do it because 
we don't have the syntax. And we don't want to have anything that 
affects behavior on non-blackbox types that we can't see in MOLD 
or MOLD/all.

Now BIND/no-self is just a proposal to make *an internal option that 
BIND already has* usable by mezzanine code (like USE). And we know 
that BIND has that option because MAKE closure! already uses it. 
And we also want that internal option to be used by REPEAT, FOR, 
FOREACH, MAP-EACH and REMOVE-EACH, the same way that it is used by 
MAKE closure!..

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

''In the case of USE, REPEAT, FOR, FOREACH, MAP-EACH and REMOVE-EACH 
we don't want the hidden 'self to be bound to the code block, but 
we *do* want the hidden 'self to be there in the context." - yes 
some may want all Rebol contexts to be isomorphic with objects, erasing 
a (perceived by me as useful) information (whether the context is 
supposed to be handled using BIND or BIND/NO-SELF, when applied on 
a block), which is present in R2, where the simple usage of BIND 
always does the right thing. It surely is a matter of preferences, 
that is why I am asking other users, what is more natural for them.

I changed my mind, self must absolutly remain in FOR loops (having 
context).
It allows rebolish tricky tricks in a nutshell.

See this one, I like it.

>> map-each [a b][1 2 3 4 5 6][copy self]
== [make object! [
        a: 1
        b: 2
    ] make object! [
        a: 3
        b: 4
    ] make object! [
        a: 5
        b: 6
    ]]

Steeve, put that in a comment in bug#1529. It's a good argument for 
keeping 'self binding for FOREACH, MAP-EACH and REMOVE-EACH, and 
then consistency would make us keep it in FOR and REPEAT as well.

map-each [a b] [1 2 3 4 5 6] [copy bind? 'a] does the same and is 
more explicit about what you want.

I.e. I can make the same arguments regarding `apply closure [x] [self] 
[42]`, which behaves differently from the MAP-EACH example.

Anyway to return the key used in a map when using find values-of 
map! ?

docs just say "not documented"
    http://www.rebol.com/r3/docs/datatypes/map.html
Use select a 'b to return the function itself
Use curecode to get the behaviour normalised :)

So the evaluation has nothing to do with maps, it's a path evaluation 
thing. You can still store stuff in a map, but as with storing active 
values anywhere you have to be careful.

yeah, ok, so its not a map thing... that is now obvious, since the 
select doesn't evaluate it..

brianH can you tell me *why* path notation evaluates map lookups?

The best would be to have complete map of what functions are available 
for what level ...

in A107... 

search-body system 'red 
== [
    'contexts/system/red: 255.0.0
    'contexts/user/red: 255.0.0
]

search-body system 'error!
== [
    'contexts/system/map: {make function! [[
    "Temporary function to catch MAP usage changes."
][

    make error! {The MAP function has been rename to MAP-EACH. Update 
    your code.}
]]}
    'contexts/system/cause-error: {make function! [[

    {Causes an immediate error throw with the provided information.}
    err-type [word!]
    err-id [word!]
    args
][
    args: compose [(:args)]
    forall args [
        if any-function? first args [
            change/only args spec-of first args
        ]
    ]
    do make error! [
        type: err-type
        id: err-id
        arg1: first args
        arg2: second args
        arg3: third args
    ]
]]}

    'contexts/system/to-error: {make function! [["Converts to error! 
    value." value][to error! :value]]}
]

with above changes, one can use search-body()  using  the paths refinement.... 
like so:

>> search-body/paths system 'error!

== [
    'contexts/system/map:
    'contexts/system/cause-error:
    'contexts/system/to-error:
]

MAP-EACH copies, REMOVE-EACH modifies, SORT modifies, UNIQUE copies, 
... yuck.

Is there a reason MAP-EACH copies?  Wouldn't it be faster if it modified?

Certainly an option. But that are not the semantics one usually associates 
with "map". In that case, "change-each" would be a much better name.

MAP-EACH that modifies would be FOREACH. Generating a new block is 
the entire reason for MAP-EACH.

1718 looks good to me.. though the name is hard to map to the effect 
it has... I didn't find a better one.

my friend was interested in comparing address ranges, which was why 
he wanted to map them to 128-bit numbers.

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots? I don't know that it's a great idea to map 
IPv6 addresses to them, or the feasibility of adding an ipv6! type. 
A utype! may be good enough, but I don't know how those are going 
to work either.

The question on tuples was related to IPv6 addresses. Just thinking 
about how the 128 bits might map into a type and syntax.

Having to convert all non-binary map keys over to binary is still 
rather stupid, but well.

Btw, in a comment to #1494 Andreas brings up the possiblilty of another 
map type with a different, case-sensitive hash function. That would 
be a possibility, whereas #1315 would not, not would #1437 where 
it was suggested that case-sensitivity be an option.

As Brian says, case sensitive map is easy to do with binary keys.

Here's my implementation of such, for anyone who needs it today). 
Improvement suggestions are welcome!
   http://www.rebol.org/view-script.r?script=r3-rehash.r

Giuseppe, part of the reason that there are no set accessors (what 
I called "properties" above) in REBOL is that there are no classes 
either, so such accessors would need to be defined on a per-object 
basis. This makes them quite a lot less useful. The other part of 
your question is that we *do* have get accessors: We use the same 
syntax for variable getting as we do for function calls, so you can 
just assign a function to a word and it will act like a get accessor. 
You only need real get accessors in a language that puts parens around 
arguments or in some other way distinguishes function calls. However, 
let's for the moment assume that you mean get-word accessors, functions 
that will still be called even if you use the GET function, a get-word 
or get-path to access the value.


But one of the main reasons is to avoid hidden unexpected overhead 
and security issues. Assignment is fast in REBOL, because it does 
basically the same thing every time (with some variation in set-path 
assignment). If we had properties, that would add overhead to every 
single assignment statement whether to a property or not just because 
we would have to check for that every time. In languages with native 
properties their compiler makes this determination and generates 
the underlying function calls. With REBOL that overhead is at runtime 
because we don't have a compiler. We could compile our own dialects 
to make set-word accessors - Gregg's COLLECT, or R2/Forward's APPLY 
or MAP-EACH do this - but it is slower.


The security issue is that at the moment assignment and get-word 
access is safe. Set-path assignment and get-path access is at least 
safe with the built-in datatypes. Accessor assignment is not safe: 
it can have side effects or unexpected overhead. If we had accessors 
then you could not safely use words that you got from unknown locations. 
We wouldn't even be able to screen for functions, which a lot of 
the mezzanine code does now. Combined with get-word arguments and 
that means that there would be no way to avoid code injection exploits, 
and thus no way to make even a secure subset of REBOL. 


Now with path syntax the behavior is (apparently) type-specific, 
so with the appropriate datatypes we can do accessor functions; .NET 
object wrappers would benefit from this, for instance. But that requires 
utypes, because there is no point to making built-in types have that 
behavior. Then for security we could just disallow utypes from a 
function that might otherwise be exploitable.

You'd think that would have to map to the ftruncate() operating system 
function

More likely a 512+MB map.

If a single R3 value slot is 128bit and a map needs two value slots 
for each (key, value) pair:
(128 / 8) * 2 * (2 ** 24) / (1024 ** 2) == 512.0

So is it about the initial sufficient prediction of programmer allocating 
enough of memory, or is there some artificial limit for the map size?

Why do guys need so large map array? Don't you remember Bill Gates 
once said, that 640KB is enough for everyone? :-)

;; Storing 2^24 in a map with 2^25 preallocated

>> dt [m: make map! to-integer 2 ** 25 repeat i to-integer 2 ** 24 
[poke m i i]]
== 0:00:33.695578
;; 1538MB resident

There must be some algorithm issue in R3 map!. When I have 21,000,000 
key-value pairs in a map, accessing it becomes very slow. Using " 
mymap/:key " to get a value takes 0.2 sec.

Initialising a map with 21M entries just took insanely long for me. 
Investigating.

On my system it had to allocate virtual memory for the process from 
the OS, and swap memory in RAM to the VM so it would have room to 
allocate the map in the working RAM. It took as long as I would have 
expected it to take given that circumstance.

An empty map! of 22,000,000 entries took nearly 1GB of RAM on its 
own, and that doesn't include memory for any strings, blocks or structures 
that you might add to the map after it is allocated.

For a single map, yes.

So maybe a 31 bits limit for a map

(http://www.rebol.com/r3/docs/datatypes/map.html)

At the moment we use SQLite and the goal is to use SQLAPI++ to map 
to all kind of backends.

Does anyone know about some cross-platform decent serial communication 
library? I miss serial port in R3. We are playing with some devices, 
and serial communication is still being widely used method. We could 
ask Carl to release it for R3, or just map some existing open-source 
library as an extension. I could start bounty on that ....

this reminded me, there should be some reb/altme map where you could 
point yourself into so we can see where we all are location wise 
.. we did this in indiegamer community and it was cool.. Then you 
can see if you can meet locally.. what was that webapps name..?

but the map still exist: http://www.frappr.com/rebol

http://www.mapservices.org/myguestmap/map/rebolers

for example actually being lua ruby or python most of their "regular" 
use  are to be merge as plugin into a host application that shares 
data with them Allowing to set up a base that will not change and 
an extention that will be faster to create ... This point is still 
in my opinion a strutural problem in rebol since in rebol data structure 
are hum ... special  and cool. 


One thing you can't do in rebol and that will miss us alot is for 
example the hability to create a ready made structure  in memory 
and map a file content directly to it. (For example in case of  "memory 
dumped files" in C ...) I could provide a detailled example but i 
think most of you saw what was my point...

thanks tom... that is a very nice real-world example I can work with. 
  

Do you understand the quick and dirty examples I gave above?  


 looking at it and without any other explanation, do you think you 
 would be able to map your example struct and would it solve all your 
 current requirements (assuming all the types are supported, of course)?


the one thing I DO NOT plan on supporting right now are unions... 
they just make a simple thing complex for no reasons... and they 
aren't that often used in the field anyways (for that very reason).