Processing 1.0 - Processing Discourse - Processing SVN will be a mess for a few days

fry YaBB Moderator Offline Posts: 2623 mass, usa	Processing SVN will be a mess for a few days Jul 16^th, 2007, 2:46pm ...as i do some major reworking on files. 'core' should be intact, but the actual application has some serious changes happening. if you need to use the svn version, i recommend checking out a particular tag (processing-0125, in particular). this will hopefully be straightened out by the end of the week (July 20 or so).

mellis

Re: Processing SVN will be a mess for a few days
Reply #1 - Jul 18^th, 2007, 4:32pm

This is probably the wrong time to ask, but as long as you're moving things around I'd like to make a request. Is there any possibility of removing the dependence that the app code has on the core (possibly by refactoring common code out into a shared module)? In particular, I've been holding off porting recent Processing app improvements to Arduino because I'm scared of having to include portions of the Processing core (e.g. PApplet.platform).

In general, it would be great if the PDE was more modular, so that Arduino, Wiring, Mobile Processing, etc. could all use the same app source code - and so we could all more easily make improvements that would also be included in Processing. Of course, this would be a lot of work, but I for one would be willing to help. Do you think this is at all feasible?

Again, I know this may not be a reasonable request, but I wanted to at least mention it while you're doing some reorganization.

fry

Re: Processing SVN will be a mess for a few days
Reply #2 - Jul 18^th, 2007, 5:59pm

hi dave, thanks for bringing it up... is there a problem with including core.jar with the app? it's interesting you mention it, since i've actually been heading the opposite direction--that i've been making more and more use of the static methods from PApplet in processing.app.* (i.e. PApplet.platform instead of Base.isMacOS(), and PApplet.open() instead of Base.openFolder()).

mellis

Re: Processing SVN will be a mess for a few days
Reply #3 - Jul 19^th, 2007, 5:26pm

Hmm... interesting. It's not a problem to include the .jar, as long as you don't inherit dependencies on things like Quicktime or OpenGL. I know that Processing tends to "just work" and therefore so should anything that uses core.jar, but it seems like it could add a lot of complications. Do you know if possible to call the functions that the PDE needs without worrying about the larger dependencies? If not, I can always extract the functions I need.

The larger issue is whether it would be possible to organize the PDE code in such a way that another application could use things like the editing and sketch management functionality while specifying its own menu items, toolbar buttons, file types, etc. This might be something that none of us have time to make happen, but it's possible that with enough applications and developers using the core IDE functionality, the gain of sharing the code would outweigh the work of making it sharable. What do you think?

At some point, I'm going to need to port the improvements you've made to Processing over to Arduino - I could try to do that by factoring out the common functionality and creating two custom wrappers on top of it - one for Processing and one for Arduino. I think it's only a few classes that would need modifying (Editor, Sketch, EditorButtons) - the rest are either the same for both applications or completely distinct and independent. If I could actually get that done, would you be interested in maintaining that level of abstraction, or would it be too much overhead?

In any case, I should thank you again for the amazing work you've done on Processing. Arduino certainly wouldn't exist in anything like its current form if it wasn't for you and Casey. The PDE has been a great foundation for the Arduino environment.

fry

Re: Processing SVN will be a mess for a few days
Reply #4 - Jul 19^th, 2007, 10:41pm

mellis wrote on Jul 19^th, 2007, 5:26pm:

Hmm... interesting. It's not a problem to include the .jar, as long as you don't inherit dependencies on things like Quicktime or OpenGL. I know that Processing tends to "just work" and therefore so should anything that uses core.jar, but it seems like it could add a lot of complications. Do you know if possible to call the functions that the PDE needs without worrying about the larger dependencies If not, I can always extract the functions I need.

yes, that's how it's intentionally structured. you can add core.jar and there are no other dependencies like opengl and quicktime. there's been lots of effort (i.e. making size() load things dynamically) to make core an island.

mellis wrote on Jul 19^th, 2007, 5:26pm:

The larger issue is whether it would be possible to organize the PDE code in such a way that another application could use things like the editing and sketch management functionality while specifying its own menu items, toolbar buttons, file types, etc. This might be something that none of us have time to make happen, but it's possible that with enough applications and developers using the core IDE functionality, the gain of sharing the code would outweigh the work of making it sharable. What do you think

to do this much work, i'd rather start with a better editing and application framework to begin with. for instance, i'd rather start with the eclipse jdt stuff, and build something on top of that. or even use jedit. in either case, i'd start with the original app and strip the thing way down. your point of "none of us have time to make [it] happen" is exactly correct. there's lots of lovely refactoring that could be done, but the amount of time does not match what you'd get for the investment. casey and i have been looking at those sort of changes as the only real change in 2.0.

mellis wrote on Jul 19^th, 2007, 5:26pm:

At some point, I'm going to need to port the improvements you've made to Processing over to Arduino - I could try to do that by factoring out the common functionality and creating two custom wrappers on top of it - one for Processing and one for Arduino. I think it's only a few classes that would need modifying (Editor, Sketch, EditorButtons) - the rest are either the same for both applications or completely distinct and independent. If I could actually get that done, would you be interested in maintaining that level of abstraction, or would it be too much overhead

this level of abstraction sounds about right, and we should discuss how to make it easier on you guys. maybe we can file a bug for this one and continue discussion there on how to put it together properly

this is also the level of stuff i'm dealing with in 0126 (adding multi-window support) and probably also in 0127 (adding tools menu), so it would be good to have it in now.

mellis wrote on Jul 19^th, 2007, 5:26pm:

In any case, I should thank you again for the amazing work you've done on Processing. Arduino certainly wouldn't exist in anything like its current form if it wasn't for you and Casey. The PDE has been a great foundation for the Arduino environment.

we're just big fans of arduino Wink

mellis

Re: Processing SVN will be a mess for a few days
Reply #5 - Sep 4^th, 2007, 2:10am

I just went ahead and merged all your improvements through Processing 0125 into the Arduino code base. It was surprisingly painless. Thank you for the care you took in making the core standalone. I was able to just drop it into the Arduino project and it worked fine (I guess I got a lot of graphics functionality that I don't need, but it doesn't hurt anything).

Actually, the only place where it seemed like it might be worth doing a bit of refactoring is the file extensions in Sketch.java. Arduino uses .c / .cpp / .h instead of .java (though it keeps .pde), and it might be nice to be able to just declare that in a variable somewhere. In any case, it's not a high priority, since it's not hard to merge in any improvements you make to the Sketch class anyway. The rest is mostly adding or removing menu items, or adding functions to handle the Arduino serial monitor, neither of which really get in the way of syncing code between the projects.

Again, thanks for all your hard work. It will be great to have printing, copy for discourse, and all the other new features in Arduino.

fry

Re: Processing SVN will be a mess for a few days
Reply #6 - Sep 5^th, 2007, 4:16pm

cool, i'll make a note and move the extensions out.. prolly will just use a preference to have a list of file extensions, that way we don't even have to get into some sort of "registerExtension()" silliness. the extension handling stuff is goofy in its current implementation, so this will be a good excuse to clean it up for 0126.

fry YaBB Moderator Offline Posts: 2623 mass, usa	Re: Processing SVN will be a mess for a few days Reply #7 - Sep 5^th, 2007, 4:18pm also fyi... the svn is still a bit of a mess, i was working on it for a couple days then got sidetracked by book deadlines and traveling, so things are still messy. for those interested, just use the processing-0125 tag until i get a chance to get back to things.

fry YaBB Moderator Offline Posts: 2623 mass, usa	Re: Processing SVN will be a mess for a few days Reply #8 - Oct 10^th, 2007, 1:16pm with the release of 0126, this should be all set, and svn should be back to normal. if not, please post a bug in the bugs db.