| # | User | Message | Date |
| 147 | BTiffin | Yep; Nice. Figured it out seconds after posting and trying a few other datatypes, Go Bri Go! I wish I had finished a work assignment a week earlier; I missed out on a lot of efforts the august group here has put in recently. Well done. | 15-Mar-08 15:32 |
| 146 | BrianH | A width of 0 is really an error, but not a serious enough one to complain about. That line screens for that, and just returns something that won't crash, cause a infinite loop, or even return a value of an unpredictable type. | 15-Mar-08 13:53 |
| 145 | BTiffin | Or maybe not. Never mind. | 15-Mar-08 6:57 |
| 144 | BTiffin | I know it's probably not too much of a biggy and too late: source extract function starts with if zero? width [return make block 0] block is input arg of series! extract 'a/b/c 0 returns some kind of weird empty path. I think it should be make block! 0 right? | 15-Mar-08 6:47 |
| 143 | BrianH | I'm not sure PARSE would provide much of a speedup, what with the context switches required for the code blocks. I'll try it. | 9-Mar-08 3:48 |
| 142 | Paul | I was thinking if you used the parse method with change/part you would have to probably build the rule block dynamically. | 9-Mar-08 3:42 |
| 141 | BrianH | Carl's suggestion in the blog of a temporary series could be interesting, as I said in my comment to the blog article. I'll try it, profile and see, I guess. | 9-Mar-08 3:39 |
| 140 | BrianH | FIND is pretty fast, though the CHANGE is the big slowdown particularly when the length of the before and after values are different. You would still need to use CHANGE in a PARSE version, and then you wouldn't have as easy a time of adding an /any option. | 9-Mar-08 3:37 |
| 139 | Paul | Brian, couldn't 'replace be changed to utilize parse much in a similiar manner as your flatten function? To me that would be much more efficient. I'm not sure how that would handle replacement of series values though. | 9-Mar-08 3:33 |
| 138 | BrianH | If REPLACE was changed to a native (with /any and /only options added), I would celebrate. And this is after all of the work I have done making it efficient too. Please keep the function-value feature though, because that is the most useful feature it has. | 9-Mar-08 2:39 |
| 137 | BrianH | Another problem with REPLACE is that there is an increasing number of options that are requested of it, just to bring it to parity with the natives it is comparable to, such as FIND, INSERT, APPEND and CHANGE. We have gotten to the point in its complexity where we would need to use APPLY just to add the features on the R3 version - with the R2 version we are out of luck. | 9-Mar-08 2:37 |
| 136 | Carl | http://www.rebol.com/article/0352.html | 8-Mar-08 19:27 |
| 135 | Oldes | I'm not going to rewrite my script anyway as I need rebcode to get the main speedup :( | 8-Mar-08 19:20 |
| 134 | Oldes | (if you compare with insert tail!) | 8-Mar-08 19:19 |
| 133 | Oldes | in R3 is the native append 1.6x faster, but if you think that improving replace is more required... | 8-Mar-08 19:18 |
| 132 | Carl | For R2, we need very close compatibility. For R3, less so. R3 is a chance to clean out the useless underbrush. | 8-Mar-08 19:13 |
| 131 | Carl | As Jerry recently pointed out, he used REPLACE for some Unicode strings, and gave up and aborted the code after 20 MINUTES of computation! That was just in REPLACE/all! | 8-Mar-08 19:13 |
| 130 | Paul | Carl, what about backwards compatibliity? What should be the limit? | 8-Mar-08 19:13 |
| 129 | Carl | I'd rather see us fix REPLACE. | 8-Mar-08 19:12 |
| 128 | Carl | Oldes: no, but I wonder how much speed gain we'd really see. | 8-Mar-08 19:12 |
| 127 | Carl | But, a native does not have that restriction, so it can completely deconstruct a series, operate on it, then rebuild it... an not worry about state. (Well, as long as GC is being carefully controlled during the op.) | 8-Mar-08 19:11 |
| 126 | Oldes | is it difficult to add APPEND as native to R2? | 8-Mar-08 19:11 |
| 125 | Carl | REPLACE as a mezz has the disadvantage that each action it takes on a series must be atomic (it cannot leave the series in some partial state, it must be valid). | 8-Mar-08 19:10 |
| 124 | Carl | Another area to address are mezz functions that cannot do their job very well. REPLACE is a perfect example... | 8-Mar-08 19:09 |
| 123 | Carl | And, in fact, I should point out that is the wrong measure for such an action. Instead, we should profile the performance, and make decisions based on that. | 8-Mar-08 19:08 |
| 122 | Paul | I think that is where I have my concerns is those high frequency mezzanines. | 8-Mar-08 19:08 |
| 121 | Carl | An exception to this rule is a very high frequency mezzanine. For example, in R3, a few functions like APPEND became natives. For most code, may make little difference, but it sure "feels" better. | 8-Mar-08 19:07 |
| 120 | Carl | Now, there have also been cases where the code of a mezz function would be almost identical to that of a native, so there is no benefit to using a native. For example, if the function is doing basic insert and append operations, then there's little value in the native, because it has the same overhead requirements... such as detecting string expansion conditions. | 8-Mar-08 19:06 |
| 119 | Carl | So, a mezz is a light wrapper around other functions, normally natives. However, that's not a requirement. It is ok to use mezz functions in other mezz functions. | 8-Mar-08 19:03 |
| 118 | Carl | In general, mezz functions are "helpers" -- used to make coding easier, but without losing much in performance. For example, without FUNC, you would need to write make function! [....] each time. | 8-Mar-08 19:02 |
| 117 | Carl | Paul asked: "Carl can you discuss briefly the goals you desire for mezzanines?" My reply follows... | 8-Mar-08 19:01 |
| 116 | Paul | How far back should we maintain backward compatibility with mezz functions? | 8-Mar-08 18:22 |
| 115 | Paul | Thanks Brian. I'll look into some changes for beyond 2.7.6. | 8-Mar-08 18:21 |
| 114 | BrianH | Cool stuff is not the only reason I was doing the backports. | 8-Mar-08 17:36 |
| 113 | Carl | Good to know. | 8-Mar-08 17:35 |
| 112 | BrianH | For that matter, during the course of backporting code from R3 to R2, I found three bugs in R3, and submitted their fixes :) | 8-Mar-08 17:33 |
| 111 | BrianH | Don't worry too much about R3 compatibility - we already have plenty of other people to do that. | 8-Mar-08 17:21 |
| 110 | BrianH | If you want to contribute, please do. Don't worry about micro-performance patterns unless you are willing to test first, but the algorithmic slowdowns and logic bugs will be fair game. Keep in mind though, that R2 development is a collaborative process and that R2 is a platform with legacy code that shouldn't be broken lightly. | 8-Mar-08 17:20 |
| 109 | BrianH | Paul, we will need your help too. Your own code and experience serves as another reference for us to examine, and we need the eyes. | 8-Mar-08 17:16 |
| 108 | BrianH | Sorry Henrik, but we will definitely be improving problem mezzanines in R2, and already have. The mezzanine source constitutes a largeish body of REBOL source, and going over it will give us ideas for improvement that can and will propagate to R3 as well. We have already changed some functions to natives in R3 based on usage patterns. With more usage information, we will get more ideas. | 8-Mar-08 17:14 |
| 107 | BrianH | Perhaps ALSO was not the best example. Profile first, rewrite later - that's what I do. | 8-Mar-08 17:09 |
| 106 | BrianH | If you looked at the source to ALSO, you would realize that it has only one get/any statement. Most of the work is being done by REBOL's evaluation rules, before the function is even called. And it is a native in R3. | 8-Mar-08 17:06 |
| 105 | Paul | I guess I'll stay clear then of mezzanines as I don't know enough about R3 to contribute then. | 8-Mar-08 16:26 |
| 104 | Henrik | I don't think we can do much more optimization on R2 mezzanines for multiple reasons: 1. It's time consuming and we have R3 to build. 2. We might introduce new bugs or crashes, trying to rebuild working mezzanines into natives. 3. R2 is well established. Its bug list is fairly well known. We have to be very careful with what is changed. We can add capabilities to the mezzanines to bring them to R3 level or backport some R3 natives to R2 mezzanines to iron out some functionality differences, but they will not be as fast as the R3 versions. R3 will in some cases be much faster and efficient than R2, even with mezzanines. | 8-Mar-08 16:08 |
| 103 | Paul | Yeah I know I can do that Henrik but want to know what we should do for R2 since that is what this group is about. I was going to work on some of the mezzanines and want to get an idea on what way we want to go. I chain the mezzanines if that is the way we want to go. | 8-Mar-08 16:00 |
| 102 | Henrik | If you don't want extra evaluation, you should not use the mezzanines. Study the source code for the mezzanines you use, and peel off the bits you don't need. For loops, don't use FORALL, but natives like WHILE, REPEAT or UNTIL. Use INSERT TAIL instead of APPEND, etc. Preallocate blocks and keep them around to avoid too much garbage collection. Spend time profiling the functions. But your code will be bigger and possibly uglier. | 8-Mar-08 15:50 |
| 101 | Paul | I hope Carl can chime in on what he believes our goals should be for mezzanine development. | 8-Mar-08 15:45 |
| 100 | Paul | I'm buidling a database as you know and I look at lot at performance especially when a function must run against millions of rows of data per query. I see a lot of extra evaluation that doesn't necessarily have to be incurred. | 8-Mar-08 15:43 |
| 99 | Henrik | Being small and simple has more to do with how humans manage source code, than how computers manage it. Modern PCs can throw around much bigger and heavier languages than REBOL, like Java quite fine, but REBOLers just don't like that needless complexity on the human side. Productivity, reliability and stability is a direct result of REBOL's philosophy. It must not be sacrificed for some speed increases, if it can be avoided. | 8-Mar-08 15:40 |
| 98 | Henrik | REBOL will never be as fast as C or if all functions were native. IMHO, more natives makes REBOL harder to maintain and it will be more error prone, simply due to increased code size. Sacrificing code size for speed is directly the opposite of REBOL's philosophy of keeping its source code small and simple at all costs. | 8-Mar-08 15:35 |
| 97 | Paul | Speed has more barriers in computing in my opinion than capacity does. | 8-Mar-08 15:30 |
| 96 | Paul | Indeed. ;-) | 8-Mar-08 15:27 |
| 95 | Henrik | it's a tradeoff. if you want real speed, use rebcode :-) | 8-Mar-08 15:26 |
| 94 | Paul | That is what we should focus on since we are using an interpreted language. | 8-Mar-08 15:26 |
| 93 | Paul | Speed - yes. | 8-Mar-08 15:25 |
| 92 | Henrik | speed perhaps, but not efficiency (as in code size) | 8-Mar-08 15:25 |
| 91 | Paul | Well were losing efficiency as a result in my opinion. | 8-Mar-08 15:24 |
| 90 | Henrik | one of the reasons REBOL is so small is because of mezzanines building upon other mezzanines. theoretically you can build every function as native; it would be fast, sure, but only Carl would be able to change them and the REBOL executable would be in the 5-10 MB size range. | 8-Mar-08 15:24 |
| 89 | Paul | I don't think it makes it easier to code new mezz functions but I think it isn't as efficient. | 8-Mar-08 15:23 |
| 88 | Paul | I think there is a great amount of sweeping changes that we can make to mezzanines to eliminate mezzanine chaining and uitlize more natives. | 8-Mar-08 15:21 |
| 87 | Henrik | why? | 8-Mar-08 15:21 |
| 86 | Henrik | forall builds on forskip which builds on while | 8-Mar-08 15:21 |
| 85 | Paul | Yeah, I don't think that is right and they should be changed. | 8-Mar-08 15:20 |
| 84 | Henrik | why not? there are already multiple functions in R2 that are mezzanines built upon other mezzanines. | 8-Mar-08 15:20 |
| 83 | Paul | I don't like to see for example the 'also as part of 'take. | 8-Mar-08 15:19 |
| 82 | Paul | Concerning mezzanines. 'I think we should avoid building mezzanines on mezzanine code | 8-Mar-08 15:17 |
| 81 | Carl | Updated r2-prot-http | 8-Mar-08 6:20 |
| 80 | BrianH | Cool. | 8-Mar-08 6:18 |
| 79 | Carl | Regarding prot-http.r -- The one I have here is more recent. Updating devbase. | 8-Mar-08 6:16 |
| 78 | BrianH | Submitted r2-mezz-series #385: Backport of R3's MOVE mezzanine. | 8-Mar-08 1:15 |
| 77 | BrianH | Note: TAKE and FIRST+ use ALSO. | 8-Mar-08 0:43 |
| 76 | BrianH | Submitted r2-mezz-series #383: Clone of R3's TAKE native as a mezzanine. | 8-Mar-08 0:20 |
| 75 | BrianH | I'll submit it and you can make any changes in DevBase. | 8-Mar-08 0:16 |
| 74 | BrianH | Carl, will this do? | 8-Mar-08 0:14 |
| 73 | BrianH | I think it won't crash though. | 8-Mar-08 0:12 |
| 72 | BrianH | I don't think that TAKE will work against a /direct port, but I can't be sure. | 8-Mar-08 0:12 |
| 71 | BrianH | I checked its behavior against R3's take, but I don't know enough about images and gobs to make comparisons. | 8-Mar-08 0:11 |
| 70 | BrianH | take: func [ "Copies and removes from series. (Modifies)" [catch] value [series! port! none!] /part "Limits to a given length or position" length [number! series! port! pair!] /deep "Also copies series values within the block" /last "Take it from the tail end" ][ if value [throw-on-error [ case [ not length [length: 1] pair? length [ unless image? value [ throw make error! reduce ['script 'invalid-arg length] ] last: none ] any [series? length port? length] [ either same? head value head length [ length: subtract index? length index? value ][ throw make error! reduce ['script 'invalid-arg length] ] ] ] if last [ length: negate length value: tail value ] also copy/part value length remove/part value length ]] ] | 8-Mar-08 0:08 |
| 69 | BrianH | OK, here's my first attempt at TAKE. My main questions are in image handling and error wording. Help! | 8-Mar-08 0:08 |
| 68 | Paul | Ah ok thanks Brian. | 7-Mar-08 23:20 |
| 67 | BrianH | I think it's Ladislav's. | 7-Mar-08 23:19 |
| 66 | Paul | I'm not familiar with timblk | 7-Mar-08 23:18 |
| 65 | BrianH | I've been mostly profiling code patterns rather than whole programs - it's like manually doing peephole optimization. | 7-Mar-08 18:33 |
| 64 | BrianH | That sounds great! We should decide on a profiling tool. I've been using timblk, but that's mostly because I am not aware of any alternatives that have been tested on R3. If you know of anything better, please say so. | 7-Mar-08 18:32 |
| 63 | Paul | As well as via timed runs. | 7-Mar-08 18:04 |
| 62 | Paul | I'm thinking we can at least just clean up many mezzanines. Like take the 'view function for example. We just need to clean up the code on many functions. For example, 'view could probably benefit from using case. In other words we should attempt to optimize alot of the performance of existing mezzanines. We can easily compares changes of the code to see if we get better performance via stats/evals. | 7-Mar-08 18:04 |
| 61 | BrianH | Submitted r2-mezz-series #380: - Backported new EXTRACT from R3. The new version is a little more complex, but is faster, safer, and lets you specify a default value instead of none. This function fixes a significant problem with the old EXTRACT, and was debated thoroughly on the R3 alpha list. The only change is to switch to R2-style error handling (thanks Gabriele!). | 7-Mar-08 16:23 |
| 60 | BrianH | In general, if you are going to make breaking changes or add new functions, do it in R3 first. Once the furor has died down there, then backport the functions to REBOL 2 as long as you can keep the spec and behavior the same. If you can't, then don't. | 7-Mar-08 16:18 |
| 59 | BrianH | A good example is the change to ALTER, made originally for R3. The new ALTER changes its return value to something useful: Whether the value has been added, true or false. This change was prompted by someone noticing that the old return value of ALTER wasn't very useful. There was a long debate as to what would be useful, and the new function was the result. Great. Before we could apply the change though, we had to find out whether the return result was used in any existing code. Using publically available code in REBOL.org as a statistical sample, I checked every reference to the word "alter" to see if any code referred to its return value - none did. With that information we were able to justify changing the return value. | 7-Mar-08 16:15 |
| 58 | BrianH | REBOL 3 is where the advanced research is happening. REBOL 2 has a lot of legacy code to not break, remember. | 7-Mar-08 15:42 |
| 57 | BrianH | A good set of guidelines for R2 mezzanines are... - Backwards compatibility: Don't break anything in existing functions, just add capabilities if useful enough to justify the cost. - Forwards compatibility: Look to R3 first for function ideas, and even there try to avoid adding anything still being argued about. - Generally useful: Don't add anything unless many people would use it for many applications. - Minimize redundancy (we are not Perl): If there is a perfectly good way to do what you want to do in R2 already, try that first. | 7-Mar-08 15:41 |
| 56 | Paul | I see all kinds of places to update mezzanines in 2.7.5 so I will attempt to submit them after this release since we pretty much determined to concentrate on bugs with this release and port back mezzanines from R3. So hopefully, we have this world for what lies beyond 2.7.6. | 7-Mar-08 13:54 |
| 55 | Gabriele | throw make error! if you want a function with [catch] to catch it. | 7-Mar-08 10:12 |
| 54 | Gabriele | cause-error: make error! in R2 | 7-Mar-08 10:12 |
| 53 | BrianH | Submitted r2-mezz-control #379: - Added clone of R3's ALSO native as a mezzanine. | 7-Mar-08 8:26 |
| 52 | BrianH | Submitted r2-mezz-file #378: - Added IN-DIR and TO-RELATIVE-FILE from DevBase; they have already been incorporated in R3. The DevBase versions are R2 compatible and tested extensively. | 7-Mar-08 8:08 |
| 51 | BrianH | REPLACE is getting complex enough that any more capabilities added to it in R3 may require using APPLY. The R2 version is just going to have to be complex I guess, or not improved :( | 7-Mar-08 7:53 |
| 50 | BrianH | I think that we can port the improved EXTRACT as well, as soon as I figure out what the equivalent of cause-error is in R2. | 7-Mar-08 7:51 |
| 49 | BrianH | Submitted r2-mezz-series #377: - Backported all of the stability fixes from R3 (mostly changing some words to get-words). - Backported the improvements to ARRAY and REPLACE, which could run without changes. | 7-Mar-08 7:49 |
| 48 | Paul | see from those same flags I can do: >> evals [flag1 flag2 flag3][1 "flag one" 2 "flag two" 3 "flag 1 & 2"] == "flag 1 & 2" | 4-Mar-08 0:23 |
| 47 | Paul | It isn't meant to replace case but to do what is inconvient to do in case. | 4-Mar-08 0:22 |
| 46 | Paul | you can evaluate for any combination in evals. | 4-Mar-08 0:20 |
| 45 | BrianH | That handles the CASE [ALL] pattern, but not the CASE [ANY] pattern. | 4-Mar-08 0:18 |
| 44 | Paul | You have to think in terms of base-2 when your building your second argument. But I would rather use evals then mess with a bunch of any's and all's. | 4-Mar-08 0:12 |
| 43 | Paul | Must easier to implement I would suppose depending on how many options your passing. | 4-Mar-08 0:11 |
| 42 | BrianH | Is that faster than the CASE [ANY or ALL] method? | 4-Mar-08 0:06 |
| 41 | Paul | say you have the following: flag1: true flag2: true flag3: false then you could do something based on desired combinations of the flags: >> evals [flag1 flag2 flag3][0 "default - all false" 3 "flag1 and flag2 are both true"] == "flag1 and flag2 are both true" | 4-Mar-08 0:03 |
| 40 | Paul | what about a function like this: evals: func [blk blk2 /local i r ][ r: i: 0 foreach item blk [if get item [r: r + (2 ** i)] i: i + 1] return select blk2 to-integer r select blk2 0 ] could be used for evaluation based on checkboxes and combinations of refinements | 3-Mar-08 23:55 |
| 39 | BrianH | Sorry, get-words :) | 3-Mar-08 23:50 |
| 38 | BrianH | There's a few words in the source of the other mezzanines that should be converted to set-words for safety, such as in JOIN. | 3-Mar-08 23:49 |
| 37 | Paul | COOL! | 3-Mar-08 23:49 |
| 36 | BrianH | ARRAY, REPLACE and ALTER have been rewritten in R3 - ALTER for speed, ARRAY and REPLACE for support of function values. | 3-Mar-08 23:48 |
| 35 | Paul | That is a pretty good list right there. | 3-Mar-08 23:47 |
| 34 | BrianH | We should also consider TAKE, FIRST+, and ALSO - they're natives but would be easy to make mezzanines of, if slower. | 3-Mar-08 23:47 |
| 33 | Paul | I guess replace is newer code than the 'replace in 2.7.5? | 3-Mar-08 23:46 |
| 32 | BrianH | MOVE would require some minor changes, TO-RELATIVE-FILE would require changes that have been already figured out. | 3-Mar-08 23:45 |
| 31 | BrianH | array, replace, move, alter, in-dir, to-relative-file, ... | 3-Mar-08 23:44 |
| 30 | Paul | What mezz functions in R3 are you considering? | 3-Mar-08 23:39 |
| 29 | Paul | Yeah go ahead and close it - I can't remember why word? was a problem. | 3-Mar-08 23:35 |
| 28 | Paul | testing something | 3-Mar-08 23:34 |
| 27 | Paul | Wait a minute | 3-Mar-08 23:34 |
| 26 | BrianH | I suppose so. Cool. | 3-Mar-08 23:33 |
| 25 | Paul | Disregard it Brian and we should be able to close out two Rambo tickets also. | 3-Mar-08 23:32 |
| 24 | Paul | Yes | 3-Mar-08 23:30 |
| 23 | BrianH | A literal, you mean? Rather than a reference? | 3-Mar-08 23:29 |
| 22 | Paul | just as a value apart from a set-word | 3-Mar-08 23:28 |
| 21 | Paul | just to distringuish between something that is a static value verses everything else | 3-Mar-08 23:28 |
| 20 | BrianH | Are you screening for variables, or a functions? You don't even check for paths. What do you hope to accomplish? | 3-Mar-08 23:27 |
| 19 | Paul | The valuable?: :word? function does work but I thought that was tried and produced a problem somewhere. | 3-Mar-08 23:26 |
| 18 | Paul | for example 'print and "print" would be values where as print would be an evaluator. | 3-Mar-08 23:25 |
| 17 | BrianH | Everything is able to be evaluated :) | 3-Mar-08 23:25 |
| 16 | Paul | Just to check and see if something able to be evaluated. | 3-Mar-08 23:24 |
| 15 | BrianH | What is the purpose of that function? | 3-Mar-08 23:23 |
| 14 | BrianH | You can't assign to a refinement, and a set-word or get-word is no more assignable than a lit-word. | 3-Mar-08 23:23 |
| 13 | BrianH | I misread it. Please read my second comment. | 3-Mar-08 23:22 |
| 12 | Paul | == [print 'print "print"] >> any-function? blk/1 == false >> any-function? blk/2 == false >> any-function? blk/3 == false | 3-Mar-08 23:21 |
| 11 | BrianH | Actually, that valuable? function proposal could be replaced with this: valuable?: :word? | 3-Mar-08 23:21 |
| 10 | Paul | any-function? doesn't return the same response as valuable? | 3-Mar-08 23:21 |
| 9 | BrianH | The proposal to add /only to REPLACE was more promising, though it wasn't clear if the /only should apply to the search value or the replace value, or both. What do you think? | 3-Mar-08 23:18 |
| 8 | BrianH | in the -> is the | 3-Mar-08 23:16 |
| 7 | BrianH | Honestly, I didn't see the point to that function. The only part that matters in the any-function? part. | 3-Mar-08 23:16 |
| 6 | Paul | How about this one?: http://www.rebol.net/cgi-bin/rambo.r?id=4317& | 3-Mar-08 23:14 |
| 5 | BrianH | Sounds good, but we don't really have the time for 2.7.6 to implement a whole lot of new stuff. Start first with existing functions and those from R3. There is a good chance that many bugs in the R2 functions have already been fixed in R3. | 3-Mar-08 23:12 |
| 4 | Paul | What about proposing new mezz functions here? | 3-Mar-08 22:17 |
| 3 | BrianH | If you have bugs that can be fixed by someone other than Carl, here's the place to fix them. | 3-Mar-08 21:43 |
| 2 | BrianH | If anyone has any favorite mezzanines from REBOL 3 that you want backported, here's the place to request them. | 3-Mar-08 21:42 |
| 1 | BrianH | The purpose of this group is to coordinate any delevopment or bug fixing of the mezzanine functions. This will allow those who want to work on this process to help each other instead of stepping on each other's toes. | 3-Mar-08 21:42 |