x), which is not "special" like /, it opens up a lot more questions and potential ambiguity. Paths are specifically meant for indirect access, and have to start with a word. Do pairs in your design have to start with a literal number, or is (pow 3 2)x(pow 2 3) valid as well? Because that's no longer Red compatible as a syntactic form. If that's not valid in your design, you can only evaluate the y axis, which seems much less useful and general.
x part of pair! defined by paren!. That kindda invalidates my idea.
:point_up: September 27, 2019 11:16 AM @9214, you're going to Hell for that. ;^) Lacking the power to send you there, I will have to concede that it's an AWFULly cool idea for a dialect.
@loziniak forgive me for not trying to come up with a more meaningful name in a short chat example. ;^)
get-field-c-from-var-a-for-rec: func [
key [string!]
][
key: to word! key
a/:key/c
]
a: [b [c 123]]
get-field-c-from-var-a-for-rec "b"rec-id.
word! instead of index in the cases where that is applicable, but then it would need to know if that word! was being reused in that branch of the tree...
For the reference, the main argument against paren! in paths is a stylistic one: you can abuse them with multi-line expressions or ungodly mess like inclusion of external files and deeply nested code logic.
head/(
...
<you can embed whole Red runtime here for all I care>
...
)/(
...
)/tailOne path (no pun intended) we can take is to prohibit newlines during path! lexing, thus allowing only simple, single-line expressions. Another is to get rid of them entirely.
page: 1 per_page: 10
for page 1 41 1 [
out: probe join out-head [per_page * page - per_page + 1 "-" per_page * page ".json.txt" ]
file: read to-rebol-file out
probe length? file
file: head remove/part file 3 ; remove initilal (UTF?) garbage
json: json-to-block file
;probe copy/part mold json 100
for n 2 11 1 [
attempt[insert/only tail items json/("html")/("body")/("div")/4/("div")/("div")/("div")/2/("div")/1/("div")/("div")/1/("div")/:n/("div")/1/("div")/("span")]
]
page: page + 1
if (probe length? file) < 90 [break]; 75
]
probe count: length? items
{
probe items/2/1/("a")/1/("#text") ; creator
probe items/2/1/("a")/2/("@href") ; link
probe items/2/1/("a")/2/("strong")/("#text") ; filename
probe items/2/2/("#text") ; description
}k: "div" once, and using :k in the path would be a big win. Or :div. :^)
json/("html")/("body")/("div")/4/("div")/("div")/("div")/2/("div")/1/("div")/("div")/1/("div")/:n/("div")/1/("div")/("span")
json/("html")/("body")/:div/4/:div/:div/:div/2/:div/1/:div/:div/1/:div/:n/:div/1/:div/("span")
json/("html")/("body")/:d/4/:d/:d/:d/2/:d/1/:d/:d/1/:d/:n/:d/1/:d/("span")
@greggirwin use parenthesis in path to select from an another block the position of the column I am searching for in the current one:
>> columns: [cd_ar 1 description 2 orders 5]
== [cd_ar 1 description 2 orders 5]
>> values: ["C00022" "Master Market" none none "22"]
== ["C00022" "Master Market" none none "22"]
>> values/(columns/description)
== "Master Market"
>>When column name sequence index name reflect data position I use the following form to pick the data form the right position.
>> columns: [cd_ar description something something-else orders]
== [cd_ar description something something-else orders]
>> values: ["C00022" "Master Market" none none "22"]
== ["C00022" "Master Market" none none "22"]
>> values/(index? find columns 'description)
== "Master Market"
>>Sometime I define an helper function to return me the right index
>> columns: [cd_ar description something something-else orders]
== [cd_ar description something something-else orders]
>> values: ["C00022" "Master Market" none none "22"]
== ["C00022" "Master Market" none none "22"]
>> ps: function [column columns-pos] [index? find columns-pos column]
== func [column columns-pos][index? find columns-pos column]
>> values/(ps 'description columns)
== "Master Market"
>>It is really useful when I navigate database data. Also I am planning more complex index retrieving experimenting with custom datatypes and their data position but I am currently in early stage as the data description language is currently building up in my mind.
-r) your compiled program and Red runtime are packed into one file, that's why it is bigger. In dev mode runtime is not included in your executable, that means you need to ship your program with the runtime (libRedRT.dll on Windows) otherwise it won't work.
I want to split a string (a 2-column table from a database query) with both "^-" and "^/" characters to get a flat block of items.
When the string is too long (13060 characters), the following:
split rawdata charset "^-^/"fails with a "not enough memory" message. While this:
split replace/all rawdata "^/" "^-" "^-"works fine and fast.
I was just wondering why the first one would not...
(I don't change so often as I'm used to gui-console-not-starting problems)
