 |
Author |
Topic: Language (Read 780 times) |
|
fjen
|
Language
« on: Oct 15th, 2002, 12:46pm » |
|
some thoughts ..
extending BImage:
- make it possible to render into an BImage instead of the player-canvas i.e. canvas(BImage)
extend image():
- image(BImage, x, y, width, height, source_x, source_y, source_width, source_height)
|
|
|
|
|
fjen
|
Re: Language
« Reply #1 on: Oct 16th, 2002, 12:29pm » |
|
another thing (see also XML-subject)...
add save("some_textfile.txt"), load("some_textfile.txt")
- i'd be happy to be able to save & load data somehow so i can i.e. import 2D/3D data
|
|
|
|
|
fry
|
Re: Language
« Reply #2 on: Oct 17th, 2002, 12:38am » |
|
[ regarding images ]
rendering into a BImage would be nice, will consider for the future.
also note that it's possible to grab what's currently being displayed and stow that with something like the following:
BImage img = new BImage(pixels, width, height, RGB);
now img can be drawn elsewhere to show a copy of what was on the screen at that time.
as for subsetting an image (source_) that'd be useful too. need to think about the best way to do that. your suggestion might be straightforward enough w/o mucking up the api so i'll put it on the list and see if it makes it into the next release.
thanks for the suggestions..
|
| « Last Edit: Oct 17th, 2002, 12:41am by fry » |
|
|
|
|
fry
|
Re: Language
« Reply #3 on: Oct 17th, 2002, 12:41am » |
|
[ regarding file i/o ]
load is already in there. if you want to read a file as individual lines, you can use:
String lines[] = loadStrings("somefile.txt");
or even with gzipped data:
String lines[] = loadStrings("somefile.txt.gz");
if you want the data as a huge array of bytes, you an use:
byte bytes[] = loadBytes("somebinaryfile");
if you want the data as a java InputStream (so you can put a BufferedReader or some other i/o class on top, say) this works:
InputStream input = loadStream("filetostream.txt");
on the other hand, save would be nice though i haven't gotten around to implementing it (also it's a pain because it will silently fail on exported applets..)
as for xml, i think i'd rather people use loadStream, then pass that to their own xml classes of choice. i'd like to avoid reinventing the wheel (anymore than we already are, perhaps) by creating yet another api for dealing with xml. there are many others that exist by more xml-centric entities than myself (sun, ibm, etc.)
|
| « Last Edit: Oct 17th, 2002, 12:46am by fry » |
|
|
|
|
Erik
Guest
|
Re: Language
« Reply #4 on: Nov 12th, 2002, 11:51pm » |
|
how about using python as the programming language? is it possible to 'hang in' a different interpreter and talk to the same graphics library?
I find python easier to teach, simpler syntax and a lower threshold to get started, yet it scales well to complicated projects.
|
|
|
|
|
fry
|
Re: Language
« Reply #5 on: Nov 13th, 2002, 1:06am » |
|
short answer on python is that casey and i aren't python gurus, and for lack of time we haven't hacked in support.
long answer:
it would eventually be possible to use python in the same shell, and the environment is being coded in such a way that would allow other languages to be dropped in (i think i hear the ruby users preparing to attack)
it's been in mind, as i did this for dbn (http://dbn.media.mit.edu) using jython. there were versions of dbn that allowed people to code in python or even scheme, but still use dbn's graphics library/environment.
that said, i don't think this is on our list for 1.0, unless we get lots of feedback encouraging us otherwise. on the other hand, once we start releasing the code for p5 (hopefully at beta? do i code the next alpha or scrub the code for release?), it will be quite possible for someone of the python persuasion to hack in support, and likely with minimal effort. the tougher bits would be things like getting export-to-applet to work (quite possible, just takes some testing, and testing == time).
|
|
|
|
|
dnm
|
Re: Language
« Reply #6 on: Jan 12th, 2003, 4:22am » |
|
on Nov 13th, 2002, 1:06am, fry wrote:short answer on python is that casey and i aren't python gurus, and for lack of time we haven't hacked in support.
long answer:
it would eventually be possible to use python in the same shell, and the environment is being coded in such a way that would allow other languages to be dropped in (i think i hear the ruby users preparing to attack)
it's been in mind, as i did this for dbn (http://dbn.media.mit.edu) using jython. there were versions of dbn that allowed people to code in python or even scheme, but still use dbn's graphics library/environment.
that said, i don't think this is on our list for 1.0, unless we get lots of feedback encouraging us otherwise. on the other hand, once we start releasing the code for p5 (hopefully at beta do i code the next alpha or scrub the code for release), it will be quite possible for someone of the python persuasion to hack in support, and likely with minimal effort. the tougher bits would be things like getting export-to-applet to work (quite possible, just takes some testing, and testing == time). |
|
This is one of the things that interested me the most about proce55ing: the choice of language to express in the application (rather than the language it was implemented in). Currently, proce55ing is mostly a subset of Java. As I wondered when I first emailed Casey and Ben about becoming an alpha tester, I was intrigued about the choice of a Java-like ("Java Lite", almost) language as it doesn't it seem to be the easiest to express graphical concepts in.
Ben had some good reasons though, which I'll share here. Ben, I hope you don't mind:
Quote:
-- java/c++ is winning, no matter what, and so the skills used to learn a java/c style language will be useful to be applied in other contexts.
-- we like python as a teaching language, but don't use it ourselves much for our own work, and it's not fast enough for implementing (at least high end) graphics stuff. to that end, we often use java as part of our sketching process because of its simplicity for rapidly building things, then as the project outgrows it, we move to c++.
-- i think of this as java with training wheels (not introducing classes off the bat, having an implicit 'graphics' object, etc) so once people learn java in this context and want more speed or more complicated features, it's easy to move to more advanced c++ work using the c version of the graphics engine (not yet released, but usable) that can be used for high-end interactive 3D apps.
|
|
Initially, I thought something like Logo, extended to be more "modern" with respect to interactive design, would be an interesting lanugage. One of the things I pulled out of DBN was that the environment should have a powerful, expressive language, but eschew as much syntax and semantics that matter only to the computer as possible (like "void").
Ruby would be interesting, but I'm a Ruby fan. ;] Although multiple languges on the same engine would be neat, that road cuts down on some of the utility of sharing source. You could certainly still do it, but you'd have to learn each proce55ing sub-language to use code in a sub-language you didn't use. I like to think of proce55ing as a _language for interactive design_ and a powerful environment for expressing designs constructed in that lanugage.
|
|
|
|
|
|
