On Tue, Jan 24, 2012 at 8:33 AM, Chris Marshall <[email protected]>wrote:
> 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... > Yes. How about we aim for this for 2.4.11. > > 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. > If somebody wanted to start such a company, I would be the first to send my resume. >> ...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 > David -- Sent via my carrier pigeon.
_______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
