Processing 1.0 - Processing Discourse - Processing in Scala: Spde

We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.

Index › Programming Questions & Help › Processing Implementations › Processing in Scala: Spde

‹ Previous Topic | Next Topic ›

Pages: 1

Processing in Scala: Spde (Read 8723 times)

n8han

Processing in Scala: Spde
Aug 29^th, 2008, 4:12am

As an experiment I decided to retrofit the Processing Development for Scala.

blah blah blah (http://technically.us/code/x/runaway-processing/)

Things have gone pretty well with this experiment. I'll try to hit some high points before we Americans all disappear from the internet for labor day weekend.

*Like the PDE but Scala sketches* The environment is mostly unchanged on its surface (and below it). You write the sketches in Scala code and then run them just like p5 sketches in the PDE. The core library is exactly the same core library.

*Build process* This fork uses Buildr to build itself, an adaptation of Rake that can pull any needed JARs from Maven repositories and elsewhere. There are no jars in the source tree.

*No preprocessor* The only sketch preprocessing step is to throw in some bracketing code. That also means there's no need for the ANTLR preprocessing step in compiling the environment itself.

*Classloader resources* All resources needed by the runtime, like interface graphics and example sources, are packaged in JARs on the classpath and fetched through the classloader rather than the user's filesystem.

*ProGuard integration* The Scala standard library is gigantic, much too big for applets. But after shrinking a Scala sketch's applet can come out smaller (88k for one I'm working on) than unshrunk Java-only sketches.

Low points?

*Most libraries not integrated* I haven't coded the buildfile for any of the libraries except xml which I needed to use in the environment itself. The others that depend on JARs will need fetch locations. Also using libraries in sketches is probably broken but not hard to fix.

If you want to check this out you need Buildr and Git. Then,

git clone git://technically.us/git/spde
cd spde
buildr spde:app-mac:run

Or if you're not on Mac then spde:app-linux:run, which should work or be close to working. Windows is probably not as close to working. There are two examples translated into Scala and available inside the environment. Translating examples is fun and I hope people want to contribute to that effort (and also perhaps the more gnarly internal porting and enhancement). Clone and branch! The big speech is starting so bye now.

Nathan

marcus

Re: Processing in Scala: Spde
Reply #1 - Sep 22^nd, 2008, 7:39pm

very, very cool!

one question though – what does it take to get the OPENGL library to run? i tried dropping SPDE.app into the Processing 0148 folder and it recognized all libraries but this sketch still fails with: value opengl is not a member of package processing

- any hints?

Code:


import processing.opengl._

size(640, 480, OPENGL) 

def draw {
  background(0)
  fill(255)
  rect(mouseX, mouseY, 10, 10)
}

n8han

OpenGL, external libraries
Reply #2 - Sep 22^nd, 2008, 8:45pm

Not implemented yet!

I haven't rigged the OpenGL module for Buildr yet. Spde *would* work with the jar distributed with Processing except that I haven't done anything to make optional libraries work either. If it is finding the jar (yay...) then maybe it just needs some tweaks to a regex to understand Scala import statements. That's probably the next thing I'm going to work on, but please feel free to beat me to it.

By the way I should announce here that there are torrents of the application package available.

Mac: http://technically.us/torrents/spde-app-mac-0147-SNAPSHOT.tgz.torrent

Linux: http://technically.us/torrents/spde-app-lin-0147-SNAPSHOT.tgz.torrent

I hope this opens Spde up to a wider audience. (I just set up a system from scratch the other day and rediscovered what a pita it can be to get the 15 great softwares I use for programming all installed and not segfaulting at the same time.)

Nathan

marcus YaBB Newbies Offline Posts: 2	Re: Processing in Scala: Spde Reply #3 - Sep 24^th, 2008, 11:00am alright. i'll give it a try later today. (if i get buildr to work – whats the best way to contact you about issues/progress – shall we use this forum?

n8han

Re: Processing in Scala: Spde
Reply #4 - Sep 24^th, 2008, 3:07pm

Probably this forum is the best place. I'm not inclined to administer one independently, and I get the impression that p.org would like to have some presence here for all the implementations.

I did just get the opengl module to compile, that's pushed into the branch now. The open question is how to actually do libraries and library imports. The answer is probably to do them just like the PDE, although in general I've been trying to have Spde be less dependent on things outside the application bundle. That is using the classloader to get example code and interface elements. But the library stuff is more user facing, and there's actually a reason for people to go into that folder and change things. So on Mac I guess the bundle should still go looking for an adjacent libraries folder.

Nathan

n8han

Spde & opengl
Reply #5 - Sep 29^th, 2008, 4:44pm

I got the opengl library working over the weekend. It builds within the Spde project and is kept inside the bundle. Tested with the Matrix example, which is now included.

A funny thing to be aware of: I went to some trouble to make it so that that sketches would not need a setup method, in general, and could instead put setup code outside of all brackets. But because that becomes constructor code (for a proxy object that is instantiated in setup() of a PApplet subclass), it is exposed to a few JVM constructor quirks, or in this case a big fat bug in Apple's 1.5 (+?) JVM. Apparently you can't call into opengl or any native code from a constructor? Or something? That was fun to discover. So as the Matrix example in Spde does you probably will want to use an override def setup() for opengl projects.

This is all pushed up to the repository. Did you get Buildr working or should I update the bundle torrent?

Nathan

n8han

Re: Processing in Scala: Spde
Reply #6 - Oct 2^nd, 2008, 6:39am

Hi everybody, opengl support and other recent stuff is available in the latest torrent. I will try to roll those out as interesting things are added or fixed. All the Spde torrents will be listed here, labeled by day:
http://technically.us/torrents/

No Windows builds still. If anybody is pining for one, make some noise and it will happen sooner.

Nathan

2280

Re: Processing in Scala: Spde
Reply #7 - Feb 3^rd, 2009, 8:50pm

Hi,

I'm using scala and p5 under eclipse and had the same problem for opengl ...
Finally, i can use OPENGL mode by importing core.jar and the opengl jars and .so (can't see processing.opengl._ neither)

Just have to resize the swing frame container when I use the OPENGL mode.

Code:


package p5

import processing.core._
import java.awt.Dimension

object Test4 extends PApplet{
  
  override def setup(): Unit = {
    size(400,300, PConstants.OPENGL)
    stroke(0)
    noFill
    smooth
  }
  
  override def draw(): Unit = {
    background(255)
    translate(width/2, height/2, 0)
    rotateZ(PApplet.radians(this.frameCount))
    box(10,20,20)
  }
  
  def main(args: Array[String]): Unit = {
    var frame = new javax.swing.JFrame("Test OpenGL")
    frame.setUndecorated(true)
    var applet = Test4
    frame.getContentPane().add(applet)
    applet.init
    frame.pack
    frame.setVisible(true)
    frame.setSize(new Dimension(400,300))
  }
  
}

+
+

excuse my english

Pages: 1

‹ Previous Topic | Next Topic ›