Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 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
hiiamboris
@hiiamboris
There was also this game about a goose that couldn't even fly straight. I added it to the showcase some time ago. It was using R/S for playing sound.
NjinN
@NjinN
@hiiamboris What is showcase?
Though I don't see any erratic goose in there.
NjinN
@NjinN
Same
GiuseppeChillemi
@GiuseppeChillemi
@burque505 Keep us updated. Windows automation is a good topic. Maybe make some blog on it, publish on github and other users will be attracted on your project and RED as language to achive their goals.
NjinN
@NjinN
The flappyBird.exe has a problem of picture flashing, and I don't know how to fix it.
hiiamboris
@hiiamboris
Yeah, flashes sometimes. And the right corner is blinking constantly
hiiamboris
@hiiamboris
@NjinN using offsets is the problem. You can instead keep the faces where they are and offset the image inside the draw block.
NjinN
@NjinN
@hiiamboris I will try it later.
Gregg Irwin
@greggirwin
@burque505, I found my old send-keys dialect. It doesn't use AHK, and is Windows only, but still works on Win10.
Gregg Irwin
@greggirwin
It's old R2 code, not ported to Red.
burque505
@burque505
@greggirwin, thanks a lot! as soon as I get time I'm going to work on that and the code from the other recent links provided to me. I really appreciate it.
Regards,
burque505
Alexander Veledzimovich
@schwarzbox
Hello. I am continue to work with live coding environment. Make some improvements after last discussion.
alt
EmptyCore
Gregg Irwin
@greggirwin

Cool @schwarzbox! I'll try to make time to check it out.

You have do [ ... and do read <file!> a couple places. The former is redundant, as the contents of the block will just be evaluated normally. Your "invisible constants" comment makes me think you hope to hide those vars, but that's not the case. For the latter, you can just do do <file!>.

R cqls
@rcqls
@schwarzbox :clap: . I guess you are developping it or macOS. I tested it on linux, everything does not work yet but it looks great. It could inspire my next debugging on Red/GTK.
Alexander Veledzimovich
@schwarzbox
@rcqls Thank you. I understand right, that in future this problems gone? And I can run same code in Linux without problem?
R cqls
@rcqls
@schwarzbox It is the goal indeed! It is already not so far… Livecoding already mostly works (as in the example in code and community repos). There is some issue with refreshing on panel and currently the tree is not working very well. The drawing zone works eventhough I did not test everything.
Alexander Veledzimovich
@schwarzbox
@greggirwin Useful thoughts. Thank you. I remove some "do" in auxiliary files. My "invisible constants" is just mark that user never have seen them in the Source editor. After your comment I move them to the main file.
NjinN
@NjinN
@hiiamboris I have fixed the flashing problem, thank you.
hiiamboris
@hiiamboris
:+1:
Toomas Vooglaid
@toomasv
@greggirwin I ported your send-keys. At least simple sending of letters seems to work. I haven't tried out other abilities yet. May-be you can show some examples of its usage (if it works of course). To get it working even so far was a major headache for me, as I am total newbe in RS :flushed: Great thanks to @NjinN and @9214 for their help!
send-keys.gif
Respectech
@Respectech
@schwarzbox Very exciting!
hiiamboris
@hiiamboris
Why do we have every actor accepting a face argument instead of referencing it by self? Can't actors object be rebound to the face?
hiiamboris
@hiiamboris
Or like this: view [base with [actors: object compose [face: (self) on-down: func [f e] [? face/type]]]]
Semseddin Moldibi
@endo64
@hiiamboris Binding cost may be?
hiiamboris
@hiiamboris
can it really justify the seeming redundancy?
Petr Krenzelok
@pekr
Part of the send-keys were utilities to position, move, bring to top windows. I have already used it with Red to change the name of the window :-)
Semseddin Moldibi
@endo64

can it really justify the seeming redundancy?

@dockimbel Can anwer that precisely.

Vladimir Vasilyev
@9214
@hiiamboris the thing is that you can't rebound object to another object.
nedzadarek
@nedzadarek

@hiiamboris so without face as argument we have to rebound it on our own?

l: layout [b: base on-down [print 'down]]
b/actors/on-down: func [event] [print 'aaaaeee]

In the above case I had to bind body of the function to the b? Or is there going to be some kind of reactors that does it for me?

Vladimir Vasilyev
@9214
Another point is that one actor can be shared by multiple faces, and each one would need to bind actor's body to itself prior to call, which is almost the same as passing arguments on stack, but with one caveat: last face that bounded body won't be freed, since it is referenced by self in actor's body. Something tells me that because of that GC might be unable to reclaim entire virtual tree of faces.
Also, self, as a keyword, exists as a backreference to the enclosing object, and can be instantiated only on object's creation (if I'm not mistaken). With your proposal you'll need something like bind <body> object [self: <face>].
Vladimir Vasilyev
@9214
With [face event] face word gets automagically bound to (any given) face at runtime, during actor's invocation. With just [event] you'll need to do that manually with actor's body, either ahead of time (provided that face already exists) or at runtime (but this is what Red already does for you, so why bother?).
hiiamboris
@hiiamboris

one actor can be shared by multiple faces

I thought so too at some point, that maybe actors are meant to be shared, but look:

>> view [style b: base on-created [probe same? b1/actors b2/actors] b1: b b2: b]
false
false
Vladimir Vasilyev
@9214
@hiiamboris I rather meant that one function can be used as a prototype for many actors (like in your example). But what if actor's body is already bound to some face? This (static) binding will persist as long as face exists, or until word is rebound to something else.
hiiamboris
@hiiamboris
I am missing something? If we have actors (like in my example) as different objects, what's the problem of binding each one to a proper face?
Vladimir Vasilyev
@9214
actors is an object!, face is an object!, you can't bind one object! to another object!, it just doesn't make any sense.
And body-of <object> returns a fresh block copy, so binding it instead won't work either.
hiiamboris
@hiiamboris
>> a: object [x: 1 b: object [f: does [x]]]
>> a/b/f
== 1
Since this magic works, it's not a problem. We can bind actor bodies after actors object is created or smth like that.
And I should clarify - what I find redundant is not that actors get a face argument for free, but that they have to use this face/facet thing every time instead of just facet, and this gets really ugly really fast.
Vladimir Vasilyev
@9214

We can bind actor bodies after actors object is created or smth like that.

...

And body-of <object> returns a fresh block copy, so binding it instead won't work either.

hiiamboris
@hiiamboris
But not body-of function.
Recently mentioned on-change* limitation comes to mind as a valid explanation. Without face/.. part it probably won't work. Still, I'm not convinced.
hiiamboris
@hiiamboris

Found a way to hack it:

>> system/view/VID/styles/style1: [
  init: [attempt [
    foreach w words-of face/actors [bind body-of select face/actors w face]
  ]]
  template: [type: 'base size: 100x100]]
]
>> view [style1 on-created [probe type]]
base

Surprisingly it even detects facet changes and redraws.

Vladimir Vasilyev
@9214
With your approach you'll need to bind each actor's body on face creation - can be done semi-automatically, fine; that way event inside body will point to evaluation stack, and all other facet words will point to face. But then, if you wish to change actor after face is created, you'll need to do it manually. And how would you deal with global event handlers?
Anyhow, sounds like too much overhead just to save a few keystrokes, and you already can do it by yourself if desired.