@jeremydouglass Any updates on this?
Hi @KartikSoneji – sorry, no updates. I am not a core developer on the Processing repo. I believe that ben fry is reviewing and merging almost everything there, and things happen as they can based on his limited availability. I’m hoping this gets a favorable look soon and am happy to chime in further on the issue / PR when it does.
@jeremydouglass oh, I thought that you were a core developer.
I completely understand.
Could you suggest something else that I could work on in the meanwhile?
Thanks again for your help and support.
Sorry for the confusion. I am a moderator on the forums and active on repo issues, but I tried to communicate the key gatekeeper is ben fry.
Great question! Do you mean issues on Processing 3 specifically, or other things in the ecosystem with quicker PR review times?
One suggestion that I have is to reach out to @sampottinger about the current work on Processing 4 – there might be ways to get involved there.
Another possibility beyond the core is if you wanted to contribute to one of the Processing libraries. There are fork mirrors to ~400 here:
Contributing to a library or mode can also be a great way to learn the how libraries work and the PDE Contributions architecture and distribution system. Here are a few libraries that are currently in active development / recently updated:
In addition, if you are excited about the pedagogical side, you might also consider contributing to the Rosetta Examples set (disclaimer: I coordinate that project):
There are many fun simple issues for first contributions, and the sky is the limit there (as there are many hundreds of unported tasks, some quite difficult).
Other people may have other suggestions – it is a big community with a lot of worthy projects in it that welcome contributions.
Al iniciar el IDE, si yo me llamo “luis”, podria crear sketches con el sistema basico de nombres:
sketch name = “luis” + “_” + counter + “.pde”;
asi, si yo soy luis, mis aportaciones seran luis_000… luis.001… luis_xxx…
Hi @erkosone!
Thanks for your suggestion.
I have two questions:
- What happens after
luis_999
? - What happens if the user creates
luis_001
andluis_002
, then deletesluis_001
? Does the next project have the nameluis_001
orluis_003
?
Also, are you sure that this scheme will be used by many users?
What do you think, @jeremydouglass ?
Thanks for such a comprehensive answer.
Nothing in particular. I was thinking of improving the build process for Processing 3 because as it stands right now, the build environment is a pain to setup. But if Processing 4 is coming out then I think that it will be better to work on that first.
I was also thinking of setting up a Dockerfile so that we can at least check that PRs compile successfully.
That seems like a good idea. I will look at the issues do what I can.
Contributing to libraries tends to be prone to feature-creep, especially as I do not use Processing and am not familiar with the libraries.
Hmm. Counters in the Untitled_1, Untitled_2, Untitled_3 system are used by a lot of office / document software. On creating a new file, it tries to create Untitled_1 and then fails-up until it hits a number that isn’t taken – so if you have
Untitled_1
Untitled_2
Untitled_4
…then your next one created will be Untitled_3. MSWord does this. So does TextMate.
So it seems like this would be two things:
- a counter
- a customized label – so instead of “sketch” it could be “bosquejo” or “luis”.
In theory you could then mix and match – luis_200512b, sketch_3, IridescentTurnip_3 etc. – but it all seems like this is all potentially getting very complicated for an interface aimed at least partly at learners.
If the goal is to have a list of sketches:
luis_1
luis_2
…
luis_48
…for instance for upload to a gallery or repo, then it might make sense to use a renaming script instead?
Sounds great! Perhaps before diving into that take a look at Sam’s fork, and/or issues / open PRs on Processing 3. It is possible that those things were already suggested and either haven’t happened yet or current main contributors have a specific way of working for builds / CI that they might not want to change. I personally would love a Docker based CI setup.
I agree, this might become too complicated.
It is quite easy to write a renaming script in Java itself.
As a side note, I was thinking that if we are including the list of friendly words then it makes sense to give the users access to the FriendlyWords
class. Combined with the random(Object[])
function, it can be used as a simple random word generator.
Bien… quizas seria mejor algo asi:. Date + _xxx
Es poco probable que alguien cree 1000 proyectos el mismo dia.
Cuando se crea un proyecto nuevo siempre sera con +1 al numero mas grande encontrado.
Creo que la forma en que ya funciona en este momento es que la Date obtiene un sufijo de letra (200512a …b …c …d) en lugar de un contador.
Sorry, I didn’t understand this part. Give users access how?
For example, the user should be able to write a sketch like:
void setup(){
print(FriendlyWords.objects[10]);
}
Ah, yes! That could definitely be done with a library, so a user could import FriendlyWords.*;
– it just wouldn’t be included in the core Processing API, and the sketch wouldn’t access code used by the PDE application in that way.
As I understand it, when Processing is used in PDE (as opposed to using Processing as a Java library e.g. with Eclipse or Netbeans) the pre-imported functionality includes the core Processing API and passing through some Java 8 builtins that you don’t need to explicitly import. For the core itself, I believe that almost all dependencies are java.etc or javax.etc (with a few exceptions like com.jogamp.opengl and org.xml). Otherwise all other code available to sketch writers is handled through library imports – including even core libraries that pre-installed, like Network, Serial, and PDF Export. Even audio and video are handled through library imports.
Hmmm. So what you are saying is that the FriendlyWords
class will need to be included as a library? I do not see the point of duplicating code, as the Processing app will already have the entire class.
Is there no way to import the class directly from the app? Maybe as a default import so that the user does not have to worry about the import path.
I think this is unfortunately a moment where, because you are not a Processing user, you may not be quite getting what Processing is. It isn’t an app. It is a language (a Java dialect transpiled into Java) and a core API, and the app supports working with that language.
So this is like a bit like saying “now we are using FriendlyWords in Eclipse to handle file saving – can’t all Java programs automatically import FriendlyWords?” They can’t for a variety of reasons. One is that Eclipse is not Java. Processing is used to program outside of PDE, so it sets up an expectation that something will work which won’t. Another is that the API is targeted (with more or less coverage) by many other modes, including p5.js, processing.js, processing.py, p5py, pyp5js, Processing.R, JRubyArt, and others. Some of these modes are modes for the PDE app itself – you can load them through Contributions Manager and change mode on a sketch window. Just because FriendlyWords is in the PDE file manager doesn’t mean it is available in any of those contexts, and the PDE app itself – because it is designed for multiple language support – treats each language as separate, and doesn’t mix its own internals in with those languages. (although Java mode is default / first). The number of things that PDE does in a “built-in” / magic-import way without explicit import is constrained almost entirely to what the core is as a shared target of support – the language API itself covered in the reference documentation, which you can also import into a Java project and use in a non-transpiled Java syntax.
Over time, Processing’s core has expanded to include a few things like Table and PShape, but these are all multipurpose general programming facilities. FriendlyWords are convenient methods for manipulating a specific list of fun words. It doesn’t make sense to add to a language core.
OK. That makes sense.
But what I was referring to is that we provide some way for users to access just the list of FriendlyWords
, but I understand that might get complicated if other languages are involved.
The only other option that I see is making (just) the list of FriendlyWords
part of the core Processing library itself, but that seems unnecessary.
The easiest thing would be just to create a FriendlyWords library package. It could even have multiple mode support if you liked, so that it would also work in p5.js etc. Then any user could import it and use friendly words.
I see you what you mean about “just the list”, but to put it another way: programming editors in general don’t have a sense of “non-project data” in this way, for lots and lots of reasons, a main one being portability. Eclipse and Netbeans don’t have magic data text files that can be referenced without import and that only work when Java programs are run within them, or that are magically copied into project directories only when referenced in code without import. (This is important because PDE has a sketch export-to-app feature – it needs to bundle up the sketch with a mac/win runtime that will execute outside PDE, so on export you have to either break the sketch or implicitly copy out the data). With a few exceptions (long lists of color name constants, for example), most programming languages don’t have much “data” in this way at all. If you want to add data to a program / project / sketch, you add it explicitly.