getin 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 Min your sequence above you can write just
Mand you will get 1 too.
>> reduce probe m 1 == 1
reduce 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 ;== 2
reduce first b(at least for my tired mental sequence)
-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 'png
Firstly, 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.
@bubnenkoff write a routine using GetCurrentProcessId from
it's only way?
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-pid
As 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 s
I 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 s
Though 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 s
Are there any other strategies to consider for injecting dynamism into parse rules ?