finalizing everything for rev 0083

This commit is contained in:
benfry
2005-04-18 00:13:40 +00:00
parent b328a0e977
commit 1dd043d629
7 changed files with 57 additions and 797 deletions
+6 -13
View File
@@ -14,12 +14,9 @@ rm -rf processing-*
cp -r ../shared processing
# add the libraries folder with source
#cp -r ../../lib work/libraries
cp -r ../../net work/libraries/
cp -r ../../opengl work/libraries/
cp -r ../../serial work/libraries/
#cp -r ../../video work/libraries/
# doesn't work on linux, don't include it and confuse people
# new style examples thing ala reas
cd processing
@@ -32,16 +29,12 @@ unzip -q reference.zip
rm reference.zip
cd ..
# clean out the cvs entries
find processing -name "CVS" -exec rm -rf {} ';'
#find processing -name "CVS" -exec echo {} ';'
# add java (jre) files
#tar --extract --verbose --file=jre.tgz --ungzip --directory=processing
tar --extract --file=jre.tgz --ungzip --directory=processing
# directories used by the app
mkdir processing/lib/build
#mkdir processing/lib/build
# grab pde.jar and export from the working dir
cp work/lib/pde.jar processing/lib/
@@ -54,18 +47,18 @@ chmod +x processing/jikes
# make sure notes.txt is unix LFs
# the 2> is because the app is a little chatty
dos2unix processing/readme.txt 2> /dev/null
dos2unix processing/revisions.txt 2> /dev/null
dos2unix processing/lib/pde.properties 2> /dev/null
dos2unix processing/lib/preferences.txt 2> /dev/null
# remove boogers
#find processing -name "*~" -exec echo {} ';'
#find processing -name ".DS_Store" -exec echo {} ';'
#find processing -name "._*" -exec echo {} ';'
find processing -name "*~" -exec rm -f {} ';'
find processing -name ".DS_Store" -exec rm -f {} ';'
find processing -name "._*" -exec rm -f {} ';'
# clean out the cvs entries
find processing -name "CVS" -exec rm -rf {} ';' 2> /dev/null
#find processing -name "CVS" -exec echo {} ';'
# zip it all up for release
echo Creating tarball and finishing...
P5=processing-$REVISION
+13 -32
View File
@@ -15,11 +15,10 @@ else
REVISION=0000
fi
#VERSIONED=`cat ../../app/PdeBase.java | grep 00$REVISION`
VERSIONED=`cat ../../app/PdeBase.java | grep $REVISION`
VERSIONED=`cat ../../app/Base.java | grep $REVISION`
if [ -z "$VERSIONED" ]
then
echo Fix the revision number in PdeBase.java
echo Fix the revision number in Base.java
exit
fi
@@ -55,16 +54,6 @@ unzip -q reference.zip
rm reference.zip
cd ..
# clean out the cvs entries
find processing -name "CVS" -exec rm -rf {} ';'
#find processing -name "CVS" -exec echo {} ';'
# get serial stuff
#cp dist/serial_setup.command processing/
#chmod a+x processing/serial_setup.command
#cp ../../bagel/serial/RXTXcomm.jar processing/lib/
#cp ../../bagel/serial/libSerial.jnilib processing/
# get ds_store file (!)
cp dist/DS_Store processing/.DS_Store
@@ -78,7 +67,7 @@ mkdir -p $RES
mv processing/lib/*.jar $RES/
# directories used by the app
mkdir processing/lib/build
#mkdir processing/lib/build
# grab pde.jar and export from the working dir
cp work/lib/pde.jar $RES/
@@ -92,27 +81,19 @@ chmod a+x processing/jikes
chmod a+x processing/Processing.app/Contents/MacOS/JavaApplicationStub
cd ../..
javadoc -public -d doc app/*.java app/preproc/*.java app/syntax/*.java core/*.java opengl/*.java net/*.java video/*.java serial/*.java
cd build/macosx
pwd
exit
#cd ../..
#javadoc -public -d doc app/*.java app/preproc/*.java app/syntax/*.java core/*.java opengl/*.java net/*.java video/*.java serial/*.java
#cd build/macosx
#cp dist/lib/pde_macosx.properties processing/lib/
# convert notes.txt to windows LFs
# the 2> is because the app is a little chatty
#unix2dos processing/notes.txt 2> /dev/null
#unix2dos processing/lib/pde.properties 2> /dev/null
#unix2dos processing/lib/pde.properties_macosx 2> /dev/null
# something like the following might be better:
# find / -name "*.mp3" -exec rm -f {}\;
# and same for cvsignore, ~ files, .DS_Store
# remove boogers
find processing -name "*~" -exec rm -f {} ';'
#find processing -name ".DS_Store" -exec rm -f {} ';' # one is legit
# need to leave ds store stuff cuz one of those is important
#find processing -name ".DS_Store" -exec rm -f {} ';'
find processing -name "._*" -exec rm -f {} ';'
find processing -name "CVS" -exec rm -rf {} ';'
# clean out the cvs entries
find processing -name "CVS" -exec rm -rf {} ';' 2> /dev/null
find processing -name ".cvsignore" -exec rm -rf {} ';'
mv processing/Processing.app "processing/Processing $SHORT_REVISION.app"
mv processing processing-$REVISION
-290
View File
@@ -1,290 +0,0 @@
KNOWN BUGS FOR THE MOST RECENT RELEASE
this was moved out of the release notes since it's getting too long,
and since only a handful of things change between releases
..................................................................
PROCESSING WON'T START! NOTHING HAPPENS WHEN I CLICK "RUN"!
- on windows, processing probably won't work if you install it inside
a folder with non-ascii characters in its name. for instance, if the
name of your user folder uses japanese text, or it has an umlaut or
cedilla or anything else fancy, and processing is on the desktop, or
somewhere inside that folder, you're gonna have trouble. the fix is
to place processing inside the root level of your C:\ drive (or
whatever drive you use) and it'll be ok again. this will be fixed in
the future.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1062794781
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1067764732
- windows.. if you have lots of garbage in your CLASSPATH environment
variable, that might cause trouble starting up a sketch. you might
get "Couldn't find package xxx.xxx" errors. clean things up (avoid
spaces and quotes)
http://processing.org/discourse/yabb/YaBB.cgi?board=BugFixes;action=display;num=1096302833;start=0
- windows.. in general, perhaps avoid having spaces in the folder name
that contains processing. this is because of windows' awesome
hokiness and its not-as-distant-as-it-should-be ancestor DOS.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1094148057
- windows.. if you're still having trouble, disable any overly
protective virus scanning software. it might be holding things up.
- windows.. you might also try using run.bat to start processing. lots
of people seem to have a better time with this method.
- any platform.. errors inside code that is outside of setup() or
loop(), for instance this code:
PFont font = loadFont("blah.vlw");
void setup {
// something fancy
}
may just hang/freeze processing if "blah.vlw" is not in the "data"
folder. in general, a better practice is to use loadFont() (and
loadImage and the rest) inside of a function like setup().
- on 50% of machines, there still seems to be a bug that causes the
application to hang completely when something that uses a library
(or a code folder) is run. symptom will be a non-responsive applet
that either never shows up, or shows up but never draws (perhaps
until you hit stop) or draws three frames and then dies. this will
only happen with applets that have a "coffee cup" icon in the
window (that's how you know it's running externally).
- on macosx, something like the following error might occur:
dyld: /Applications/processing-0079/jikes version mismatch for library: /sw/lib/libiconv.2.dylib (compatibility version of user: 5.0.0 greater than library's version: 3.0.0)
it seems that this happens when an older version of fink is
installed. in this case, you should either disable fink or update to
the latest version. (thanks to ryan govostes for tracking this down)
..................................................................
COMMON ISSUES (NOT BUGS)
things that are often perceived as bugs, which means maybe they'll be
changed in the future, but for now, they're not actually 'broken'.
- names of sketches cannot start with a number, or have spaces
inside. this is mostly because of a restriction on the naming of
java classes. i suppose if lots of people find this upsetting, we
could add some extra code to unhinge the resulting class name from
the sketch name, but it adds complexity, and complexity == bugs. :)
- if you get a "ClassCastException" when trying to run your code in a
browser, you're probably trying to run non-java 1.1 code. this
means any classes that didn't exist in java 1.1. or, if if you're
exporting as applet, variables that are 'final int' need to be
'static final int'. otherwise they'll have trouble with a java
1.1-only machine: (i.e. running microsoft's java on windows). you
should also avoid using "final" variables *inside* of methods,
since those aren't supported by microsoft's vm (and that's the
one most widely installed).
- 'export to application' remains unimplemented, though it's closer,
and should be ready before beta.
- on macosx, the error message:
## Component Manager: attempting to find symbols in a component
alias of type (regR/carP/x!bt)
is not something from processing, it is a bug in toast 5.2's video
cd support extension. to suppress the messages, move "Toast Video CD
Support.qtx" out of /Library/QuickTime (at least until you need to
do video cd work).
- on windows, sometimes your programs will run in a window that has a
java coffee cup icon, instead of the usual processing icon. this
simply means that the application is being run outside of processing
(by java itself) rather than from within processing. this happens
when extra libraries, multiple source code files (more than one tab),
or extra code files in the 'code' folder are employed.
- a long sketch menu that goes off the edge of the screen? doesn't
scroll properly? not much we can do. this is a java issue which
happens on most platforms. to get around it, you can organize your
sketches into subfolders which will appear as submenus.
..................................................................
QUICKTIME FOR JAVA / VIDEO PROBLEMS
- windows.. you must make sure that "QuickTime for Java" is
installed. to install it, you need to download it at:
http://www.apple.com/quicktime/download/
if you install the version "with iTunes", there's a second
step. after the installation, go to Start Menu -> QuickTime ->
QuickTime Updater. when it runs, use the "Custom" install, scroll
down, and click the checkbox next to "QuickTime for Java" and then
install. if you install the version of QuickTime without iTunes,
you'll also need to use the "Custom" install, as outlined above. the
same is true if you have already installed QuickTime, and did not
use the "Custom" or "Full" install.
- windows.. in order for camera input to work, you'll need to install
a quicktime-compatible video digitizer (VDIG). we've had reasonable
luck with WINVDIG: http://www.vdig.com/WinVDIG/
- windows.. sometimes a full uninstall/reinstall of quicktime will do
the trick.
- on windows, if you're having trouble with video examples crashing
processing or locking up your system, you should try placing the
processing folder into the root level of your C:\ drive, or at least
inside a set of folders that have no spaces in the name. we haven't
determined if this is a quicktime for java or processing bug yet,
but it's been a problem for lots of people.
- on windows, if you can't install quicktime for java yourself, all
you really need is a copy of QTJava.zip from the quicktime install,
which needs to be at %WINDIR%\system32\QTJava.zip. WINDIR is an
environment variable on windows, open up a DOS prompt and type
echo %WINDIR%
to find out what it's set to (prolly something like C:\windows on
windows xp/me/98 or c:\winnt on windows 2000).
- video sometimes likes to crash the application completely on
windows. this seems to be due to problems with quicktime for java
(since we shouldn't be able to write code that crashes using
java.. heh right). so this is probably outside of our control.
- on macosx 10.2.x (jaguar, or jagwyre if you like black turtlenecks),
quicktime for java was missing from the initial release of quicktime
6.4 on the mac. an upgrade to quicktime 6.4 that includes qtjava is
now available from software update. or you can download it from:
http://www.versiontracker.com/dyn/moreinfo/macosx/21302
you can also upgrade to maosx 10.3.x (panther) which doesn't have
this problem.
- mac os x.. if you get the following error:
Exception in thread "main" java.lang.NoClassDefFoundError:
com/apple/mrj/macos/carbon/CarbonLock
then it means you need to update and/or reinstall quicktime. there
was some monkey business about quicktime for java updates being out
of sync with the java vm releases, and this is one of the leftovers
of that scenario. blame canada. blame apple.
..................................................................
OPENGL PROBLEMS
- we don't recommend running other opengl programs while running processing
in opengl mode. gl tends takes charge of things so results will be
unexpected (windows from the other app showing through to the processing
window, etc.)
- if you're getting this error:
"net.java.games.jogl.GLException: Unable to enumerate pixel formats
of window using wglGetPixelFormatAttribivARB: 0"
and your machine has built in "intel" graphics (this is the case for
many dell machines, for instance) you may just need an updated version
of your driver, which can be found here:
http://downloadfinder.intel.com/scripts-df/Detail_Desc.asp?sType=prev&agr=N&ProductID=865&DwnldID=7919
of course, read the page closely and make sure that you in fact
have this graphics chipset on your machine before installing.
(thanks to Daniel Shiffman for finding this fix!)
- on macosx, i don't think there's much we can do about the following error:
Error: view not ready, cannot lock focus at
"/Users/kbr/JavaNet/jogl/src/native/jogl/
MacOSXWindowSystemInterface.m:createContext:51"
this shows up sometimes on run, just hit run again and things oughta work.
- on windows, if you're getting a lot of opengl crashing, blue screens,
or other mess, your driver might be bad. if you're using a dell, use
the driver they provide (support.dell.com) instead of what might be a
more recent driver obtained directly from nvidia.com.
..................................................................
KNOWN BUGS
the real deal, keeping us awake at night.. this is only a partial
list, see the bboard for more, and inside ben's head for others.
- beautify doesn't retain the *exact* position of the caret within the
text.
- beautify has problems with indenting when lines with a brace are
commented out, and also ignores switch statements.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1067309918;start=0
- clipping planes are not yet implemented. meaning that objects may
sometimes fly into the camera and turn upside down or do other tricks.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1058491568;start=0
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1052313604;start=0
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1042699742
- there is a bug that when smoothing is enabled, sometimes thin lines
will be visible within a concave polygon. this will just have to be
fixed in a future release. however, as long as stroke() is enabled
on the polygon, the lines should not be visible.
- the app doesn't provide an option to 'cancel' when it so politely asks
if you want to "save changes before quitting?". this is because of
java weirdness that we're trying to straighten out. the vm seems to
be force quitting itself, even if cancel is selected.
- lines with stroke weights that aren't 1 are sometimes strange.
- single pixel lines still have some problems with drawing over things.
- the size of exported applets has jumped in recent releases. this will
get smaller again in a future release. we're in the midst of
transitioning between two different sets of rendering/graphics code.
- curveTangent() is not yet implemented. contributions welcome.
- strokeMiter() and strokeJoin() exist but are not implemented.
- textures warp in strange ways due to perspective problems.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1050650262
- smooth() is not completely implemented. there will be quirks in how
it draws (like a weird flat line at the end of a shape, or areas
that are less than smooth).
- jikes is ~9 megabytes in size, which is a bit obnoxious. it doesn't
hurt anything but we plan to put it on a diet for a future release.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1062581723
- the horizontal scroller for the text area has some weirdness, this
may not be fixed until after beta, depending on how bad it is.
- using saveFrame() or saveBytes() or some of those things will cause
trouble inside applets. we'll try to do better error trapping soon
so that your applet doesn't crash when this happens.
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs;action=display;num=1059928189;start=0
..................................................................
BUGS THAT WE PROBABLY CAN'T FIX
these are things that are out of our control
- on windows, the system clock seems to go weird, especially when
using framerate() or delay(). this is a long-standing bug with the
window version of the java vm:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4500388
according to someone on the sun site: This bug has been fixed in
bug no 4500388 and one requires a PRODUCT FLAG to use the fix.
This flag and fix are available in 1.3.1_4, 1.4.0_2, 1.4.1 and 1.4.2.
For the plugin to pickup the fix :
In your Java Plug-in Control Panel in the section 'Java Runtime
Parameters' just enter the following flag:
-XX:+ForceTimeHighResolution
- "create font" crashes sometimes on windows, bringing down the whole
environment. this seems to be a jdk bug, because it's not a java
exception, but a full crash.
-443
View File
@@ -1,443 +0,0 @@
PROCESSING DEVELOPMENT ENVIRONMENT
(c) 2001-05 Ben Fry and Casey Reas
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
FREQUENTLY ASKED QUESTIONS, INFO ABOUT PLATFORMS, & DEVELOPER SOAPBOX
'revisions.txt' contains more information about the specific updates
and fixes in this and recent releases.
'bugs.txt' has up-to-the-second information about our favorite bugs.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HOW DO I GETTING STARTED?
double click the 'Processing' application, and select something from
the examples menu: File -> Open -> Examples. hit the 'run' button
(which looks like the play button on a vcr or tape deck).
lather, rinse, repeat as necessary.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHAT'S WITH THE VERSION NUMBERS?
this is not 1.0 software.. it's buggy and may kill people. that's part
of why we make everyone sign up to download, so that we know that you
care enough to bother and have more of an inkling of what you're
getting into.
at least until the final "1.0" version, we'll be using four digit
numbers for the release. we're calling revision "0043" the first
"alpha", which for us means "first publicly consumable app that can
be used by early adopters". later revisions (like this one) will
simply be numbered.
the numbered releases aren't heavily tested, so don't be surprised
if/when something breaks.. just report the problem and go back to the
previous numbered release until there's a fix.
there will be a few more numbered releases leading up to a beta
release. beta means that all the features are in, but not all the bugs
are out. there are several known issues with the alpha release (thin
lines, lack of alpha transparency, etc) that will need to be sorted
out for beta.
additional numbered releases will follow, leading up to 1.0, a
version that we can actually proud of and that has a minimum number
of bugs. hopefully this is not a *long* ways off, but...
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I FOUND A BUG!
haven't we all?
NOTE! avoid the urge to just email us, especially sending mail to ben
or casey directly. while you may prefer the privacy of an email, it's
much quicker for you to ask the whole gang, who are super helpful.
visit the discussion board to report: http://processing.org/discourse/
it's also what we use to keep track of bugs, so if you email us, we'll
just ask you to use the bboard anyway.
first, read the bugs.txt file to see if your problem is found there.
second, check this file to see if it's mentioned. a simple search for
keywords in this file might turn up something.
next, check the bboard to see if something related has been reported,
or if there is already a workaround.
we prefer for you to use the bboard for bugs, since:
- we like to use the bboard as a way to track bugs and get feedback
- casey and ben can't always respond quickly to email
- and there are several knowledgeable people on the bboard
if you want to go straight to the bugs page, it's:
http://processing.org/discourse/yabb/YaBB.cgi?board=Proce55ing_software_bugs
when reporting this "bug" please include information about
1. the revision number (i.e. 0070)
2. what operating system you're using, on what kind of hardware
3. a copy of your code--the smallest possible piece of code that will
produce the error you're having trouble with.
4. details of the error, which may be the last few lines from
the files stdout.txt or stderr.txt from the 'lib' folder.
for stranger errors during compile time, you can also look inside the
"build" folder inside "lib", which is an intermediate (translated into
java) version of your code.
the more details you can post, the better, because it helps us figure
out what's going on. useful things when reporting:
- we want the minimum amount of code that will still replicate the
bug. the worst that can happen is we get a report that says
"problem!" along with a three page program. sure, everyone likes a
puzzle, but simpler code will receive a faster response.
- occasionally we may need you to pack up a copy of your sketch folder
or something similar so that we can try and replicate the weirdness
on our own machine. rest assured, we have no interest in messing with
your fancy creations or stealing your ideas. the p5 team is a pair
of straight-laced boys who hail from the midwestern u.s. who were
brought up better than that. and as we often lack enough time to
build our own projects, we have even less time to spend figuring out
other peoples' projects to rip them off.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLATFORMS
the processing development environment is tested most heavily on:
1. Mac OS X 10.3
1. Windows XP
3. Fedora Core (Linux)
windows is by far the superior platform for running java
applications. it's not because we like windows the best but that's
just how it is. the vm for mac os x is really quite good (especially
when compared to apple's previous efforts), but it's still clunky and
behind. we think os x will be a great bet for the future, and apple is
putting all their feeble weight behind it, hopefully it will evolve
somewhere.
developing the version for mac os 9 was a big headache, we badly
wanted to support it, since so many people use it, but it had to be
discontinued for lack of time to work on it.
windows 95/98/ME is a piece of crap, but since lots of people (are
often forced to) use it, we'll do our best to support it. early alpha
versions seem to be having trouble with 95/98/ME, so if possible, we
*strongly* recommend using Windows 2000 or XP.
for the linux version, you guys can support yourselves. if you're
enough of a hacker weenie to get a linux box set up, you oughta know
what's going on. for lack of time, we won't be testing extensively
under linux, but would be really happy to hear about any bugs or
issues you might run into. actually, we don't get happy that you're
having issues, but if you're going to have issues, we're happy that
you tell us about them, so we can fix them.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MAC OS X
the most current release has only been tested on Mac OS X 10.3.5.
your mileage may vary if you're running something else. actually, your
mileage will vary no matter what, because who knows what this software
is gonna do. you're playing with free, alpha software. get psyched!
minimum requirements.. processing requires at least Mac OS X 10.1.
if you're running anything older than 10.2, you'll need "Java 1.3.1
Update 1", the latter of which is available as a free update from
the "Software Update" control panel. it can also be downloaded from
http://www.apple.com/downloads/macosx/apple/ or from:
http://www.apple.com/downloads/macosx/apple/java131.html
for what it's worth, we don't test processing under mac os x 10.1
and we don't recommend it at all. nor do we particularly recommend
10.2, if you can avoid it. and if you're running 10.4, processing is
the least of your worries.
serial port.. we use rxtx (version 2.1_6) to handle serial i/o, which
is included with the processing release. unlike previous releases
(anything before 57), it no longer requires separate installation.
however, if this is the first time you're using rxtx, you'll need to
make your way to the "libraries" folder, find "serial", and inside,
run macosx_setup.command (double-click it and follow the instructions)
to make sure that things are properly set up (a few permissions
need to be changed). if you're getting a "serial port is already in
use by another application" it's possible that you haven't run this
script. you may also need to reboot after running the script. on my
machine, i installed the keyspan driver for my usb-serial converter,
ran the script, and then rebooted in order for things to work. in the
past, i've used a keyspan 28X dual port adapter, and the selection i
use on the serial port menu reads "/dev/cu.USA28X21P1.1". you'll
probably have something similar. don't mind the frightening names.
another note on serial port.. tom igoe was kind enough to note that
you'll be in a world of hurt if you disconnect your serial adapter
while a sketch is running--it'll prolly freeze the machine and require
a forced reboot. (while this may seem nutty, you might run into it if
your adapter is plugged into your usb keyboard, and you have the
keyboard plugged into a monitor/keyboard switcher).
quitting presentation mode.. on other platforms, hitting the
'escape' key will quickly get you out of presentation mode. however,
there seems to be some key event weirdness under osx. we hope to find
a fix someday.
out of memory? right-click on processing, select "show package
contents", then edit "Info.plist" inside "Contents". change these lines:
<key>VMOptions</key>
<string>-Xms128M -Xmx256M</string>
to set to something higher than 128M and 256M (128 and 256 megabytes
of ram) as you need to / at your own risk.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WINDOWS
winxp is used as the primary development platforms, so the release
will likely work best there.
win95/98/me seem to have some trouble, but we think it's just with
the .exe that we use, so that'll get fixed in the future. you can try
using the 'run.bat' file instead, and see if that works better.
the release is now split into 'standard' and 'expert' versions. the
basic release includes a working java vm, and is all set up and ready
to go. the advanced version is for people who already have java
installed (and don't want to deal with the 20MB download), and know
what they're doing enough that they can also install the serial port
code by hand. instructions on installing the serial code are in the
'serial' folder inside the 'expert' release.
out of memory? try adjusting the parameters in the file 'run.bat' and
use that to run instead of Processing.exe. short instructions can be
found inside that file.
mouse issues: by default, windows seems to skip every other pixel on
screen, causing weirdness for some drawing applications done with
p5. if you're seeing this, you can fix it by going to the windows
"mouse" control panel, the "pointer options" tab, and select "enhance
pointer precision." (this was actually tracked down by someone else in
the p5 community, whose name i have misplaced. if it was you, please
drop me a line so you can be properly cited. this kind of help is huge
for us, since we're such a small group!)
video.. if you want to use video input on the pc, you'll have to
have a device that's compatible with quicktime, or use something like
winvdig to make it work: http://www.vdig.com/WinVDIG/index.html
otherwise you'll get no video.
"hs_err_pid10XX.txt" error.. this is something within the java vm that
we can't fix. it's not clear what the problem is, but it seems to have
shown up with java 1.4.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LINUX
the processing application is just a shell script, you can use this
as a guide to getting p5 to run with your specific configuration,
because who knows what sort of setup you have. this release was tested
on a redhat 9 box, and sun's jre 1.4.2 is included with the
download. replacing (or making a symlink to) the contents of the
'java' folder will let you tie in a preferred jvm for your machine.
the following message (or messages like it) on startup:
Warning: Cannot convert string "-b&h-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1" to type FontStruct
is just a java issue, not really a problem that will affect things.
serial.. this release uses rxtx-2.1_6 (just like macosx). if you're
having trouble getting things to run, i.e. the port menu stays grayed
out or you get error message spew to the console when starting the
application saying "Permission denied" and "No permission to create
lock file" and to read "INSTALL". this is because you probably need
to add yourself to both the uucp or lock groups so that processing
can write to /var/lock so it doesn't get in a fight with other
applications talking on the serial port.
alan kilian contributes this description:
1. I did an ls -l /dev/ttyS0 and saw that the group was set to uucp.
2. Then I edited /etc/groups, I found the uucp group, and I added my
login ID to the uucp line.
3. I logged out, and logged back in again.
4. The "groups" command now showed I was in group uucp, and when I
started processing, the serial port menu item was not greyed-out.
it's important that you're in both groups, and that you completely
log out and log back in again.
running processing as root will often get rid of the errors, but
that's obviously not a good solution for a million reasons (among
them: alpha code that runs as root and handles files? yeah great...)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHAT IS THE SKETCHBOOK?
we think most "integrated development environments" (microsoft visual
studio, codewarrior, jbuilder) tend to be overkill for the type of
audience we're targeting with Processing. for this reason, we've
introduced the 'sketchbook' which is a more lightweight way to
organize projects. as trained designers, we'd like the process of
coding to be a lot more like sketching. the sketchbook and the
'history' menu under 'sketch', are attempts in that direction.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHY JAVA? OR WHY SUCH A JAVA-ESQUE LANGUAGE?
We didn't set out to make the ultimate language for visual
programming, we set out to make something that was:
1) a sketchbook for our own work, simplifying the majority
of tasks that we undertake,
2) a teaching environment for that kind of process, and
3) a point of transition to more complicated or difficult
languages like full-blown Java or C++. (a gateway drug)
At the intersection of these points is a tradeoff between speed and
simplicity of use. i.e. if we didnt' care about speed, python or other
scripting languages would make far more sense. if we didn't care about
transition to more advanced languages, we'd get rid of the crummy
c-style (well, algol, really) syntax. etc etc.
Processing is not intended as the ultimate environment/language (in
fact, the language is just Java, but with another graphics api and
some simplifications), it's just putting together several years of
experience in building things, and trying to simplify the parts that
should be easier.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HOW DO I USE EXTERNAL FILES?
if you want to use external files, like images or text files
or fonts, they should be placed in a folder called 'data' inside your
sketch folder.
starting with version 44, there are several functions that make
dealing with data in files much easier (loadFile, loadStrings,
splitStrings, etc) so file i/o should be fun!
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHY IS IT CALLED "PROCESSING"?
at their core, computers are processing machines. they modify, move,
and combine symbols at a low level to construct higher level
representations. Processing allows people to control these actions and
representations through writing their own programs.
the project also focuses on the "process" of creation rather than end
results. the design of the software supports and encourages sketching
and the website presents fragments of projects and exposes the
concepts behind finished software.
"Proce55ing" is the spelling we originally used for the url. even
though it's a combination of numbers and letters, it was simply
pronounced "processing." casey and i saved our pennies and had a can
drive so now we've acquired the processing.org domain name. as a
result we are no longer using the name "Proce55ing". when we see it
with the 55's it annoys us and we want to punch people in the face. or
punch ourselves in the face for using it in the first place. actually,
we don't care that much but we're trying to kill off the previous
naming. however, to make it more confusing, we still use "p5" as a
shortened version of the name.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HOW MUCH DOES PROCESSING COST?
we think it's important to have Processing freely available, rather
than selling it for a million dollars under some godawful yearly
contract update scheme. to that end, we encourage people to distribute
the word widely and refer them to the site: http://processing.org
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DO WE HAVE TO CITE PROCESSING? CAN WE DISTRIBUTE OUR SKETCHES?
we like it when people include a "built with processing" note with a
link back to the site, since it helps create interest / brings in more
people to the project. we don't/can't/shouldn't require it, but it
makes us happy because the project is free and this is our way of
getting advertising and generating interest.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IS PROCESSING OPEN SOURCE?
we plan for this project to be "open source", everyone's favorite
phrase that means that you'll be able to get your grubby little mitts
all over our code (all the code that's behind the processing
development environment and the graphics engine used in tandem with
it). we can't promise, since we're still working on getting the
licensing taken care of with our employers, but we think this should
likely happen soon.
the export libraries (internally known as 'bagel') will probably be
LGPL, which means they can be used as a library and included in your
project without you having to open up your code (though we encourage
people to share anyway).
more information about the gnu public license can be found here:
http://www.gnu.org/copyleft/gpl.html
processing also includes other open projects, namely the older version
of the oro matcher (http://www.savarese.org/oro/), the jikes compiler,
and the jedit syntax package. the oro tools are distributed under a
bsd style license as part of the apache jakarta project, and jikes is
covered by the ibm public license:
http://oss.software.ibm.com/developerworks/opensource/jikes/
we're sorry that our source code isn't available just yet, we're
cleaning and scrubbing it, it was a decision between getting the alpha
out to people to try versus taking a few more weeks to clean up the
project and deal with the technology licensing departments at
mit. these things are far more difficult and time consuming than
they initially appeared.
our plan is to have the code available with the first "beta" release,
which will be the first release that is publicly available and
downloadable from the site.
+20 -2
View File
@@ -7,7 +7,13 @@ releases will be super crusty.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ABOUT REV 0083 -
ABOUT REV 0083 - 17 april 2005
- new reference and examples in this release. please test!
- readme.txt and bugs.txt have been removed in favor of a single FAQ,
which contains the appropriate information, and will be mirrored as
the FAQ on processing.org as well.
- what he hope is the finalized lighting api for beta/1.0
@@ -42,6 +48,9 @@ ABOUT REV 0083 -
- video camera api should now be finalized:
+ we're still debating on whether to rename Camera to something
else. we just can't think of a good name.
+ that whole thing with passing null or "" to the camera constructor
was really silly. now either one will just give you the default
video input device.
@@ -72,7 +81,16 @@ ABOUT REV 0083 -
- nfc() joins the nf() family to format integers and floats with commas.
- linux version returns, with several fixes, and now handles
(warns about) libstdc++ incompatabilities.
(warns about) libstdc++ incompatabilities with jikes
The last remaining things before Beta:
- make sure there isn't any super badness in the current version
- fix the "save as" bugs
- "create font" is somewhat broken in this release
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
+5 -6
View File
@@ -4,10 +4,10 @@ REVISION=`head -c 4 ../../todo.txt`
# check to see if the version number in the app is correct
# so that mikkel doesn't kick my ass
VERSIONED=`cat ../../app/PdeBase.java | grep $REVISION`
VERSIONED=`cat ../../app/Base.java | grep $REVISION`
if [ -z "$VERSIONED" ]
then
echo Fix the revision number in PdeBase.java
echo Fix the revision number in Base.java
exit
fi
@@ -24,7 +24,6 @@ rm -rf processing-*
cp -r ../shared processing
# add the libraries folder with source
#cp -r ../../lib processing/libraries
cp -r ../../net processing/libraries/
cp -r ../../opengl processing/libraries/
cp -r ../../serial processing/libraries/
@@ -52,7 +51,7 @@ cd ..
unzip -q -d processing jre.zip
# directories used by the app
mkdir processing/lib/build
#mkdir processing/lib/build
# grab pde.jar and export from the working dir
cp work/lib/pde.jar processing/lib/
@@ -91,8 +90,8 @@ find processing -name "*.exe" -exec chmod +x {} ';'
find processing -name "*.html" -exec chmod +x {} ';'
# clean out the cvs entries
find processing -name "CVS" -exec rm -rf {} ';'
#find processing -name "CVS" -exec echo {} ';'
find processing -name "CVS" -exec rm -rf {} ';' 2> /dev/null
find processing -name ".cvsignore" -exec rm -rf {} ';'
# zip it all up for release
echo Packaging standard release...
+13 -11
View File
@@ -61,12 +61,20 @@ X update checker (can be turned off in prefs)
X send unique id, and information about person's java vm/platform
o using timezone would be an interesting method for tracking location
sunday evening
X fix up dist scripts for new faq stuff, cleaning out some old crap
X consolidate readme.txt, bugs.txt, info.html (faq)
X document things that will be broken for beta
X opengl set() functions.. though get() probably ok
X stop button with external apps
X java 1.1 support
X code is larger than we'd like, has increased in size
X working to remove and optimize, also make possible to remove un-needed
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
_ create font is somewhat broken
pending
_ rename video.Camera to video.Video ?
_ VideoInput VideoOutput, SoundInput, SoundOutput or AudioInput/AudioOutput
@@ -75,15 +83,9 @@ _ new bboard? archive the old one, remove bugs sections
_ environment reference
_ list of changes since rev 69? run through revisions.txt
non-coding tasks
_ consolidate readme.txt, bugs.txt, info.html (faq)
_ document things that will be broken for beta
_ opengl set() functions.. though get() probably ok
_ stop button with external apps
_ java 1.1 support
_ code is larger than we'd like, has increased in size
_ working to remove and optimize, also make possible to remove un-needed
_ setup bugzilla, move legit bugs there, non-bugs to readme
_ setup bugzilla and enter all the bugs
_ create font is somewhat broken
//