Local Version of Playground

[JohnK]

Currently I am writing PBTs (Playground Based Tutorials) . Writing the code in the playground editor is OK but since the code alters itself it can get tricky and you can lose code you have just written. Writing the code in VSCode and then copying and pasting into the PG and running is one way. The best way I have found is to

• clone Babylon.js
• install npm and monaco into the playground directory
• add simple serve script into the playground directory
• run local server
• in browser localhost.../index.js

Is this the best way to obtain and run the Playground locally? If not what is the better (best) way?

 

 

[adam]

I follow this tutorial:

https://doc.babylonjs.com/how_to/how_to_start

It's basically:

• clone Babylon.js
• npm install
• gulp run
• localhost:1338/Playground/index-local.html

[Wingnut]

(Wingy looks over John's shoulder to see what he's working-on.) 

I think we NEED TO contact the authors/maintainers of Monaco, and ask-about a "portal" or interface.

*sigh*.   You know... John, I am going to TRY to "gently steer you" towards "anyone can make a PBT using standard playground". 

When you accidentally hide-lose some PG code, due to "oh shit", have you ever tried adding 400 blank lines to the TOP of the current code, and re-save?  What does THAT do?

The whole concept of editors... analyzing what they contain... is a bit gray.  Embedded-in-code "editor directives" are looked-upon with disdain, by some.

I'm not sure HOW we're supposed to think about that.  I'm thinkin'... 

//** is start hiding here
**// is end hiding here
and... any playground URL ending in * means... "Hey editor, ignore hidings... show me entire code."

Quite a pile of annoying hopes, huh?  heh.

[Wingnut]

(more)...

Behind the scene (ar ar), the end-of-url asterisk-check/action... is done with an $editor.function()... part of that portal to the editor that could be given to us... by the good folks at Monaco Inc. 

I don't think... you will have a need to hide/unhide editor lines... dynamically (from pbt code).  Just keep your PBT-code...  //** here **//   (multiple occurrences within  same playground = allowed)

We might even have a "Don't allow gaps in line number sequences" = true;    Yeah!  (drooool)

What we DO have a need-for... is CSS-attacking certain code-lines of SHOWING code.  Flashing it, encircling it, coloring it, font-styling, underlining, copying-to-GUI-textblock, etc.

$editor.setLineStyle(lineNum, whatever);  (done from within hidden PBT-code, of course). 

This is just an example.  Ideally, the folks at Monaco will simply do a check-for plugins... in the Monaco plugins directory... and thus... we write our own editor plugin and interface.  We can add/remove/adjust editor directives anytime we wish... because the plugin is local and does not get distributed with Monaco package.

It might all be ready to happen.  Monaco might already check for add-ons.  It might simply be a "Does the boss want to allow this nonsense?" decision... now. 

[JohnK]

@Wingnut As I am busy now with family until Tuesday I will have to wait until them to read and digest your posts. Will give them serious consideration then.

[Wingnut]

  No probs, JohnnyKakes!  (I hope you don't get grumpy when I call you that) 

Really, I've placed all the "weight" onto Deltakosh, now, anyway.  He will need to "establish":

/github.com/BabylonJS/Babylon.js/Playground/editors/Monaco/plugins/monylon01.js

Then he'll adjust the playground bootstrap to haul that bitch into scope.

Then we will go crazy, adding demented things to monylon01.js 

(we can actually do it all without his help, using our own file.js, but, it would be good to have a Deltakosh wizard-dusting... to make the air smell pretty.)

And then... he needs THE WORST thing he can imagine.  "The pipe"... "the binding"... trying to figure out HOW to get Babylon engine... to ignore/hand-off occurrences of $editor.whatever()... to our new plugin.  And maybe allow $editor.property setters/getters, too. 

Deltakosh will HATE this, I predict.    To a coding "purist", this activity is a blatant slimy sneakin'-around-in-the-back-alley kludge-bind.  heh.

(At least I THINK it will feel that way to purists.  Not sure.)

Think about downloading a playground ZIP... with index.html containing a bunch of $editor.bullshit() within the code.  Scary thought.  Preventable?  Not sure.  Perhaps pre-process the code... to remove all //** stuff **// ...before assembling/zip-up of index.html?  hmm.

[JohnK]

Managed to get some time to have a read think about and answer your points.

23 hours ago, Wingnut said:

He will need to "establish":

/github.com/BabylonJS/Babylon.js/Playground/editors/Monaco/plugins/monylon01.js

 

23 hours ago, Wingnut said:

And then... he needs THE WORST thing he can imagine.  "The pipe"... "the binding"... trying to figure out HOW to get Babylon engine... to ignore/hand-off occurrences of $editor.whatever()... to our new plugin.  And maybe allow $editor.property setters/getters, too.

Not at all sure what the above means or why it is necessary - sorry.

On 11/12/2017 at 2:00 PM, Wingnut said:

$editor.function()

 

23 hours ago, Wingnut said:

$editor.whatever()

This type of thing is already available.

Code in the PBT will have a form such as

1    var createScene = function() {
    
        //code for display

        //code not for display

        return scene
43   }

//more code not for display

81    $editor.readOnly(); //needed IMHO to keep PBT working correctly for user
82    $editor.hideCodeNotForDisplay();
83    $editor.hideMoreCodeNotForDisplay();
84    $editor.styleLines(from, to); 
85    $editor.hideCodeLines(82,88);
86    if(button clicked) {
87        $editor.addLines(from, to, text);
88        $editor.hideAdditionalLines()
88    }       

When you run or save such code within the standard playground the code above is changed in the editor window of the PG. Now you could have a 'Save' that does not run the code as well as saving it but in my opinion even if this was added there are two issues.

1. Remembering to click the correct save option
2. theAs any code needs testing and development this would lead to a lot of unnecessary  PGs saved.

So IMHO there are better ways BUT even using these better ways does NOT stop the above being possible and  so

On 11/12/2017 at 1:32 PM, Wingnut said:

anyone can make a PBT using standard playground

will remain true.

A safer way is to write the PBT in your favourite text editor and then copy and paste the PBT code into the standard playground and test with RUN and not Save. When needed re-edit your PBT code in the text editor and repeat.

For me the easiest way is to have a local copy of the playground on my local computer and with a few 'minor adjustments' I can write and test a PBT in one environment and only copy the PBT code into the standard playground when I am completely happy with it. NOTE that this method will only provide a working environment for PBT testing it has nothing to do with having to PR the PBT. In fact because the 'minor adjustments' would make unnecessary changes to the playground code base this working environment should not be PRed.

Once finished I will explain in documentation and in detail

1. the functions required to add, hide and decorate text;
2. the three alternative ways of writing a PBT in a step by step manner all of which end with the PBT code in the standard playground.

[Wingnut]

Agree with all, thx J.

Yuh, yuh, yuh.  Put the PG's "replace" button... right next-to the save button?  :/   Button only offered on PG's where occurrences of $editor are found?

OMG, could that cause trouble, eh?  heh.  Handy, sometimes, though.

Yeah, your code-in-offline-editor method... is wise.  Paste'n'Run... avoid saving until final.  Best idea, so far... probably.