Of course, I'm sure David will reply, but before he does, I think his goal for Prima is to replace the old graphics libraries, and as such I would be shocked if he is going through all this work just to put PGPLOT in a Prima window.
To see the current state of the project look at https://github.com/run4flat/PDL-Graphics-Prima As I understand it, if you actually want to try it you will also need the underlying https://github.com/run4flat/PDL-Drawing-Prima and Prima (and PDL) of course. Its exciting, I can't wait to try it! PGPLOT drives me nuts sometimes. Joel Berger On Wed, Jan 25, 2012 at 3:58 AM, Fabio D'Alfonso <[email protected]> wrote: > Hi, > I didn't know Prima before, so thanks for pointing at that (in general). > > I played a bit with it and also with the examples, that show quite well the > level of graphics it can bring. > > The idea to bring the ability to plot on Prima can be a maiking difference > in the life of PDL. I do not know the approach used by David, but I thing > it would be very important not to bring the limitations of the current > plotting libraries to the widgets of Prima. > I think that if using > use PDL::Graphics::Prima > would result in a PGPLOT/PlPlot old fashion drawing within a Prima window > anyone would kindly prefer > use Prima; > and, paying the price for performance, would unfold the piddles to get the > benefit of Prima in getting a computed/perhaps interactive window. > > > Fabio D'Alfonso > 'Enabling Business Through IT' > cell. +39.348.059.40.22 *** > web: www.fabiodalfonso.com <http://www.fabiodalfonso.com/> > email: [email protected] > <mailto:[email protected]>linkedin: > www.linkedin.com/in/fabiodalfonso <http://it.linkedin.com/in/fabiodalfonso> > twitter: www.twitter.com/#!/fabio_dalfonso > <http://www.twitter.com/#%21/fabio_dalfonso> > > fax: +39.06.874.599.581 > BlackBerry® Wireless Enabled Address. > > > ** Hidden numbers are automatically rejected by the phone* > > > On 1/24/2012 7:34 PM, David Mertens wrote: >> >> No, no, Prima wouldn't replace TriD at all. Rather, it would provide a >> container widget in which you could use TriD, as well as the rest of the GUI >> toolkit that you get with Prima. My plotting library is strictly >> 2d-plotting. >> >> David >> >> On Tue, Jan 24, 2012 at 12:12 PM, MARK BAKER <[email protected] >> <mailto:[email protected]>> wrote: >> >> will Prima replace the TriD with out any hassle ??? >> >> will points3d() recognize Prima as a out-put instead of TriD >> or is Prima to be used as a replacement just for Tk ??? >> >> Cheers >> --Mark >> >> >> ------------------------------------------------------------------------ >> *From:* David Mertens <[email protected] >> <mailto:[email protected]>> >> *To:* MARK BAKER <[email protected] >> <mailto:[email protected]>> >> *Cc:* >> >> *Sent:* Tuesday, January 24, 2012 8:14 AM >> >> *Subject:* Re: [Perldl] Getting What Is Missing >> >> >> >> On Tue, Jan 24, 2012 at 9:33 AM, MARK BAKER >> <[email protected] <mailto:[email protected]>> wrote: >> >> 1. Is there a good link to Prima ???? >> >> >> Yes, sorry. The website is http://www.prima.eu.org/ and the >> module's docs can be found at p3rl.org/Prima <http://p3rl.org/Prima> >> >> 2. Im developing a website right now that has >> a tracking system for the support Questions. >> so that each question has number attached to it >> and a database that holds them until there closed >> and even hold the closed ones for 12 months... >> >> >> Sounds like a start, but don't reinvent the wheel. How will this >> be any better or different from tickets on sf.net <http://sf.net> >> or issues on Github? >> >> 3. as far as spam goes there is no email per say >> that a spammer can attack just the sql database >> unless they get the the cloud administrator >> password and user name ???? >> >> >> If we had a mail webform, somebody malicious could hack the POST >> request and start flooding the PDL mailing lists. But that seems >> to me like it would take a lot of work with not much payoff. It's >> hard to distribute that sort of thing, and it's easy for us to >> modify the structure of the webform to fix it. >> >> 4. I will send the site out so that it can be tested >> so our hackers out there can do there worst ... >> and I can make some improvements to it >> >> Cheers >> >> --Mark R Baker >> >> >> >> ------------------------------------------------------------------------ >> *From:* Chris Marshall <[email protected] >> <mailto:[email protected]>> >> *To:* David Mertens <[email protected] >> <mailto:[email protected]>> >> *Cc:* MARK BAKER <[email protected] >> <mailto:[email protected]>>; ""[email protected] >> <mailto:[email protected]>"" <[email protected] >> <mailto:[email protected]>> >> *Sent:* Tuesday, January 24, 2012 6:33 AM >> >> *Subject:* Re: [Perldl] Getting What Is Missing >> >> On Tue, Jan 24, 2012 at 7:17 AM, David Mertens >> <[email protected] <mailto:[email protected]>> >> wrote: >> > Mark - >> > >> > Sorry for not responding sooner to these ideas. They've been >> rolling around >> > in my head for the last couple of days, so, here goes. >> > >> > On Fri, Jan 20, 2012 at 11:22 AM, MARK BAKER >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> >> I have gotten the the core PDL functionallity to work with >> the PP >> >> PAR::packer >> > >> > >> > This is a very interesting concept. I can't recall if you've >> mentioned this >> > in the past, but I have not given it much thought until now. >> >> It has been mentioned in list discussion. It is a possible >> solution to the Devel::REPL install problem of too many >> CPAN modules and something always goes wrong before >> success... >> >> >> with the one exception of the TriD.pm <http://TriD.pm> >> which throws some errors at me... >> > >> > Yes, TriD will be *very* difficult to get working with >> PAR::Packer, I >> > expect. But read on. >> >> There is no problem with binary files, libraries, etc in PAR >> distributions. As always the issue is taking the time to >> sort things out. I expect the real issue might be the OpenGL >> module which is in process of being revised to no longer >> require build-time configuration which should fix many of >> the issues of package dependencies. >> >> >> if we can show that we can make the exe's possibly with Tk >> to have full >> >> functionality like MatLab, (that means trying to streamline >> a lot of code) >> >> then we can have a Open Source software where we can go >> into the code and >> >> get it to work the way we want, there we solve both ends of >> the needs 1. the >> >> need for it to work 2. to be able to get into the code and >> change what we >> >> want to change based on our ideas of functionality >> >> I second this. Tk is not OpenGL friendly while Prima is. >> The current TriD infrastructure is planned to evolve to work >> with Prima while for win32 platform specific issues (no >> OpenGL widget support), Tk is not planned in the near >> term. >> >> > I may sound like a broken record here, but I would advocate >> for Prima over >> > Tk. In fact, I have a (very simple, somewhat hackish) GUI >> REPL built on >> > Prima and PDL that I would be willing to distribute, or at >> least try to >> > distribute. Perhaps I can play with this more later this >> week or over the >> > weekend. At any rate, it would be *really neat* to be able >> to post >> > downloadable executables on PDL's website that users could >> run on their >> > machines without having to install. If we could find a way >> to include an >> > unpackage/install onto the user's machine, kinda like a PAR >> LiveDisk, that >> > would be even cooler. But I need to learn to walk before I >> can run, as they >> > say. :-) >> >> It would be nice if you could put some/all of your free PDL >> cycles between now and 01-Feb towards the PDL::Book and >> the PDL-2.4.10 release checkout especially as regards the >> web page and install info... >> >> > What are the command-line switches you use to pack your >> script? I just >> > glanced through the PAR::Packer docs, but it seems like many >> options are >> > possible and I'm not quite sure where to start. >> > >> >> >> >> And I have gotten the exe's to work on other computers >> using the same type >> >> of operating system (Windows 2008 at the moment only) if we >> want a one shot >> >> for all types of operating systems then we want to use C# >> am I right about >> >> that , as far as i know >> >> C/C++ are the languages of interest for PDL. C# is far from >> being a platform portable or platform neutral language. >> >> > No, C# will not be necessary. PDL's guts are written in C, >> which is more >> > cross-platform and faster than C#. The only limitation with >> C is that it >> > must be compiled for the target machine, which in practice >> means we need >> > access to a working copy of that OS. As we need working copy >> to an OS in >> > order to test PDL anyway, this is not a limitation in practice. >> > >> >> ...snip... >> > >> > Lots of parentheses there. Everybody can already get at the >> underlying C and >> > Perl code, so PAR::Packer will help with first-time users. >> BTW, I don't see >> > us doing anything commercial with PDL any time soon. It >> would go somewhat >> > against the grain of PDL's style from the last 15 years. >> >> A company providing support and a fully-integrated PDL >> for interested customers would help in the sustainment >> of PDL. Look at what the SciPy distribution has done >> for NumPy. >> >> >> ...snip... >> > >> > I'm skeptical about a support website. PDL's current line of >> support is the >> > mailing lists and we don't get very many hits here from new >> users. I wonder >> > how things might look if it were possible for people to send >> an email to the >> > mailing list from our web site, though? Any web hackers want >> to give this a >> > shot? >> >> There are real problems with that and spam attacks. >> >> Cheers, >> Chris >> >> >> >> >> >> _______________________________________________ >> Perldl mailing list >> [email protected] <mailto:[email protected]> >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> >> >> David >> >> -- "Debugging is twice as hard as writing the code in the first >> place. >> Therefore, if you write the code as cleverly as possible, you are, >> by definition, not smart enough to debug it." -- Brian Kernighan >> >> >> >> >> _______________________________________________ >> Perldl mailing list >> [email protected] <mailto:[email protected]> >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl >> >> >> >> >> -- >> Sent via my carrier pigeon. >> >> >> _______________________________________________ >> Perldl mailing list >> [email protected] >> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
