AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 237 |
r3wp | 1294 |
total: | 1531 |
results window for this page: [start: 1431 end: 1530]
world-name: r3wp
Group: Parse ... Discussion of PARSE dialect [web-public] | ||
Geomol: 26-Apr-2011 | Ah ok, then you need to convert the word to a series, for example a string, and check on last letter: parse [some word! other* stuff'] [some [set word word! (print last form word)]] | |
Geomol: 27-Apr-2011 | Think of the end of a series as an internal marker, which the user shouldn't see as an element in the series, if you ask me. | |
Geomol: 27-Apr-2011 | I think, the docs match pretty well. thru advance input thru a value or datatype You're right, taking this strictly, we should be able to advance thru the end. But this doesn't make much sense, so my guess is, most people wouldn't take this strictly, when talking the end of a series. | |
Geomol: 27-Apr-2011 | Argh, I was confused by sentences like Where do you think the cursor is after matching the [end] rule? :-) Old def. of thru: advance input thru a value or datatype New def. of thru: scan forward in input for matching rules, advance input to tail of the match Then it can be argued, the tail of end (of a series) is still the end. Or it can be argued, that thru always advance some way further (as in all cases except at end). I understand, why [thru end] not failing is confusing. (And stop saying, I should read the doc. I have read it ... in full this time.) ;-) | |
Ladislav: 30-Apr-2011 | Geomol: "Are there a set of PARSE tests somewhere, that I could test my version against?" - there are the core tests at https://github.com/rebolsource/rebol-test , that contain a couple of PARSE tests in the functions/series/parse.r section. It would be nice if you added some tests. | |
BrianH: 1-May-2011 | It seems like an error that is improperly not triggered. SET is supposed to set to a single value, not a series of values - an embedded block is a single value. | |
Dockimbel: 1-Dec-2011 | Endo: in your first attempt, your second rule in SOME block is not making the input advance when the end of the string is reached because (remove "") == "", so it enters an infinite loop. A simple fix could be: t: "abc56xyz" parse/all t [any [digit (prin "d") | x: skip (prin "." remove x) :x]] (remember to correctly reset the input cursor when modifying the parsed series) As others have suggested, they are more optimal ways to achieve this trimming. | |
Endo: 1-Dec-2011 | Doc: Thank you. I tried to do that way (advancing the series position) but couldn't. I may add some more things so I wish to do it by parse instead of other ways. And want to learn parse more :) Thanks for all! | |
Group: !REBOL2 Releases ... Discuss 2.x releases [web-public] | ||
BrianH: 26-Apr-2008 | REBOL's installer hasn't worked at all since the 2.7 series, and it never worked correctly before that, though the 1.3 series improved directory usage. Fixing the installer is on the list for the next version. | |
BrianH: 26-Apr-2008 | By next version, I mean next version in the 2.7 series. | |
BrianH: 28-Dec-2009 | It hasn't worked at all for the 2.7 series, and worked incorrectly before then. | |
Graham: 28-Dec-2009 | 2.7.7 release Call dockimbel: About CALL console window issue, the CreateProcess( ) win32 call has flags to hide the window. There just need to be set. In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE. maybe add a new refinement and let the users decide when they want to see the console window ? or maybe just /show Paul: Run is not enabled Graham Is anyone concerned that shell windows opened in Encap do not contain the correct window title? Rambo #3660 ( reported march 2005 ) Brian For me, the big question is what kind of release we will be doing: - 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing the backports and mezzanine fixes. - 2.8.0: Backporting some of the R3 native changes (function, not infrastructre), and the above. I think that the decision a long time ago was to focus on R3 as a priority, and just patch up R2 as necessary. At the very least, I would want a 2.7.7 to have a version that fixes post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3. Henrik We also need to implement BrianH's new window resize scheme. Ashley,Anton, Brian, etc ... VID fixes Graham Fixes to prot-http to support put etc. BrianH SQL_FLOAT and SQL_REAL are converted the same way, just with different sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can point you in the right direction. Henrik view/new make face [] a: open/binary/direct/no-wait tcp://:9000 forever [wait reduce [ a 0.001]] This produces a 16 byte leak when started. And when I move the window and click in it, I get a lot of 64 byte leaks. | |
BrianH: 29-Dec-2009 | Graham, thanks for copying over those priorities from R2-Beta to here. About how those choices were made and phrased: The R2-Beta world was used when we still thought of REBOL being updated more rarely, in larger increments. This is no longer the case, we are adopting the rapid release model, though more regulary than the R3 alphas. We need to shift our thinking accordingly. Rapid release means that each individual R2 release doesn't have to include fixes for every outstanding bug. We can and will triage and prioritize, and your favorite bug may be moved to the next release. Which won't be a problem because that's coming next month, or the month after. Minor point releases will not be a major deal from now on, they will be monthly occurances. The overall plan for the R2 2.7.x series is to fix what we can in R2 in a way that doesn't break things. This won't be a ground-up rewrite, as we are doing one of those already. No major model changes, just tweaks. There is a lot we can tweak though, including natives. We are trying to avoid disruptive changes that affect scripts at runtime, except in cases where things just didn't work before. Almost all code that works on 2.7.6 should continue to work - that is our goal. Don't expect broken code to stay broken though :) The 2.7.7 release will not be ambitious, we just don't have the time. The priorities are business model changes and low-hanging fruit. The one piece of major breakage from the 2.7.x series that needs fixing in this release is the installer. If you have other priority fixes that can't wait til next month, and you are willing to do the work in this week, please speak up. | |
BrianH: 29-Dec-2009 | It's been broken for so long, I no longer have the computer where I originally wrote it back in 2000 and posted it to the mailing list. It's still in my head though, so I'll collect it by Tuesday evening and start working. In brief: - I don't know about installation on platforms other than Windows. Someone else will have to chime in here. Too ambitious for 2.7.7. - Windows 2000+ support is still broken. Multi-user support is broken (same thing, really). - Folder usage was mostly fixed in 2.6.3, but the registry is still misused. Registry migration will be needed. - Non-admin installation should be possible, including user-specific file associations. - Installation was broken altogether in the 2.7.x series - it doesn't work at all, not even to 2.6.3 levels. - No-install usage of View needs better support. This means UI support too, if need be. VIew should be able to be a portable app. Keep in mind that portable app usage of directories is completely different than installed usage, and needs to be. | |
Graham: 29-Dec-2009 | 2.7.7 release Call dockimbel: About CALL console window issue, the CreateProcess( ) win32 call has flags to hide the window. There just need to be set. In the STARTUPINFO used by CreateProcess( ), just set in dwFlags, the STARTF_USESHOWWINDOW flag and set wShowWindow to SW_HIDE. maybe add a new refinement and let the users decide when they want to see the console window ? or maybe just /show Paul: Run is not enabled Graham Is anyone concerned that shell windows opened in Encap do not contain the correct window title? Rambo #3660 ( reported march 2005 ) Brian For me, the big question is what kind of release we will be doing: - 2.7.7: Patching glaring bugs in a few natives, VID fixes, and continuing the backports and mezzanine fixes. - 2.8.0: Backporting some of the R3 native changes (function, not infrastructre), and the above. I think that the decision a long time ago was to focus on R3 as a priority, and just patch up R2 as necessary. At the very least, I would want a 2.7.7 to have a version that fixes post-2.7.6 mezzanine bugs, and 2.7 series regressions vs. 2.6.3. Henrik We also need to implement BrianH's new window resize scheme. Ashley,Anton, Brian, etc ... VID fixes Graham Fixes to prot-http to support put etc. BrianH SQL_FLOAT and SQL_REAL are converted the same way, just with different sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can point you in the right direction. Henrik view/new make face [] a: open/binary/direct/no-wait tcp://:9000 forever [wait reduce [ a 0.001]] This produces a 16 byte leak when started. And when I move the window and click in it, I get a lot of 64 byte leaks. | |
Henrik: 29-Dec-2009 | well now.... I just had a crash in 2.7.6. Thought that would be a little on-topic: --------------------------- REBOL Error --------------------------- REBOL Internal Error: Invalid series width 1 was 16 (type 39) Program terminated abnormally. This should never happen. Contact www.REBOL.com with details. --------------------------- OK --------------------------- | |
BrianH: 30-Jan-2010 | Posted mezzanine changes for 2.7.8, ported from R2/Forward 2.100.80.0: - Added COLLECT-WORDS, RESOLVE, SINGLE?, IMMEDIATE!, INTERNAL!, INVALID-UTF?, CD, MORE, and the convenience words LS, PWD, RM and MKDIR. - Removed buggy binary! support from ASCII? and LATIN1?, as done in 2.100.60. See mezz-control.r #6763, mezz-file.r #6776, mezz-series.r #6772, mezz-string.r #6773 and mezz-reflect.r #6771 for the relevant changes. Details in R3's docs. Note: The APPEND and REMOLD rewrites are too awkward to incorporate without a native APPLY function. UNBIND hasn't been written yet (hoping for a native). | |
BrianH: 14-Apr-2010 | I would guess 2.5.6, the last version before the 2.6 series. Other platforms were dropped after 2.5.0 (like WinCE). | |
BrianH: 29-Apr-2010 | We switch between R2 and R3 work. The last week has been focused on R3. A week-or-so ago I made a few tweaks to R2/Forward for 2.7.8, including a backported fix from R3, and Carl put together a plan and implemented a lot of his portion of the plan. I expect that soon after the R3 a98 release, we'll have a R2 2.7.8 release. And 2.7.8 looks like it will be the first really stable release in the whole 2.7.x series, something to really look forward to. | |
Graham: 14-May-2010 | If I want to set something to the index of a series, or something else if it's not there I have to do this b: either a: find series var [ index? a ][ default ] when I'd rather do b: any [ index? find series var default ] So how about letting index? also take none as an argument ? | |
Graham: 14-May-2010 | b: any [ attempt [ index? find series var ] default ] | |
Steeve: 14-May-2010 | yep, no need for additional var. all [b: find series var b: index? b] | |
Ladislav: 14-May-2010 | indeed, I just meant: b: either b: find series var [index? b] [default] | |
Graham: 14-May-2010 | index?: func [ [ series! | none! ] ][ either series [ index? series ][ none ] ] would likely cause a stqack overflow | |
BrianH: 15-May-2010 | use [idx?] [ idx?: :index? index?: func [series [ series! | none! ]] [ either series [ idx? series ][none] ] ] | |
Group: Profiling ... Rebol code optimisation and algorithm comparisons. [web-public] | ||
Maxim: 27-Jan-2011 | all path access is slow...but I woudn't have thought that using a series function and multiplying both values in the pair would be twice as fast! | |
Group: Core ... Discuss core issues [web-public] | ||
BrianH: 20-Apr-2011 | Onetom, that error has been reported already and fixed in R2/Forward, but it hasn't made it into R2 yet. Here is the revised MAP-EACH: map-each: func [ "Evaluates a block for each value(s) in a series and returns them as a block." [throw catch] 'word [word! block!] "Word or block of words to set each time (local)" data [block!] "The series to traverse" body [block!] "Block to evaluate each time" /into "Collect into a given series, rather than a new block" output [any-block! any-string!] "The series to output to" ; Not image! /local init len x ][ ; Shortcut return for empty data either empty? data [any [output make block! 0]] [ ; BIND/copy word and body word: either block? word [ if empty? word [throw make error! [script invalid-arg []]] copy/deep word ; /deep because word is rebound before errors checked ] [reduce [word]] word: use word reduce [word] body: bind/copy body first word ; Build init code init: none parse word [any [word! | x: set-word! ( unless init [init: make block! 4] ; Add [x: at data index] to init, and remove from word insert insert insert tail init first x [at data] index? x remove x ) :x | x: skip ( throw make error! reduce ['script 'expect-set [word! set-word!] type? first x] )]] len: length? word ; Can be zero now (for advanced code tricks) ; Create the output series if not specified unless into [output: make block! divide length? data max 1 len] ; Process the data (which is not empty at this point) until [ ; Note: output: insert/only output needed for list! output set word data do init unless unset? set/any 'x do body [output: insert/only output :x] tail? data: skip data len ] ; Return the output and clean up memory references also either into [output] [head output] ( set [word data body output init x] none ) ] ] | |
BrianH: 20-Apr-2011 | The revised mezz-series.r (relative to the 2.7.8 SDK source) is in R3 chat #8008 - that's the number of the particular version, which you can see by going to #41 (R2/Mezzanines) and doing a LF command. | |
Geomol: 26-May-2011 | FIRST, SECOND and THIRD can be used on functions like: >> first :repend == [series value /only] SECOND and THIRD returns the function body and spec. FIRST returns a stripped spec, just the arguments and refinements. I notice, it's produced each time contrary to the other two: >> same? second :repend second :repend == true >> same? third :repend third :repend == true >> same? first :repend first :repend == false What is FIRST on a function used for? It may be used internally, but does anybody use it externally? It seems more logical, if FIRST on a function returned the spec, SECOND the body, and nothing else. | |
Geomol: 9-Jun-2011 | Tonight's Moment of REBOL Zen: >> same? :empty? :tail? == true Wouldn't it be better to define EMPTY? as: empty?: func [ series ][ tail? head series ] | |
Geomol: 25-Jul-2011 | That information is only available in the serialized format like this: Why isn't it available using the do dialect, like: do [next reduce [true none 'none]] And then you say, because DO, NEXT and REDUCE may not hold the meaning, you expect. 2 points: 1. Right, but is it worth the effort, if those are being redefined? 2. Why SAVE series like that at all? Why not save HEAD series and then maybe an offset, if you need it? | |
Maxim: 25-Jul-2011 | What I usually use to differentiate these is that there are literal values which do not have to be interpreted (only parsed), and logical values which have no real meaning without this interpretation. Serialization in the REBOL sense, hence the quotes, is used to give the second form of data a way to be described in the first, *where its possible* which it isn't at all in the case of some types (native,etc) and only partially in others (objects!, functions!, etc.) even with these distinctions there is still a sizeable amount of REBOL *data* (interpreter values, not human visible source code) which cannot be serialized (in the real sense) in any way because either: -the notation has simply not been defined for it (cyclic series/objects, which is serializable in other languages) -it implicitely depends on its interpretation (a VID dialect block (you cannot save the vid from the faces)), custom types (in the future)) so the way I see it is that: -MOLD is the counterpart to DO -MOLD/ALL is the counterpart to LOAD. which leads to saying that: only MOLD/DO can effectively represent all data, (with the caveat that it is extremely insecure) only MOLD/ALL can effectively represent literal data without interpretation (with the caveat that it is not complete) BOTH , are highly complex to use effectively in non-trivial cases. IMHO, if it's notation where completed, the second form could actually be built to represent all data, since it could be built to include binding hints, series reference graphing and more. It doesn't have to be pretty, it just has to be symmetric. | |
Maxim: 26-Jul-2011 | The only problem right now, is that the serialized form of the language is just not complete. all the edge cases I can think of have a way of being resolved, especially in R3. having cyclic references be checked and used on object/block types would already go a very long way. #[block 1 [ val1 val2 ...]] ; serialized block with uid as first parm (only needed when it is shared in the string being loaded). #[block 2 [ val3 #[block 1] val4] ; shared block #[block 3 [ #block 3 ]] ; self-reference effectively shows a simple way to solve the cyclic series/object problem. | |
Steeve: 26-Jul-2011 | I'm not sure to see your point. But If you want to see if the series are the same or not you have to use same? Actually, Your trial does not prove your claim | |
Cyphre: 26-Jul-2011 | I'm not sure which behaviour is better though. Ie copying whole string vs. just the 'ranges' defined by the series values in the block. | |
Cyphre: 26-Jul-2011 | I think it works same on all series. | |
Henrik: 4-Aug-2011 | I have a COPY/DEEP question: When doing a COPY/DEEP, the first level requires that the argument must be a series!, port! or bitset! But when doing a /DEEP, I imagine that COPY traverses a series for elements and uses a different process than for the first level to determine whether the element can be copied. If it can't, it silently passes the value through. Why can't we do that on the first level as well? | |
Geomol: 4-Aug-2011 | I try to think of situations, where I would need to do that. I also don't think, I do it often. But it's an interesting idea. I try to come up with some situations, where I need to copy a value, that can sometimes be a series, sometimes not. Hmm... | |
Endo: 15-Aug-2011 | Oh shame on me! I forgot to GET the values.. Thank you. One more question, I use COPY on objects to be able to use same series! values in different objects, is that right? I mean pointing to the same series inside different objects. In R2 I do like that: >> o: context [a: ""] >> p: context [b: get in o 'a] >> append p/b "*" >> o/a == "*" | |
Steeve: 16-Aug-2011 | - "The block defines the binding". It's against Rebol's first law. AFAIK binding (context) is a property of words. Series have not. | |
Gregg: 16-Aug-2011 | We all know you can make REBOL do just about anything. We also know there are a few things that trip people up (e.g. copying series values defined in funcs). My questions for John are: 1) Has this behavior ever been behind a bug in any of your REBOL code? If so, what was the context and what was the impact (e.g., how did you work around it)? 2) If you got your wish, what would the consequences be? i.e., how would it change REBOL? | |
Geomol: 18-Aug-2011 | Gregg, about your questions. 1) Has this behavior ever been behind a bug in any of your REBOL code? If so, what was the context and what was the impact (e.g., how did you work around it)? I guess, you mean series inside functions. I'm not for everything should do a copy, as Gabriele imply. The problem with series in functions is only a problem, because functions in REBOL isn't functions in the traditional understanding. They are semi-closures. If they were functions, the local values would just be on the stack. Because the locals live on, this was a problem for me years ago. First I solved it by putting COPY in series definitions, then I in many cases changed to just do a CLEAR, like in: local-block: clear [] Now with the discovered behaviour regarding objects, I find the binding rules so complicated, that I would forget, how it works in two weeks. I will remember, that I have to be very careful, when making objects inside functions, especially if it's recursive functions. The consequence for me is, that I will probably put COPY/DEEP in, when making objects. As I won't start new big projects in REBOL, I will probably not do this a lot in practice. | |
Ladislav: 18-Aug-2011 | ...Because the locals live on, this was a problem for me years ago. First I solved it by putting COPY in series definitions... - sorry to chime in, but I simply have to. The issues you mention (series in functions, extent of function locals) are not related. For example, the extent of function locals has changed a bit in R3, while the issue with series remains unchanged. | |
Ladislav: 18-Aug-2011 | I can easily prove, that the extent of function locals is immaterial, when the behaviour of series in functions is examined. | |
Gregg: 19-Aug-2011 | John, it sounds like where you get confused, or think of things as bugs or design flaws, is when having your REBOL "That's funny!" moments, borne of deep tinkering. Aside from the "copy series in funcs" behavior, which I think bites many people at some point, your issues don't come from writing application code in REBOL and bumping up against REBOL's behavior. Rather, it seems that REBOL's implementation and design don't match your expecations in these cases, and you really want it to. :-) The reason I asked about consequences is because you may want a change that affects other users negatively. Imagine REBOLers as being in one of two groups. Group A is the gurus. They have internalized REBOLs design, understand it deeply, and use BIND and recursive PARSE rules without fear. That group is very small. Group C contains everybody else, which includes people that don't know about using /local with funcs, and suggest REBOL should use = for "assignment". They have never used USE, BIND, or many other functions, because they aren't sure how they work. Some of them know a little about series references, so they always use COPY to be safe. (Yes, group B exists too, but they are much more like C than A). If REBOL were meant only for A users, it would be very different. As a designer, it seems pragmatic to make it so things work well for the B and C users who, when they hit a problem that requires advanced understanding, will work around issues with the bits they understand (and adding many COPY calls), no matter how inelegant. Group A users may suffer at their expense, but I'm OK with that, because I'm not one of them. | |
Henrik: 24-Aug-2011 | lit-path is a series, so I think the argument is sound for the latter result. | |
Geomol: 24-Aug-2011 | But yes, Henrik, COMPOSE should maybe work on path too, as it is a series. And maybe also on parens (also a series), where COMPOSE should work on parens inside. | |
BrianH: 19-Sep-2011 | map-each: func [ "Evaluates a block for each value(s) in a series and returns them as a block." [throw catch] 'word [word! block!] "Word or block of words to set each time (local)" data [block!] "The series to traverse" body [block!] "Block to evaluate each time" /into "Collect into a given series, rather than a new block" output [any-block! any-string!] "The series to output to" ; Not image! /local init len x ][ ; Shortcut return for empty data either empty? data [any [output make block! 0]] [ ; BIND/copy word and body word: either block? word [ if empty? word [throw make error! [script invalid-arg []]] copy/deep word ; /deep because word is rebound before errors checked ] [reduce [word]] word: use word reduce [word] body: bind/copy body first word ; Build init code init: none parse word [any [word! | x: set-word! ( unless init [init: make block! 4] ; Add [x: at data index] to init, and remove from word insert insert insert tail init first x [at data] index? x remove x ) :x | x: skip ( throw make error! reduce ['script 'expect-set [word! set-word!] type? first x] )]] len: length? word ; Can be zero now (for advanced code tricks) ; Create the output series if not specified unless into [output: make block! divide length? data max 1 len] ; Process the data (which is not empty at this point) until [ ; Note: output: insert/only output needed for list! output set word data do init unless unset? set/any 'x do body [output: insert/only output :x] tail? data: skip data len ] ; Return the output and clean up memory references also either into [output] [head output] ( set [word data body output init x] none ) ] ] | |
Ladislav: 10-Oct-2011 | Hi, I found the following text part in the Replacement article: "ENLINE any-block!,". Forgive my ignorance, please. What exactly is ENLINE meant to do in case its SERIES argument is a block? | |
Endo: 12-Oct-2011 | move-next 'series looks ok but multiply looks weird. but ++ already works for series as you say. | |
Endo: 12-Oct-2011 | ++ : "Increment an integer or series index." | |
Endo: 12-Oct-2011 | NEXT already test for different datatypes, as it can handle blocks, strings, etc. But it's all series type. So no type checking I think. It supports only series and port values. | |
BrianH: 13-Oct-2011 | Try it in R3: >> dt [i: 0 loop 1000 [i: i + 1]] == 0:00:00.000251 >> dt [i: 0 loop 1000 [++ i]] == 0:00:00.000383 Then the difference is more due to the code in ++ to tell whether i is an integer or a series | |
Geomol: 13-Oct-2011 | So we would expect things like next 'series to be faster aswell than series: next series | |
BrianH: 13-Oct-2011 | But not as useful. The current NEXT can operate on values returned from functions, or series referred to by protected variables. | |
Geomol: 13-Oct-2011 | Mezzanine example: >> my-next: func [series] [either word? series [set series next get series] [next series]] >> my-next [a b c] == [b c] >> block: [a b c] == [a b c] >> my-next 'block == [b c] >> block == [b c] | |
Endo: 13-Oct-2011 | We talked about to change the value of non-series values by this way: >> a: 5 >> multiply 'a 5 >> ? a == 25 But ofcourse we are not sure about performance overhead or possible other problems. | |
BrianH: 13-Oct-2011 | For all those series functions that are non-modifying, except for ports, all we have to do to use them safely is to avoid putting ports in our data. This isn't usually a problem because it's rare to put ports in data; but words, on the other hand, are really common in data. This would make a misplaced word in your data not only not caught, but also *modified*. That is really bad. | |
Geomol: 9-Nov-2011 | Why isn't the length of a char one? >> length? #"a" ** Script Error: length? expected series argument Kinda related: it's funny, that a bitset! isn't a series, even if we can ask the length of it: >> series? charset "" == false | |
Andreas: 9-Nov-2011 | Why isn't the length of a char one? Because characters are no series datatype and therefore it does not make much sense to speak or their length. That's about the same as asking "Why isn't the lenght of an integer one?" or "Why isn't the length of a logic! one?" | |
Endo: 20-Dec-2011 | Its no sense SHIFTing bytes in binary, we can simply use series functions, append #{00}, copy/part etc. Shifting bits in binary could be more useful for graphics operations (not so sure) | |
Group: !REBOL3 Proposals ... For discussion of feature proposals [web-public] | ||
Maxim: 27-Jan-2011 | unique returns a new series. | |
Rebolek: 27-Jan-2011 | I was just curious, because even with new series unique is much faster. | |
Maxim: 27-Jan-2011 | its a shame that all "set" functions make new series. we could just easily copy before calling unique: new: unique copy serie | |
Maxim: 27-Jan-2011 | though there is a lot of memory overhead for large series, I'd rather have a refinement on all sets probably /only or something similar, to have them work "in-place" come to think about it, maybe we could make a CC wish for this, seems like its been a topic of discussion for years, and pretty much eveyone agrees that both versions are usefull. | |
Maxim: 27-Jan-2011 | SWAP is another interesting one... takes two series and swaps their content, in-place. | |
Maxim: 27-Jan-2011 | INTERLEAVE is a very usefull function, using two series and mixing them up with many options like counts, skip, duplicates, all cooperating. | |
Maxim: 27-Jan-2011 | anyway, I really think that we should accumulate all of the series functions we are using (even the more obscure ones) and make a big standard series handler module in R3. it helps people who are learning REBOL since they don't have to figure out as much how to build these (somethimes non-obvious to implement) funcs. | |
BrianH: 28-Jan-2011 | See http://issue.cc/r3/1573for remove-duplicates and the reason it's not as good an idea as you might think. It turns out that the set functions have to allocate a new series to do their work (for series larger than trivial size), even if they were changed to modify in place. So you can't avoid the allocation; might as well benefit from it. | |
Maxim: 28-Jan-2011 | its a good idea, because I can't copy the series, its linked in many places. | |
BrianH: 28-Jan-2011 | It has to allocate another series anyways, as the set functions do hashing. In-place is just for convenience, not to save memory. | |
Ashley: 29-Jan-2011 | Does DEDUPLICATE *have to* create a new series. How inefficient would it be to SORT the series then REMOVE duplicates starting from the TAIL. Inefficient as a mezz, but as native? | |
Ladislav: 29-Jan-2011 | To find out what is wrong, just write an "in place" version of Deduplicate in Rebol, divide the time needed to deduplicate a 300 element series by 30, and compare to the algorithm (in Rebol again) allowed to use auxiliary data. | |
Ladislav: 29-Jan-2011 | Or, to make it even easier, just use an "in place deduplicate" written in Rebol, divide the time to deduplicate a 300 element series by 30, and compare to the time Unique takes (Unique uses aux data, i.e. a more efficient algorithm) | |
Gregg: 16-Feb-2011 | I have my own versions of the series comparison funcs Max proposed on 27-Jan. My versions of SHORTEST and LONGEST take a block of series values, and return the given item by length. I don't use them much, but there are times they are nice to have. | |
Group: Red ... Red language group [web-public] | ||
BrianH: 28-Feb-2011 | Code like this in FIND-ALL: assert [series? orig: get series] could be internally rewritten into this as part of the compilation process: orig: get series assert/type [orig series!] | |
Dockimbel: 9-Mar-2011 | I'm not sure adding macros at the "data" level (LOADed source) would be really needed. Once Red will be ready, you'll be able to compose Red/System dialect source code at Red level (with all the block! series power), as you do today in REBOL with VID, DRAW, or other dialects. | |
Kaj: 20-Jun-2011 | *** Compiler Internal Error: Script Error : first expected series argument of type: series pair event money date object port time tuple any-function library struct event *** Where: opposite? *** Near: [first select/skip opp-conditions cond 2] | |
Kaj: 21-Jun-2011 | With the latest series of Red versions, the 0MQ binding didn't work anymore due to crashing on a certain imported function call. This is now fixed, probably as a side effect of the last few fixes | |
Kaj: 8-Aug-2011 | Humble beginnings, but I've had a series of issues already | |
Kaj: 3-Dec-2011 | I'm looking into the allocator. alloc-series says it takes a size in cells of 16 bytes, but then it relays it to alloc-series-buffer unmultiplied, which says it takes a size in bytes, and only rounds it up to 16 bytes | |
Kaj: 3-Dec-2011 | How are non-block series going to be allocated, for example binaries of one byte per cell? | |
Dockimbel: 3-Dec-2011 | Alloc-series: right, the comment is obsolete, it accepts any integer value as argument and leave it to alloc-series-buffer to round it to 16 bytes. | |
Dockimbel: 3-Dec-2011 | Non-block series: in fact all series will use the same allocator, so 128-bit (16 bytes) is the minimum allocating unit. | |
Pekr: 26-Dec-2011 | Anyway - not sure if such a news article for OSNews is not a bit preliminary ... no bindings yet, no possibility to use standard channes (market), no RED yet = not much of a REBOL featureset either. Achievement is great - RED gets us onto mobile OSes, still far superior to R2 or R3, except that Red/System is mostly a C with REBOL syntax. I can understand, why Doc wants to work on RED itself some bits too :-) Anyway - I am here to do some testing with HTC Sensation. The fun part comes, when the bridge is going to be done. Imagine having parse and REBOL like series handling, with access to stuff like SMS, calendar, address-book, and other APIs :-) | |
Dockimbel: 24-Jan-2012 | Pekr: the link you're giving is the exact same article I've pointed to in 2), it just have a left menu added for quicker navigation, but that's the same article. If I haven't just stopped on this algorithm, it's because of the initial warning at the beginning: This article is obsolete. Its replacement - which will fix some errors and better explain the relevant issues - is being crafted as a multi-part series And from Dawson's blog: "Years ago I wrote an article about how to do epsilon floating-point comparisons by using integer comparisons. That article has been quite popular (it is frequently cited, and the code samples have been used by a number of companies) and this worries me a bit, because the article has some flaws. I’m not going to link to the article because I want to replace it, not send people looking for it." So it appears that there are some errors (probably some edge cases not handled properly). | |
Dockimbel: 24-Jan-2012 | Th new fixed version of Dawson's article is split in a new series of blog entries: http://randomascii.wordpress.com/category/floating-point/ But, alas, he hasn't yet reached the point where he shows the fixed version of `almost-equal` function. | |
Pekr: 7-Feb-2012 | I can agree with Oldes, that when wrapping some C stuff, things like series would be handy - namely - a block! type, to have an array, plus accompanying series handling functions. But - where would that end? :-) Wouldn't we then want also a path, etc. to work? | |
Group: Topaz ... The Topaz Language [web-public] | ||
Maxim: 19-Jul-2011 | the Other alternative I see is using <- , as in: >> x <- string! but with endo's comment, its very misleading to read. >> x <- t it looks like an assignment. (put value of t within x) so maybe standardizing on a first character which means, this operator is an in-place modifier, might be a good idea... it might also allow a new class of series operators. ----------------------------- with: := to :< append ------------------------------ label: "prefix-" :< "text" :< "-suffix" x: 1 y: 3 x := string! x :< "test" x: label :< 1 :< y: "2" :< (y := string! ) ----------------------------- x == "prefix-text-suffix123" y == "23" | |
BrianH: 2-Dec-2011 | Does it return the subject series at the position of the last result, or does it return the last recognized pattern as a value? | |
Gabriele: 3-Dec-2011 | Brian, each "rule" has two effect: it advances the series, and returns a result. Most rules return the matched value, but not all. Examples: >> parse [1] [number!] == 1 >> parse [1 2 3] [number! number! number!] == 3 >> parse [1 2 3] [some number!] == 3 >> parse [1 2 3] [object [a: number! b: number! c: number!]] == object none [ == a: 1 == b: 2 == c: 3 == ] >> parse [1 2 3] [object [a: number! b: object [c: number! d: number!]]] == object none [ == a: 1 == b: object none [ == c: 2 == d: 3 == ] == ] | |
Group: World ... For discussion of World language [web-public] | ||
Geomol: 2-Dec-2011 | I fear, that implementing unicode! datatype will mean, all series functions will have to deal with it separately, like LENGTH?, NEXT, SKIP, etc. Would it be an idea to make a unicode! datatype just to pass data back and forth and be able to view it somehow, but without support for all the series function? | |
BrianH: 2-Dec-2011 | Is your bytecode polymorphic, or is it statically typed? A polymorphic VM like REBOL's wouldn't have problems with higher-level series like unicode!, but to support that on a static-type VM you would need either a lot of opcodes or compiling to a lot of code to support it. | |
BrianH: 2-Dec-2011 | Geomol: Are series operations included in your polymorphic opcodes, like they are in REBOL? Or are you sticking to the C-like opcodes? | |
Gregg: 2-Dec-2011 | John, on range! values, do you envision transparent iteration/lazy generation support for them? I use the term 'bounds for what you call range! and my 'range is a series with the values filled in (with /skip support). | |
Geomol: 7-Dec-2011 | - Gave series an overhaul, so compiling blocks should really work now. Let me know, if it doesn't. - Changed system/version/platform, so it's now a word. - Added new tests. | |
Geomol: 9-Dec-2011 | - Added handle! datatype - Gave routines an overhaul - Added AS native to change type of series without copying. - Fixed crash with function redefinition to reset compile state | |
Geomol: 13-Feb-2012 | Continuing from #Not REBOL. A MORE? function could look like: more?: make function! [[ "True if a series isn't empty." series [series! none!] ][ if none! = type? series [ return false ] 0 < length? series ]] | |
Geomol: 13-Feb-2012 | Could also be made easier to read maybe, but slower: more?: make function! [[ "True if a series isn't empty." series [series! none!] ][ not any [none? series tail? series] ]] | |
Geomol: 13-Feb-2012 | And to make is less confusing, the function description should probably read "True if a series isn't at its tail." |
1401 / 1531 | 1 | 2 | 3 | 4 | 5 | ... | 12 | 13 | 14 | [15] | 16 |