AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 43 |
r3wp | 567 |
total: | 610 |
results window for this page: [start: 301 end: 400]
world-name: r3wp
Group: Core ... Discuss core issues [web-public] | ||
Janko: 3-Jul-2009 | hm.. this would be very good to have .. and it sounds very much like data structures that Clojure has ... I think it calls them persistend data structures , like list, map, etc .. and the same as you described here. You have many versions of a data structure but they share the unchanged parts.. this highly benefits functional programming style .. you get "new" data structure each time, but without the penalty of copying it each time , and is cruicial in concurrency which is in focus in clojure, because then different threads dont's share and "corrupt" one to another the data structure , but each can have it's own revision , etc .. I am not that good in this complex stuff, but it might be very intersting to you becuase you will know much better what's he talking about and how can that be implemented .. they made some of his data structures in Factor , so they ren't impossible to make in other languages.. I don't remember exacty where I read about this | |
Graham: 3-Jul-2009 | janko .. I see drawing is not your strong point! :) Try this tool http://map-editor.s3.amazonaws.com/map-editor.exe | |
Graham: 3-Jul-2009 | To use it, double click on the blank canvas to create nodes, and double click on nodes to edit them. Drag arrows from one node to another by click and drag from the left bottom corner. Control-L to load a new map Control-S to save a new map | |
Geomol: 20-Aug-2009 | Is it possible to give a function with a refinement as an argument to another function? If I e.g. would make a MAP function in REBOL, it could be: >> map: func [:function list /local result][result: clear [] foreach value list [append result function value] >> map sine [0 15 100] == [0.0 0.258819045102521 0.984807753012208] MAP apply the function to each member of the list. But I can't give sine/radians to map: >> map sine/radians [0 15 100] == 100 Is there a way around this? | |
Sunanda: 20-Aug-2009 | You could use the MAP syntax that R3 uses (soon to be renamed MAP-EACH) map x [0 15 100] [sine/radians x] == [0.0 0.650287840157117 -0.506365641109759] | |
Geomol: 20-Aug-2009 | It seems to work, if I put DO before function: map: func [:function list /local result][result: clear [] foreach value list [append result do function value]] | |
Graham: 21-Aug-2009 | is this something that one can use 'map for? | |
Graham: 21-Aug-2009 | I thought with map you can apply a function over all the parameters ... | |
Geomol: 21-Aug-2009 | Yes, you can with map, but you want it to stop, if one item isn't found, so not on all parameters. | |
BrianH: 26-Oct-2009 | If you preallocate the result it might be faster in some cases - it should be twice the length of the UNIQUE a (or the saame length in map) | |
Paul: 19-Dec-2009 | wha tis the suffix-map in REBOL used for? | |
BrianH: 19-Dec-2009 | Oh, and suffix-map is used by the codec system, afaik. | |
Dockimbel: 3-Jan-2010 | Rebolek: thanks for the link, lots of good food for thought here. That would be great to support it at native level (using a R3 extension). I also wonder how much of it could be implemented efficiently using 'map-each and 'apply. Anyway, this could be a really great addition to R3 (or even R2). Keep up the good work. | |
BrianH: 21-Jan-2010 | People say "do it in a dialect" like those come for free. There's dialect processing overhead, issues of when the arguments are processed, decisions about whether there are keywords or not. To get an idea about the real overhead of doing it in a dialect, look at the source of APPLY or MAP-EACH in R2. Both are compiled dialects. | |
BrianH: 20-Apr-2010 | Series, or map or object. | |
Terry: 7-May-2010 | how about this.. adding a variable as key in a map ie: n: make map![] b: 4398 n/b: "42" ; where b is 4398? | |
BrianH: 7-May-2010 | Terry, try FIND VALUES-OF map value, if you can afford to trade memory overhead for the loop. | |
Pekr: 20-May-2010 | http://technet.microsoft.com/en-us/sysinternals/default.aspx... look at RAM Map, Process Manager, etc. | |
Maxim: 21-Sep-2010 | It does, for the map specifically. | |
Oldes: 22-Sep-2010 | You can always use TO-MAP:) | |
Group: !RebGUI ... A lightweight alternative to VID [web-public] | ||
btiffin: 5-Apr-2007 | Ashley; Well I'm more confused than when I started. I got sick of bad Courier and fixed it. It had to do with the order of 100dpi and 75dpi font lists and removing ghostscript font mapping. Anyway, now REBOL/View can't find Serif, Sans Serif or Monospace. The "real" names "DejaVu Serif", "DejaVu Sans", and "DejaVu Sans Mono" work in font [name: ] blocks. So, I can't help much yet. The short list (and I'll need to look into this more) is DejaVu Sans Mono for a good font-fixed DejaVu Serif for a good font-serif DejaVu Sans for a good font-sans-serif These names may be very specific to my setup...not sure yet. These fonts should map to "Monospace" "Serif" "Sans Serif", which I just broke. And after I mucked around the stock font names, which on this REBOL/View 2.7.5.4.2 18-Mar map to font-fixed = "courier" font-serif = "times" and font-sans-serif = "helvetica", all look way better now. Maybe I'll just let you get on with it, and quit mudding the waters :) | |
Anton: 11-May-2007 | Well, it would solve Robert's immediate need from real life. But it does beg for a more general solution. Maybe each iterating face can have an optional map function. | |
Ashley: 23-Sep-2007 | How hard would it be to write a LAYOUT function that will transform the RebGUI layout into a HTML page? Dynamic or static conversion? I think it's possible to map most VID/RebGUI styles/widgets to CSS and HTML with Javascript required for a few of the more complex widgets; so reproducing simple layout forms online is trivial, more complex apps with tab-panels, etc a whole lot harder. This reminds me of some of the R&D work I was doing with IBM back in the early 90's. Layouts were IODEFs (Input/Output definitions) where you hooked a data source (e.g. DB, Terminal, Webpage) to an output target (e.g. Screen, printer, Webpage) with zero application/logic changes. The entire app was stored in a code repository across a couple of simpe DB2 tables. Anyway, I digress. | |
Graham: 24-Dec-2007 | My plan ( provisional ) was to turn the PDF into a PNG, and map the widgets to the PNG. With that in mind, I know the relative displacements to the pdf which I would then turn into an EPS. I can then turn my widget content into postscript and write that onto of the eps to give me perfect printouts. | |
Ashley: 7-Dec-2008 | Map the CNTRL key to one of the freely assignable TabletPC buttons? How does he do it currently (e.g. in File Explorer)? | |
shadwolf: 10-May-2009 | rebgui-ctx.r >> system/view/screen-face/feel: none ; kill global events system (used by 'insert-event-func) the reason why area-tc will not be adapated to rebgui until ashley explain me how to map custom events for a custom face | |
Ashley: 22-Jun-2009 | Uploaded build 121 with a completely rewritten tabbing system. Tabbing into/out of tables and text-lists is now supported (you need to copy new behavior/tabbed and behavior/cyclic values across into %ui.dat). Will add remaining widgets next build plus ability to exit a cyclic widget (e.g. press a key to exit a group-box). What keystroke/combo do folks want to map the later functionality to? | |
Steeve: 11-Mar-2010 | btw, map-event crash if the event doesn't contain a gob. | |
Group: !REBOL3-OLD1 ... [web-public] | ||
Pavel: 9-Feb-2009 | For Map also limit about 500000 items was mentioned, it suggest an idea use Map in pagged manner. Ie for larger set use multiple Maps rather fixed size in the manner of cache. | |
Pavel: 9-Feb-2009 | Back to map Brian's note words-of returns all keys is easy to overlook, but this is only way how to traverse thru map (when no next is at hand) THX Brian | |
Pavel: 10-Feb-2009 | Theoreticaly empty space may be in the middle, that is question of implementation with influence to performance of course (and diference betwen block, hash, list, map etc.) | |
BrianH: 12-Feb-2009 | Yes. But not for (RE)JOIN because JOIN or REJOIN /into is exactly the same as INSERT and INSERT REDUCE. What we *do* need to add /into to is (RE)MOLD, (RE)FORM, REDUCE, COMPOSE, READ, COLLECT (needs changes), MAP and EXTRACT. | |
Steeve: 12-Mar-2009 | i make a proposal: Most of the times, we use the same rules several times on different data. reword should be able to not reconstruct the rules if so. I used the similiar tricks in some scripts, for example: map-chars: func [ {replace/all pair chars in a string} data [string!] values [block!] /local chars pos ][ ;** if the first value in values is a bitset, do not reconstruct the bitset unless bitset? chars: first values [ chars: make bitset! 256 forskip array 2 [append chars array/1] insert values chars ] pos: data values: next values while [pos: find pos chars][pos: change/part pos select/skip values first pos 2 1] data ] data: "Hello You" map-chars copy data values: [#"s" "SS" #"t" #"T"] ;** the second call is faster map-chars copy data values | |
Chris: 27-Mar-2009 | My Daylight Map used color to detect irregularly shaped hit spots... | |
Chris: 27-Mar-2009 | http://ross-gill.com/r/daylight/map.jpg http://ross-gill.com/r/daylight/map-zones.png | |
BrianH: 3-Apr-2009 | load: func [ {Loads a file, URL, or string.} source [file! url! string! binary! block!] {Source or block of sources} /header {Includes REBOL header object if present. Preempts /all.} /next {Load the next value only. Return block with value and new position.} ; /library {Force file to be a dynamic library. (Command version)} ; /markup {Convert HTML and XML to a block of tags and strings.} /all {Load all values. Does not evaluate REBOL header.} /unbound {Do not bind the block.} /local data content val rst tmp ][ ; Note: Avoid use of ALL and NEXT funcs, because of /all and /next options content: val: rst: tmp: none ; In case people call LOAD/local ; Retrieve the script data data: case [ block? source [ ; Load all in block return map x source [apply :load [:x header next all unbound]] ] string? source [source] ; Will convert to binary! later binary? source [source] ; Otherwise source is file or url 'else [ ; See if a codec exists for this file type tmp: find find system/catalog/file-types suffix? source word! ; Get the data, script required if /header content: read source ; Must be a value, not unset case [ binary? :content [content] ; Assumed script or decodable string? :content [content] ; Assumed script or decodable header [cause-error 'syntax 'no-header source] block? :content [content] 'else [content: reduce [:content]] ] ; Don't LOAD/header non-script data from urls and files. ] ; content is data if content doesn't need copying, or none if it does ] ;print [1 "data type?" type? :data 'content true? :content] if string? :data [data: to-binary data] ; REBOL script is UTF-8 assert/type [data [binary! block!] content [binary! string! block! none!]] assert [any [binary? :data not header]] if tmp [ ; Use a codec if found earlier set/any 'data decode first tmp :data ; See if we can shortcut return the value, or fake a script if we can't case [ block? :data [if header [insert data val: make system/standard/script []]] header [data: reduce [val: make system/standard/script [] :data]] (to logic! unbound) and not next [return :data] ; Shortcut return any [next any-block? :data any-word? :data] [data: reduce [:data]] 'else [return :data] ; No binding needed, shortcut return ] assert/type [data block!] ; If we get this far ] ;print [2 'data mold to-string :data] if binary? :data [ ; It's a script unless find [0 8] tmp: utf? data [ ; Not UTF-8 cause-error 'script 'no-decode ajoin ["UTF-" abs tmp] ] ; Process the header if necessary either any [header not all] [ if tmp: script? data [data: tmp] ; Load script data ; Check for a REBOL header set/any [val rst] transcode/only data unless case [ :val = [rebol] [ ; Possible script-in-a-block set/any [val rst] transcode/next/error rst if block? :val [ ; Is script-in-a-block data: first transcode/next data rst: skip data 2 ] ; If true, val is header spec ] :val = 'rebol [ ; Possible REBOL header set/any [val rst] transcode/next/error rst block? :val ; If true, val is header spec ] ] [ ; No REBOL header, use default val: [] rst: data ] ; val is the header spec block, rst the position afterwards assert/type [val block! rst [binary! block!] data [binary! block!]] assert [same? head data head rst] ; Make the header object either val: attempt [construct/with :val system/standard/script] [ if (select val 'content) = true [ val/content: any [:content copy source] ] ] [cause-error 'syntax 'no-header data] ; val is correct header object! here, or you don't get here ; Convert the rest of the data if necessary and not /next unless any [next block? data] [data: rst: to block! rst] if block? data [ ; Script-in-a-block or not /next case [ header [change/part data val rst] ; Replace the header with the object not all [remove/part data rst] ; Remove the header from the data ] rst: none ; Determined later ] ] [rst: data] ; /all and not /header ] ; val is the header object or none, rst is the binary position after or none assert/type [val [object! none!] rst [binary! none!] data [binary! block!]] assert [any [none? rst same? head data head rst] any [val not header]] ;print [3 'val mold/all :val 'data mold/all :data "type?" type? :data] ; LOAD/next or convert data to block - block either way assert [block? data: case [ not next [ ; Not /next unless any [block? data not binary? rst] [data: to block! rst] data ] ; Otherwise /next block? data [reduce pick [[data] [first+ data data]] empty? data] header [reduce [val rst]] ; Already transcoded above binary? rst [transcode/next rst] ]] ; Bind to current global context if not a module unless any [ ; Note: NOT ANY instead of ALL because of /all unbound (select val 'type) = 'module ][ bind/new data system/contexts/current ] ;print [6 'data mold/all :data 'tmp mold/all :tmp] ; If appropriate and possible, return singular data value unless any [ all header next ; /all /header /next empty? data 1 < length? data ][set/any 'data first data] ;print [7 'data mold/all :data] :data ] | |
Anton: 6-Apr-2009 | Is there any way in R3 to optimize code such as out: insert insert insert insert insert [] 'fill-pen color [text vectorial] 0x0 "hello" ? I think the appearance of n INSERTs is kind of ludicrous. People are doing this for performance reasons, so the usual way we would optimize the code (which produces an intermediate block), isn't an answer. I've forgotten if R3 has any way. (A quick look at APPLY and MAP doesn't seem to bear any fruit.) | |
Oldes: 8-Apr-2009 | Steeve.. I don't care if it's hash, map, list, block or object.. I need fast lookup for key-value pairs | |
BrianH: 8-Apr-2009 | Upped the priority. POKE of an existing string or binary map key fails too. | |
Janko: 9-Apr-2009 | but my understanding is that hash functions different than hashtables or dictionaries in other languages? and map will work that way.. or did you need the specific way how hash worked? If I used hash I used in as a hashtable (because I wasn't aware of the difference) and I could have gotten nasty errors because of it | |
Pekr: 9-Apr-2009 | Wasn't map supposed to be a hash! replacement plus/minus few differences in behaviour? | |
Pekr: 9-Apr-2009 | here's some map! doc - http://rebol.net/wiki/Map- isn't it replacement for hash!? | |
Pekr: 9-Apr-2009 | btw - we have 'map function. This is imo confusing. We sometimes use shortcuts, e.g. for make object! we have 'context. Will not users expect 'map being a shortcut for make map! ? | |
Pekr: 9-Apr-2009 | btw - it was extremly difficult to find above Map link. The DocBase structure is completly twisted. | |
shadwolf: 9-Apr-2009 | A map is an name-to-value associative array. It uses hashing for high performance. Sometimes this kind of association is also referred to as a dictionary. The map datatype replaces the R2 hash datatype. The motivation for this replacement was that some people in the user community felt the design of the older hash datatype was confusing, since it hashed both keys and their data. The new map datatype just hashes keys. Data is not hashed. | |
Oldes: 9-Apr-2009 | Again.. when talking about fonts.. I want bitmaped font support. For example I create font's for my Flash apps in Rebol using simple image where I draw pixel precise glyphs: http://box.lebeda.ws/~hmm/fonts/fixedsys.png And provide the needed informations in Rebol format: http://box.lebeda.ws/~hmm/fonts/fixedsys.png.txt(using UCS2 to map the glyphs) Then I use my vectorizer to get the Flash font format. The last step could be skiped in Rebol. And just the bitmaps could be used. So as in my Flash apps I can be sure, that the font will looks like I really want it! But first we must have the R3 core stable and opened host sources. I will wait:) | |
Pekr: 10-Apr-2009 | BrianH: don't you mind that we have 'map function, which is complatly unrelated to map! datatype? I mean - sometimes we use shortcuts - e.g. 'context for make object! ... so I thought it might confuse a bit to have map func, which does something unrelated? | |
BrianH: 10-Apr-2009 | The map! type is used extensively in the GUI, and some mezzanines. The MAP function's name wasn't my idea - some Haskell fan thought we needed a map function (true) and that it should be called the same thing (not REBOL-like). This came before the name of the map! type was chosen, and prevents us from making a proper functional map function of that name. At least we already had a fold-like function with a REBOL name: REMOVE-EACH. | |
Janko: 10-Apr-2009 | I really wanted the map punction, but I don't mind it being called anything else, I agree with pekr's reasons | |
Pekr: 10-Apr-2009 | map function is similar to apply, no? | |
BrianH: 10-Apr-2009 | I love the MAP function, but it could really use a *-EACH name since it is in that family. We're probably stuck with the name :( | |
Pekr: 10-Apr-2009 | Hmm, R3 is whole new REBOL. So far I am using at R2 level. I have my own old map func, which maps some object fields from other object. Now I need to learn how 'resolve could be usefull. | |
Steeve: 28-Apr-2009 | This is the very minimalist event handler i use to do my tests on gobs and events. then, just add your gobs into the main screen gob set 'screen system/view/screen-gob unless system/view/event-port [ system/view/event-port: open [scheme: 'event] ] system/view/event-port/awake: func [event /local gob offset ev][ ev: map-event event gob: ev/gob offset: ev/offset switch event/type [ move [...] up [...] down [...] ... ] tail? screen ] append screen make gob! [...] do-events | |
BrianH: 29-May-2009 | Quick discussion needed, and here because more people need to chime in: There is a proposal to change the name of the MAP function to MAP-EACH. Here's why: - There's a map! type, and this function is unrelated - except in CS theoretical terms, which is why we suggest the name MAP-EACH. - The other functions that have the name of a type without the ! are constructors for that type. The map! type could use one. - This function is behaviorily one of the *EACH family already. - This is *not* the functional language map function, and it might be good to emphasize that... In functional languages, functions like map take functions as parameters. However, such languages tend to be compiled and the function values they take are constructed ahead of time. Since REBOL is interpreted and functions are created at runtime, that kind of code pattern tends to be inefficient. That is why REBOL control and loop functions tend to take blocks instead, and have any argument words to those blocks as a separate parameter: It's much more efficient that way. There is precedent: The REBOL function that corresponds to the functional-langage filter function is REMOVE-EACH. We ask this question now because now is the time to make the change, if ever. Not many functions in R3 use MAP yet (the only one I can think of off the top of my head is LOAD). This will change when we do a hand-optimization pass of the mezzanines, and it will definitely be too late once we hit beta. What do you all think? Please chime in in the next couple days if you can (and have an opinion). | |
Sunanda: 29-May-2009 | Thanks for the opportunity to comment..... I'll vote yes to renaming it away from 'map. Not sure 'map-each is an _ideal_ alternative, but it is better than 'map for the reasons given by BrianH. | |
Janko: 29-May-2009 | My vote: I don't want it to be called MAP because of reasons you named.. anything reasonable else is ok... I can't decide if I like map-each remove-each *-each ... naming convention... just thinking outloud.. 1) you named fold/reduce accumulate ... if you name map/filter in similar vein they could be something like map -> transform translate alter apply ? remove-each -> filter purge ... 2) common to these functions is that they take a block of code (and a series) ... each hints about the serries but maybe more specific about them is first part - block of code (function in classic functional).... one idea for the common word that hints about do something with block of code as a rule IMHO is with map -> map-with , transform-with , ... ; remove-with filter-with purge-with ; fold-with ?? | |
Pekr: 29-May-2009 | I am OK with renaming too. OTOH I too dislike map-each, remove-each names, but not a big deal here ... | |
BrianH: 29-May-2009 | Well, one advantage for calling them something other than map and filter is that you could put functional map and filter functions in a module somewhere and not have naming conflicts. They'll be less efficient and less flexible, but at least the functional programming fans would be happy :) | |
BrianH: 29-May-2009 | The only reason the *EACH makes sense is the word parameter that comes first: foreach x data [code] -> For each x in data do code remove-each x data [code] -> Remove each x in data if code map-each x data [code] > Map each x in data to code | |
Maxim: 29-May-2009 | map-each isn't long. the 'each part is classification, and adds intent and meaning to what the function does. | |
Maxim: 29-May-2009 | map in this context is a verb. | |
Steeve: 29-May-2009 | REMOVE*, MAP* Is that not enough ? | |
BrianH: 29-May-2009 | Steeve, if you want short wording then the question is whether the MAP-EACH block builder or the MAP map! constructor would be called more often. In mezzanine code creating map! values if more frequent than the use of the current MAP function. | |
Pekr: 29-May-2009 | guys, chill out :-) How often will you use map-each so that it will irritate you? Well, I do care for naming conventions too, but I have my reservations for where imo architecture goes wrong, like using read-text, load-plugin and similar stuff .... | |
Izkata: 29-May-2009 | I prefer just "map", but if there's going to be a name change, I think "map-each" is best - not only is it consistent with foreach, remove-each, etc, it's shorter than "map-every" or other alternatives, and feels like more natural English to me. And I use my map all over the place | |
Izkata: 29-May-2009 | if nothing else, at least keep "map" in the name. Part of the reason I dislike "accumulate" for fold - it's harder to find, coming from another language | |
Steeve: 29-May-2009 | Yes, map is useful. Maxim, map this "baillon" on your mouth :-) | |
Janko: 29-May-2009 | my vote now: map-each , filter-each (isn't remove-each reverse in meaning) , fold-each (accumulate - I never know how to type this word) ... and something like find-each would also be very nice to have | |
Janko: 29-May-2009 | Steeve .. do you say this to me because of find-each :) .. I mean a fing that uses block of code to determine what to find .. like: find-each x numbers [ x > 3 ] ... in same manner as map/fold/filter work | |
Janko: 29-May-2009 | I use map reduce and seek at jsgoo and I can do a lot of stuff with those (an appy inject for dictionaries) .. let's say you want to check if users with username and password exists in a block of users: find-each U users [ all [ equal? U/user user equal? U/pwd pwd ] ] ... much cleaner and more error prone than with foreach IMHO ( and these functions show intent of why you are looping through block of users ) | |
BrianH: 29-May-2009 | Pekr, MAP-EACH (using the new name) is used in LOAD to implement LOAD [%s1.r %s2.r ...]. I don't know how it is used in the rest of the mezzanines. I mostly use it in my own code, but the version I backported to R2 as a mezzanine. | |
Janko: 29-May-2009 | can I just express humble request that if you will have something like map in "core" please also have accumulate .. they are cousins if you use one you will also the other .. (like map-reduce) :) | |
Janko: 29-May-2009 | to bad... I gues some people won't use neither map-each or accumulate , but those that will use map-each will also use accumulate, as they together give you the most usages of foreach and other primitive loops | |
BrianH: 29-May-2009 | Janko, map and fold are only efficient in functional languages that are compiled and optimized. In hand-optimized, interpreted languages iteration is *much* more efficient. | |
BrianH: 29-May-2009 | You could use map and fold to implement foreach, but FOREACH is much faster that that implementation. | |
Janko: 29-May-2009 | if I would care only for efficient I wouldn't be using compiled languages anyway .. sometimes it doesn't matter that much .. I like map/fold because they cleanly express what you want to do , you don't have to setup and update temp variables and they are expressions ( they return result) | |
Anton: 30-May-2009 | I am OK with MAP -> MAP-EACH. | |
Pekr: 3-Jun-2009 | I have to be really stupid, or I really can't understand, how renaming something = removing something? So are we going to remove 'map, just because we are going to rename it to 'map-each? | |
BrianH: 5-Jun-2009 | If we do these as mezzanine with the full R3 *EACH word and set-word syntax these become big functions, similar in scope to my R2-Forward MAP function. If we limit the words to the word! type it becomes much easier, but still with more overhead than ANY and ALL. I had put off working on these for months because I thought DO/next was needed to implement them, but I've just realized that it isn't. | |
BrianH: 5-Jun-2009 | (Soon-to-be) MAP-EACH also supports the record and set-word tricks :) | |
Maxim: 23-Jun-2009 | I could see the binding to map being usefull, it might be impossible due to the inner implementation of map | |
Maxim: 23-Jun-2009 | yep :-) I guess asking for a word in a map which isn't there returns none ? | |
Maxim: 23-Jun-2009 | to me an unbound word is a lit-word in the context of the map... | |
Maxim: 23-Jun-2009 | yep this means we can use the map exactly like in AREXX, very usefull for sparse arrays :-) | |
Maxim: 23-Jun-2009 | if you used the object's pointer in the map internally, we could use objects too, it would actually be very usefull and not that much heavy to implement. | |
BrianH: 23-Jun-2009 | Map keys get hashed when the map gets large enough. No, I don't know how large that is :) | |
BrianH: 24-Jun-2009 | The advantage of map keys is that they don't have to be the SAME? as the key, they can just be EQUAL? and the hashing speeds things up. With objects you either have a reference to it or you don't. If you have a reference, you can extend it with new fields, which can refer to the values you want to associate with the object. If you don't have a reference you need to specify a key within the object that you are searching for, and hashing won't help there, but we're going to add a mezzanine to do that kind of searching. | |
Sunanda: 25-Jun-2009 | Another update of my R2--->R3 porting adventures. Highlights of new stuff: -- pick 0 vs pick -1 -- hash vs map -- examples of version sniffing to ensure one source works in R2 and R3 (thanks to Ladislav for the method of distingishing R2 from R3) http://www.rebol.org/art-display-article.r?article=j26z | |
Sunanda: 6-Jul-2009 | It helps us map to those few (but real) areas of the world whose timezone is +/-15 offset from a whole hour. That's useful to some! | |
BrianH: 17-Jul-2009 | The problem is that an http server has the option to provite a directory of their resources, but there is no generally agreed-on machine readable format for providing such a directory, and the human readable format (a Site Map), isn't implemented on most sites. If the site you are interested in has a site map you can grab and parse that, or you can trace throuugh the links on the site and hope for the best, or you can make use of an external service like Google that has already traced through the links. | |
BrianH: 17-Jul-2009 | Most sites that do provide a site map only include a brief overview of their resources, not a comprehensive directory. | |
BrianH: 1-Aug-2009 | The REPEAT behavior sounds like an oversight - but the none argument was left out of MAP on purpose, so who knows? | |
Geomol: 21-Aug-2009 | When investigating the creation of a MAP function in REBOL 2, I found that sending functions with refinement to map required some extra work (the need for a DO). The rules about get-words as arguments has changed in REBOL 3. Maybe I should talk to Carl about it, but I could discuss it with you guys first to not disturb Carl too much. First a REBOL 2 version of MAP, that can't cope with refinements: >> map: func [:f l /local r] [r: clear [] foreach i l [append r f i] r] >> map sine [0 30 90] == [0.0 0.5 1.0] f is the function, l the list and r the result. i is an item in the list. The critical part is append r f i The function f is evaluated taking the argument i. Easy to read and understand. But it can't cope with refinements, which are seen as the path! datatype. Example: >> map sine/radians reduce [0 pi / 6 pi / 2] == [sine radians sine radians sine radians] This can be fixed by putting a DO before f. Now it works both with and without refinements: >> map: func [:f l /local r] [r: clear [] foreach i l [append r do f i] r] >> map sine [0 30 90] == [0.0 0.5 1.0] >> map sine/radians reduce [0 pi / 6 pi / 2] == [0.0 0.5 1.0] In REBOL 3, the function is not evaluated: >> map: func [:f l /local r] [r: clear [] foreach i l [append r f i] r] >> map sine [0 30 90] == [sine sine sine] Including DO just makes it worse: >> map: func [:f l /local r] [r: clear [] foreach i l [append r do f i] r] >> map sine [0 30 90] == [make native! [[ "Returns the trigonometric sine." value [number!] "In degrees by default" /radians "Value is specified in radians" ]] make native! [[ "Returns the trigonometric sine." value [number!] "In degrees by default" /radians "Value is specified in radians" ]] make native! [[ "Returns the trigonometric sine." value [number!] "In degrees by default" /radians "Value is specified in radians" ]]] To make map behave correctly, I have to do something like: >> map: func [:f l /local r] [r: clear [] foreach i l [append r do reduce [f i]] r] >> map sine [0 30 90] == [0.0 0.5 1.0] >> map sine/radians reduce [0 pi / 6 pi / 2] == [0.0 0.5 1.0] Is this ok and accepted behaviour? Will it break many scripts? (Sorry for the long post, but I wanted to be precise.) | |
sqlab: 21-Aug-2009 | This seems to work for R3 >> map: func [:f l /local r] [r: clear [] foreach i l [append r do get f i] r] >> map sine [0 30 90] == [0.0 0.5 1.0] | |
BrianH: 21-Aug-2009 | Geomol, I wrote MAP-EACH and APPLY functions for R2/Forward - both required code generation by the function. | |
Maxim: 10-Sep-2009 | so basically, you build a little module in cheyenne which does a tcp exchange to your R3 server. the R3 server maps the request to a module, returns the molded result. cheyenne then returns the value in an xml block which your ajax app did the request for. allowing multiple handlers on the cheyenne side (and an equal amount of R3 servers) would allow you to support multiple concurrent users, but you'd have to map which R3 service is being used within the cheyenne module, in order to send your tcp request to a free R3 service. does any of this make sense? | |
Maxim: 22-Sep-2009 | its like saying when I say implied, I really mean that you cannot just look at rules like they are now with a single use bblocks for many rules. it terminates somewhere later ... you must find an | statement.... which doesn't properly map to open or close something... its implied based on something else before it... [ ] are explicit. | |
Pekr: 22-Sep-2009 | Today I posted more philosophical topic, and Carl noticed it - we ares shooting ourselves in the foot. Here's what I posted: ------------------- There will always be problem with dialects, if they contain the same keyword names as REBOL functions. So we have to somehow live with that. So the question is, where to introduce new name and why, just to be different, and where to not. E.g. parse 'copy keyword has already different semantics to REBOL's one, or VID's 'at has different semantics to REBOL's one. Now can users be confused? It depends. I try to think about each dialect in the context of the dialect itself - so the only measure for me actually is, when reading the source code (or trying to understand one's), how quickly I am able to understand, what is going on? But then we could as well replace 'stay by 'save-position, 'of by 'any-of, 'if by 'only-if, etc., which would imediatelly map the meaning to what the keywords are really doing. But we are somehow mysteriosly looking for one-word-only-mantra naming convention, and I suppose it is already our style, and we will not change it :-) ... so, the topic is a little bit more abstract - it is about contexts, and user/programmer switching between contexts, and his/her ease of understanding of the code. In above case, all 'if, 'check, 'either are OK, even if their semantics is a bit different to their REBOL counterparts. | |
Maxim: 23-Sep-2009 | as long as you can detect what word is under the cursor at a given coordinate using specified scrolling, you could use the rich text directly. and then output to whatever format you want... as long as you can predermine how all the coordinates map in both systems. This last part is what just about every importing/exporting out there tries to get just right... but in the end, its never exact because coordinate systems are different, font rendering engines don't use the exact same algorythms, etc, etc, etc. | |
Chris: 3-Oct-2009 | Right, objects present a similar pain. I know for the most part, you don't want to do this. It's a very specific case - when 'parse into encounters a map, instead of returning false, it converts to a block and parses. I don't see this as touching the way map! works at all, just parse - for those occasions where it'd be useful over an old-style workaround. |
301 / 610 | 1 | 2 | 3 | [4] | 5 | 6 | 7 |