Re: [PHP-DEV] Give the Language a Rest motion (fwd)
2013/2/20 Derick Rethans : > Looks like it is time to forward this email from 2006 again: > > -- Forwarded message -- > Date: Thu, 09 Mar 2006 12:57:32 +0200 > From: Zeev Suraski > To: internals@lists.php.net > Subject: [PHP-DEV] Give the Language a Rest motion > > I'd like to raise a motion to 'Give the Language a Rest'. > > Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), > and 2 more major versions since then, and we're still heatedly debating on > adding new syntactical, core level features. > > Is it really necessary? I'd say in almost all cases the answer's no, and a > bunch of cases where a new feature could be useful does not constitute a good > enough reason to add a syntax level feature. We might have to account for new > technologies, or maybe new ways of thinking that might arise, but needless to > say, most of the stuff we've been dealing with in recent times doesn't exactly > fall in the category of cutting edge technology. > > My motion is to make it much, much more difficult to add new syntax-level > features into PHP. Consider only features which have significant traction to > a > large chunk of our userbase, and not something that could be useful in some > extremely specialized edge cases, usually of PHP being used for non web stuff. > > How do we do it? Unfortunately, I can't come up with a real mechanism to > 'enforce' a due process and reasoning for new features. > > Instead, please take at least an hour to bounce this idea in the back of your > mind, preferably more. Make sure you think about the full context, the huge > audience out there, the consequences of making the learning curve steeper > with > every new feature, and the scope of the goodness that those new features > bring. > Consider how far we all come and how successful the PHP language is today, in > implementing all sorts of applications most of us would have never even > thought > of when we created the language. > > Once you're done thinking, decide for yourself. Does it make sense to be > discussing new language level features every other week? Or should we, > perhaps, > invest more in other fronts, which would be beneficial for a far bigger > audience. The levels above - extensions to keep with the latest technologies, > foundation classes, etc. Pretty much, the same direction other mature > languages > went to. > > To be clear, and to give this motion higher chances of success, I'm not > talking > about jump. PHP can live with jump, almost as well as it could live without > it > :) I'm talking about the general sentiment. > > Zeev > > -- > 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 > Agree. There are only a few core devs working daily in the PHP internals. I would say please give the Language (and devs) a rest motion, because there are a lot of bugs and work to be done but I'm afraid that is more easy/funny to request a new feature/syntax than do the grunt work :( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Perl logo in the php website
I've been owned :( 2012/4/2 Charlie Somerville > April fools > > On Monday, 2 April 2012 at 4:41 PM, Eloy Bote Falcon wrote: > > Hi internals, > > Maybe this is not the correct list to ask this, but why is the perl logo > placed in the php website, instead of the php logo? > > >
[PHP-DEV] Perl logo in the php website
Hi internals, Maybe this is not the correct list to ask this, but why is the perl logo placed in the php website, instead of the php logo?
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Oops, it was a mistake. I replied to all rather than to the list, so I
apologize because I wanted to give my opinion in general and not to reply to
anybody in particular.
Regards.
2011/6/2 John Crenshaw
> There’s no need to be rude. If you can’t make your point without attacking
> people, then you need a better argument.
>
>
>
> “JSON” in this case just means a simple object notation using {, [, and :.
> You know that. Yes, we’re all abusing the term, just like we all abuse
> “AJAX”, regardless of the fact that almost nobody ACTUALLY uses XML as the
> transfer encoding. Who cares? “JSON” is the best word available. Unless you
> can suggest a better word to differentiate this format from the others (one
> that isn’t designed to insult anyone who disagrees with you) stop fussing
> about it.
>
>
>
> John Crenshaw
>
> Priacta, Inc.
>
>
>
> *From:* Eloy Bote Falcon [mailto:eloyb...@gmail.com]
> *Sent:* Thursday, June 02, 2011 3:58 AM
> *To:* Sanford Whiteman
> *Cc:* John Crenshaw; PHP internals
>
> *Subject:* Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
>
>
>
>
>
> 2011/6/2 Sanford Whiteman >
>
> > I don't think anyone cares about JSON for the sake of being perfect
> > JSON, I didn't intend to give that impression.
>
> Then you should stop saying "pure JSON" and "true JSON" constantly!
>
>
> > I'm only hoping for something that generally works on par with all
> > the other JSON parsers in the world.
>
> OK, that trashes your example, where values were set based on the
> result of a PHP function. There is no "par" for JSON parsers running
> methods _at creation time_, within the server (author) context.
> Setting vars to the return value of a function is something we take
> for granted in real languages, but it cannot happen within what a
> knowledgeable person would call "JSON."
>
>
> > Yes, JSON is a very specific encoding, but when a developer writes
> > something "jsony", what they mean is "an object/array with the
> > following structure/values", because that is what the encoding
> > really represents.
>
> Not Javascript developers. Maybe jQiddies think that
>
>{'$gt': strtotime('-1 day')}
>
> is "JSONy" more than it is "JS objecty"?
>
> This is like starting from "Wouldn't inline CSVs be great for creating
> arrays?" and drifting to "I mean, not like with that comma-escaping
> stuff, and, uh, newlines would be allowed in the middle of a record,
> and you'd have to allow create-time interpolation of function calls.
> You know, CSVy!"
>
> Only thing I might generously refer to as being "JSONy," while
> provably not being valid JSON, is a string that conforms in every way
> _except_ for using single quotes -- everywhere that doubles are
> required -- instead of using doubles. Anything else is someone's
> mangled "JankySON" or just not JSON.
>
> -- S.
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
>
>
>
> -1 to the RFC.
>
> +1 to => against : if the array short syntax it's finally implemented.
>
>
>
> I, being a lazy programmer, don't want anymore new syntax to do the same
> thing. I don't care if it a) saves me houndred of kaystrokes in the
> definition of arrays, or if b) it's more familiar with
> _put_your_favorite_syntax_here_ because:
>
>
>
> a) I prefer the simple way of _this_ is done _this_ way against _this_ is
> done _this_ way or _this_another_ way or _this_yet_another_ way.
>
> b) When another new fancy tendency of encoding appear I don't want to see
> it in the core, because another one will appear in the future and then we
> will be in the same point, stacking stuff forever or talking about
> deprecating the old and breaking BC.
>
>
>
> My point is: I'm for implementing something that can't be done currently in
> PHP, but against for implementing another way of doing the same.
>
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
2011/6/2 Sanford Whiteman
> > I don't think anyone cares about JSON for the sake of being perfect
> > JSON, I didn't intend to give that impression.
>
> Then you should stop saying "pure JSON" and "true JSON" constantly!
>
> > I'm only hoping for something that generally works on par with all
> > the other JSON parsers in the world.
>
> OK, that trashes your example, where values were set based on the
> result of a PHP function. There is no "par" for JSON parsers running
> methods _at creation time_, within the server (author) context.
> Setting vars to the return value of a function is something we take
> for granted in real languages, but it cannot happen within what a
> knowledgeable person would call "JSON."
>
> > Yes, JSON is a very specific encoding, but when a developer writes
> > something "jsony", what they mean is "an object/array with the
> > following structure/values", because that is what the encoding
> > really represents.
>
> Not Javascript developers. Maybe jQiddies think that
>
>{'$gt': strtotime('-1 day')}
>
> is "JSONy" more than it is "JS objecty"?
>
> This is like starting from "Wouldn't inline CSVs be great for creating
> arrays?" and drifting to "I mean, not like with that comma-escaping
> stuff, and, uh, newlines would be allowed in the middle of a record,
> and you'd have to allow create-time interpolation of function calls.
> You know, CSVy!"
>
> Only thing I might generously refer to as being "JSONy," while
> provably not being valid JSON, is a string that conforms in every way
> _except_ for using single quotes -- everywhere that doubles are
> required -- instead of using doubles. Anything else is someone's
> mangled "JankySON" or just not JSON.
>
> -- S.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
-1 to the RFC.
+1 to => against : if the array short syntax it's finally implemented.
I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
_put_your_favorite_syntax_here_ because:
a) I prefer the simple way of _this_ is done _this_ way against _this_ is
done _this_ way or _this_another_ way or _this_yet_another_ way.
b) When another new fancy tendency of encoding appear I don't want to see it
in the core, because another one will appear in the future and then we will
be in the same point, stacking stuff forever or talking about deprecating
the old and breaking BC.
My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.
Re: [PHP-DEV] Implicit isset/isempty check on short-ternary operator
What is the purpose of that generateHash function? It doesn't work in the
isset check.
Anyway, you can do a simple $a = array('foo'); isset($a[$x][$y][$z]) without
notices at all unless any of $x $y or $z are not defined, you don't need to
check the indexes one by one.
2011/4/14 Ole Markus With
> On Thu, 14 Apr 2011 02:24:56 +0200, Ben Schmidt <
> mail_ben_schm...@yahoo.com.au> wrote:
>
> I think these shortcuts could be really useful for array elements, but
>>> for other variables I am really sceptical and I think they would do
>>> more harm than good. Generally I do not really see any reason why a
>>> variable should not be 'instanciated' before use.
>>>
>>> So
>>> +1 if this shortcut is implemented to only work for array elements.
>>> -1 for any other variable type.
>>>
>>
>> There are two issues here.
>>
>>1. Suppression of notice. I agree, it is best done only for array
>>keys. It's not hard to initialise a variable with $var=null at the
>>beginning of a code block to avoid such a notice, and that is the
>>appropriate way to do it for variables.
>>
>>2. Offering a shortcut for the common idiom isset($x) ? $x : $y in
>>line with the DRY design principle. A notice would never be emitted
>>here in any case. The problem is that this idiom is still in wide use
>>despite the shortcut ternary operator already provided, because an
>>isset() check is different to a boolean cast.
>>
>> Some thoughts:
>>
>>- The actual intent of 2. is probably $x!==null ? $x : $y i.e. it's
>> not about suppressing notices at all, but about offering a default
>> value, and the idiom quite probably only uses isset() because it
>> predated null in the language.
>>
>>
> I have never felt the need for a shortcut in these cases. It would be
> interesting to see some code where this would be practical.
>
>
>- If we view 2. in this way, the two problems are independent, and it
>> seems to me it would be best to solve them independently, rather
>> than with a single operator.
>>
>> So, I suggest:
>>
>>1. An array lookup mechanism that suppresses the notice for undefined
>>keys. It would work the same as regular array index lookups except
>>that the notice for undefined keys (and only for undefined keys)
>>would not be generated (it would not just be hidden, but would never
>>be even generated).
>>
>
> This is what I feel PHP is missing. Particularly when it comes to
> multi-dimensional arrays. Because this feature is missing I tend to do
> something like
>
> function generateHash($x, $y, $z)
> {
> return "$x::$y::$z";
> }
>
> if (isset($a[generateHash($x, $y, $z)]) {
> ...
> }
>
> instead of
>
> if (isset($a[$x]) && isset($a[$x][$y]) && isset($a[$x][$y][$z])) {
> ...
>
> }
>
> Arguing about syntax is then a second step. However, my views on this
>> are:
>>
>>
> I think it best to avoid discussing the actual syntax before agreeing on
> what we really need.
>
> --
> Ole Markus With
> Systems Architect - Sportradar AS
> Developer - Gentoo Linux
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Deprecating "global" + $GLOBALS, making $_REQUEST, $_GET, $_POST read-only
2010/12/9 Andrey Hristov > Reindl Harald wrote: > >> Please do not >> >> global + GLOBALS can be used in so many ways and you would break >> 200.000 LOC only here which is running with reporting E_STRICT >> in a production environment >> > > what happened after register_globals was introduced and registering of > globals was switched off? > > > The same for making $_GET/$_POST/$_REQUEST readonly >> I know that it is not best practice, but sometimes >> it makes life easier to fetch $_POST in a method >> which overwrites a parent method and add a single >> item before the parent is processing $_POST >> > > It's bad practice. > > > Yes, there are many other ways to do the same but >> BC-breaking trigger a lot of work and testing >> >> Am 09.12.2010 11:14, schrieb Andrey Hristov: >> >>> Hi guys, >>> the topic says most of it. What do you think about deprecating the global >>> keyword and $GLOBALS with it? Together >>> with this making $_REQUEST, $_GET and $_POST read-only as they should be >>> used only to read-only anyway. >>> >>> The reason for global + GLOBALS is that these are abused and which leads >>> to spaghetti programs, when used by >>> unexperienced users. Also they have impact on side effects from functions >>> that don't only rely their parameters. >>> >>> Best, >>> Andrey >>> >> >> >> > Best, > Andrey > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Is copying the POST variables into another variables best practice (like a manual register_globals)? In the global scope of the application I think it's cleaner to work with $_POST to overwrite the values than copying the items into variables. Inside a function/method, I agree that it's best practice to pass $_POST as a parameter and then overwrite the values as you need. Regards, Eloy Bote Falcon.
Re: [PHP-DEV] RFC: C-sharp style property get/set syntax for PHP
2010/12/1 Eloy Bote Falcon
> 2010/12/1 Richard Quadling
>
> On 1 December 2010 09:22, Stas Malyshev wrote:
>> > Hi!
>> >
>> >> Its not a matter of consistency - Properties, as a cross-language
>> concept
>> >> are not meant to work that way. You need to think of a property as a
>> set
>> >
>> > Meant by whom? Is there some law of universe that prevents us from
>> > implementing the feature?
>> >
>> >> of two methods that just have a pretty syntax. Methods cannot be
>> unset,
>> >> and nor should properties be allowed to. isset() should simply tell us
>> >> whether a property with the specified name is part of the class or not.
>> >
>> > If you need methods, why not use methods? If you mimick object
>> properties,
>> > however, it makes sense to make them work exactly like property,
>> otherwise
>> > you have to explain why they don't work this way.
>> >
>> >> isset() in the way you suggest would just be confusing. It would allow
>> is
>> >> to say that a property does not exist, when in fact it does exist.
>> This
>> >> is not logical.
>> >
>> > Sorry, from your answer I don't understand - what happens when you call
>> > isset($foo->property) and unset($foo->property)?
>>
>> If we think of properties as this new entity for the language (rather
>> than somehow massaging existing entities to fit a new usage scenario),
>> then
>>
>> isset($instance->property) will always return true for any defined
>> property. Even if the getter would return null. This is new behaviour
>> and can be easily documented. isset() for a property is more like
>> method_exists() than isset() on a variable.
>> With regard to unset($instance->property), from the manual ...
>>
>> "The behavior of unset() inside of a function can vary depending on
>> what type of variable you are attempting to destroy."
>>
>> So, we already have differing behaviour based upon context. Attempting
>> to destroy a property should through a non fatal error.
>>
>> One idea I had was to keep just the get/set property methods and add
>> to them an additional parameter ...
>>
>> > public $seconds {
>>public set($value, $unset = False) {
>>if ($unset) {
>>// unset() has been called on the property.
>>// In this instance $value will be Null.
>>} else {
>>// set the property using the supplied $value.
>>}
>>},
>>public get($isset = False) {
>>if ($isset) {
>>// isset() has been called on the property.
>>// If the value is a non-destructive calculation
>> then maybe
>> returning the comparison of the result of the calculation to null.
>>} else {
>>// return the value for this property.
>>}
>>}
>> };
>>
>> So,
>>
>> isset($instance->property) would call $instance->property->get(True);
>> unset($instance->property) would call $instance->property->set(Null,
>> True);
>>
>> This keeps just the 2 property methods. It still allows isset/unset
>> and allows the developer the option of handling them.
>>
>>
>>
>>
>> --
>> Richard Quadling
>> Twitter : EE : Zend
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>
> Why change the expected behavior of isset? If a property has not been set
> then isset must return false, and that includes $foo->name = NULL.
>
>
> Regards.
>
Oops, the mail has been marked has spam because of some URI.
Regards.
Re: [PHP-DEV] Type hinting
Hi! 2010/6/2 Stas Malyshev > Hi! > > > Is there some other reason / use case for wanting exceptions? So, I >> mean, where is the use case where '123abc' will be passed to a >> type-hinted field where you could catch the exception and do something >> meaningful to carry on with the execution of the program other than >> simply error-ing out? >> > > Pretty much everywhere. Suppose you have form with, say, 2 fields and first > field does not validate. Maybe you want to check the second field too and > give the user both errors if they are both wrong? > > In general, looking at strict typing as user input validation mechanism is > a very bad idea. There are specialized use input validation > functions/classes/frameworks, and one should use them. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I agree with you. The type hinting is not a replacement for the sanity check of the user input but a proper way of defining what type of data your functions should work with, so it's OK to trigger errors when data loss happens. When you have function foo(int &$bar) the data loss will affect the application in the same way that an undefined var would do; so the E_NOTICE error level seems the best approach to me. And when the data conversion is not possible (e.g. object to numeric) just trigger an E_FATAL. Let the top level users take care of the input because I think that language features like this type hinting are for the low level of the development. Regards, Eloy Bote Falcón.
Re: [PHP-DEV] RFC: Custom Factories (SPL)
2009/11/19 Mathieu Suen
> Eloy Bote Falcon a écrit :
>
> 2009/11/18 Mathieu Suen
>>
>> Etienne Kneuss a écrit :
>>>
>>> Hello,
>>>
>>>> On Wed, Nov 18, 2009 at 5:54 PM, Mathieu Suen <
>>>> mathieu.s...@easyflirt.com
>>>>
>>>>> wrote:
>>>>>
>>>> Robert Lemke a écrit :
>>>>
>>>>> Hi folks,
>>>>>
>>>>> after discussing the idea with various PHP developers I now felt safe
>>>>>> enough that it's not a completely stupid idea to post an RFC for it.
>>>>>> The
>>>>>> idea is to add support the registration of custom factories which are
>>>>>> responsible for instantiating certain classes.
>>>>>>
>>>>>> Here is the first draft of my RFC:
>>>>>> http://wiki.php.net/rfc/customfactories
>>>>>>
>>>>>> I suggest that we first discuss the implications and usefulness of
>>>>>> this
>>>>>> feature. In a second step I'd need to find some skilled internals
>>>>>> wizard
>>>>>> who
>>>>>> can implement it, because not being a C developer myself, all I can
>>>>>> offer is
>>>>>> making suggestions and fine coffee.
>>>>>>
>>>>>> Looking forward to hearing your comments!
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> An other way maybe to allow this:
>>>>>>
>>>>> $email = new $emailClassName();
>>>>>
>>>>>
>>>>>
>>>>> This is already allowed.
>>>>>
>>>> Best,
>>>>
>>>>
>>>> Right!!
>>> I get confused with:
>>> $classNamme::getInstance();
>>>
>>> So you can easily inject dependency:
>>>
>>> class Foo {
>>>
>>> protected $emailer;
>>>
>>> public function __construct($emailClass) {
>>> $this->emailer= $emailClass;
>>> }
>>>
>>> public function bar() {
>>> // $email = new $this->emailer(); Of course not allowed
>>> $emailer = $this->emailer;
>>> $email = $emailer();
>>> // ...
>>>
>>> }
>>> }
>>>
>>> -- Mathieu Suen
>>>
>>>
>> Well, $email = new $this->emailer(); it's allowed too, and behaves as
>> expected since FOO::emailer it's a string.
>>
>
> I have tested in php 5.2 is that a feature added in 5.3?
>
>
>>
>> Reagards,
>>
>> Eloy Bote.
>>
>>
>
> --
>
>
> • *Mathieu Suen* | It Team | www.easyflirt.com
> • mathieu [dot] suen [at] easyflirt [dot] com
> • EasyFlirt - Park Nord, Les Pléiades, 74370 - Metz-Tessy - FRANCE
>
>
> • Pensez à l'environnement, n'imprimez cet e-mail qu'en cas de réelle
> nécessité
>
>
>
Yes it is.
Returning to the topic, I don't think that these kind of features should be
implemented in the PHP core...let's focus in other interesting features like
traits; a new wide range of possibilities will open and the (not so) new
programming paradigms like AOP or SOP could be powerfully and easily
implemented by the end users.
Regards,
Eloy Bote.
Re: [PHP-DEV] RFC: Custom Factories (SPL)
2009/11/18 Mathieu Suen
> Etienne Kneuss a écrit :
>
> Hello,
>>
>> On Wed, Nov 18, 2009 at 5:54 PM, Mathieu Suen > >wrote:
>>
>> Robert Lemke a écrit :
>>>
>>> Hi folks,
>>>
after discussing the idea with various PHP developers I now felt safe
enough that it's not a completely stupid idea to post an RFC for it. The
idea is to add support the registration of custom factories which are
responsible for instantiating certain classes.
Here is the first draft of my RFC:
http://wiki.php.net/rfc/customfactories
I suggest that we first discuss the implications and usefulness of this
feature. In a second step I'd need to find some skilled internals wizard
who
can implement it, because not being a C developer myself, all I can
offer is
making suggestions and fine coffee.
Looking forward to hearing your comments!
Robert
An other way maybe to allow this:
>>>
>>> $email = new $emailClassName();
>>>
>>>
>>>
>>> This is already allowed.
>>
>> Best,
>>
>>
>
> Right!!
> I get confused with:
> $classNamme::getInstance();
>
> So you can easily inject dependency:
>
> class Foo {
>
>protected $emailer;
>
>public function __construct($emailClass) {
>$this->emailer= $emailClass;
>}
>
>public function bar() {
>// $email = new $this->emailer(); Of course not allowed
>$emailer = $this->emailer;
>$email = $emailer();
>// ...
>
>}
> }
>
> -- Mathieu Suen
>
Well, $email = new $this->emailer(); it's allowed too, and behaves as
expected since FOO::emailer it's a string.
Reagards,
Eloy Bote.
[PHP-DEV] SSL streams switching to blocking socket
Hi everybody!
Three months ago one of my PHP applications started to hang webserver
processes. The schema of the application is as follows (it's a webservice):
-Main server, with LINUX, Apache and PHP, handles the requests from the
clients.
-Once the client is authenticated, and the request is valid, it relays the
request to one of the four slave servers (let's call them nodes).
-One of the nodes uses PHP4 (works fine), and the other three use LINUX,
Apache and PHP 5.1.6 with the following SSL configuration:
OpenSSL support => enabled
OpenSSL Version => OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
-The nodes send the request to a remote webservice, and reply it back to the
main server.
-The main server processes the response and sends back the response to the
client.
The problem is that, eventually, the PHP5 nodes ends with blocked (sleeping)
processes from Apache. Finally the system runs out of resources because all
the blocked-sleeping processes have a ESTABLISHED socket.
First I noticed that, at least in that version of PHP, the blocking sockets
can have a send and recive timeout. Then I switched to non blocking sockets
and select. Now the application works fine in the upper level of the
communication with the other webservices, but I noticed that it still ends
with sleeping processes. I "straced" the Apache and this is what I found
(the bound IP and the remote webservice IP are not real; the second one is
from google.com):
Block 1 -
5503 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 20
5503 bind(20, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("10.6.0.11")}, 16) = 0
5503 fcntl64(20, F_GETFL) = 0x2 (flags O_RDWR)
5503 fcntl64(20, F_SETFL, O_RDWR|O_NONBLOCK) = 0
5503 connect(20, {sa_family=AF_INET, sin_port=htons(443),
sin_addr=inet_addr("74.125.127.100")}, 16) = -1 EINPROGRESS (Operation now
in progress)
5503 poll([{fd=20, events=POLLIN|POLLOUT|POLLERR|POLLHUP}], 1, 1370327) = 1
([{fd=20, revents=POLLOUT}])
Block 2 -
5503 getsockopt(20, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
5503 fcntl64(20, F_SETFL, O_RDWR) = 0
5503 time(NULL)= 1251911098
5503 brk(0xb9e39000) = 0xb9e39000
5503 time(NULL)= 1251911098
5503 write(20,
"\200d\1\3\1\0K\0\0\0\20\0\0009\0\0008\0\0005\0\0\26\0\0\23\0\0\n\7\0\300"...,
102) = 102
5503 read(20, "\26\3\1\0J\2\0", 7) = 7
5503 time(NULL)= 1251911098
5503 time(NULL)= 1251911098
5503 read(20,
"\0F\3\1J\236\245\273^\v\375\357<\205\223\334n}\226k\232\\\311\300\21Q\256\267\304\257o#"...,
72) = 72
5503 read(20, "\26\3\1\6\252", 5) = 5
5503 read(20,
"\v\0\6\246\0\6\243\0\3\2400\202\3\2340\202\3\5\240\3\2\1\2\2\4<\260Eh0\r\6"...,
1706) = 1376
5503 read(20, " 2 CA1\r0\v\6\3U\4\3\23\4CRL10+\6\3U\35\20\4$0\"\200"...,
330) = 330
5503 read(20, "\26\3\1\1^", 5) = 5
5503 read(20, "\r\0\1v\3\...@\1p\0m0k1\v0\t\6\3u\4\6\23\2es1\0170\r\6"...,
350) = 350
5503 write(20,
"\26\3\1\0\7\v\0\0\3\0\0\0\26\3\1\0\206\20\0\0\202\0\200\215\30
\tT\312\313\255\210"..., 210) = 210
5503 read(20, "\24\3\1\0\1", 5)= 5
5503 read(20, "\1", 1) = 1
5503 read(20, "\26\3\1\", 5) = 5
5503 read(20,
"\364\35k\17\25\224\314]|\263Y\307z\310\223\314\210\235h\224t\345\305\373\267\241\377\t\1s\345\250"...,
48) = 48
Block 3 -
5503 fcntl64(20, F_GETFL) = 0x2 (flags O_RDWR)
5503 fcntl64(20, F_SETFL, O_RDWR|O_NONBLOCK) = 0
Block 4 -
5503 select(21, [], [20], [], {44320, 0}) = 1 (out [20], left {44320, 0})
5503 gettimeofday({1251911098, 885029}, NULL) = 0
5503 write(13, "[Wed Sep 02 19:04:58 2009] [erro"..., 161) = 161
5503 write(20,
"\27\3\1\2\240\10\260\325k\v\37{\251\355t_R\274\312\16\354r\315\1\277\204b\342xU\30L"...,
677) = 677
5503 select(21, [20], [], [], {44320, 0}
5503 <... select resumed> )= 1 (in [20], left {44319, 828000})
5503 read(20, "\27\3\1\0\240", 5) = 5
5503 read(20,
"\304\310\273s\370\304e\335\273\1\346\376N\234\376\226\276\0\fG9T\313\235\2&\31\340B=\f\""...,
160) = 160
5503 select(21, [20], [], [], {44320, 0}) = 1 (in [20], left {44320, 0})
5503 read(20, "\27\3\1\4P", 5) = 5
5503 read(20,
"\333`\341\212},\215\3476\370\325\273\"\260\340\234\365\324\324\10a\25v\327\266'+\340\34\1\317\364"...,
1104) = 1104
Block 5 -
5503 write(20, "\25\3\1\0
\305\10\236\5\10\226JS\330\365\204\21\230\246\362\247R\332\220:\210o\2\333\10.\27"...,
37) = 37
5503 brk(0xb9e2d000) = 0xb9e2d000
5503 close(20) = 0
Block 6 -
5503 brk(0xb9e2b000) = 0xb9e2b000
5503 chdir("/")= 0
5503 setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) =
0
5503 writev(19,
[{"\27\3\1\0\260n?\301\204\263\0341yi\204\v\273\332\335\263\277\335M\t\223\364$\266\214\212c\362"...,
714}], 1) = 714
5503 gettimeofday({1251911099, 58549}, NULL) = 0
5503 write(14, "10.6.0.1 - noone [02/Sep"..., 97) =
