get in such a situation, which is more clear to me.
/only -- Only evaluate words and paths, not functions
words -- Optional words that are not evaluated (keywords) (Type: block none)REDUCE M in your sequence above you can write just M and you will get 1 too.
>> reduce probe m
1
== 1reduce first blk (I never used it) and if it's really worth to add at least 2 datatype checks with evaluation branches (don't know how it's done in Red, but that is what would be needed to do in R3).. into frequently used function.
b: [m m + 1] m: 1
do/next b 'b
;== 1
do/next b 'b
;== 2reduce first b (at least for my tired mental sequence)
-c or -r. If you aren't already, use -r (or -u`) to make sure it's not a runtime issue with an old build, and also use the automated build rather than the (very old) stable build of Red.
Hi everyone, happy new year also.
A question related to the gui.
In the following code, I display a matrix of buttons with one particular button being twice as high as the others, followed by two full width text fields.
lay: layout [
origin 10x10
space 1x1
style b: button 72x38 font-size 12
; default space of 1 turns as 3 pixels high in my display
b "1" b "2" b "3" b "4" return
; twice high is 38*2 + 3 =
b "5" b "6" b "7" b "8" 72x79 return
; (1) this row should be shifted to the top from 38 + 3 (button height + space height)
pad 0x-41 b "1" b "2" b "3" return
; lets add a full width field - width is 72*4 + 3*3 = 297
; (2) correct field row that is one pixel to the left compared with buttons
pad 1x0 field 297x38 orange font-size 16 "F1" return
; (3) correct further gap between field widget and text widget that is 2 pixels high and not 3
pad 1x1 text 297x38 green "F2" return
]
view/no-wait lay
; for a dump of the window
; img: to-image lay
; save/as %layout.png img 'pngFirstly, I understand the need for padding the third row of buttons to account for the higher button (1), but I don't get it why the text fields and buttons are not aligned on the left (2). I don't get it either why field and text widgets are not 3 pixels apart like the buttons, or the buttons and the field (3).
Secondly, I suspect that all this hard work will be useless in a different environment (other resolution and other system). My environment is Windows 10 / x64 / 1920x1080. How can I enforce this layout in all situations ? Cheers.
I tried to compile example:
Red []
#import [
"kernel32.dll" stdcall [
process-id?: "GetCurrentProcessId" [
return: [integer!]
]
get-env: "GetEnvironmentVariableA" [
name [c-string!]
buffer [c-string!]
size [integer!]
return: [integer!]
]
]
]
pid: process-id?and got error: undefined word process-id?
It's error in example oк I forget how to interact with r/s code?
Red []
#system [
#import [
"kernel32.dll" stdcall [
process-id?: "GetCurrentProcessId" [
return: [integer!]
]
]
]
_pid: func[return: [integer!]] [return process-id?]
]
get-pid: routine [/local pid [integer!] ] [
pid: _pid
print pid
]
get-pidAs mentioned in red/bugs. How do you create parse rule with dynamic values ?
I tried using compose to mix a static rule with some dynamic values, like with view. However as parenthesis are useful in parse dialect, it quickly becomes messy. I ended up using to-paren all the times which makes the rules hard to read.
Maybe there is another way ? Compose with a different delimiter ?
keys: #(
k1: ['k1 'Key1]
k2: ['k2 'Key2]
)
rule: compose [
(keys/k1/1) keep ( to-paren keys/k1/2 )
| (keys/k2/1) keep ( to-paren keys/k2/2 )
]
s: copy []
parse [k1 k1 k2] [collect into s [any rule]]
probe sI also tried generating the rule dynamically :
keys: #(
k1: ['k1 'Key1]
k2: ['k2 'Key2]
)
rule: do [
b: copy []
foreach v values-of keys [
append b reduce [v/1 'keep to-paren v/2 '| ]
]
take/last b
b
]
s: copy []
parse [k1 k1 k2] [collect into s [any rule]]
probe sThough it is fine for creating a rule with multiple alternate, it is not that useful for twisting a bunch of static rules with few dynamic values.
Then I thought I could do some sort of meta parsing and twist the rules before using them. I was tempted to use !tag datatype for implementing delimiters for values to replace.
keys: #(
k1: ['k1 'Key1]
k2: ['k2 'Key2]
)
rule: [
<keys/k1/1> keep ( <keys/k1/2> ) |
<keys/k2/1> keep ( <keys/k2/2> )
]
; meta-parse the rule
meta: [ any [ item ] ]
item: [ s: tag! ( change s reduce load to-string s/1 ) | ahead [ block! | paren! ] into meta | skip ]
parse rule [ meta ]
probe rule
; parse
s: copy []
parse [k1 k1 k2] [collect into s [any rule]]
probe sAre there any other strategies to consider for injecting dynamism into parse rules ?