Re: Standard library for perl6? (graphical primitives)
On Sat, Oct 15, 2005 at 08:33:26AM +0300, Markus Laire wrote: Could it be possible to create a Standard library for perl6, which would also include graphical primitives (putpixel, getpixel, getcolordepth, putimage, getimage, copyrectangle)? I'm interested in creating a perl6 binding to cairo (http://cairographics.org), but haven't gotten anywhere close to starting that project. -kolibrie
Re: Standard library for perl6? (graphical primitives)
Markus Laire wrote: I'm not completely sure if it would be worth the trouble to support only most primitive graphical commands in core, (no windows, etc..), and leave the rest to the modules (or to the programmer). To a large extent, I'd want to leave most details to modules, etc. But what would be nice (tm) would be to establish a framework within graphics libraries can the created. Sort of like DBI/DBD: A core set of capabilities ala DBI, implemented in multiple ways via drivers (DBD). The only problem is ... it's hard. But things like create window are the sort of interfaces that you would want to become defacto standards. Drawing pixels/lines is much less interesting (except as exposed by a canvas widget) The thing that makes it feasable is perhaps that most look-and-feel stuff is already externalized from specific applications. So it is reasonable to have a generic open window that just works. Perhaps the equivalent of DBI is semantically the same as the interface to web browsers (client side) -- thats probably the closest we have a broadly accepted standard.
Re: Standard library for perl6? (graphical primitives)
On 10/14/05, Markus Laire [EMAIL PROTECTED] wrote: Perl does have CPAN, but the problem is that there are no standard modules, and so there can be several modules doing the same thing. And what is the problem with that? For example, some of the modules for graphics you get to choose from are wxPerl, Tk, SDL. Each of these has its strengths and weaknesses, so you may have one project where Tk is the right thing (perhaps a graphical debugger), and another where SDL is the right thing (a game of some sort), etc. A standard library has to be able to do everything, which usually means that it won't be good at anything. That is, unless we put as much effort into designing it as we have into Perl 6, which is not going to happen. Plus, people have already done that, and put the results into modules like wxPerl, Tk and SDL. Could it be possible to create a Standard library for perl6, which would also include graphical primitives (putpixel, getpixel, getcolordepth, putimage, getimage, copyrectangle)? With what underlying library? There are many ways to access the screen. If we stick to one way, we'll be as portable as QBasic. But more importantly, we're trying to stay away from that word standard. When you wish for a standard library, you're wishing that something get done. In open source projects, the best way to ensure that something get done is to do it. So go write a graphics library, and then we'll see about making it standard. The other thing we've learned about standard, is that we're making an early commitment, which is probably a crappy commitment. If you provide nothing, that is forcing the CPAN community to come up with one (probably more than one). And all of those will probably be better than one that we come up with: I don't see too many graphics efficianados around p6l. The other other thing we've learned about standard is that if there is a decent standard library, then vendors don't care about installing any modules. So the plan for perl 6 is to provide little or no standard library so that vendors will be forced to install a decent set of modules (maybe Bundle::Standard... oops, there's that word again). Luke
Re: Standard library for perl6? (graphical primitives)
On 10/15/05, Luke Palmer [EMAIL PROTECTED] wrote: On 10/14/05, Markus Laire [EMAIL PROTECTED] wrote: Perl does have CPAN, but the problem is that there are no standard modules, and so there can be several modules doing the same thing. And what is the problem with that? The problem may be that it doesn't work everywhere. What I find exciting about parrot is that (it sounds like to me) you'll be able to run a perl6 file anywhere that has parrot, much like Java. I think what Markus is getting at is for there to be a way to display graphics through parrot everywhere parrot runs as well. Yes, different modules are extremely important, because the programmer deserves a choice, but some modules run someplaces, others run other places - it'd be a good thing to have the absolute bare essentials run everywhere. Bryan
Re: Standard library for perl6? (graphical primitives)
On Sat, 2005-10-15 at 12:45 -0500, Bryan Burgers wrote: What I find exciting about parrot is that (it sounds like to me) you'll be able to run a perl6 file anywhere that has parrot, much like Java. I think what Markus is getting at is for there to be a way to display graphics through parrot everywhere parrot runs as well. Yes, different modules are extremely important, because the programmer deserves a choice, but some modules run someplaces, others run other places - it'd be a good thing to have the absolute bare essentials run everywhere. I agree, but it's not an easy question: which bare essentials are those? How big is the screen on every device where Parrot runs? Is there hardware acceleration? Is there a text-mode console? Is there a framebuffer? How many colors? Is there a back buffer? What types of input devices are available? Does the platform have POSIX support? Does it have a MMU? Can it run a compiler from the program? Is there an existing graphics library on every platform we can use or will we have to write and maintain a superset of all graphics primitives we want to provide on every platform? Does the platform support tiling or overlapping windows? Does it manage resources automatically or leave that up to the programmer? -- c
