dockimbel on master
TESTS: adds regression test for… (compare)
--no-compressoption seems to make no difference on the false detection of the remaining ones.
>> reduce [random/seed 20 random "taskohucRrhdt anr e Jee!"] == [unset "Just another Red hacker!"]
What's before string adds a space. But:
>> print do [random/seed 20 random "taskohucRrhdt anr e Jee!"] Just another Red hacker!
@dockimbel speaking of R/S features, using Red stack from R/S feels like holding a blade by it's edge :) It's filled manually item by item in various parts of code, sometimes recursive code, then gets modified by the many functions you call from that code (and the functions called by those functions). So basically it's impossible to predict what will happen to the stack by just looking at the source. As an example if anybody will be able to follow how the stack works inside do-print in less than 2 hours, I'll applaud him :)
So, can you add a (debug-mode) feature that would check the Red stack (or any data referred to by another pointer) layout declaratively and report if anything's amiss?
Something like this:
#check stack/arguments [some/value1 some/value2 some/value3] some-func*
(the above would check that stack/top is at least 3 slots above the arguments, and compare it's contents with the provided constants, then call the
some-func* that relies on this specific layout)
This morning, I stumbled upon an old blog entry from Carl about redefining
find on objects. In a nutshell, there's a duplication between
find when used with objects. Carl proposed to repurpose
find to search among the values instead of the object's words. That sounds like a useful feature to have, so I made a prototype implementation in Red:
obj: object [a: 4 b: "hi" c: 'hello d: 4] find obj 4 == a find obj 'hello == c
/part refinement is supported, to start the search from a different word/value pair than the first one, allowing to find all the occurrences of the same value within an object:
i: index? find obj 4 == 1 find/part obj 4 i + 1 == d
index? in Red can be used on words, to return the index of the word in a context. As
findreturns a word that is bound to the object, we can extract its index that way, increment it, then use it as argument to
find/part to start after
c in the object.
/same refinements are supported also.
What do you think about it? Should I merge it in master?
values-of), but they create intermediary blocks, that can become a significant overhead when searching through a tree of objects. OTOH, if we add support for
foreachon objects, browsing objects becomes much lighter, though, such searching operation would be way slower than having
findhandle it at low-level. So it looks like this could be a sweet spot.
index?works with words in Red.