Re: [PHP-DEV] Re: Git Migration: Status Update
I was about to respond to Lester's comments but it looks like Jeremiah beat me to it (again). Yeah he's correct in that "bad habits" refers to using Git the same way you would use Subversion. It was not mean to refer to how you've used Subversion itself. @David Generally, I would resolve this by having an intermediary branch intended solely for such collisions. For example: git checkout PHP_5.3 (git commits) git checkout PHP_5.4 (git commits) git checkout PHP_5.3-5.4_bridge git merge --no-ff PHP_5.3 git merge --no-ff PHP_5.4 (resolve merge conflicts, if any) git checkout PHP_5.4 git merge --no-ff PHP_5.3-5.4_bridge (then, when it's time for a major release; which is the only time master should ever be used) git checkout -b Release-(version number) PHP_5.4 (any last-minute release commits; basically, each commit is a release candidate) git checkout master git merge --no-ff Release-(version number) git checkout PHP_5.4 git merge --no-ff Release-(version number) git branch -d Release-(version number) The above approach would allow for David's scenario of merging 5.3 changes into 5.4 without disrupting development on either branch in the event of merge conflicts, simultaneous commits, etc. I could probably draft something a little more comprehensive if anyone's interested. --Kris On Sun, Mar 4, 2012 at 1:30 PM, David Soria Parra wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/04/2012 10:32 AM, Jaroslav Hanslik wrote: > >> > >> (3) Karma system fixes. Already done by me. People who have > >> access to the root of a repository are able to do forced pushes. > >> > > > > > > Do you think it's good idea not to forbid forced pushes at all? > No. We will always need to be able to delete branches created, or tags > (we had situations were we needed to retag, for example). That in > itself can be used to do a forced push: > > git push :master && git push mynewmaster:master > > Will be equal to > > git push +mynewmaster:master > > equal to > > git push --force mynewmaster:master > > I am also not a strong believer trying to forbid as much as possible. > If you have an SVN account you are trusted enough to not just delete > something that is used. Also thanks to the decentralized model of git > we all have backups, so we can just recreate it. > > David > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQIcBAEBAgAGBQJPU98AAAoJEAT0aMuPE7Z1SM8P/1eN+edqsqoMPukCZfeeWbFm > DM4wRS1UYyc4WZ2LrUi/6+hadgEk4QZLwkLiZPw+CuYwlGtkRhIoPWskV3HK4xT9 > HqdMeHxTxEAjsq0dnb37hklSGc2LlTFRnUhCHkrZdGb4OZEjOXeQBVa8ud/32Exa > Cjxcyrmrzdxzu65W1P203zjAwo4jCR24PgWw4qhAqqI4UNYuHhgmIvptOo0MMvZV > bkZ2GzKDsZladGG+mVwHdxZNwPOU9CxFnWG36wX7tl11uX80M+4WMTTJ43T1kpif > ZhqbUrUWwitaZfdLBE9apKpwzO09cQdEsY7hgezZNntyH4PmHV+NCvCgz+BBywzM > ivxNSjvTj8Kt3p4Y63WXOlfdrhTG/65hoZQTMn2Mv3qSIx3lVIqnUc/UFk5WBEI/ > qOBARLGBtqy1ytMTdLLAcYN3cqFKS+zV0ucYIrBClr1LeIuAkIjfXNZ55CILmGy8 > KEwJn6gC495jzV3LK7dw9S0mUiVvraG3IeBsNcJr8OELPZFC/U5IZHO0o1bafXWQ > I/iqAA2tPeHQ289XyyHRSqL+qQHfDwP75gB0uUcu43lSieu0bNwkCI7IotHtC5vi > dePV4pzyj+Yjyicx4NcrurWW5BeLafe8l1wvzUNS7SmrtUr3ZMJkj6qIVbVq6hq5 > GvGw6+527FSIwn0TUGC2 > =+P5T > -END PGP SIGNATURE- > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Re: Git Migration: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2012 10:32 AM, Jaroslav Hanslik wrote: >> >> (3) Karma system fixes. Already done by me. People who have >> access to the root of a repository are able to do forced pushes. >> > > > Do you think it's good idea not to forbid forced pushes at all? No. We will always need to be able to delete branches created, or tags (we had situations were we needed to retag, for example). That in itself can be used to do a forced push: git push :master && git push mynewmaster:master Will be equal to git push +mynewmaster:master equal to git push --force mynewmaster:master I am also not a strong believer trying to forbid as much as possible. If you have an SVN account you are trusted enough to not just delete something that is used. Also thanks to the decentralized model of git we all have backups, so we can just recreate it. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU98AAAoJEAT0aMuPE7Z1SM8P/1eN+edqsqoMPukCZfeeWbFm DM4wRS1UYyc4WZ2LrUi/6+hadgEk4QZLwkLiZPw+CuYwlGtkRhIoPWskV3HK4xT9 HqdMeHxTxEAjsq0dnb37hklSGc2LlTFRnUhCHkrZdGb4OZEjOXeQBVa8ud/32Exa Cjxcyrmrzdxzu65W1P203zjAwo4jCR24PgWw4qhAqqI4UNYuHhgmIvptOo0MMvZV bkZ2GzKDsZladGG+mVwHdxZNwPOU9CxFnWG36wX7tl11uX80M+4WMTTJ43T1kpif ZhqbUrUWwitaZfdLBE9apKpwzO09cQdEsY7hgezZNntyH4PmHV+NCvCgz+BBywzM ivxNSjvTj8Kt3p4Y63WXOlfdrhTG/65hoZQTMn2Mv3qSIx3lVIqnUc/UFk5WBEI/ qOBARLGBtqy1ytMTdLLAcYN3cqFKS+zV0ucYIrBClr1LeIuAkIjfXNZ55CILmGy8 KEwJn6gC495jzV3LK7dw9S0mUiVvraG3IeBsNcJr8OELPZFC/U5IZHO0o1bafXWQ I/iqAA2tPeHQ289XyyHRSqL+qQHfDwP75gB0uUcu43lSieu0bNwkCI7IotHtC5vi dePV4pzyj+Yjyicx4NcrurWW5BeLafe8l1wvzUNS7SmrtUr3ZMJkj6qIVbVq6hq5 GvGw6+527FSIwn0TUGC2 =+P5T -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/04/2012 02:09 PM, Stefan Marr wrote: > Hi David: > > On 03 Mar 2012, at 22:58, David Soria Parra wrote: > >> (1) Pull requests on github.com go to the git-pull mailinglist. >> Make sure you subscribe to it. (2) Johannes is working on an >> interface that allows people with valid PHP user accounts to >> close pull requests. (2) Fix the bugsweb integration, so that >> references to bugs inside the commits will work. Florian is >> working on it. (4) FAQ > > Will there be an integration with pull requests and the bug > tracker, or remains attaching patches the preferred way? Nobody has worked on that, but it's a possiblity. I would like to see pull requests supported in the bugtracker. > > What is the new preferred replacement for a sparse SVN checkout + > single commit per change? As I understand it, currently, we try to > have a single commit for all branches (PHP_5_n, and trunk). How is > that supposed to be done with git? From reading > https://wiki.php.net/rfc/dvcs#workflows, I assume, all branches > need to receive separate commits + pushes? Sparse checkouts won't work anymore. The proposed workflow is: commit to the lower possible branch, then merge up to the other branches e.g: $ git checkout PHP_5_3 ..hackhack... $ git commit $ git checkout PHP_5_4 $ git merge PHP_5_3 $ git checkout master $ git merge PHP_5_4 There will be situations were we have to cherry pick certain changesets and then make sure that git doesn't get confused. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPU9tNAAoJEAT0aMuPE7Z1sFcP/3Bc4AFhR0D78PDpovnflR8D KWRNyl6s1w6cwo1P98NhZzIJ9DuxKg0VAkU18YZamDpoghJScJe/W9YFu4xJLuZF oaw/4HhVxiQyi60i+eAADx9rAeanVRPVlBEjB4SOsAuj2Ax9Mx8gcfUHu37X+CiT sXOfL92lDDsHx9kJMM/mHkkXpyf5xfcgUatHoTNiBY7qkmznIvVEto8ohGmjsCbh GUQK5xbIqFzcmuN9uLnfMiDsppL+fFO05VHWJam8KmpoUQ4vNINZZp7zhpjGj5on PGi3Q/5jlAtJvK0utvqpfFbolk+d+54BN6YlnfNEsP/kageNIuR42qq/5SVm6qPa qyDcmrQp5kgyOAy2SwxFYZThEel46FBgu8LmCizh6n/sCgk9hFkg1GSH7lxNA4D5 FASiv1zYDVY2RpnxTyArUmgSdns+k6gXwc2gYZ6CcDJSzTg2jSPnyyjWjbKy5Edd k8NOHxM+GduvHpbQGO1uk2sk3TLY8inWHW22IVtIZ+kiXKPW2daJs8AcKeQqUSUe /mZQ3tci8XlWiaazWbcoU5Zw5iHNp/39BRWkJi2rHCNGFEqrcUOF8o4fo9Txjlwi 7h2vhcl00el1vS5k6vNQhrPd4a98uOc2AQQOJuwlAM2+xXgoxxuGPC0kAfP4n2+s zRsjMjOBD3ZCNypV8U0R =RgaM -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
On Mar 4, 2012 11:47 AM, "Lazare Inepologlou" wrote: > > > Anthony, just a tiny detail in your RCF: > >> So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo = “1” will generate an E_COMPILE_ERROR. > > > If null is going to be cast, (int)null is 0. So I don't think it should be a valid default value. Well, there were two reasons that I added null: first, for consistency with the existing type hints. Second, and more importantly, to allow checking if a parameter is specified. So without null, you couldn't tell the difference between an explicit 0 and an implicit (not specified) 0. This way, you can. I admit the use cases for that are rather slim, but a good portion of internal functions behave this way (substr comes to mind)... I think it is worth discussing further, as your point is indeed valid... > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara >> >> Hey all, >> >> I've drafted an RFC for the Parameter type casting hint proposal that >> I posted to before. Attached to the RFC is a patch that's proposed >> for inclusion in core for functionality (it doesn't include news >> entries, or documentation, or any of the other steps that would be >> needed prior to commit). >> >> https://wiki.php.net/rfc/parameter_type_casting_hints >> >> Please provide feedback here on the implementation and RFC topics. >> >> Thanks, >> >> Anthony >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > On Mar 4, 2012 11:47 AM, "Lazare Inepologlou" wrote: > > Anthony, just a tiny detail in your RCF: > > So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo >> = “1” will generate an E_COMPILE_ERROR. >> > > If null is going to be cast, (int)null is 0. So I don't think it should be > a valid default value. > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara > >> Hey all, >> >> I've drafted an RFC for the Parameter type casting hint proposal that >> I posted to before. Attached to the RFC is a patch that's proposed >> for inclusion in core for functionality (it doesn't include news >> entries, or documentation, or any of the other steps that would be >> needed prior to commit). >> >> https://wiki.php.net/rfc/parameter_type_casting_hints >> >> Please provide feedback here on the implementation and RFC topics. >> >> Thanks, >> >> Anthony >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
It would make sense that the default value you're setting matches the zval.type of the casted value. You always want it to be an int, if you're doing (int) so setting it to a string or array would not make sense. - Paul. On Sun, Mar 4, 2012 at 4:46 PM, Lazare Inepologlou wrote: > Anthony, just a tiny detail in your RCF: > > So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo >> = “1” will generate an E_COMPILE_ERROR. >> > > If null is going to be cast, (int)null is 0. So I don't think it should be > a valid default value. > > > Lazare INEPOLOGLOU > Ingénieur Logiciel > > > 2012/3/4 Anthony Ferrara > >> Hey all, >> >> I've drafted an RFC for the Parameter type casting hint proposal that >> I posted to before. Attached to the RFC is a patch that's proposed >> for inclusion in core for functionality (it doesn't include news >> entries, or documentation, or any of the other steps that would be >> needed prior to commit). >> >> https://wiki.php.net/rfc/parameter_type_casting_hints >> >> Please provide feedback here on the implementation and RFC topics. >> >> Thanks, >> >> Anthony >> >> -- >> 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] [RFC - Discussion] Parameter Type Casting Hints
Anthony, just a tiny detail in your RCF: So (int) $foo = null and (int) $foo = 1 are both supported, but (int) $foo > = “1” will generate an E_COMPILE_ERROR. > If null is going to be cast, (int)null is 0. So I don't think it should be a valid default value. Lazare INEPOLOGLOU Ingénieur Logiciel 2012/3/4 Anthony Ferrara > Hey all, > > I've drafted an RFC for the Parameter type casting hint proposal that > I posted to before. Attached to the RFC is a patch that's proposed > for inclusion in core for functionality (it doesn't include news > entries, or documentation, or any of the other steps that would be > needed prior to commit). > > https://wiki.php.net/rfc/parameter_type_casting_hints > > Please provide feedback here on the implementation and RFC topics. > > Thanks, > > Anthony > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Git Migration: Status Update
jeremiah.do...@gmail.com wrote: I hope that clarifies things a bit. It definitely doesn't make grokking things a whole lot easier, and it is certainly *possible* to follow a very svnish workflow using git (and may sometimes make sense to, although I am struggling to thing of such a time). I've been using Hg myself for the 'DVCS' style of working. This allows me to publish my own ports of things which others can follow, but from which I can push things back to the original project as required. I'm still not convinced that the 'production' branches such as PHP5.3 can be run without some element of management, although of cause a release will still be packaged as a tarball set and then frozen. On Hg I just pull a particular tarball ... such as PHP5.3.10 ... as I require it direct from the repo but some of the projects I am working with have now lost the 'master' codebase simply because groups of developers are now doing their own thing. The overall flexibility of DVCS still needs a mindset of maintaining a code base that follows the master route plan? Which may well be a more 'svnish' way of working when testing and committing production ready code? The question I think that needs to be asked is 'should experimental development branches exist in the master code base?' all very easy to do with DVCS, but is it practical. Does it not make sense to clone the experimental work from another source, and keep the main codebase tidy with just proven pushes that follow the production path. There is nothing actually stopping someone producing their own private branch and sharing that while it is being developed, just pushing the results back to the relevant master branch when development work has been completed? -- 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
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Is (DateInterval) a valid cast currently in PHP ?
If not, then we're not looking to add new fancy casting options, just
give casting options on the simple existing ones.
- Paul.
On Sun, Mar 4, 2012 at 4:26 PM, Lazare Inepologlou wrote:
>> I wouldn't want people to put class typehints in there such as
>>
>> function foo( (SomeClass) $foo)
>
>
> Why not? I would definitely like something like that, in the future. Here is
> an example:
>
> class DateTime {
> ...
> public function add( (DateInterval) $interval ) { ... }
> ...
> }
> $date = new DateTime;
> $date->add( 'P3D' ); // string to DateInterval casting
> $date->add( 3600 ); // int (seconds) to DateInterval casting
>
> Personally, I find this to be much closer to free type-juggling PHP style
> than the current implementation with type hints
> (http://www.php.net/manual/en/datetime.add.php).
>
> [ Actually, I would prefer even type hints to work like this. Check if the
> passed argument if of the correct type and, if not, try to cast it. Failure
> to do so will lead to the E_RECOVERABLE_ERROR as today. ]
>
>
> Lazare INEPOLOGLOU
> Ingénieur Logiciel
>
>
>
> 2012/3/4 Paul Dragoonis
>>
>> Can you make sure that only scalar or array casts can be done?
>>
>> I wouldn't want people to put class typehints in there such as
>> function foo( (SomeClass) $foo)
>>
>> - Paul.
>>
>> On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara
>> wrote:
>> > Hey all,
>> >
>> > I've drafted an RFC for the Parameter type casting hint proposal that
>> > I posted to before. Attached to the RFC is a patch that's proposed
>> > for inclusion in core for functionality (it doesn't include news
>> > entries, or documentation, or any of the other steps that would be
>> > needed prior to commit).
>> >
>> > https://wiki.php.net/rfc/parameter_type_casting_hints
>> >
>> > Please provide feedback here on the implementation and RFC topics.
>> >
>> > Thanks,
>> >
>> > Anthony
>> >
>> > --
>> > 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] [RFC - Discussion] Parameter Type Casting Hints
>
> I wouldn't want people to put class typehints in there such as
>
function foo( (SomeClass) $foo)
>
Why not? I would definitely like something like that, in the future. Here
is an example:
class DateTime {
...
public function add( (DateInterval) $interval ) { ... }
...
}
$date = new DateTime;
$date->add( 'P3D' ); // string to DateInterval casting
$date->add( 3600 ); // int (seconds) to DateInterval casting
Personally, I find this to be much closer to free type-juggling PHP style
than the current implementation with type hints (
http://www.php.net/manual/en/datetime.add.php).
[ Actually, I would prefer even type hints to work like this. Check if the
passed argument if of the correct type and, if not, try to cast it. Failure
to do so will lead to the E_RECOVERABLE_ERROR as today. ]
Lazare INEPOLOGLOU
Ingénieur Logiciel
2012/3/4 Paul Dragoonis
> Can you make sure that only scalar or array casts can be done?
>
> I wouldn't want people to put class typehints in there such as
> function foo( (SomeClass) $foo)
>
> - Paul.
>
> On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara
> wrote:
> > Hey all,
> >
> > I've drafted an RFC for the Parameter type casting hint proposal that
> > I posted to before. Attached to the RFC is a patch that's proposed
> > for inclusion in core for functionality (it doesn't include news
> > entries, or documentation, or any of the other steps that would be
> > needed prior to commit).
> >
> > https://wiki.php.net/rfc/parameter_type_casting_hints
> >
> > Please provide feedback here on the implementation and RFC topics.
> >
> > Thanks,
> >
> > Anthony
> >
> > --
> > 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-DEV] Could somebody apply a patch for bug #61273
Hi! Could somebody with Zend karma please apply the patch attached to https://bugs.php.net/bug.php?id=61273 ? Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patches for Review
On Sun, 04 Mar 2012 15:02:23 +0100, Anthony Ferrara wrote: In sum, I think the rule that if a mathematical operation involves a float, the result should be a float ought to be kept. Yes, it is a must. Well, I'm not so sure about that. If you look at the docs of pow(), it describes the return type as "base raised to the power of exp. If the result can be represented as integer it will be returned as type integer, else it will be returned as type float.". That's not the current behavior. pow((float) 2, 1) returns float(2). If you want to update the docs instead of the code, then that's fine. You're reading too much into the documentation. The intention of that phrase seems to be if the result overflows, it will a float instead (just like when you add two large integers, for instance). Yes, the plain text doesn't preclude your interpretation, but it's not supported by the implementation or the general behavior of mathematical operators in PHP. By all means, change it in order to make it more clear. However, this can lead to precision loss in a number of cases (like pow(2, (float) 55) which is not representable exactly by a float, and hence cause data-loss. Whereas converting to an integer allows (on 64 bit platforms) an exact representation. You're making a critical error here. float(55.) is in fact different from int(55). Float values have a rounding error associated, while integers don't. The accuracy of float(55.) is 14.2142, which means the uncertainty is 6.10623*10^-15, or that float(55.) = 55 +- 3.05311*10^-15. Mathematical operations will only increase the (relative) error and therefore decrease the precision. This is an example with Mathematica's arbitrary precision numbers (NOT machine precision numbers, even though I'm setting the arbitrary precision to $MachinePrecision); this keeps track of the accumulated errors: In[30]:= SetPrecision[55, $MachinePrecision] // Precision Out[30]= 15.9546 In[31]:= 2^SetPrecision[55, $MachinePrecision] // Precision Out[31]= 14.3734 This means that if you do 2^55., the result will have total uncertainty: In[34]:= 2^SetPrecision[55, $MachinePrecision] // 10^-Accuracy[#] & Out[34]= 152.492 Take your example: var_dump((int) (pow(2, (float) 55) - 1)); You're adding 1 to a result that has a total uncertainty of more than 152... It's pointless, don't you think? Of course, PHP doesn't keep track of errors, and the reason subtracting 1 has no effect is because the rounding error itself in the result is already larger than 2: In[45]:= 2^55. // 10^-Accuracy[#] & Out[45]= 4. [...] Additionally, I thought the whole point of type juggling in PHP was such that the type didn't matter? So that a float and an int are the same from a usage standpoint? This is a very vague statement. "Doesn't matter" for what? We have different types for integers and floats, 1. and 1 are different things and this is reflected in several places. What type juggling does is that one *one specific type is expected*, but another one is given, PHP tries to convert the result. This doesn't mean the types are "implementation details". But this is a case where the exact same input (just type is different) leads to different output. Which I believe is inconsistent and incorrect. But if the consensus is otherwise, that's fine... -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
Stefan Marr writes: > Hi David: > > On 03 Mar 2012, at 22:58, David Soria Parra wrote: > >> (1) Pull requests on github.com go to the git-pull mailinglist. >> Make sure you subscribe to it. >> (2) Johannes is working on an interface that allows people with >> valid PHP user accounts to close pull requests. >> (2) Fix the bugsweb integration, so that references to bugs inside >> the commits will work. Florian is working on it. >> (4) FAQ > > Will there be an integration with pull requests and the bug tracker, or > remains attaching patches the preferred way? > > What is the new preferred replacement for a sparse SVN checkout + single > commit > per change? I'm not familiar enough with PHPs workflow to answer this in full, but a single commit per change can be done by developing a feature in a branch, and then merging it with the '--squash' option, which does the merge in your working directory, but does not create a commit for it, allowing you to bring in multiple commits from your branch(es) into one commit that is going to be shared in public history. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
Lester Caine writes: > Kris Craig wrote: >> I count myself lucky in that I started using Git before Subversion. People >> with that background often have an easier time at first because they aren't >> burdened with having to un-learn a bunch of "bad habits." > > I feel I HAVE to comment on that statement. A 'different way of work' is not > bad habits' ... most of the time I am criticised for my method of working, but > it has worked well of a long time now, and it's people who have never used a > decent integrated IDE that complain that it's bad. Most of the 'extras' that > are > being bolted on now, and the changes to a 'git' mentality simply don't live > well > when one has an existing functional method of working ... but 'bad habits' do > not come into it! I'd like to do a little bit of clarification here. Apologies in advance if this is a boring bunch of review for anyone. "Bad habits" in this context is not referring to your workflow using svn being a bad thing. It refers to "not using git in a manner in line with its philosophy", or more generally "using a tool in a manner that is impractical for that tool". Svn is all about preserving commit history. A commit in svn represents a *permanent* point in the global history of a repository. You can make modifications to it, but it's painful because you're not intended to -- and if you feel the need to, you are not using svn "correctly", or you have bad habits when working with svn. Git is also about preserving commit history, but since commits can happen locally and never be shared with anybody, git only cares about it for commits that are shared. The change in mentality, and change in habits largely comes from thinking about the commits that exist only on *your* machine as only *your* commits. This is what all the extra crap that's annoying to wrap your head around is about. While git happens to preserve public commit history, it's more of a result of its primary goals than a goal itself. Its goal is to allow someone working on a codebase to freely experiment and take exploratory lines of development while staying current with what other people are doing. To accomplish the above goal, git makes its primary operations ones that are operations on a DAG that represents commits. If you have a repo with the following history (where letters are commits): A -> B -> C If you want to develop a feature, you make a branch. To git, a branch is just a pointer to a commit, so you end up with a graph like this: A -> B -> C \-> D -> E -> F If work has been done on the same line of development while you've been working on your feature, you could have a graph looking like this: A -> B -> C -> G -> H -> I \-> D -> E -> F Now, if you wanted to share your changes, you *could* merge these branches, but this gives you a graph like this: A -> B -> C -> G -> H -> I --> J \-> D -> E -> F / Which *does* serve your purpose, but it also exposes the fact that your development happened in a separate part of the graph. It's likely that you don't actually care about this, and neither do the people receiving the commits you're sharing. This is what "rebasing" is for. If instead of merging, you rebased your feature branch onto its parent, you'd get a graph like this: A -> B -> C -> G -> H -> I \-> D -> E -> F Git takes the work that's been done since you branched, and makes it so that the commits you made were made after that work was done, as far as the commit history is concerned. When you then share your changes by merging them into the parent branch, git is smart enough to see that this is a linear line of development, and doesn't create a new commit: A -> B -> C -> G -> H -> I -> D -> E -> F You can also tell git to take the *sum* of your changes and combine them into *one* commit on the parent branch instead of the three you made (referred to as squashing), if you don't think that anything but the end result is relevant for the people you're sharing with. Doing this "rebase into my feature branch and then merge into the parent branch" dance means that if conflicts happen, they happen locally, and only with the commits you have made -- which makes them easier to fix. The *ability* of git to do things like this means you can be very fluid with your workflow on your own machine, while not disturbing the workflows of other developers. In svn, the DAG in question still exists conceptually, but it's represented in a different way. Because operations that modify it effect everyone with a checkout, it's very difficult to modify it, and people merge branches with caution. In git, branching tends to be something people do ridiculously often, so much that the history of what branch was made and merged into what and so on becomes noise in a majority of cases. As such, people tend to use a workflow that is a bit different from the svn workflow as far as their machine is c
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Good. On Sun, Mar 4, 2012 at 2:03 PM, Anthony Ferrara wrote: >> Can you make sure that only scalar or array casts can be done? >> >> I wouldn't want people to put class typehints in there such as >> function foo( (SomeClass) $foo) > > That's how it is implemented now. That'll generate a parse error... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
> Can you make sure that only scalar or array casts can be done? > > I wouldn't want people to put class typehints in there such as > function foo( (SomeClass) $foo) That's how it is implemented now. That'll generate a parse error... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patches for Review
>> In sum, I think the rule that if a mathematical operation involves a float, >> the result should be a float ought to be kept. > > Yes, it is a must. Well, I'm not so sure about that. If you look at the docs of pow(), it describes the return type as "base raised to the power of exp. If the result can be represented as integer it will be returned as type integer, else it will be returned as type float.". That's not the current behavior. pow((float) 2, 1) returns float(2). If you want to update the docs instead of the code, then that's fine. However, this can lead to precision loss in a number of cases (like pow(2, (float) 55) which is not representable exactly by a float, and hence cause data-loss. Whereas converting to an integer allows (on 64 bit platforms) an exact representation. I'm not suggesting changing addition to follow these rules, but to bring pow() into alignment with the documentation. And I think because of the nature of pow(), the likelihood that you'll have precision loss is a lot higher than other areas... But if the sentiment is strong against it, then an update of docs is in order... Additionally, I thought the whole point of type juggling in PHP was such that the type didn't matter? So that a float and an int are the same from a usage standpoint? But this is a case where the exact same input (just type is different) leads to different output. Which I believe is inconsistent and incorrect. But if the consensus is otherwise, that's fine... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC - Discussion] Parameter Type Casting Hints
Can you make sure that only scalar or array casts can be done? I wouldn't want people to put class typehints in there such as function foo( (SomeClass) $foo) - Paul. On Sun, Mar 4, 2012 at 1:28 AM, Anthony Ferrara wrote: > Hey all, > > I've drafted an RFC for the Parameter type casting hint proposal that > I posted to before. Attached to the RFC is a patch that's proposed > for inclusion in core for functionality (it doesn't include news > entries, or documentation, or any of the other steps that would be > needed prior to commit). > > https://wiki.php.net/rfc/parameter_type_casting_hints > > Please provide feedback here on the implementation and RFC topics. > > Thanks, > > Anthony > > -- > 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] Patches for Review
On Sun, Mar 4, 2012 at 2:29 PM, Anthony Ferrara wrote: > Hey all, > [snip] > https://bugs.php.net/bug.php?id=60596 > A little code-cleanup to remove a superfluous if statement in a switch > in the spl_offset_convert_to_long function... Applied in http://svn.php.net/viewvc/?view=revision&revision=323863. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patches for Review
On Sun, Mar 4, 2012 at 2:52 PM, Gustavo Lopes wrote: > In sum, I think the rule that if a mathematical operation involves a float, > the result should be a float ought to be kept. Yes, it is a must. -- 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
Re: [PHP-DEV] Patches for Review
On Sun, 04 Mar 2012 14:29:49 +0100, Anthony Ferrara wrote: I had messaged about these patches before, but with the 5.4 release process happening I think it slipped through the cracks. I have 3 patches that are ready for inclusion... [...] https://bugs.php.net/bug.php?id=60789 Bringing pow() inline with docs in that it will attempt to return an integer (by casting one or more of the arguments to int) if possible. This fixes a precision loss that can occur with float arguments that are exactly integers on 64 bit platforms. [...] This doesn't seem right. It's overly clever. It's like saying that 4.0 + 1 should return int(5) and not float(5.). Or perhaps a closer analogy would be: if we're in a 64-bit platform (only then can integers have a larger precision than doubles); if one of the operands is exactly an integer; if the other operand is a float exactly representable as an integer (perhaps a large power of 2), but its accuracy is negative (where accuracy is the 15.9546 - log10(abs(x)), or, informally, the effective number of digits to the right of the decimal point); if the result of the sum is exactly representable as a 64-bit integer; then return such integer. It's easy to see these sort of tricks would have to be applied all over the place (additions, products, and all other mathematical operations). In sum, I think the rule that if a mathematical operation involves a float, the result should be a float ought to be kept. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Deprecate and remove /e modifier from preg_replace
The vote ended with 23 pro / 4 con. The /e modifier is now deprecated in trunk: http://svn.php.net/viewvc?view=revision&revision=323862 Nikita On Sun, Feb 12, 2012 at 7:34 PM, Nikita Popov wrote: > As there doesn't seem to be any further discussion regarding this > issue I have opened the vote: > > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier#vote > > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patches for Review
Hey all, I had messaged about these patches before, but with the 5.4 release process happening I think it slipped through the cracks. I have 3 patches that are ready for inclusion... https://bugs.php.net/bug.php?id=60813 Adding a new hash_pbkdf2() function to allow for a C level implementation of the PKCS5 recomended password key stretching algorithm. https://bugs.php.net/bug.php?id=60789 Bringing pow() inline with docs in that it will attempt to return an integer (by casting one or more of the arguments to int) if possible. This fixes a precision loss that can occur with float arguments that are exactly integers on 64 bit platforms. https://bugs.php.net/bug.php?id=60596 A little code-cleanup to remove a superfluous if statement in a switch in the spl_offset_convert_to_long function... If anyone can commit these, if I can be granted the Karma to commit them. of if anyone can comment as to why they should not be committed, that would be great. Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
Hi David: On 03 Mar 2012, at 22:58, David Soria Parra wrote: > (1) Pull requests on github.com go to the git-pull mailinglist. > Make sure you subscribe to it. > (2) Johannes is working on an interface that allows people with > valid PHP user accounts to close pull requests. > (2) Fix the bugsweb integration, so that references to bugs inside > the commits will work. Florian is working on it. > (4) FAQ Will there be an integration with pull requests and the bug tracker, or remains attaching patches the preferred way? What is the new preferred replacement for a sparse SVN checkout + single commit per change? As I understand it, currently, we try to have a single commit for all branches (PHP_5_n, and trunk). How is that supposed to be done with git? From reading https://wiki.php.net/rfc/dvcs#workflows, I assume, all branches need to receive separate commits + pushes? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration: Status Update
Kris Craig wrote: I count myself lucky in that I started using Git before Subversion. People with that background often have an easier time at first because they aren't burdened with having to un-learn a bunch of "bad habits." I feel I HAVE to comment on that statement. A 'different way of work' is not 'bad habits' ... most of the time I am criticised for my method of working, but it has worked well of a long time now, and it's people who have never used a decent integrated IDE that complain that it's bad. Most of the 'extras' that are being bolted on now, and the changes to a 'git' mentality simply don't live well when one has an existing functional method of working ... but 'bad habits' do not come into it! -- 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
Re: [PHP-DEV] Git Migration: Status Update
+1 what Jeremiah said! I've noticed that people who are accustomed to Subversion tend to go into Git using the SVN branching mindset. While that does technically work in Git, it essentially misses the point. To illustrate, let's say a person from the 16th century travelled forward through time to today. He's been using lanterns and torches all his life to light dark rooms. You then hand him a flashlight, explaining that this new technology is far better. This time traveller then proceeds to dip the end of the flashlight in kerosene and lights it on fire, using it as a torch. Technically, that time traveller would be able to light the room that way, but it would essentially negate the point of using a flashlight to begin with. Using Subversion branching practices in Git is basically the repo version of dipping a flashlight in pitch and setting it ablaze. I count myself lucky in that I started using Git before Subversion. People with that background often have an easier time at first because they aren't burdened with having to un-learn a bunch of "bad habits." If anyone is interested, I would encourage you to take a look at this: http://nvie.com/posts/a-successful-git-branching-model/ This is a widely accepted and efficient branching model that I use on all my projects. Of course, in PHP's case, it would have to be tweaked to account for parallel version development (i.e. phasing out 5.3 while continuing to build 5.4), but that's essentially how it would work. It looks like that's also what Jeremiah was referring to (though please correct me if I'm wrong). And he is right in saying that it's not nearly as confusing as it looks. It's actually really simple once you've grasped the underlying concept. What does everyone think of implementing an approach similar to this model? It would certainly make it much easier to manage in the long-run IMHO. --Kris On Sat, Mar 3, 2012 at 11:53 PM, wrote: > Kris Craig writes: > > > Thanks for the update! > > > > Quick question: As far as the branching model goes, are we going to > stick > > with the SVN-style of just having a branch for each release version and > > dumping all the commits directly onto it, or do you plan on switching to > a > > more modern Git-style branching model of merging feature sub-branches > into > > the parent version branches? Or has this issue not been discussed yet? > > > > --Kris > > > > > > On Sat, Mar 3, 2012 at 1:58 PM, David Soria Parra wrote: > > > > The "idiomatic" way to do this would be to have releases done as tags > off of the master branch. Other than that, it makes a lot of sense to > have a branch for major features / versions, and for people to develop > specific features in their own branch, to rebase changes coming from > parent branches onto working branches, and then to merge those into > their respective parent branches after they're done. > > I swear that sounds much more complicated than it is. I personally think > that php as a whole would *greatly* benefit from adopting this sort of > development model -- it's likely that git-savvy new contributors will > anyhow, and it makes accepting contributions a hell of a lot less > painful. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Re: Git Migration: Status Update
(3) Karma system fixes. Already done by me. People who have access to the root of a repository are able to do forced pushes. Do you think it's good idea not to forbid forced pushes at all? Cheers Jaroslav -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
