so using slang and domain-specific terms ain't bad at all, it's the exact opposite. Good metaphors makes you think at the whole new level.
Yes, it makes your code more readable... if you get it right. If you are non-native speaker then you may make mistakes. That's why I'm little afraid. Well, maybe I'll use "your style" sometimes. I may fail but with failure we learn more. Thank you for your opinion about naming.
sliders. I wanted set and get value of the a slider so I've put
text(just to try getting values), like this:
view [s: slider 50% on-change [f/data: s/data] f: text]. It worked so I've changed from
view [s: slider 50% on-change [f/data: s/data] f: field]). It works but it's much slower than
Red for Windows version 0.6.3 built 26-Mar-2018/1:14:22+02:00on win 8.1 x64
Fieldwill have more overhead, though
textflickers a bit here. To me that says there are a lot of updates going on. Profiling
fieldupdates will be easy. Looking at event cycles will be a bit more work, but there may be something in all sliders triggering
@greggirwin thank you
Profiling text vs field updates will be easy.
I am not sure if I understand.
field updates should be (almost*) the same. There is no another
field and I change
field (and vice versa) in the
textthat I update Line 330
Looking at event cycles will be a bit more work, but there may be something in all sliders triggering color-model-changed.
Every change of a slider should trigger
color-model-changedonce. I guess I should put some
To me that says there are a lot of updates going on.
At least 3/4 group of sliders & text,
base and 1x text is updated each time I move a slider. I want to see result instantly - I do not think I can make less updates to achieve this.
The difference in styles is that the field may have more internal overhead, as the OS manages more because it's editable. My guess.
Profile (my gist or others) and updating facets on one should tell us quickly.
The number of updates was more a thought, sorry for writing quickly. The reactive system does a good job, but if you trigger events from within events, there may be cases where extra events trigger before it stabilizes. My thought was just that there may be more events than we think.
on-changehandler, and if fields and sliders react to each other, then the following scenario occurs: you enter something in a field, it changes value of a slider, which in turn triggers an update in field, which either triggers slider again or remains silent because the actual data hasn't changed. Justs my after-midnight, uneducated guess.
Hello! I'm trying to compile a Red code with callback function.
Red  a: function [ num [integer!] ] [ print "num: " print num ] b: function [ cb [function!] num [integer!] ] [ ;-- cb: function spec-of :cb body-of :cb cb num ] b :a 15
This does work only in interpreted mode. I've read https://github.com/red/red/wiki/%5BDOC%5D-Guru-Meditations#compiled-vs-interpreted-macros , but uncommenting a commented line in my code also does not help.
react. Can you give me examples of using it with refinements
/unlink? (not with VID objects) I tried, but hadn't proper result:
obj1: make reactor! [a: 1 b: 2] obj2: object react/later [sum: obj1/a + obj1/b] ;-- sum is evaluated during creation, but mustn't react/unlink [sum: obj1/a + obj1/b] obj2 ;-- reactivity continues to work, but mustn't
reactivity continues to work, but mustn't
And why should it break all of a sudden, if I may ask?
sum is evaluated during creation, but mustn't
sum is evaluated during creation of an object from a block to which you applied
react/later. This creation isn't necessary, unless you explicitly wanted to show us something.
>> foo: make reactor! [a: 1 b: 2] == make object! [ a: 1 b: 2 ] >> unset? :x == true >> react/later [x: foo/a + something-else] == [x: foo/a + something-else] >> unset? :x == true >> react [x: foo/a + something-else] *** Script Error: something-else has no value *** Where: + *** Stack: react
reactivity continues to work, but mustn't
obj2 in your example isn't even a reactive source. Secondly,
[sum: obj1/a + obj1/b] block you've provided does not contain any reactive relations.
>> foo: make reactor! [a: 1 b: 2] == make object! [ a: 1 b: 2 ] >> bar: object [c: 0] == make object! [ c: 0 ] >> block: [bar/c: foo/a + foo/b] == [bar/c: foo/a + foo/b] >> react block == [bar/c: foo/a + foo/b] >> bar/c == 3 >> foo/a: 100 == 100 >> bar/c == 102 >> react/unlink block foo ; note that I unlink the same block in which reaction was linked in the first place! == [bar/c: foo/a + foo/b] >> foo/a: 200 == 200 >> bar/c == 102
source-a: make reactor! [a: 1] source-b: make reactor! [b: 10] obj: object [c: 0] block: [obj/c: source-a/a * source-b/b] react block obj/c ; == 10 source-a/a: 2 obj/c ; == 20 ; react/unlink block [source-a source-b] ; works fine react/unlink block source-a ; freezes the console
reactfunction, only for
if. Moreother, I literally have followed a description from that document. :)
react [sum: obj1/a + obj1/b]in my sample constructs a reactive relation, because changing
obj2, so I thought I was on right way.
react. I think the author should post @9214 in his/her site.
objectcreates a copy of a spec block on creation, so original block with a linked reaction cannot be accessed anymore, not even with
body-of obj2, as it returns a copy too.
>> obj1: make reactor! [a: 1 b: 2] == make object! [ a: 1 b: 2 ] >> obj2: object block: react/later [sum: obj1/a + obj1/b] == make object! [ sum: 3 ] >> obj1/a: 100 == 100 >> obj2 == make object! [ sum: 102 ] >> react/unlink block obj1 == [sum: obj1/a + obj1/b] >> obj1/a: 1'000 == 1000 >> obj2 == make object! [ sum: 102 ]