kuifje09's FGPlot Development

[Hooray]

according to his code, he's using it to set up plot-specific stuff:

http://pastebin.com/yrLu9j7W

Code ("At the top of"): Select all

var dum = {} ;
var menubar = {};
var sidebar = {};
var plot = {};

And then he has an _App::create() function, which is doing this:

http://pastebin.com/yrLu9j7W

Code ("_App::create() (line 540+)"): Select all

plot["canvas"] = Box.new();
plot["canvas"].create(dlg,grphB, me.sbwidth,me.mbheight,me.pwidth,me.pheight);
plot["xline"] = Xline.new();
plot["xline"].start(grph,me.sbwidth,me.pwidth,me.pheight,me.height);
plot["line"] = _plot.new();
print ( "type plot[0] : "~typeof(plot[0]));

So he does use hashes for a reason, even though it's a single shared hash for all instances of _App currently, it's only the debug/typeof() expression that treats it like a vector.

@Philosopher: What's happening here under the hood, i.e. semantics-wise: 1) we have a hash like var dum = {} and 2) someone assigns something to it by using the vector-syntax, using a number as the hash key i.e. dum[0] - which would be like dum.0 (invalid), so is it mapped to dum["0"] transparently ??

[Philosopher]

Strings and numbers are completely separate as far as hashing goes (it's much easier to generate a hascode for a number ) and they are compared for equality without conversion (so a number will only equal a number, and a string will only equal a string if it has the same data and length) - So dum[0] is different than dum["0"].

Also, instead of size(), kuifje should use this:

Code: Select all

            foreach( var i ; keys(me.Prop))
               print("graph running. plotting "~me.Prop[i]);

[Hooray]

I just tried it using the standalone interpreter (and expected to see you there...) - it really works like that, which I didn't expect at all - on the other hand, I would not have come up with such semantics in the first place

[Philosopher]

Nah, I tried it out a couple of months ago .

[Hooray]

so that is why, I was already wondering why it worked at all - without causing a parse/runtime error. This "niche language" has some fancy features

[kuifje09]

Thanks guys, I saw the construction Philosofer suggested before, but did not see why to use it.
Well that's clear now. Should use it even more...
Will try to get the rest of the code also a bit cleaner menubar.start and so on instead of menubar["start"].

Sorry to generate somuch work for you too, but some things are still a bit strange to me.

Oh, and about the foreach, that indeed is a bit smarter here. I can go on now again for a few days....

EDIT: juste tried the foreach but : Nasal runtime error: foreach enumeration of non-vector

EDIT2: this works, did not know it. thats why i used the construction with ["..."]

Code: Select all

#     plot["canvas"] = Box.new();
#     plot["canvas"].create(dlg,grphB,
#                   me.sbwidth,me.mbheight,me.pwidth,me.pheight);
     plot.canvas = Box.new();
     plot.canvas.create(dlg,grphB,
                   me.sbwidth,me.mbheight,me.pwidth,me.pheight);



[Hooray]

you will probably also want to look into turning your plot/menubar/sidebar hashes into classes with a new() constructor, unless you really want to share everything, but if you want to support multiple instances of your dialog, you'll need to use separate instances of plot/menubar/sidebar, you can then add those to your _App framework as member variable, so that you end up with App.plot, App.sidebar, App.menubar - which you can then access from your class by using me.sidebar, me.menubar and me.plot - which will allow you to support multiple fgplot dialogs running independently.

Check out the bottom of this howto (look for the section titled "A generic constructor"): http://wiki.flightgear.org/Howto:Start_ ... s_in_Nasal
It explains how to come up with a generic constructor for simple hashes using a single function:

Code: Select all

var new = func {
 return {parents:arg};
}
 
var Position3D = {x:0.0, y:0.0, z:0.0};
 
var p = new( Position3D );


In fact, you may want to introduce another small class named FGPlot that you derive from _App, where you add all fgplot-specific stuff.

http://wiki.flightgear.org/Object_orien ... g_in_Nasal

[kuifje09]

Hi Hooray, about the last example, I had to think twice...

Code: Select all

var leg = {length:0};
 var animal = {eyes:0,ears:0,legs:[] };


But you can have indeed animals which legs all different lenght ...

[Philosopher]

Whoops, I edited my post to fix that error.

[Hooray]

regarding the foreach error, you can turn a hash into a vector by using the keys() API, which accepts a hash an returns a vector of keys.
And yeah, you are right about the tutorial: It was originally intended to get people starting without any prior programming experience, just to convey the concept of OOP - so there are obviously shortcomings in it.

So you would need to initialize legs[n] by calling new(leg) and setting each leg's length separately.

PS: I suggest to base future changes on the Nasal submodule that I provided, also the PUI (property browser) issue isn't easy to solve - it may be simpler to use an alternate picker scheme, or re-implement the browser in Nasal/canvas space (which will need to be done anyways).

[Hooray]

kuije09, in case you're using git/next:
- "size" is now "content-size": https://gitorious.org/fg/fgdata/commit/ ... 2c43180496
- TheTom just implemented resizing support via a 'resize' flag: https://gitorious.org/~tomprogs/fg/toms ... 866239f4d2

Code: Select all

var dlg = canvas.Window.new([400,300], "dialog")
                              .set("resize", 1);


[TheTom]

I've now pushed my changes to fgdata. Enter the following into the Nasal console to give it a try (You can drag the dialog around and resize/close it):

Code: Select all

canvas.Window.new([400,300], "dialog").set("resize", 1).createCanvas();

If the canvas is created using 'createCanvas', the canvas is automatically resized if the window is resized. To update the layout just listen on the canvas size properties and react accordingly.

Have a look at my canvas-gui-demo branch on how to use the new widgets:

Code: Select all

var dlg = canvas.Window.new([400,300], "dialog")
                       .set("resize", 1);

var my_canvas = dlg.createCanvas()
                   .set("background", canvas.style.getColor("bg_color"));

var root = my_canvas.createGroup();
var text =
  root.createChild("text")
      .setText("This could be used for building an 'Aircraft Help' dialog.\nYou can also #use it to play around with the new Canvas system :).")
      .setTranslation(10, 30)
      .setAlignment("left-top")
      .setFontSize(14)
      .setFont("LiberationFonts/LiberationSans-Regular.ttf")
      .set("max-width", 380)
      .set("fill", canvas.style.getColor("text_color"));

dlg.addWidget( canvas.gui.widgets.Button.new(root, style, {size: [64, 26]})
                                 .setText("Ok")
                                 .move(20,  250) );
dlg.addWidget( canvas.gui.widgets.Button.new(root, style, {size: [64, 26]})
                                 .setText("Apply")
                                 .move(100, 250) );
dlg.addWidget( canvas.gui.widgets.Button.new(root, style, {size: [64, 64]})
                                 .setText("Cancel")
                                 .move(180, 200) );


[Hooray]

hey, those windows look AWESOME, and I only just realized that you are already changing the mouse cursor - I didn't even know we had a Nasal API for that ?
Also, in comparison with PUI there's a major advantage: using the "safe mode" startup profile, frame rate impact is only 35 fps here (down from 785 to 750), while PUI dialogs will slow down fps by 500 here...

[Philosopher]

Hey Hooray, you used to know that numeric-indexing worked for hashes : http://wiki.flightgear.org/Nasal_Conditionals#section_2

[Hooray]

how embarrassing ... indeed, I added at least the paragraph titled "Using Hashs to map keys to functions" - but I think I may have been under the false impression that these would be mapped to strings internally, which you clarified recently. BTW: I also looked at your optimization findings, and am currently trying to think of a way to speed up the optimizer so that we can profile a full live FG session, without any significant performance impact - checking various ideas currently, such as introducing additional OP codes for profiling, or using a dedicated profiler thread - or some form of hybrid approach. So thanks for posting your findings!