Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 03 2017 05:53
    @PeterWAWood banned @matrixbot
  • Sep 28 2016 12:19
    @PeterWAWood banned @TimeSeriesLord
  • Aug 13 2016 03:23
    @PeterWAWood banned @Vexercizer
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.

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

Vladimir Vasilyev
@9214
@Ungaretti this ticket was a subject to a hot design debate some time ago, so I suggest you to use this info, but to provide a "caveat emptor" for readers, as this behavior can change, and probably is not an intended one as it is now.