I'm flooded with this warning when my system is under a high load and uses
a lot of sockets/file descriptors. I get it in stream_select:
"E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with
a larger value of FD_SETSIZE.
It is set to 1024, but you have descriptors numbered at
Hi,
I'd +1 moving to git. I just moved my own project to github from our own
SVN. Mainly for economical reasons as this allowed us to not have to
maintain our own repository and because github had excellent features.
Another point was of course git's superiority over svn when it comes to many
basi
Good explanation Ferenc.
Yeah I think there's a lot of misunderstandings going on with weak/soft
references and how the garbage collector works. Weak/soft references is not
some kind of solution to the cyclic reference problem. The GC takes care of
that already. You can use whatever OOP patterns w
Soft references could theoretically be implemented if PHP only implemented
weak references even though the implementation would consist of a very ugly
and "coincidental" hack.
Lets say you had an object A that you wouldn't want to be collected until
approximately when PHP needs more memory. E.g. w
long run should help as well to understand the
> goals, implementations, etc., for the pecl users or for the 2nd
> attempt to get it in the core, if still desired.
>
> Cheers,
>
> On Wed, Aug 3, 2011 at 12:25 PM, Hannes Landeholm wrote:
>> Hello,
>>
>> We had a h
Hello,
We had a healthy discussion around WR and I have been able to express
my concerns. The consensus is clearly to put it in a PECL extension so
I think this discussion should move on to the practical matters of
doing this. I suggest aborting the vote and changing the RFC state to
something lik
Tired...
> I don't agree with the concept of putting new feature in PECL itself...
should of course be:
>I don't disagree with the concept of putting new feature in PECL itself...
~Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.p
Hello Stas,
On 3 August 2011 02:39, Stas Malyshev wrote:>
> I notice some tone of hostility here.
I'm not hostile. Perhaps a bit disappointed that the PECL objection
wasn't brought up earlier in the discussion period so It could have
been toughly discussed.
> /* snip */
> This is why we tend to
On 2 August 2011 23:32, Chris Stockton wrote:
> I would like to make a couple points here, first I is that PECL is not
> a place for a extension to rot, that statement makes absolutely no
> sense to me. PDO I recall years ago getting from PECL, Http a
> extension I often use, was recently on this
I've talked to Etienne and he still believes we should vote on this so the
vote is still up. He just replied to quickly. If the vote fails the patch
can still be implemented in a PECL extension. There's no point canceling the
vote or the RFC - it's still valid and ongoing, and there is still time
instead of starting a new thread.)
Regards,
Hannes Landeholm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I'm not sure it is the right way to
> do it, or if it is actually needed. The more I look at it the more I
> would recommend you to go with a pecl package, get feedbacks from the
> actual users (framework&co) and come back once you have reached more
> maturity with both the design
Hello,
I would just like to remind you that the voting will take place for 7
more days so there are still time to discuss your concerns. If you
find something confusing or have objections I would be very interested
in hearing them and discussing that _before_ you vote as I have
reminded you twice
this idea. But I'd like to ask something; maybe someone could
> please correct the Example section of RFC?
> Unfortunately, I cannot understand how it could work on "else"
> conditional block, because $obj is undefined.
>
> Cheers,
>
> On Mon, Aug 1, 2011 at 1:46
r not.
Regards,
Hannes Landeholm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arguably the feature is already "popular". I have pointed this out many
times before but many other major OO languages provides weak references
natively. Read the introduction in the RFC.
Pragmatically speaking (as a framework designer) you are unfortunately not
so privileged on what PECL/PHP ext
Hi,
I'd like to initiate voting on this RFC today since the minimum period of
two weeks has now passed. Can someone with the right wiki
powers/responsibilities start a vote and announce the [VOTE] on the mailing
list?
Thank you,
~Hannes
Hello guys,
I'd just like to remind you that I plan to initiate voting for this RFC on
Monday (less than 2 days) so if you plan on voting no, please reply here
asap so we can discuss your concerns.
Thank you for your time,
~Hannes
Hi,
Yes, I'm also interested in caching - It's a very interesting subject...
borderline philosophical. When you are caching model instances in a database
object relation layer you could clearly benefit from implementing some kind
of caching mechanism that retains object even though it's unclear wh
Weak references is an OOP concept. Scalar data types and arrays are not
OOP-related so I don't think that would make sense. Variable references is
not the same as object references. A variable reference is simply a variable
that is connected with another variable (if you set one it will change the
Hello,
This is the official RFC discussion thread for Weak References and an
announcement of the RFC.
Please read the RFC before replying: https://wiki.php.net/rfc/weakreferences
In a nutshell: The RFC proposes adding a single class called "SplWeakRef"
which provides the "Weak Reference" feature
Lars: Please don't break up my sentences and take them out of context before
you reply to them. (Hint: If a sentence begins with "so" it's not a good
idea to just reply to that sentence.)
If you are caching stuff you would rather want to use a strong reference
since the objects should be retained
On 17 July 2011 12:38, Ferenc Kovacs wrote:
>
> Hannes, now you should have karma for the rfc namespace, so you can
> now extend the article with your suggestions.
Great, I'll start contributing ASAP. What's the next step after the RFC is
complete? Testing? Voting?
On 17 July 2011 15:04, Lar
I'm not familiar with the internal implementation of GC in PHP but if
the current garbage collection implementation makes catching the gc
event non-trivial I'd agree and vote for postponing my "SplQueue
ref_queue" suggestion until the future. It could always be added later
and there is the temporar
Since Weak references is already an established concept in many OOP
languages a lot can be learned from their implementation. A lot of the
potential related problems and solutions has already been studied.
Anyone who wish to contribute to this feature should start by reading
this excellent article
I was going to add some content to
https://wiki.php.net/rfc/weakreferencesnow but the wiki tells me that
the page is read only for me. I couldn't find
any details on who to contact to change this.
~Hannes
Hello,
I just realized you could actually utilize the __destruct method to catch
the event I described in my last post. The SplWeakRef class as currently
defined in the RFC would therefore suffice to build a userland class that
automatically garbage collects indexes.
~Hannes
Hi,
Ferenc: Good idea to move the discussion to a separate thread.
Etienne: Awesome. I wish I had time to write the patch myself. I could
probably put some hours into adding more details to the RFC though.
The only problem as I see it by making it a weak reference class instead of
a weak referen
Okay, maybe it could be attempted to be squeezed in anyway to 5.4? I really
need this feature and apparently others feel the same way.
- It would benefit MVC framework design - one of the most common design
pattern for web development.
- The ticket has been open for over a year now and it has a lo
Hello,
Is it possible to add Weak References to this todo list?
https://bugs.php.net/bug.php?id=52318
I've been waiting over a year now for this feature. It's a critical part of
object relational layer mapping and my framework will be broken until it
exists. One of our important customer projects
On 10 June 2011 16:54, Pierre Joye wrote:
> The sad part is not that windows uses a consistent type size across
> architecture but that linux and gcc considers that a type could be
> whatever the architecture uses. Hence why stdint.h was introduced and
> should be used instead of the long/int.
>
Greetings.
One very important feature of PHP is its interoperability. This allows my
colleagues to work in both Windows, Ubuntu and OSX - developing the same
application. Details like the fact that PHP will replace forward slash with
backward slash automatically in windows is a great example of th
On 7 June 2011 15:53, John Crenshaw wrote:
> > foreach ($arrays as list($e1, $e2, $e3)) { ...
>
> Disagree. This feels very obtuse. I wouldn't expect this construct to work
> at all, and even if it did, it is highly ambiguous (I.E. at first I thought
> you were intending to grab 3 entries at a ti
Hi,
I like to do stuff "inline" instead of cluttering my code with variables.
There are currently three syntaxes/expressions which are currently not
supported but I hope could be implemented until 5.4.
First inline constructing (which I think has already previously been
discussed), but also cloni
+1
~Hannes
I don't there's a good general case for this. I'd +1 on throwing E_NOTICE.
Hannes
On 2 June 2011 13:54, Hannes Magnusson wrote:
>
> How about making it useful rather then just throwing an notice?
> Recursive implode maybe? Or json/php serialized? :)
>
> -Hannes
>
> --
> PHP Internals - PHP Runt
> Agree with Derick, strictly speaking, in maths science, INF != INF.
I disagree,based on quote from
http://compilers.iecc.com/comparch/article/98-07-134:
"Since a projective infinity doesn't have a sign, comparing a floating point
value other than infinity to a projective infinity is unordered.
Yeah, I was wondering why the magical logo thing was implemented like that.
Just use the href= "data:image/png;base64,..." scheme instead if you really
need a logo there. Combine that with smaller size and heavy jpeg compression
and it shouldn't make the HTML /that/ bloated.
Hannes
If you really
I was planning on replying to the "coalesce" suggestion but you really took
my concerns and stated them much better than I could have myself, plus a
couple of other concerns I didn't even think about.
To respond to Arpad Ray's statement:
"To elaborate, I'd probably think this code was an unlikely
This discussion is equivalent to the one that we just had. Read the thread
"[PHP-DEV] Implicit isset/isempty check on short-ternary operator".
Also the "$var = var_set($_GET['var'], $_POST['var'], 'default');" syntax
you propose would be equivalent to (as per previous discussion):
$var = $_GET[?'
es a
> default), we only get paradigms 3, 4, 5 and maybe 7, but worse, if we
> want to add any of the others later, we need to design more complicated
> new operators, or break backward compatibility, not just extend what we
> have.
>
> I personally use 1, 3, 5 and 6 quite often, and
s generated
and have to be ignored when running the custom error handler - so it should
be faster too.
~Hannes
On 14 April 2011 18:08, Ole Markus With wrote:
> On Thu, 14 Apr 2011 16:05:45 +0200, Hannes Landeholm
> wrote:
>
> So basically the discussion now is what exact characters tha
solution that makes everything easier for everyone so let's
solve one thing at a time and start with the most generic problem
specifically and not all minor problems that happens to partially intersect
that one.
~Hannes
On 14 April 2011 16:26, Ben Schmidt wrote:
> On 15/04/11 12:05 AM,
Trying to summarize this discussion... I think we can all agree that the
main problem is "code duplication for array access when parameters are
possibly not existing". I think we all can also agree that @ can be both
used properly and misused - and it is a blunt tool and not a nice solution
to the
@ is not convenient since it turns off error reporting for all errors. I
don't know how many times I've silenced a notice and got a blank page in my
face as a "thank you for accidentally silencing that fatal error too".
"Silent" is reserved for the purpose of the silence operator though @ so
using
ariable was already defined is a bad programing habit, these
> operators will encourage that kind of things
>
> In the other hand, the isset check inside the condition ?: would silently
> improve not-so-well written code, and could be a good feature for the lang.
>
> Martin Scotta
I think "?!" wouldn't work as an operator as it would conflict with ternary
comparision + not operator. Also I don't see the point of adding an operator
for "empty" as the function/construct itself is pretty confusing and
non-useful as you have to memorize all the things that happen to be
considere
Hi. I like Adam's suggestion _a lot_ however I'd also find a third
case very useful.
In addition to:
*
// standard
$value = isset($a[$key]) ? $a[$key] : 'Not set';
// new ?? double ternary that performs isset check and omits second
expression
$value = $a[$key] ?? : 'Not set';
// new ?? d
, $min = -1, $max = -1) // returns true if string has a
certain length (easier to read and faster to write)
quote($string) // for exporting any string to javascript escaping any escape
or control characters automatically (e.g. \n) so "foo\"bar" becomes exactly
that
~Hannes
On 30 Ma
PHP's substr() is awesome and that comes from a person that code in at least
5 different languages daily. Parsing is a problem in many real-world
problems and substr currently works great for that purpose. You work with
two parameters: offset and length of parsing. Since meaning of a negative
offse
What is more likely to be wrong? Your understanding of a specific
regex pattern (which happens to be full of escapes making it
incredibly hard to read) or the implementation of preg_replace?
~Hannes
On 14 March 2011 16:18, Martin Scotta wrote:
>
> I chose the simplest example to show the preg_re
http://brian.moonspot.net/php-history-newline-closing-tag
~Hannes
On 10 March 2011 17:42, Martin Scotta wrote:
>
> hi all,
>
>
> 1 1
> 2 2
> 3 3
>
>
>
> 1 1
> 2 2
> 3 3
>
>
> First try works... but second fails
>
> output:
>
> 1 1
> 2 2
> 3 3
>
> 1 1
e a problem: Array
> (
> [type] => 1
> [message] => Call to a member function bar() on a non-object
> [file] => /home/tyrael/c/fatal.php
> [line] => 9
> )
>
> as I mentioned, it works.
>
> Tyrael
>
>
> On Wed, Mar 9, 2011 at 4:59 PM, Hannes Lande
ld be only used for the first problem, in which case
> it could be catchable IMO, because it doesn't leave the engine in an
> unstable state.
>
> Tyrael
>
> On Wed, Mar 9, 2011 at 3:53 PM, Hannes Landeholm wrote:
>
>> That's not a problem. Timeouts should be non-recove
Good Sugesstion.
Currently I'm forced to use huge internal classes for my framework because
dividing them into smaller classes would expose internal behavior to the
"outside"... the application layer.
This would solve that problem.
~Hannes
On 3 March 2011 18:21, Jarrod Nettles wrote:
> Has t
ontain any kind of logic,
even logic that uses set_time_limit by itself.
~Hannes
On 9 March 2011 15:52, Thomas Hruska wrote:
> On 3/9/2011 6:56 AM, Hannes Landeholm wrote:
>
>> A simple way to implement this would be to register a function that would
>> be
>
are
> triggered for non fatal problems.
> that should be changed, so open a bugreport if you think you found one,
> where isn't neccessary to halt the execution.
>
> Tyrael
>
>
> On Wed, Mar 9, 2011 at 3:30 PM, Hannes Landeholm wrote:
>
>> You mean the shut
when
> the max_execution_time is exceeded.
> What it doesn't let you do is to recover in the same way an error
> handler would let you.
>
> David
>
> On 09/03/11 22:56, Hannes Landeholm wrote:
> > I second making time limit reached catchable. All non catchable fatal
> err
be changed to "catchable fatal errors" so
> applications will be able to recover themselves... and if they don't catch
> the error... then die.
>
> it would be nice if all errors could be changed into exceptions.
>
> Martin Scotta
>
>
>
> On Wed, Mar 9,
I second making time limit reached catchable. All non catchable fatal errors
are a problem for me. I need to handle problems gracefully to ensure the
stability of production systems instead of PHP just killing itself without
warning. I just reported a similar issue:
http://bugs.php.net/bug.php?id=5
Lemme jump in here... An enum declaration is just a list of unique PHP
constants.. not mathematical sets. You could argue the same thing for
constants (that they can only contain scalars and not any values ->
therefore not useful). If developers need to model the period table they'd
define the data
Let me jump in here and say that I agree that strings are useful. IMO
any scalar type should be allowed for enum's. String enum's are great
for understanding debug data. Also it would integrate smoothly with
MySQL enums (building queries) and when you want to model enumerations
in an external API o
If you're looking into doing something that are both useful and good for
learning C, my suggestion is to hack PHP in some way that makes something
possible (in PHP) that you couldn't simply accomplish by writing a simple
wrapper function or workaround. Making var_export use tabs instead of spaces
i
Using references does not speed up PHP. It does that already
internally, if I'm not mistaken. The point of my post was that
assigning values to tree arrays are in general faster than a full
array copy.
Hannes
On 19 January 2011 08:36, Ben Schmidt wrote:
> Yep. PHP does clock up memory very quick
Hello,
I don't think a language becomes a "beginners language" just because many
new programmers use it. And it's still not a good argument for not including
new features.
As long as the new thread doesn't share any memory/variables with the
spawning context, no "reasoning" is required at all. It
x27;re insane.
The patch: http://pastebin.com/4GS83nKs
Regards,
Hannes Landeholm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
66 matches
Mail list logo
