Re: [PHP-DEV] PHP User Survey
> > > When do you upgrade to a new release of php e.g. 5.3 -> 5.4 > > - As soon as released > > - wait for the x.1 release > > - Once our OpCode cache supports it > > - When previous version hits EOL > > - When a new feature warrants the upgrade > > - When my Framework (Zend/Symfony/cake) or Software (Wordpress, Gallery, > > etc) requires it > > You should add: > When my distro/hosting company upgrades. Also 'When my Framework supports it', as opposed to requires it. -- Niel Archer niel.archer (at) blueyonder.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git merge and generated files?
> Pierre, > > On Tue, Mar 27, 2012 at 5:43 PM, Stas Malyshev wrote: > > > Hi! > > > > >> Why would these change every 2nd commit? These only should change when > > >> you change the scanner, which happens very rarely. > > > > > > It depends what you do, but still annoying when it happens. > > > > > > But that does not answer the question... > > > > Looking at the patch, it looks like yours and git's line endings did not > > match, which may have caused the conflict. > > > Stas is right. Looks like the Windows CR line endings are causing it to > puke on ya. I'm assuming you're working in Windows, right? What Git > client are you using? > > If you're using Msysgit, it automatically converts these line endings for > you specifically to avoid this problem, but you have to select that option > during the installation process when it prompts you. I don't know if the > setting can be changed after install; my guess would be it can, but I have git config --global core.autocrlf true Global option obviously makes this apply to all repoes, not sure how it applies without it, as this is pretty much the only way to be able to work interoperably with Visual Studio. > no idea how. The easiest thing to do would be to just re-run the Msysgit > installer (if that's what you're using) and when prompted select the option > to auto-convert line endings (i.e. I think the option is something along > the lines of "Use Unix-Style line endings"). > > --Kris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
> On Wed, Jan 18, 2012 at 8:25 PM, William A. Rowe Jr. > wrote: > > > The SDK and DDK remain free with a minimal toolchain, including 64 bit > > compilers. Of course they aren't called that anymore, because things > > are only fun in the Windows world when they overhaul the glossary of > > terms every 3 years. > The SDK only supports 64bit now too? I remember it was not the case, > but if yes that's pretty good :). VS Express editions do not, but > that's not really a problem :) I can't say for VC9, but VC10 Express will compile 64 bit with the "Windows SDK for Windows 7" + .NET Framework 4.0 installed. I believe the compilers come with the Framework build additions. I'm currently using this on another project. > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting
>
> On May 26, 2010, at 5:20 PM, Zeev Suraski wrote:
>
> > At 23:44 26/05/2010, Davey Shafik wrote:
> >
> >> On May 26, 2010, at 3:08 PM, Zeev Suraski wrote:
> >>
> >> > At 21:12 26/05/2010, Pierre Joye wrote:
> >> >> As PHP's type system is seen as a big plus,
> >> >> I have to say that many users consider it as a plus in the
> >> >> implementation of a given method function or method. But the same
> >> >> users ask to have something more strict for the methods signature. I
> >> >> think it is a valid request and somehow makes sense too.
> >> >
> >> > I think that the proposed auto-converting type hints answer this request
> >> > quite well...
> >> >
> >> > Zeev
> >>
> >> Do you propose to have a warning when the types are a mis-match, similar
> >> to the
> >> array->scalar conversion example from Gustavo? (strtoupper(array('ABC')))
> >>
> >> If you have a warning or notice, that warns of potential loss of data
> >> accuracy, then
> >> I think I'd be OK with auto-converting.
> >
> > Yep - that's exactly the idea.
> >
> >> Having said that, all other type hints are strict, throwing a catchable
> >> fatal error consistency
> >> for what is essentially the same syntax, is more important IMO.
> >
> > In my opinion it's really a matter of whether the value makes sense in its
> > context or not. Much like a function that requires an object of type X
> > will accept an object of type Y if Y extends from X - because Y is a kind
> > of X, "42" is a kind of an int. It's true that no conversion is made in
> > the former case, but still - across 99.9% of PHP, "42", 42 and 42.0 are the
> > same thing.
> >
> >> Would it be possible to support two syntaxes:
> >>
> >> function foo( (int) $bar) { } // auto-cast to int
> >> function foo(int $bar) { } // require int
> >
> > I would advise against it - IMHO having both strict and auto-converting
> > type hints means having all of the issues of strict typing, and making that
> > worse by having similar confusing syntaxes on top of it... In general I
> > think there should be an exceptionally good reason to add core language
> > syntax. Auto-converting type hints would cater for the vast majority of
> > real world use cases. While I'm sure we can come up with situations where
> > you'd want a strict type check, for those few cases - you could simply use
> > is_int() - no need to add a language-level support for it.
> >
> > Zeev
>
> You could just as easily say to do:
>
> function foo($bar) {
> $bar = (int) $bar;
> }
>
> as:
>
> function foo($bar) {
> if (!is_int($bar)) {
> // error
> }
> }
Except this would be treated as an error with "42" and 42.0, whereas the
currently suggested implementation would not.
If your functions need strict type enforcement (I refuse to call it
hinting when there is no leeway that hinting implies), then you would be
better coding it in and reporting back any failures to the caller so
they can deal with it.
This is also true for type hinting.
Neither options are must have features in my mind, although type hinting
(hinting at what is needed and accepting anything which is close enough)
would be a nice to have feature.
> Why bother with either if that's the case? Why not add support for something
> like:
>
> function foo($bar) {
> (int) &$bar;
> }
>
> to allow for in-place casting (instead of temp-var+assign) and make it a
> shortcut.
>
> I'm sorry, but your reasoning is silly IMO. Type checking or casting are both
> currently
> easy enough to do; the only value in the auto-casting is to inform the user
> of loss of
> precision when they write against it. Does that really need language-level
> support?
>
> It could just as easily be part of the docblock.
>
> - Davey
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PDO DBLIB
> > Stanley Sufficool wrote: > > > I have tried to contact the maintainers of PDO with this, but have yet > > > to get a response. Can I get this reviewed and if possible commited? > > > > > > Fixes BUG # 50755: > > > http://bugs.php.net/bug.php?id=50755&edit=1 > > > > > > Compiled and tested with PHP SVN 5.2 > > > > PDO development has it's own list ;) > > p...@lists.php.net > > although joining it seems impossible ;-) Using the page here > http://www.php.net/mailing-lists.php to try joining the PDO list gets > the usual "A request has been entered into the mailing list processing > queue. You should receive an email at m...@example.com shortly describing > how to complete your request." however the mail never arrives. No such > problem with the other lists though. It's been this way for some time > now. Well whaddya-know! This time it worked for me, although 45 minutes wait seems long. I'd given up 20 minutes after the other requests had been answered. > > Although no doubt someone will pick it up from here ... > > > > -- > > Lester Caine - G8HFL > > - > > Contact - http://lsces.co.uk/wiki/?page=contact > > L.S.Caine Electronic Services - http://lsces.co.uk > > EnquirySolve - http://enquirysolve.com/ > > Model Engineers Digital Workshop - http://medw.co.uk// > > Firebird - http://www.firebirdsql.org/index.php > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PDO DBLIB
> Stanley Sufficool wrote: > > I have tried to contact the maintainers of PDO with this, but have yet > > to get a response. Can I get this reviewed and if possible commited? > > > > Fixes BUG # 50755: > > http://bugs.php.net/bug.php?id=50755&edit=1 > > > > Compiled and tested with PHP SVN 5.2 > > PDO development has it's own list ;) > p...@lists.php.net although joining it seems impossible ;-) Using the page here http://www.php.net/mailing-lists.php to try joining the PDO list gets the usual "A request has been entered into the mailing list processing queue. You should receive an email at m...@example.com shortly describing how to complete your request." however the mail never arrives. No such problem with the other lists though. It's been this way for some time now. > Although no doubt someone will pick it up from here ... > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Alternative mbstring implementation using ICU
> Hi there, > > I almost finished an alternative implementation of mbstring that uses > ICU instead of the exotic libmbfl in hope of replacing the current one > for 5.4 (and possibly, 6.0.) > > Although there are admittingly some known incompatibilities that need > extra libraries to resolve them besides a number of missing functions > that are intentionally removed for simplicity's sake, frequently used > functions are fully usable, and more compliant with the standard (e.g. > case insensitive matches). > > Any comments are appreciated. > > The source is ready in the following location: > > http://github.com/moriyoshi/mbstring-ng/ > > > Implemented functions: > > - mb_ereg() > - mb_ereg_replace() as ereg functions are deprecated in 5.3, are these still needed? > Regards, > Moriyoshi > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Niel Archer niel.archer (at) blueyonder.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Standards for developers
> > One of the problems with playing with a new platform is getting things > they way you are used to them. Linux is somewhat easier than Windows in > that respect, but using Eclipse has at least provided a level playing > field and now that I've got it tidied up and working on the Vista64 box > ( has to use w32 jave to run ;) ) I can now get around some of the > little niggles. I do not understand why you have to run with win32 Java. There is a 64 bit version of Java from Sun which runs on Windows. Like most 64 bit support on Windows, it takes some work to locate, the Java site mentions it, but despite referring to a download I can't find it there. Instead, I use this link: http://java.sun.com/javase/downloads/index.jsp Also, there is a 64 bit version of Eclipse, although you have to do some digging to find it exists. Go to the mirror of your choice and look for the 'eclipse-platform-SDK-3.4-win32-x86_64.zip' file. This requires that you add any dependencies for PDT etc yourself, but as each project lists its dependencies this is not a real problem. However, it's the only 64 bit version of Eclipse I have been able to find, PDT does not do a bundle for x64 yet :-( > Files that are common to windows and linux will naturally follow linux > rules on new line, so can't be displayed in 'notepad', and I've had to > switch some of the windows defaults to get 'wordpad' used instead. I had > forgotten to switch the wrap to ruler off which was causing a little > confusion with white space, but once I get Eclipse configured to the > windows php framework the problem will go away. Being used to 'notepad' > I kept opening files the wrong way at first, although some files do > actually display correctly in notepad. > > > Bottom line - rather than reinventing the wheel - is anybody else > actually using Eclipse and has a simple set-up guide for how they have > configured things? Ideally for windows, but I'd like to pull this up on > the Linux boxes as well. If I'm going to have to start working on > extension code it's easier on the linux box anyway and then I can cross > test on windows. > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Niel Archer niel.archer (at) blueyonder.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
