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: 1501 end: 1531]
world-name: r3wp
Group: Core ... Discuss core issues [web-public] | ||
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: 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." | |
Geomol: 21-Feb-2012 | Update! I'm implementing support for cyclic series in World these days. My initial research about freeing memory taken by cyclic series made me realize, that it'll hit performance, if every block and paren freed is being tested for cyclic references. So I'll implement a FREE mezzanine written in World, that can free such structures. This lead me to molding such structures, which is only partly implemented in current version of World and copying such structures. Those functions will be mezzanines too, as it's much easier to write the code in World than in C. So some C code will be removed in next release, but we'll have some more World code instead. |
1501 / 1531 | 1 | 2 | 3 | 4 | 5 | ... | 12 | 13 | 14 | 15 | [16] |