red/help

For help with your code, suggestions and ideas, and learning Red.

nedzadarek

@nedzadarek

@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.

nedzadarek

@nedzadarek

@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

Vladimir Vasilyev

@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"
    ]
  ]
]

Vladimir Vasilyev

@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.

nedzadarek

@nedzadarek

@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:

nedzadarek

@nedzadarek

@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.

Vladimir Vasilyev

@9214

@nedzadarek https://doc.red-lang.org/en/reactivity.html#_dynamic_relations

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

nedzadarek

@nedzadarek

@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]
]

nedzadarek

@nedzadarek

@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?

nedzadarek

@nedzadarek

@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.

nedzadarek

@nedzadarek

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?

Vladimir Vasilyev

@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?

Vladimir Vasilyev

@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!

Vladimir Vasilyev

@9214

Note that only input position is backtracked, whatever changes were applied in that failed rule will remain.

nedzadarek

@nedzadarek

@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

Vladimir Vasilyev

@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

Vladimir Vasilyev

@9214

@Ungaretti and what do you expect, if I may ask?

break breaks the outer loop, that's it.

nedzadarek

@nedzadarek

@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.

nedzadarek

@nedzadarek

@dsunanda I do not see any difference in how precise it is.
Red:
Red for Windows version 0.6.3 built 26-Mar-2018/1:14:22+02:00
Rebol:
REBOL/View 2.7.8.3.1 1-Jan-2011

Vladimir Vasilyev

@9214

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]]

Ungaretti

@Ungaretti

@9214 I can't thank you enough for all your help.
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.

dsunanda

@dsunanda

One of these two SIZE-TEXTs is from R2 - and is useful. The other is from Red and is not:

layout [tb: box wrap 10x1000 ". . . . . . . . ."]

size-text tb
== 6x171
== 51x15

Where communities thrive

People

Repo info

Activity