It is nice to see Prima work at 64bits which "GUI" and "Tk" have problems with
at least on the Windows front I have not yet tested that Ubuntu, I got "GUI" to
build
with pp and the PAR packer yet couldn't get Prima to build on win32 , I'm gonna
try to get it built on a win64 bit setup, which would allow app's to be made,
and possibly be portable in the same OS... which could make some people's life's
easier instead of using the console or terminal (linux term); Having PDL like
Matlab
I think would be pretty cool , I don't know how long it took to write TriD ,yet
I know that OpenGL dosen't always build well from Cpan on win64, which
I can see as a foreseeable problem ... integrating with OpenCL , I could see
PDL as a loader for OpenCL like a kernal cause that can get rather complex
booting TriD for for Prima could make app development easier, it looks like...
yet trying to keep all the functionality the same, while improving might make
things hard
for instance we know that if we use "GreyCode" then the transistor's used could
be
dramatically reduced , which would reduce heat as well , and improve performance
by allowing better use of resources in a loop, and that might clash with other
things going
on under the hood...
-Mark
"sometimes I think perl is alive"
________________________________
From: Chris Marshall <[email protected]>
To: Craig DeForest <[email protected]>
Cc: MARK BAKER <[email protected]>; ""[email protected]""
<[email protected]>
Sent: Monday, January 7, 2013 6:16 AM
Subject: Re: [Perldl] PDL Ram efficiency
Well, a clean up of TriD has been long planned but
has been taking a back seat to getting 2D graphics,
64bit support, and NiceSlice.
Ideally, the TriD code would become more independent
of the GUI toolkit used, able to interoperate, and
easier to see how to extend. I've taking a couple
of whacks at it but the architecture is pretty tricky
and totally undocumented. I haven't wanted to go
further since, at the moment, I think the only way
forward would be a complete rewrite.
--Chris
On Sun, Jan 6, 2013 at 11:42 PM, Craig DeForest
<[email protected]> wrote:
> Shudder. I just went back and looked at the various evil hacks I used to
> get fluxon movies out of PDL::Graphics::TriD. Either Prima or Gnuplot would
> probably be a better choice.
>
> On Jan 6, 2013, at 9:06 PM, MARK BAKER <[email protected]> wrote:
>
> David
>
> I was thinking the same thing, I don't think you need all the old "points3d"
> to reproduce the the next
> $x,$y,$z ... maybe it was something used to make sure every thing was
> working, and was forgotten to
> be changed ... I have looked at the pointsd3 in a couple different places
> in the PDL folders
> when trying to figure out where to try the sprite rounding for the points
> instead of the big ugly
> squares , as well trying to get different size points in the same scene ..
> which is in the OpenGL bible ...
> I think I may have to do a search to find all the files that are involved
> with it ...
>
>
> -Mark
>
> ________________________________
> From: David Mertens <[email protected]>
> To: MARK BAKER <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Sent: Sunday, January 6, 2013 7:32 PM
> Subject: Re: [Perldl] PDL Ram efficiency
>
> Mark -
>
> I ran reproduce your ram troubles with the PDL code that's contained in your
> YouTube description. I suspect it has something to do with how one creates
> animations using TriD, and that repeatedly calling points3d. Specifically, I
> suspect (though haven't dug through the TriD code enough to confirm) that
> each time you call points3d, the data gets copied somewhere, and that copy
> never gets destroyed.
>
> Chris, does my explanation sound plausible?
>
> David
>
>
> On Thu, Jan 3, 2013 at 2:06 PM, MARK BAKER <[email protected]> wrote:
>
>
> here is the pastable text ... Tested it on Ubuntu..
> both work.. posted below
>
> -Mark
>
> ________________________________
> From: MARK BAKER <[email protected]>
> To: "[email protected]" <[email protected]>
> Sent: Thursday, January 3, 2013 8:56 AM
> Subject: Re: [Perldl] review of sf.net bugs/features for PDL-2.4.12
>
> I Have been noticing a problem with the ram usage with PDL
> I wrote some code in PDL then in OpenCL and the OpenCL
> code Doesn't use any ram while the PDL code slurps up
> about .01 Gigabytes per second , which really starts to add
> up ...
>
> here is the code for both ...
>
> OpenCL code
>
> http://www.youtube.com/watch?v=Tm2-YCGvBvo&feature=share&list=UUPHFUHiwbpMqC8ONxEICCiQ
> PDL code
>
> http://www.youtube.com/watch?v=3LXUz_Qez4A&feature=share&list=UUPHFUHiwbpMqC8ONxEICCiQ
>
>
>
> --Mark
>
>
>
> Given the recent work on plotting libraries, I wonder if you, Craig, Dima,
> and I might consider working on stronger support for PDL::Graphics2D? As
> your work on the tracker indicates, there are quite a few other subsystems
> that could use help, so perhaps we should focus some effort now on those,
> and come back to the graphics end later. Furthermore, that'll be a pretty
> big project, and I would prefer to hold off until this summer due to tuits
> and timing.
>
> That having been said, if it would work better for you guys to hit that now,
> I would be game. :-)
>
> David
>
>
> On Wed, Jan 2, 2013 at 12:25 PM, Chris Marshall <[email protected]>
> wrote:
>
> I've just completed a review of the PDL Bugs and Feature
> Requests tracker items outstanding at
> http://sourceforge.net/tracker/?group_id=612&atid=100612
> and
> http://sourceforge.net/tracker/?group_id=612&atid=350612
> with an eye to goals for an upcoming PDL release and what
> would make a good target.
>
> I urge PDL users and developers to look over the existing
> Bugs and Feature Requests. If any strike your fancy, please
> feel free to step up and code. Also, if there is something
> you think would be a good/useful addition to PDL, add an
> item to the Feature Requests or bring it up on this list.
>
> Thanks much,
> Chris
>
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
>
>
>
> --
> "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
>
>
>
> _______________________________________________
> 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
>
>
>
>
> --
> "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
>
>
>
> _______________________________________________
> 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
