arctic: ArcticState

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

arctic: ArcticState

Craxy Z
Hi,
  I'm using ArcticState to implement a trace window like this:

-- Code Start --
private var traceState:ArcticState<String>;

public function new() {
    traceState = new ArcticState<String>('', function(t:String) {
            return Arctic.makeText(t);
        });
}

public function trace(v:Dynamic, ?inf:haxe.PosInfos) {
    var s = inf == null ? '' : inf.fileName + '(' + inf.lineNumber + '):';
    try s += Std.string(v) catch(e:Dynamic) s += '????';
    traceState.state += s + '\n';
}
-- Code End --

Now my question is everytime a new trace incoming, Arctic.makeText got
called. this is just a demo, how about
a more complicate block inside the callback function? could this cause
a terrible performance problem? or should I
try another way to do this?
In my old none arctic version, I just use a TextField to do this, when
new trace coming, only a textField.text += s + '\n'
was called. Now the TextField is an internel component of Text block,
how can I operate it directly now? for example, I
create a Text block, and wanna change the TextField's type.

Thanks.

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: arctic: ArcticState

gershon
Just a very small comment on the subject, seems that you can get better performance on fp9 using TextField.appendText()...

On Fri, Oct 30, 2009 at 9:22 AM, Craxy Z <[hidden email]> wrote:
Hi,
 I'm using ArcticState to implement a trace window like this:

-- Code Start --
private var traceState:ArcticState<String>;

public function new() {
   traceState = new ArcticState<String>('', function(t:String) {
           return Arctic.makeText(t);
       });
}

public function trace(v:Dynamic, ?inf:haxe.PosInfos) {
   var s = inf == null ? '' : inf.fileName + '(' + inf.lineNumber + '):';
   try s += Std.string(v) catch(e:Dynamic) s += '????';
   traceState.state += s + '\n';
}
-- Code End --

Now my question is everytime a new trace incoming, Arctic.makeText got
called. this is just a demo, how about
a more complicate block inside the callback function? could this cause
a terrible performance problem? or should I
try another way to do this?
In my old none arctic version, I just use a TextField to do this, when
new trace coming, only a textField.text += s + '\n'
was called. Now the TextField is an internel component of Text block,
how can I operate it directly now? for example, I
create a Text block, and wanna change the TextField's type.

Thanks.

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: arctic: ArcticState

Craxy Z
2009/10/30 gershon <[hidden email]>:
> Just a very small comment on the subject, seems that you can get better
> performance on fp9 using TextField.appendText()...
>

Thanks for the tip, I'll give it a try.

Looks like Asger's mail got some problem. Here is his solution:

> You can use an Id block, and then getRawMovieClip, and then find the textfield there.

I think this is little tricky, looks like the Arctic use a thought of
immutable variable scheme
in most functional programming languages, so every block was created
and destroyed, but never
modified. you wanna modify, need to create a new one and replace the
old one. IMHO, without a
compiler or vm support, this could cause performance issue in some
situation. yes, by the trick
method we can get an escape. but I don't think it's a clean & clear
style. how about add a reference to the key items in the block
interface?

Think about another situation, the Arctic blocks was defined by enum,
ok, basic block types was
battery inside, but what if I need more, how can I make new block type
by extend this enum? I know there is CustomBlock, ok, this is a way,
but CustomBlock envalope blocks, what if I wanna reuse a component not
powered by arctic? is there any envalope way?

Back to my question, if there is such envalope way, I can create a
TextField by my own, and
save it's reference, then pass it to an envalope to make an arctic
block. now I can have arctic power without lose full control to the
original TextField.

Again, I know the triky way works, I just wanna Arctic be better.

Regards,
Z

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: arctic: ArcticState

back2dos
In reply to this post by gershon
gershon wrote:
> Just a very small comment on the subject, seems that you can get
> better performance on fp9 using TextField.appendText()...
Just another small comment: Yes, this really works faster. mxmlc will
even give you warnings if you use text+=someText instead of
appendText(someText). But I experienced cases where text was appended in
different order than my calls where (especially when doing a lot of
calls (i was outputting rather large trees, logging some recursive
algorithm)). This was maybe 1.5 years ago, so I guess it's fixed by now,
but I wanted to mention it, just in case someone runs into weird
problems (really took me a while to figure out what the problem was). At
that time, I simply subclassed TextField to override this behaviour by
accumulating the text, invalidating the stage, and then appending it at
once on Event.RENDER.

greetz
back2dos

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: arctic: ArcticState

alstrup
In reply to this post by Craxy Z
You are right that Arctic is based on destroy/create for updates. That keeps things simple, and works well with the value-based enums. We did not have any performance problems with this approach so far, but if you need something else, the best is surely to create a CustomBlock for it. In case you have a fixed number of states to choose from, there is also the select block.

Regards,
Asger


--
haXe - an open source web programming language
http://haxe.org