Board index FlightGear Development Canvas

canvas.Window.new co-lateral glitch with FG Menu.

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

canvas.Window.new co-lateral glitch with FG Menu.

Postby Michat » Sun Jun 29, 2014 1:14 am

Hi there, I was trying copy/paste code to the FG's Nasal Console executing both pieces of code independently. In both cases I found problems when FG menu are deployed over a canvas screen, FG's menu get stuck in those areas when overlaps to the canvas area. So I'm reporting what I found, but also a have some silly questions:


1.
var dlg = canvas.Window.new([400,300], "dialog")
.set("title", "My Canvas Dialog...");



2.
canvas.Window.new([400,300], "dialog")
.set("title", "My Canvas Dialog...");

Being this code mostly the only I can understand in FG :D Trying to way out to my illiterate condition as code reader .......

1 why under FG's structure some folders are named with First Capital Letter (Nasal) while others like flightgear in the upper level and canvas inside Nasal are named in lowercase. ?

2. why canvas.Window.new does have a lowercase canvas, is it calling the canvas folder...? why Windows is in capitals letters?. Is it part of a poesy code style, or instead off it is a convention, or maybe a case sensitive language duty related with OS.

3. laughing loud allowed. Be free.

And thanks for your great job. Is been a hard and intense show your are giving to us with all the enhancements that Canvas receives each minute.
User avatar
Michat
 
Posts: 976
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Philosopher » Sun Jun 29, 2014 1:30 am

Welcome to programming! I hope you enjoy your swim ;)

1. Because it was created that way ;-). A lot of people (e.g. me) like to use capital folder names to make it look clean. Inside Nasal/ it's best to use lowercase, because that tells the namespace, and most programmers use lowercase namespaces in Nasal and other languages.
2. Yes, canvas is the name of the folder, all lowercase. canvas.Window is that way because it is defined that way: https://gitorious.org/fg/fgdata/source/ ... ui.nas#L59 (var Window = ...). That means it must be used that way – Nasal is case sensitive (unlike our dear friend Microsoft Windows.... ;)).
3. fortasse ego rideo, but in the sense of smiling/sonrío :D (http://es.wiktionary.org/wiki/rideo, http://en.wiktionary.org/wiki/rideo, http://en.wiktionary.org/wiki/sonre%C3%ADr)

Good luck!
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby bigstones » Sun Jun 29, 2014 9:15 am

I wouldn't laugh about those questions either, actually I find them interesting as I come from Java, which has a well established convention: lower case namespaces (the packages), lower case methods and variables/instances, capitals only for classes/interfaces, and camel case forComposedNames. Especially in Android, they also have the convention of starting with an 'm' in member variables and 's' for static ones (redundant if you use an IDE?).

So, the fact that Window "is that way because it is defined that way" worries me a bit, isn't there a convention?
bigstones
 
Posts: 95
Joined: Sat Apr 05, 2014 11:09 pm
Location: Italy
Callsign: I-NOOB
OS: Debian testing

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby TheTom » Sun Jun 29, 2014 9:34 am

Basically it's the same convention. Lower case namespaces (canvas), camel case for classes (Window), camel case with initial lower case for methods (new). For member variables I use lower_case_underscore and private/protected members/methods I prefix with an underscore (there exists no such thing as private in Nasal).
TheTom
 
Posts: 321
Joined: Sun Oct 09, 2011 10:20 am

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Hooray » Sun Jun 29, 2014 9:59 am

Michat wrote in Sun Jun 29, 2014 1:14 am:why canvas.Window.new does have a lowercase canvas, is it calling the canvas folder...? why Windows is in capitals letters?. Is it part of a poesy code style, or instead off it is a convention, or maybe a case sensitive language duty related with OS.



Those are all namespaces, NOT file names/paths. For non-coders, this one should be the most accessible explanation we have: http://wiki.flightgear.org/Howto:Unders ... nd_Methods
You could also check out this one: http://wiki.flightgear.org/Nasal_Variables
And here's a more technical one: http://wiki.flightgear.org/Nasal_Namespaces_in-depth
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Philosopher » Sun Jun 29, 2014 10:39 am

Remember: Nasal is a little scripting language, the most hard-like convention it has it runtime type-checking ;). It really doesn't care what variables you use – they're all just [_a-zA-Z][_0-9a-zA-Z]* to the interpreter. (Nasal actually doesn't have classes; if you haven't noticed, they're all plain hashes with dead-simple inheritance mechanism on member access. Thus there can't be any rules about names on classes vs functions. My next class could be named __hash_with_memberFunctions_and_newConstructor for it cares ;))

P.S. If you try my Nasal browser you'll see that some symbols are interned (displayed as symbols) while others are not (displayed as strings) Almost always the C/C++ code produces non-interned ones and Nasal produces interned ones, but I've seen some exceptions. Both were designed to work, but non-interned is less efficient (theoretically; it's probably negligible in practice from what I've seen) and means that interned symbols will be found before it, even if the interned is in a closer namespace. Anyways, that was OT :)
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Hooray » Sun Jun 29, 2014 12:18 pm

Nasal actually doesn't have classes; if you haven't noticed, they're all plain hashes with dead-simple inheritance mechanism on member access.


I find the way classes are "supported" simple and elegant enough, also due to its very simplicity.

Even though supporting access specifiers to make things private/protected would obviously help with encapsulation, and having some way to support "real" RAII by having implicitly/automatically called dtors would also be handy. Especially for FG specific stuff that is likely to "leak", as mentioned by Zakalawe: Listener objects.

Back when we were discussing GC stuff, I actually came up with a GC modification that would look for a .del() method if the naIsHash() is true and if parents is not nil - that should work and would be simple enough, i.e. we could provide a single extension function for assigning implicitly called dtors for certain VM events, such as GC'ing a released object:

Code: Select all
var Foo = {

del: func {
 print("Foo.del() implicitly called by VM/GC event !");
},


new: func {
 var m =  { parents:[Foo] };
 register_vm_handler(object: m, event: 'GC_RELEASE', pre_callback: m.del );
 return m;
},
};

var foo = Foo.new();
foo = nil;


That way, we could implement API-level helpers like maketimer() and makelistener() directly in Nasal space :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Philosopher » Sun Jun 29, 2014 12:35 pm

That violates the whole principal of a GC in my eye: ensure things in the user stack are safe, ensure completely dead (and unrecoverable!) objects are released appropriately. Calling any Nasal during GC means it's now in limbo – it could've just been referenced again if you passed it back to Nasal space, and maybe another ref was un referenced by the deletion, it might not be picked up. More dangerous than call() IMO.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: canvas.Window.new co-lateral glitch with FG Menu.

Postby Hooray » Sun Jun 29, 2014 12:45 pm

that's a pretty good point, but it was just an experiment - and back then we were talking about other extensions, and I found having a handful of "VM events" to be pretty straightforward to add, even though you are right that it isn't particularly safe/clever to call Nasal there. It was just fairly straightforward to play with the idea of responding to VM events by registering custom callbacks. I think we kinda used a similar method to expose the tokenizer/AST (parser) to Nasal a while ago, obviously that was not about "VM events" but about "lexer/parser events", but it worked well enough for our needs and could actually be used to procedurally transform/rewrite (i.e. reformat) Nasal source from scripting space, without fancy to use perl/sed or regex. And your whole decompile()/recompile() work is basically using a very similar method - maybe it just wasn't too clever that I used the same method in the GC :mrgreen:

PS: Looking really forward to seeing decompile/recompile et al committed to SG, so that we can actually use the stuff to better understand Nasal internals and how performance is affected by certain scripts.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11437
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest