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]> 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]> > *To:* MARK BAKER <[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]>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 > > > 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 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]> > *To:* David Mertens <[email protected]> > *Cc:* MARK BAKER <[email protected]>; ""[email protected]"" < > [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]> > 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 > > > 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] > 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
