Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2014-08-09

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
14:10 mohawk joined #pdl
14:59 drrho joined #pdl
17:18 chm joined #pdl
17:19 chm mohawk: See the PDL home page for development information.  The perldl mailing list is the "official" method for PDL support.
17:19 chm mohawk: Glad you figured it out.  :-)
17:56 mohawk chm, ;-)
17:56 mohawk i do wish sf had an interface as easy as github
17:56 mohawk is there any way you guys could be persuaded to move to github?
20:40 chm mohawk: There has been discussion at various times, no one ready to support is my summary.
20:40 chm jberger did a demo version of the PDL web site which was cool.
20:40 mohawk gahhh
20:41 mohawk so i have to email patches for them to be ignored?
20:41 mohawk can't i just click a couple of buttons to have them ignored instead? ;-)
20:41 chm I could say the same here.
20:42 chm If you put a git format patch on sf.net then I'm happy to apply.
20:42 mohawk ha
20:42 mohawk ok
20:42 mohawk how does one do that?
20:42 chm I suggested it might be possible to transition to github by mirroring
20:42 chm from sf.net to github so folks could use the github mirror and the changes would
20:42 mohawk you say "put on sf.net", you mean on the bugs system?
20:43 chm propagate back to sf.net.
20:43 chm There are trackers for bugs, feature requests and patches.
20:43 mohawk ok
20:43 chm Whichever is appropriate is fine.
20:43 mohawk my patch to implement the PDL_BOOT thing was taken, which is awesome
20:44 chm You may be interested in the current perldl list discussion about
20:44 chm getting PDL on android.
20:44 mohawk but my patch to implement ExtUtils::Depends support was tragically not taken
20:44 mohawk android, that must take some deep magic
20:44 chm I seem to remember that ExtUtils::Depends sounded nice but there was
20:45 chm no compelling justification.  Personally, I've been trying to reduce and simplify PDL
20:45 chm dependencies hence the idea that PDL3 starts as a kernel.
20:46 chm It might make sense to put ExtUtils::Depends support into that but I don't know
20:46 chm ExtUtils::Depends and I've had some experience with evanescent perl modules
20:46 chm and technologies.  One example is Module::Build which sounded nice and was getting
20:47 chm better but then the development support dried up---makefile and build process stuff
20:47 chm can be so tricky to get right.  In fact, my feeling now is that it is simpler to just check
20:47 mohawk did the patch i made give the impression it would add dependencies?
20:48 chm for a make command and just use ExtUtils::Makemaker
20:49 mohawk i'm now (for my sins) directly involved in EUMM
20:49 chm My statement was "ExtUtils:epends sounded nice but...no compelling justification."
20:49 mohawk and M::B was considered too hard to use
20:49 chm I also mentioned that I didn't know E:D nor was I conversant with the implications...
20:50 mohawk ok
20:50 chm re M:B, I agree.  I've never been able to figure out how to get a proper build script
20:50 mohawk yes
20:50 mohawk that's why the dev has dried up ;-)
20:50 chm and going up the learning curve on a "dying planet module" (deliberate hyperbole)
20:50 mohawk if i add a bit of explanation to my old EU::D patch, will you see it?
20:51 chm seemed like time could be better spent.
20:51 mohawk i hear you on the "use of time" point ;-)
20:51 chm The place for ExtUtils:: Depends discussion is on the perldl or pdl-porters mailing list
20:51 chm since that is where the full developer and user community can participate.
20:52 mohawk let me check the archive  to see what i said there
20:52 chm Feel free to update the ticket but the issue was lack of understanding of
20:52 chm all the issues, whether support made sense,... definitely something that needed
20:53 chm more than a cursory look by someone who isn't conversant with the benefits or usage
20:53 mohawk ah, i remember - you started out by describing this as a change to the internals, which baffled me a bit
20:55 chm I took a look at the ticket.  Changing the PDL build process *is* changing the internals
20:55 chm since if something breaks then the entire distribution breaks.
20:56 chm Compare that with breaking support for a library where the remainder of PDL
20:56 chm continues to "just work".
20:57 chm Take a look at the crufty Makefile.PL process and you'll see why PDL3 and a clean
20:57 chm start is a better place to fix things at the start.
20:58 mohawk i just looked at the email archive
20:58 mohawk i did send the email, and got zero responses
20:59 mohawk wait, hang on
21:00 mohawk re-reading your response at the time: http://mailman.jach.hawaii.edu/pipermail/pdl-porters/2014-April/006272.html
21:01 mohawk you said "make a git branch and do implementation" - how would i get those changes submitted?
21:02 chm Git is a distributed version control system.  You could host on github and when code
21:02 chm was ready to try, send email to the list with the link.
21:02 mohawk ok
21:03 chm The current plan for PDL-2.x is to finish the 64bit index support which I'm
21:03 mohawk in the email, you're inviting me to make large changes, from which you'll make a dev release
21:03 chm the only one working on and when PDL-2.008 is released, make that the stable PDL
21:03 chm and move real development to PDL3.  I think some of the big problems I'm having to
21:04 chm get a hacked in 64bit index support in PDL-2.x Core could actually be done more simply and
21:04 chm faster if we reboot the architecture.  Of course, something would be bound to break.
21:04 mohawk i have a concern
21:05 mohawk pdl2.008 is taking a long time
21:05 mohawk pdl3 will take no doubt a very long time
21:05 chm Actually, PDL-2.008 is taking a long time because I am the only one working
21:05 mohawk the change i'd like to make i need to see in a released version since it's for gimp-perl's build system
21:05 chm on it.  It mostly works but debugging the edge cases is difficult and I'm not
21:06 mohawk i tried to submit something that would have been part of 2.008 ;-)
21:06 chm that good with debug perl build and gdb.
21:06 chm I suggested a dev release of your E:D version of PDL-2.007 as a way to
21:07 chm verify that there was no adverse result.  I have no problem with supporting new
21:07 mohawk that sounds great
21:07 chm development but it seems to me perl module authors often do not consider
21:07 chm stability or portability to be important while my goal has been to have PDL
21:08 mohawk i'm patching EUMM
21:08 chm that can build everywhere and is compatible.  In fact, I've built some old PDL modules
21:08 mohawk let that be my statement of considering portability and stability ;-)
21:08 chm with the latest, bleeding edge version of PDL and it built out of the box.
21:08 chm Not many key modules can say that---the temptation to change the interface is
21:09 chm overwhelming (I know).
21:09 mohawk ok
21:09 mohawk you say you're considering a dev release with my EU::D support in?
21:09 chm A developer's release is just what it says.  A version on CPAN for developers.
21:10 chm We currently use them to make available the latest git progress for non-developers
21:10 mohawk i do know what a dev release is ;-)
21:10 chm to access and to take advantage of CPAN Testers (I'm saying what I use developer releases for)
21:10 mohawk yes, me too
21:11 mohawk smoke-testing is great
21:11 chm When PDL3 is underway, I'll be releasing franken-PDL to see how PDL2 compatability is going.
21:11 mohawk that's a good idea
21:11 chm I'm happy to do the same for a proposed development effort.
21:11 mohawk i've just spotted something in your april email i didn't properly notice before
21:11 mohawk you said about "moving to EU::D"
21:12 chm Just don't want to break PDL accidentally since I don't have the cycles to
21:12 mohawk "moving to" implies a change inside - my patch implements something pretty much on the outside only?
21:13 chm If there were a version of PDL master git that used ExtUtils Depends instead,
21:13 chm *and* the developers release passed 100% tests,
21:13 chm *that* would be an excellent starting point for moving it into a stable release
21:14 chm *but* with limited time, I'm not prepared to make a possible risky code change to PDL-2.x
21:15 chm *however*, Even if the PDL-2.x dev release wasn't stable, it would definitely be
21:15 mohawk i don't know why you keep referring to "using EU::D"
21:15 chm a good way to discuss how and when/where to implement for, say, PDL3.
21:16 mohawk my change doesn't "use" EU::D at all
21:16 mohawk it allows other modules to use EU::D
21:16 mohawk with PDL
21:18 chm I'm happy to make an ExtUtils Depends [whatever your word is] developers release of PDL.
21:18 chm Great point to start further discussion.j
21:18 chm Sorry, but I've got to go.  Have a good evening.  o/
21:19 mohawk i am begging you to please do that :-)
21:19 mohawk augghghhh
21:19 mohawk good evening to you too ;-)
21:19 Mithaldu he reads the logs, so he'll see it when you chat more at him :)
21:19 mohawk i know, that's why i included the wish for a pleasant evening even though he'd left
21:20 Mithaldu word :)
21:26 mohawk once the dev release happens, i can then depend on that dev release in GP in the "requires" and then delete a bunch of code
21:26 mohawk w00t
21:27 Mithaldu code--

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary