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

[Michat]

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 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.

[Philosopher]

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 (http://es.wiktionary.org/wiki/rideo, http://en.wiktionary.org/wiki/rideo, http://en.wiktionary.org/wiki/sonre%C3%ADr)

Good luck!

[bigstones]

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?

[TheTom]

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).

[Hooray]

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

[Philosopher]

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

[Hooray]

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

[Philosopher]

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.

[Hooray]

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

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.