Closed ff6347 closed 6 years ago
Thanks! But I think we don't need any magic external stuff for this ... this seems pretty easy to write on your own ... and if external, then something more generic eg. underscore extend.
I think we do need some magic. I've been trying several ways to add the functions of an object into another functions scope in extendscript but it dies not work. I of course tried the method you suggested without luck.
Had a look into the bind-methods source. es6 to es5 transpilation does not solve the problem. Maybe the underscore extend is the way to go.
tried lodash.assign as well. No luck. If anyone as a suggestion how this could work without adding all of Basils functions to the global scope - please enlighten me 😞
So something like https://gist.github.com/medikoo/2394476 does not work in extend script?
And if your write simply at https://github.com/basiljs/basil.js/blob/master/includes/core.js#L34 eg.
glob.fill = pub.fill
Is fill
then global?
or in https://github.com/basiljs/basil.js/blob/master/includes/core.js#L46 just for the scope in setup
glob.setup.fill = pup.fill
nope. I tried several solutions. Created a small version of Basil for testing purpose https://github.com/fabiantheblind/micro-basil
Odd, we is then this line working? https://github.com/basiljs/basil.js/blob/master/includes/core.js#L3
IMO this should work ... might have time to look into it end of the week. Sorry! No more ideas on my end.
Played a bit with it.
line 3 in core adds pub
as b
to the global scope. When adding glob.foo = pub.foo
like this. It works fine. Adding pub.foo
to the scope of glob.setup
does not work.
I need to finish a project as well. Then there is some time for Basil.js 2
glob.fill = pub.fill
Is fill then global?
yes it is.
Had a look this morning. The underscore bind functions works for me. I'm able to "inject" variables e.g. var name into the scope of the draw function. But unfortunately I can't get rid of the this.name. Hmm ... ideas?
#includepath "~/Documents/;%USERPROFILE%Documents";
#include "basiljs/bundle/basil.js";
// underscore 1.4.4
#include "basiljs/libraries/underscore.js";
function draw() {
b.println("hello");
b.println(this.name); // works
// how to get this working?
b.println(name); // error!
}
this.draw = _.bind(this.draw, {name: 'moe'});
b.go();
There might be some solutions in this SO thread I started. Using eval and nasty things like that.
Hi guys, I've been thinking a lot about this issue in the last week or so. While preparing my upcoming seminar it becomes more and more obvious to me that we need to remove the b.
. It seems like there is no way to just add the functions of basil to the scope of setup and draw without doing some regex/eval magic on the functions.
Can somebody explain to me why the functions of Basil should not be in the global scope?
In Processing and in P5.js all the functions are in global scope. It is normal to not create own functions called random
or draw
and everything worked fine for the last 15 years. So my suggestion is: Let's move everything into the global scope. I gave it already a test run and there seems to be no difference in the execution time.
I tried to compare the execution time of the same code in the current version and a version where all functions of b are also added to the global scope (for backwards compatibility). As you can see there is no actual difference in the execution time.
with Basil.js 1.0.10
// @includepath "~/Documents/;%USERPROFILE%Documents";
// @include "basiljs/bundle/basil.js";
function setup () {
doc = b.doc();
b.clear(doc);
for(var i = 0; i < 500;i++){
b.ellipse(0,0,10,10);
}
}
function draw() {
}
b.go();
// with 500 ellipses
// [Finished in 13.4s] without open document
// [Finished in 17.0s]
// [Finished in 17.8s]
// [Finished in 17.2s]
with Basil.js 2.0.0
// @includepath "~/Documents/;%USERPROFILE%Documents";
// @include "basiljs/basil.js.dev/basil.js";
function setup () {
doc = doc();
clear(doc);
for(var i = 0; i < 500;i++){
ellipse(0,0,10,10);
}
}
function draw() {
}
b.go();
// with 500 ellipses
// [Finished in 13.4s] without open document
// [Finished in 17.5s]
// [Finished in 16.9s]
// [Finished in 17.6s]
Just to keep things moving: As long as b.
still works and it does not make anything slower, I would say, sure why not?
What do others say? @b-g ? @ffd8 ?
My two cents,
I'm still for the removal of b. – but want to make sure it's only done when keeping things easy and beginner-proof.
Side note.. your example above is still converting the #includes to @includes... is that really necessary? it would cause the break of all code written before. \ same is true for removing the b., it's of course ideal if done in a backward-compatible way, so b.function() still works...
Hi all,
I hereby try to summarise the discussion ... so that we finally can get that off the table:
b.something
to global scope is fine e.g. b.fill
becomes fill
. (Please research how p5.js is dealing with it)b.something
for backward compatibility reasons#includes
of examples will be untouched and will still be working@includes
will be used for everything in /src/*
I furthermore suggest:
Please go ahead!
Sounds good, just two remarks:
includes of examples will be untouched and will still be working
I see no reason to not change them all to @includes
eventually. There is absolutely no hurry for that, but in this issue I propose to improve the example scripts anyway and I think if we are touching them all anyways, we might as well just switch to @includes
. Or is there any reason not to, that I am missing?
@fabianmoronzirfas and @trych use the new global style in their teaching appointments
I can definitely mention that it works without b.
now, however, as long as all the documentation and examples still use b.
I would still prefer to also teach the b.
way. I do not think in my course it's gonna be such a problem, as I am not teaching Processing or p5.js on the side (unlike Fabian, I think). So, I will mention it, but still mainly go with b.
. Hope that's ok.
Does this mean we release a basil 1.0.11 soon before the semester begins (by Sept 19th in my case) with the global style and with the bug fixes and features we have so far? I think that should be the way to go.
as I am not teaching Processing or p5.js on the side (unlike Fabian, I think).
Yes thats right.
Does this mean we release a basil 1.0.11 soon before the semester begins (by Sept 19th in my case) with the global style and with the bug fixes and features we have so far? I think that should be the way to go.
That or we create a prerelease for the global style. The bug fixes and new features should go into master. The global style is not ready for master yet.
OK to @includes
in examples as long #includes
are working too.
OK to release the new mode as soon as possible. But this release should be clearly an alpha (unstable, not for production) of the upcoming 2.0. Hence it might be good not to communicate this on the official website.
You can of course also teach the b.
way :)
Okay guys. This commit https://github.com/basiljs/basil.js/commit/993c255138e7a7c4f78ec60d8bba4231e971c915 allows to call all functions without using b.
I'm trying to wrap my head around a way to get rid of the b.go()
as well but I can't come up with a solution. If we wouldn't have the different modes we could just call the b.go
ourselves but with the different modes there seems to be no way to do that.
So my suggestion is. Including this into the core but keep the 2.0 version backwards compatible by keeping b.go()
at the end. For a 3.0 version we could reevaluate how the whole calling of basil could be done. I could think of having the modes and and the loop function as global flags in the start of the script that get checked instead of having them as function calls and parameters.
One thing to, if you teach the usage of basil without b, is that something like:
var doc = doc();
won't work anymore. This of course overwrites the function doc. So variable and function names the user declares can not be the ones used by Basil.
I would love to hear from you about this before I create a PR.
All test passing.
Indesign returned: 53 test cases run
239 assertions run
239 passed
0 failed
Hi @fabianmoronzirfas! Yay!! 🎉 I feel so Processing like now! :) A few comments and questions:
#includepath "~/Documents/;%USERPROFILE%Documents";
#include "basiljs/bundle/basil.js";
var fill = "nonsense";
var rect = "nonsense";
var color = "nonsense";
var random = "nonsense";
function draw() {
var newRandomColor = color(random(0,255));
fill( newRandomColor );
rect(0,0,b.width,b.height);
}
b.go();
b.go();
just go()
One thing to, if you teach the usage of basil without b, is that something like:
var doc = doc();
won't work anymore.
Does that mean also var doc = b.doc();
would not work anymore? Because, if so, I think this would indeed break backwards compatibility for quite a lot of scripts.
var doc = b.doc();
still works. It's just the overwriting of global variables. It is backwards compatible.
Cool! Looking forward to this then. Had the first student today who was very fascinated that you can just take the b. out of your script and then use it in Processing pretty much straight away. He will be happy to hear that he does not need the b. in the first place from now on. 😎
Yes. I'm totally into it as well. I'll be OOO for the next few days. I hope I find some time in Quito to hack on Basil. If not I will continue on this after the 24th
b. has been removed. :) Closing.
get rid of the
b.
to make it more Processing like and even easier to write