On Tue, Jan 24, 2012 at 7:17 AM, David Mertens <[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]> 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 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] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
