## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
• Oct 20 2019 22:59
@dockimbel banned @SmackMacDougal
• Dec 03 2017 05:53
@PeterWAWood banned @matrixbot
• Sep 28 2016 12:19
@PeterWAWood banned @TimeSeriesLord
• Aug 13 2016 03:23
@PeterWAWood banned @Vexercizer
Gabriele Santilli
@giesse
ah, also notice, he said b/text not t/text
perhaps a bug with show on hidden tab panels?
@giesse it still doesn't work with it:
...
b/text: append/dup "" "*" 999
show b
...
Ungaretti
@Ungaretti

Could anyone explain why Red behaves like this:

Red []
csvtext: "first,second,third"
b: split csvtext ","
print b/1
print b/2
repeat i 3 [prin i print b/i]
first
second
1none
2none
3none

In the last line, i is incremented as an integer, but would need a to integer! conversion to work as a proper index.

Boleslav Březovský
@rebolek
@Ungaretti
>> b: [1 2 i 3]
== [1 2 i 3]
>> i: 1
== 1
>> b/i
== 3
>> b/:i
== 1
Semseddin Moldibi
@endo64
Or b/(i) would work.
Ungaretti
@Ungaretti
I see the answer, but i can't figure WHY the i as an index is not evaluated? It becomes a different word? Thanks by the way.
Toomas Vooglaid
@toomasv

@Ungaretti Words are not evaluated by default to allow words to action as keys, I think. E.g.

select b 'i
;is same as
b/i

When used in path, word stands for itselt, unless get-word is used.

@Ungaretti you can retrieve value of a block by:
• number/index (integer!): bl: [11 22 33 44] bl/2; 22
• word! - here the Red will look for given word and returns next element: bl: [a 1 b 2] bl/a; 1
• get-word! - here it will evaluate it (e.g. into number): bl: [11 22 33 44] ind: 1 bl/:ind
• or paren! - it will evaluate it but you can look for anything: bl: [1.2 a 3.14 b] bl/(1.2); a
@9214
@Ungaretti i is not evaluated because it's a part of a composite value b/i, which is a path!. Same logic applies to [b i], or to quote (b i).
You can use indexing by words to treat series as a key/value store.
Toomas Vooglaid
@toomasv
@nedzadarek Your original example works as expected. When setting size on first tab, you do not change the position of t. E.g. here t-s position is changed. You might do it with react I suppose.
view [
p: tab-panel [
"size" [
x: field "200"
y: field "200"
button "set size" [
b/size/x: x/data
b/size/y: y/data
t/offset/x: b/offset/x + b/size/x + 10
]
]
"image" [
b: base 50x50
t: text "some text"
]
]
]
@9214
@Ungaretti on the other hand, if you want i to evaluate to integer, use b/:i
Ungaretti
@Ungaretti
Thank you all! @nedzadarek Your answer made me laugh at my own ignorance! I didn't know (or forgot) the fact that Red looks up the list for the word after ´/´and returns the next element. That explains a lot.

@toomasv

t/offset/x: b/offset/x + b/size/x + 10

If you do not know how to do it automatically then I guess nobody knows it. That is what I have started to do, thank you nevertheless.

Toomas Vooglaid
@toomasv
@nedzadarek This is very simple line. How much more automatic you want it? :smile:

@Ungaretti If you haven't used this feature you may forget about it. The Red has many types for key-value things map! for associative arrays, and object! for immutable (keys) container. Not everyone used Lua to know that feature.

@toomasv It is easy but I have to use it many times. I have many 1 more tab and there might be more elements in each tab. It is not a problem but I am just looking for conveniences as vid taught me.

@9214
Toomas Vooglaid
@toomasv
@nedzadarek You might do something like this, but you still need to determine same relations:
view/no-wait [
p: tab-panel [
"size" [
x: field "200"
y: field "200"
button "set size" [
b/size/x: x/data
b/size/y: y/data
]
]
"image" [
b: base 50x50
t: text "some text"
]
]
]

react [t/offset/x: b/offset/x + b/size/x + 10]
do-events
@9214 @toomasv Thank you.
Toomas Vooglaid
@toomasv
@nedzadarek You are welcome. This is better:
view [
p: tab-panel [
"size" [
x: field "200"
y: field "200"
button "set size" [
b/size/x: x/data
b/size/y: y/data
]
]
"image" [
b: base 50x50
t: text "some text"
]
]
react [t/offset/x: b/offset/x + b/size/x + 10]
]
@toomasv :+1:
Toomas Vooglaid
@toomasv

@nedzadarek I'm curious if this might do the automatization?

view [
p: tab-panel [
"size" [
x: field "200"
y: field "200"
button "set size" [
b/size/x: x/data
b/size/y: y/data
]
]
"image" [
b: base 50x50
t: text "some text"
]
]
do [
foreach pan pane/1/pane [
foreach [bas txt] pan/pane [
if all [bas/type = 'base txt/type = 'text] [
react [txt/offset/x: bas/offset/x + bas/size/x + 10]
]
]
]
]
]

Of course, this is only for consecutive base and text faces. But still?

@toomasv foreach idea is interesting. We can add resize flag and we can almost call it "responsive design".
Toomas Vooglaid
@toomasv
Yeah, if you make base faces responsive to window size, why not.
Well, thank you.
Toomas Vooglaid
@toomasv
:smile:
Ungaretti
@Ungaretti
What does parse's if statement do? It seems it just exit the parsing process if the result is false or none. There is no if-this-do-that? Red blog says it "backtracks", what is that?
Boleslav Březovský
@rebolek
@Ungaretti it works like if-this-do-that. If the condition is true, parse rule continues:
>> block: [1 2]
== [1 2]
>> parse block [set value integer! if (value = 1) to end]
== true
>> block: [2 2]
== [2 2]
>> parse block [set value integer! if (value = 1) to end]
== false
Gabriele Santilli
@giesse
@Ungaretti you would use it with | to implement an if/else scenario. eg. some-rule if (condition) true-rule | false-rule
Ungaretti
@Ungaretti
@giesse & @rebolek Thank you! I could not find an example anywhere.
Ungaretti
@Ungaretti
Sorry for being insistent but, so, if not used with the true-rule | false rule, it just exits the parse returning false if it's condition is false?
@9214
@Ungaretti if expression in parentheses evaluates to false or none, then Parse backtracks and tries to apply the next alternate rule. If there's no such rule, it will fail.
Ungaretti
@Ungaretti
@9214 by alternate rule you mean something with this | that? What exactly means "backtrack"?
Bactrack means try the same input again, right?
@9214
Yes, alternate rule is anything past |. "To backtrack" means to restore input position prior to invocation of a failed rule.
Ungaretti
@Ungaretti
@9214 Thanks!
@9214
Note that only input position is backtracked, whatever changes were applied in that failed rule will remain.
@dsunanda rebol does the same - y is not resized.
Ungaretti
@Ungaretti

I'm resuming my documentation of Red at helpin.red , and working on the parse chapters. There is a lot to be done there.
Since I can't find information about many keywords, I'm learning by trial-and-error, but I stumble on some inexplicable behaviours, for example: Red blog says that break should "break out of a matching loop, returning success". I try it but it returns false (failure?):

block: [1 2 3 4]
print parse block  [
integer! (print 1)
integer! (print 2)
break
integer! (print 3)
integer! (print 4)
]
1
2
false

It seems to me as the same as ´fail´ or ´reject´. How come?
I think I have checked all the available online documentation. Is there any hidden or unknown document that explain parse's keywords?

dsunanda
@dsunanda
Latest build does not seem much different with SIZE-TEXT
@9214
@Ungaretti red/red#3478
dsunanda
@dsunanda

layout compose [tb: box (mold system)]
length? tb/text
== 668501
size-text tb
== 159x17

In R2:
size-text tb
== 97x49436062

@9214
@Ungaretti and what do you expect, if I may ask?
break breaks the outer loop, that's it.
@dsunanda you cannot compare system from both languages and I think they have different default font size.
dsunanda
@dsunanda
I appreciate that - it was just a way to get a large text object. But there is no way ANY of the Red SIZE-TEXT values I am seeing are accurate or useful.
size-text should return width/height of area which can wrap the text in a face. This is clearly not the case here, even with wrap option:
view [text 100x100 gray wrap "a  b  c^/b^/c" [face/size: size-text face]]
So a "matching loop" is one of any, some and while. That is the information I was missing. I thought of a "matching loop" as the parsing itself. It is a matching loop after all. Hence my surprise when a parse with break returned false.