New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check if library is installed before running sketch; if not, prompt to install #2566

Closed
alignedleft opened this Issue Jun 6, 2014 · 15 comments

Comments

Projects
None yet
6 participants
@alignedleft
Copy link
Member

alignedleft commented Jun 6, 2014

When sharing sketches with others, the sketches can't be run unless all required libraries are installed.

Add logic that, when a sketch is about to be run, checks to see if the required libraries are installed. This could be based on looking at any import statements in the code, and then taking a best guess about what's needed. For example, if my code includes: import peasy.*; we can assume I would need the PeasyCam library installed.

If the libraries are installed, run per usual. If they are missing, introduce a prompt to facilitate download and installation through the contribution manager. (For example, "This sketch may require ___ and ___. Download and install them now?")

Request posted per @benfry in our conversation today.

@fjenett fjenett added this to the GSOC 14 - Joel/Florian milestone Jun 10, 2014

@tillnagel

This comment has been minimized.

Copy link

tillnagel commented Jun 16, 2014

Just to say this would be fantastic for beginners. I typically add used libraries to the /code folder of the sketch for distribution, but this would heavily reduce file size, and teach about library use, on the side.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Aug 22, 2014

What would be the best way to go about this? While most libraries may be guess-able from the import statement, it may be harder for some libraries (Eg: AppleLight Sensor has an import statement import lmu.*;). So, I could do one of the following:

  1. Take the case of such imports, where the library to be imported can't be determined directly from the import statement direcly, separately and specifically.
  2. Ignore such cases where the library to be imported can't be determined directly from the import statement, and take into account only those import statements have a substring that matches a library name.
  3. Add a field to the .properties file which contais the most general form of the import statement. For example, Arduino (Firmata) library has 2 different import statements: import org.firmata.*; and import cc.arduino.*;, so the entry would be something like org.firmata, cc.arduino. However, AI for 2D Games has statements like import game2dai.entities.*; import game2dai.entityshapes.ps.*; import game2dai.maths.*;, so an entry of game2dai would suffice.

Which of these methods would be the best? I'm a little biased towards 2, as it seems the most general and hastle-free. Will have to add to the libraries contributions page that it would be recommended that the contributors have their folder strucutre so that the full class path contains at least a substring of their libray name though.

Have I missed something? Is there an easier way to do this?

Thanks

@benfry

This comment has been minimized.

Copy link
Member

benfry commented Aug 22, 2014

I lean toward the third option... We could add this field to the current list as a one-time thing, and for the future, library authors can tweak it.

As an aside, I think the idea would be to make sure that the imports mentioned be as specific as possible, so that it's not a matter of listing all the packages in the library (which could be many), but rather, the ones that users would actually include.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Aug 22, 2014

Perfect. Thanks!

@benfry

This comment has been minimized.

Copy link
Member

benfry commented Nov 19, 2014

@Manindra29 This is implemented (though imperfect), right?

@Manindra29

This comment has been minimized.

Copy link
Member

Manindra29 commented Nov 19, 2014

No, this is not implemented. Error checker shows an error that The class XYZ doesn't exist. Import suggestions are shown only if the library is installed.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Nov 19, 2014

Since I have exams going on right now, would it be alright if I finish
implementing this in around 3 weeks' time?

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Dec 18, 2014

OK. I have begun implementation. However, the method which I'm using to find import statements at present searches the entire sketch for import statements. Is there a more elegant way to do this? Does the new Java mode already search for import statements when generating the AST? If so, shall I make this a feature specific to the new Java mode? If not, would there be a more efficient way of doing this?
@Manindra29 @benfry
Thanks.

@Manindra29

This comment has been minimized.

Copy link
Member

Manindra29 commented Dec 18, 2014

The new Java Mode uses regex to find import statements while generating the AST. See here. I feel this feature could be added to the core Java mode(2.0) so that the new Java mode will have it directly. @benfry, please confirm.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Dec 20, 2014

Ah perfect, thanks. So in the implementation, shall I check whether or not the current mode is Java; if so, then leave the implementation to the mode (and I'll add the implementation to the location you showed me, @Manindra29), and if not, then implement it within, say, the prepareRun() method?

@Manindra29

This comment has been minimized.

Copy link
Member

Manindra29 commented Dec 20, 2014

I pointed out the method in PDE X code to show you how PDE X checks imports
while building the AST. You'll probably need to do something similar.
Don't implement it inside prepareRun(). Have a separate function for it,
and call it from within prepareRun().

On Sat, Dec 20, 2014 at 7:55 AM, Joel Moniz notifications@github.com
wrote:

Ah perfect, thanks. So in the implementation, shall I check whether or not
the current mode is Java; if so, then leave the implementation to the mode
(and I'll add the implementation to the location you showed me,
@Manindra29 https://github.com/Manindra29), and if not, then implement
it within, say, the prepareRun()
https://github.com/processing/processing/blob/master/app/src/processing/app/Editor.java#L2765
method?


Reply to this email directly or view it on GitHub
#2566 (comment)
.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Dec 21, 2014

Ah yes, a separate method is what meant to do. So this method should be
common to all modes, as opposed to having a separate implementation (in the
place you showed me) for the java mode?

@Manindra29

This comment has been minimized.

Copy link
Member

Manindra29 commented Dec 21, 2014

Yeah, IMHO it should be a part of processing.mode.java.
On Dec 20, 2014 7:25 PM, "Joel Moniz" notifications@github.com wrote:

Ah yes, a separate method is what meant to do. So this method should be
common to all modes, as opposed to having a separate implementation (in the
place you showed me) for the java mode?


Reply to this email directly or view it on GitHub
#2566 (comment)
.

@joelmoniz

This comment has been minimized.

Copy link
Member

joelmoniz commented Mar 17, 2015

@Manindra29 Thanks! I've submitted PR #3155, where I've done the appropriate checks from within a function that calls prepareRun() in processing.mode.java

@benfry benfry closed this in #3155 Mar 30, 2015

@benfry

This comment has been minimized.

Copy link
Member

benfry commented Mar 30, 2015

Incorporated for 3.0a6. Let the debugging begin!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment