Re: Maintaining Math_Integer, Math_Complex, Math_Vector, Math_Matrix

Hi, A side note on top of this discussion, a few of us have started moving PEAR packages to github and created organisations for pear (https://github.com/pear) and pear2 (https://github.com/pear2); We would be more than happy to help you guys setup that up with the appropriate team structure. If you opt for using the php.net SVN setup then no problem, go ahead and request the SVN permissions. This next part is more for Jesus. 3 of the packages you are marked on as maintainer (one of which Louis mentioned) have a slight technical problem which I was hoping we could get fixed, even if you guys go for a pear2 version. Math_Basex, Math_Fibonacci, Math_Matrix have all had a stable release at one time or another but have a version below 1.0.0; This is what was marked as a grandfather rule, as that versioning schema came after your releases :-) It's nothing major and doesn't have to be done. But more importantly, these packages only have a package.xml v1 format and could do with an upgrade; Pyrus does not understand that format anymore, so these packages wouldn't install under that: Math_Fibonacci, Math_Histogram, Math_TrigOp, Message While I am at it and being innnnnncreadibly annoying here, sorry for that, would you consider moving the code away from PHP License to say... MIT or New BSD? I know it is a hassle and you are a busy busy man but the PHP License isn't the best suited for userland code and a while back the PEAR group decided against accepting more code in PEAR under that license. Anyway, whatever you guys decide on, not a problem; Excited to see progress on the Math packages... PHP can do with better math support in general ;-) - Helgi On 16 Mar 2011, at 16:20, Jesus M. Castagnetto wrote: > (I am CC'ing the pear-dev list.) > > Sure, request an SVN account, with the appropriate permissions. > > If you want I can give a hand with the new versions. That way is better, so > it is clear that they have a new API. > > You choice of svn or git for the collaboration. I can keep new versions on > github as I am keeping the old ones, along with the PEAR versions > > One thing that may be needed is to go through the proposal process, to get > the Math_Matrix2, etc. more in line with the current PEAR specs & standards. > > As soon as I get some free time, I'll put up some of the experimental > changes I made to my old code on my github. Feel free to pick from that if > you want. One idea I toyed with is to generalize de Math_Complex and > Math_Quaternion code a bit, but I am not sure how practical that would be. > Also it might not be useful (or perhaps it is) to keep the tuple support in > Math_Vectors, mainly because I am not sure now how much need there is for > inmutable-type vector types. > > Cheers. > > -- > Jesus M. Castagnetto <jesus@castagnetto.com> > Web: http://www.castagnetto.com/ > > > On Wed, Mar 16, 2011 at 11:12, Louis Mullie <louis.mullie@gmail.com> wrote: > >> Hello, >> >> Thank you for your fast reply. >> >> Should I go ahead and request an SVN account, or do I need further >> approval? >> >> Cheers! >> Louis-Antoine >> >> On 2011-03-15, at 5:56 PM, Jesus M. Castagnetto wrote: >> >> I got no objections, my time to help in PEAR is almos nill atm. >> >> You can pull current code for all those packages (and a couple more) from >> my github repos at (in reality, minor cosmetic changes from what it is on >> PEAR's SVN): >> >> https://github.com/jmcastagnetto >> >> As an aside, you will need to change de API of all the packages to be able >> to do the refactoring you propose, it would be better to change the name too >> (eg. Math_Matrix2) and move the whole new codebase to PEAR2. There is also a >> need to do some code elimination o replacement in some methods because now >> with the niceties of 5.x things can be cleaner. Perhaps even think about >> being compatible with 5.3+ namespacing? >> >> I got some kludges to the code to make those packages more 5.x friendly on >> a local repo at home, but it is not published yet because I have not had >> time to polish that and they are very flaky. >> >> If you need to bounce some ideas, keep writing to the list and/or send me a >> copy to my personal email address (in my sig), I will be glad to help in the >> nanoscopic free time I got now :-) >> >> (Note: being a dad of a 2yr old uses oodles of time, but it sure is fun :-) >> >> Cheers. >> >> -- >> Jesus M. Castagnetto <jesus@castagnetto.com> >> Web: http://www.castagnetto.com/ >> >> >> On Tue, Mar 15, 2011 at 15:29, Louis Mullie <louis.mullie@gmail.com>wrote: >> >>> Hi, >>> >>> I would be interested in taking over the packages Math_Complex, >>> Math_Integer, Math_Vector and Math_Matrix. I have discussed my request on >>> PEAR-QA and Mr. Christian Weiske has suggested I post here to detail my >>> intentions concerning these packages, as well as tell you a bit about me. >>> >>> There are no open bugs for any of these four packages as of March 15th, >>> 2011. Therefore, my first concern would be to unify the implementation of >>> operations in these packages; currently, Math_Integer, Math_Complex and >>> Math_Vector use an "operations" class with static functions, while >>> Math_Matrix supports direct operations on Math_Matrix objects. For example, >>> adding a matrix to a matrix in Math_Matrix is done by >>> $matrix->add($matrix2), while adding a vector to a vector in Math_Vector >>> would be done by calling Math_VectorOp::add($vector1, $vector2). I would >>> transfer matrix operations to a static Math_MatrixOp class, to make things >>> consistent with the three other packages. Finally, I would unify the >>> operations interface (e.g. Math_Matrix::substract() vs. >>> Math_VectorOp::sub(), etc.). All of these packages are still beta, so my >>> objective would be to make the interface as consistent as possible before >>> releasing stable versions. As a side note, I am having trouble finding >>> PEAR's official guidelines on backward-compatibility - anybody who could >>> link me to the relevant documentation would be greatly thanked! >>> >>> After this is done, I would like to achieve better integration between >>> these different packages. i.e. add support for complex numbers in >>> Math_Vector and Math_Matrix. I am quite open to ideas about how to go about >>> this; my basic idea would be to provide a common "Math_Number" class >>> providing a common interface for Math_Complex and Math_Integer (and maybe >>> eventually Math_Fraction?), and a "Math_NumberOp" class interfacing >>> Math_ComplexOp and Math_IntegerOp (and Math_FractionOp?). The updated >>> versions of Math_Vector and Math_Matrix would support matrixes and vectors >>> of Math_Number objects as well as native PHP numbers. >>> >>> A bit about me and my capacities: I am a 19-year old student of medicine >>> living in Montreal, and I have been working with PHP for more than 6 years. >>> I have already submitted a package proposal called "Lexer" to PEAR back in >>> 2005 (http://pear.php.net/pepr/pepr-proposal-show.php?id=197), which was >>> accepted, but eventually orphaned (I was, then, 13 years old and my interest >>> in PHP, as you may imagine, gradually shifted towards other things). I have >>> gotten back into PHP about a year ago, and I now feel I can contribute more >>> significantly to the PEAR community. >>> >>> Best regards, >>> Louis Mullie >>> >>> On 2011-03-15, at 2:58 PM, Christian Weiske wrote: >>> >>>> Hello Louis, >>> >>>> That's great to hear! Before officially giving you maintainer status on >>>> the packages, please discuss your future plans with the package on the >>>> pear-dev mailing list since there is a wider audience of developers >>>> than on the pear-qa list. >>>> >>>> You may also attach patches to the open bugs/feature requests on the >>>> bug tracker, which helps us to assess your skills and eligibility to >>>> lead the package development. >>>> >>>> -- >>>> Regards/Mit freundlichen Grüßen >>>> Christian Weiske >>>> >>>> -=≡ Geeking around in the name of science since 1982 ≡=- >>> >>> >>> -- >>> PEAR Development Mailing List (http://pear.php.net/) >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> >> >>