Hi David,
great work!
Cheers
Sascha
On Wed, 25 Jan 2012, David Soria Parra wrote:
> Hi Internals,
>
> we are a few weeks into the git migration, so I want to give you a short
> status update.
>
> - web/ is completly migrated. all php websites are updating from
> the git repositories now
The way some systems start to treat autoconf (installing
multiple versions in an absolutely braindamaged way) is not
something we should support.
I suggest whoever is bothered by FreeBSD doing stupid things
should go to the ports maintainer and complain to him.
- Sascha
--
P
Yes, use different install prefixes.
/opt/autoconfX.XX
/opt/autoconfY.YY
And add the suitable prefix to your PATH.
But don't change the names of the utilities..
- Sascha
On Tue, 29 Mar 2005, Roman Neuhauser wrote:
# [EMAIL PROTECTED] / 2005-03-29 16:46:37 +0200:
The way
They are not helpful for various reasons. e.g. if you need
to ask whether a session was started, your architecture is
broken (a central place needs to manage sessions; that single
place must know whether a session has been started).
Also, the concept of session_id_exists is fun
Nope.
- Sascha
On Tue, 26 Apr 2005, Hans Lellelid wrote:
Sascha Schumann wrote:
They are not helpful for various reasons. e.g. if you need
to ask whether a session was started, your architecture is
broken (a central place needs to manage sessions; that single
place must
I'm more of the mindset that whoever breaks it, also fixes
it.
My current 'fix' would simply revert that patch. If you
agree with that, I will happily follow through.
- Sascha
-- Forwarded message --
Date: Thu, 28 Apr 2005 12:58:05 +0200
From: [EMAIL PROTECTED]
Thanks, Jani.
- Sascha
On Thu, 28 Apr 2005, Jani Taskinen wrote:
I addded fastcgi.logging ini option. Set that to 0 and you'll
get the original behaviour back.
--Jani
On Thu, 28 Apr 2005, Sascha Schumann wrote:
I'm more of the mindset that whoever breaks it, also f
Is the argument about changing struct temp_variable?
Why cannot the desirable behaviour be obtained without
changing that particular structure?
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
So +1 from me. (wasn't there a patch for this already somewhere?)
PHP has enough horrid language misfeatures. It does not need
another one. Seeing the potential damage of adding goto to
the language, I can only give it a -1.
- Sascha
--
PHP Internals - PHP Runtime Developm
As for my own example, many state machines make extensive use of goto to
avoid recursive calls.
Goto is not required for that. State machines such as the
following
state1:
...
goto state99;
state99:
...
goto state2;
And it really should not be going away in PHP 6 either. I
don't get why you are suggesting to expend so many resources
as part of a migration effort while it is obvious that there
are no advantages at all in dropping {}. It makes no sense.
- Sascha
On Fri, 18 Nov 2005, Rasm
Hey, you're still alive?
Alive and kicking.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
whether we want to remove {} in PHP 6. I
didn't think people had such strong feelings about it. From my checks with
people, most had no idea you could even use {}'s on strings.
-Rasmus
Sascha Schumann wrote:
And it really should not be going away in PHP 6 either. I
don
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
I suggest removing that warning immediately until the matter
is resolved.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
So, I'm +1 on the patch with sane names and removed restrictions;
Agreed.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
No, as this breaks backwards compability. I have code written for this
and that is going to be released. If the class constants are removed,
you will break code that is out there. There were similar reasons why
Wez didn't want to change the odd PDO method because people were running
it production
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not 5.1.1.
Then I have to ask both of you: why is there no mentioning in
the release notes or the up
On Fri, 25 Nov 2005, Derick Rethans wrote:
On Fri, 25 Nov 2005, Sascha Schumann wrote:
It's definitely not the most elegant way, I agree there. But there was
also no sneaking as it was discussed months before, and it was actually
Ilia who suggested doing it in PHP 5.1.0 and not
On Fri, 25 Nov 2005, Ilia Alshanetsky wrote:
Sascha Schumann wrote:
Then I have to ask both of you: why is there no mentioning in
the release notes or the upgrading guide regarding "Date"
being reserved for PHP now?
There are notes in the guide, and I quote:
I&#x
Bottom line there is a problem and we need a fix for it. One solution
that has been suggested is to revert the date class and release 5.1.1,
but this means we pretty much deny ourselves the ability to have a
native "Date" class in PHP. Is this really the only fix we can come up with?
There i
Or simply use eAccelerator which does not cause those open
calls.
Rasmus, is that behaviour by design? I deinstalled APC
because of this 'characteristic' last week. It was killing a
high-traffic site.
- Sascha
On Thu, 2 Feb 2006, Rasmus Lerdorf wrote:
> I think the m
On Thu, 2 Feb 2006, Rasmus Lerdorf wrote:
> Sascha Schumann wrote:
> > Or simply use eAccelerator which does not cause those open
> > calls.
>
> Which doesn't support PHP 5.1 very well.
Which is pretty fine for us PHP 4.4 users.
The site where I rei
On Tue, 7 Mar 2006, Dmitry Stogov wrote:
> Hi,
>
> Because of some confused people I reverted "break label" patch and post it
> for discussion once again together with GOTO patch.
>
> Please reviw and vote.
>
> 1) goto and break label
> 2) goto only (like C)
> 3) break label only (like Java)
>
> If you like "goto" instead of "jump", please open yet another vote.
> I am indifferent with name.
Let's call it goto.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Instead of guessing branch probabilities, why not measure them?
Or, simply tell the compiler what you expect. Sometimes, GCC
predicts incorrectly - if-branches are usually assumed _not_
to be executed.
if (expect_true(x)) {
foo();
}
with..
#ifdef HAVE_BUILTIN_
> They aren't hints. It is strict typing and in its current form I would
> ask you guys not to call the 5.4 release PHP. Because it won't be.
Fully agreed.
I'd suggest "NoPHP". "AntiPHP" might also work.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubs
On Thu, 13 Mar 2003, James Cox wrote:
> I asked joe to ask for commit privs as he's the redhat guy doing PHP work,
> and has useful stuff to commit.
I think that we can handle the 20 line patch manually for now.
What's up with this internals list now? Should not php-dev
be decommiss
On Mon, 24 Mar 2003, Rasmus Lerdorf wrote:
> How many people would this actually help and how many would it annoy? I
> know it would annoy the hell out of me if every CVS commit included a
> bunch of useless HTML. All the Pine and Mutt users would have absolutely
> no use for this.
It would
On Mon, 24 Mar 2003, Sebastian Bergmann wrote:
> Sascha Schumann wrote:
> > if they would add a plain text mode, it might be something to switch
> > to, because it is actively maintained in contrast to our scripts.
>
> Have a look at
>
> http://sourceforg
There are on-going problems with the cvs setup, so we are
disabling commits until further notice.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> That's one of the reasons, I would guess. The libc memory manager is not
> very efficient with multiple threads accessing it at once, it has locks
> (which is one of the reasons we implemented our own in ZE2). It's
> definitely one of the reasons, and as you know, performance penalties
> accumu
> ack, that's awful! Session id's aren't unique across clusters of
> machines. You'll risk session corruption.
They are not guranteed to be unique, even on a single host.
Spreading your load across multiple machines actually
decreases the probability of a collision, because the
> There's also the problem of file locking on nfs mounts.
That's true for 3-5 year old Linux boxes.
Try running a proper NFS setup.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> The syntax is meaningless and confusing if the program does not operate
> the way it is written. By all sensible considerations, B should be
> local to A. Since it is not, the syntax should cause a parser error,
> and the same with namespaces. And then what happens with that stuff
> when, at s
> Last I checked there were reliability problems with locking
> implementations across NFS on many UNIXes.
Well, if you want to deploy a NFS-based web cluster, you will
very likely not choose some heterogeneous setup with
incompatible NFS implementations.
As if that was not obviou
> Or you implement a storage architecture that doesn't rely on unreliably
> implemented OS features.
George, I would appreciate some constructive messages from
you. This thread contained mostly FUD from your side.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To
> That's a short list.
Concerning systems which have been phased out a long time
ago, even at organizations with strict policies. You
occassionally find a SunOS 4 box from 1990, but would you
integrate it into a web cluster? I don't think so.
Sharing session data over a netw
> I thought Siberia is much further, then PECL =)
> By the way, in Russian "PECL" sounds almost like a word, that
> means "hell"..
In German, it sounds like "pimple". I've always been saying
that it was a bad choice.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
On Mon, 31 Mar 2003, Marcus Börger wrote:
> Hi Sascha,
>
> could you have a look at this
Fixed
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Here are some further functions which directly or indirectly
cause a segfault. In some cases, the prior function
invocation screwed up the engine internals, so that the next
function call resulted in a segfault.
How to reproduce:
1. wget http://schumann.cx/do_crash.txt
And some more (the 13 should have been 0 in the script):
bcsub('',$maxn);
dbase_open($maxs,$maxn);
exif_imagetype($maxn);
> ob_start();
>
> socket_iovec_alloc($maxn,$maxn,$maxn);
>
> exif_thumbnail('',$maxs,$maxn);
>
> mb_ereg('',$maxs,$maxn);
>
> mb_ereg_match
Extending the list, now also testing with an empty array().
i18n_convert('','',$mina);
mb_convert_encoding('','',$mina);
array_pad($mina,$maxn,$maxn);
setlocale($maxn,$mina,$maxn);
unregister_tick_function($maxn);
xml_parser_create($maxs);
> bcsub('',$maxn);
>
On Wed, 2 Apr 2003, Andi Gutmans wrote:
> AFAIK, doc comments are for classes and functions only. I think this is
> what's important because interfaces are functions not variables.
Hm, so my PHP 4-stylish code would cause a parse error, if it
contained a valid character like a "*" after t
PHP:
- the engine needs to verify whether the result of a
integer multiplication fits into its integral type
(script context)
- the memory allocator has to ensure that no integer
overflows happen
Your input is appreciated.
- Sascha/* Copyright (c) 2003 Sascha
> -ob_start (3)
> +ob_start (3) (Unable to reproduce - Moriyoshi)
I still see them here.
The segfault disappears when only valid output_handlers are
used (the second chunk of the patch achieves that). Unless
I'm missing something, there really is no purpose in
preserv
Sterling, you are missing some important points here.
> Geeze Luise, its not that hard, and the coding standards are there for a
> (good) reason. If you object to some of the standards, discuss that,
If you look at my code, 99% of it follows the coding styles,
because I've adopted th
Derick, your attempts at setting rules are misguided.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> I'm not setting any rules, I'm just trying to push ways of effective
> collaboration due to the adoption of the same standards for everbody.
You are in no position to push anything.
Try 'encouraging' or 'convincing' the next time.
- Sascha
--
PHP Internals - PHP Runtime Developme
> The difference between 'pushing' and 'encouraging' is tought in
> management school. The semantical difference is NULL.
Derick, you need to realize that you lack authority. Someone
without authority cannot push anything what so ever.
Or to put it differently:
A bully pushes.
On Wed, 28 May 2003, Uwe Schindler wrote:
> during configure of PHP 4.3.2-RC3 under solaris 9 the following occurs:
> checking for dlfcn.h... no
>
> this leads to the fact that no dynamic things never work and compiler
> warning that "dlsym" is undefined occurs. This header file is available
> und
On Thu, 29 May 2003, Uwe Schindler wrote:
> Still not working in php4-STABLE-200305291130:
Look at config.log, locate the dlfcn.h check and you will see
why the check is failing.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
> Can anyone give me a hand with tracking down the problem?
Did you try a more stable compiler already?
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 4 Jun 2003, Chris wrote:
> Which would be better to try, 2.95x or 3.x?
Our codebase has been exposed to 2.95 mostly, so going with
that would be wise.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Thu, 12 Jun 2003, Sebastian-Hendrik Picklum wrote:
> ID-Change: Sascha Schumann told me to re-apply. Need access to
> PHPDOC and PHPDOC-DE. Thanks in advance!
Granted.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
Fine with the concept.
If you move the additional check (newlen <
SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
branch, the changes won't affect the common code path.
> @@ -47,7 +51,11 @@
> if (!(d)->c) (d)->len = (d)->a = 0;
On Wed, 18 Jun 2003, Stanislav Malyshev wrote:
> SS>> If you move the additional check (newlen <
> SS>> SMART_STR_START_SIZE) and preallocation into the if (!(d)->c)
> SS>> branch, the changes won't affect the common code path.
>
> IMO, the common code path is that of SMART_STR_START_S
> BTW, why do you think "make test" is a bad test of memory allocation
> patterns? What do you propose as a better test?
make test is synthetic. My primary use of smart_str involves
IRCG based application.
> That's very bad news, because actually my test show that about 95% of
> mallocs
> In fact, that was initial though behind all my tests - to see how many
> small blocks PHP allocates, what are these small blocks and how well they
> are cached. If anybody is interested in working or it or has suggestions
> about that - I can share my thoughts.
If you are concerned about PHP
(I don't have the time right now to write a lengthy reply)
1. malloc is expensive on some systems, and less expensive on
many others. It really depends.
2. some mallocs (Linux, Solaris probably) are optimized for
non-contentious allocations in threaded contexts
(
> This might actually be a very good idea, since it can likely improve
> performance a lot by having a pool of zval-sized blocks (I have no idea
> of how big they are). Have you thought about how to implement it in a
> good way?
Free lists already exist.
- Sascha
--
PHP Internals - PHP
> That's good, but that's only one step. Some system mallocs are very
> inefficient on small blocks so it might be very worthwhile to grab a
> "chunk" of, say, 64k, instead of many small mallocs of 20 bytes.
How do you know that this is a significant problem?
Quantify first, optimize lat
> fairly certain that doing 100 000 allocations of 20 bytes is a whole lot
> 1) slower and 2) more memory consuming than allocating 2 megs at once.
Of course. That's not the point though. The point is
whether the difference matters in the global picture.
You can optimize almost ever
On Wed, 18 Jun 2003, Per Lundberg wrote:
> On Wed, 2003-06-18 at 17:24, Sascha Schumann wrote:
> > Of course. That's not the point though. The point is
> > whether the difference matters in the global picture.
>
> Point taken. But is it such a big thing? I mean, w
On Wed, 18 Jun 2003, Stanislav Malyshev wrote:
> SS>> since end of 2001. And for ZE2, Sterling reported a 20%
> SS>> increase in performance after disabling the memory manager.
>
> You mean "zend MM memory manager" or "ZE1 memory cache manager"?
> If you talk about the former, it's known
> I'm putting this message out as a feeler. I'm going to go ahead and
> remove the mysql library from the PHP source tree. This won't affect
> the extension, it simply means we won't be bundling the *library* with
> PHP anymore. This is in a large part due to MySQL's decision to switch
> to usin
> The last one is the ONLY thing where existing code is modified, and I've
> really tested it extensively. So where's the problem???
There is no problem. Can you or Harrie make sure that the
patch gets applied to head, so that the branches are in sync?
- Sascha
--
PHP Internals - P
Currently, PHP uses aclocal of the automake suite to include
libtool's /usr/share/aclocal/libtool.m4. This is a trivial
task which does not require aclocal per se.
However, extension authors might depend on additional m4
macros such as AM_PATH_GTK_2_0 which are provided by oth
On Mon, 23 Jun 2003, Olivier Hill wrote:
> Hi,
>
> What would it take to make PHP OSI Compliant (Certified?)?
That's on the way already.
> It seems it
> would permit PHP to be linked to MySQL libs, or am I wrong?
You are not right (yet).
- Sascha
--
PHP Internals - PHP Runtime De
Can someone explain why James just made it impossible to
properly work with source code which resides in PHP 4 and 5?
- diffing is impossible
- merging is impossible
- history of new commits becomes fragmented
James, why did not you discuss this first? All opensource BSDs
James, in the past, there was very little interest in a PHP 4
HEAD branch, if you care to recall. Because your rashness
has rendered diff and merge unusable between PHP 4/5, we can
only expect to see even less interest.
Lowering the bar should be the answer to faiding interest
> A bunch of things are broken. Files are missing in php4 head and the
> wrong versions of files are also in there. I think we need to roll this
> change back as soon as possible and take another shot at this in a much
> more organized manner.
Here is a plan.
- rename /repository/php5 t
It's done (1 insert, 1 delete).
- Sascha
On Tue, 5 Jun 2007, Greg Beaver wrote:
> Hi Wez,
>
> We really need an update to the [EMAIL PROTECTED] alias. This is the
> 4th request. Please remove [EMAIL PROTECTED] and add [EMAIL PROTECTED]
>
> Thanks,
> Greg
>
>
--
PHP Internals - PH
On Tue, 12 Jan 2016, Peter Petermann wrote:
> >
> >
> > > This seems useful. I do wonder whether we should use by default for
> > > RFCs. It's interesting to see how different people vote, and knowing
> > > who voted which way means you can ask them what their objections were.
> > I have gotten th
> During the CoC-Discussion the idea came up to vote certain CoC-issues
> (call them whatever you like) in a more secure way so that no one sould
> be able to bully someone into an - for him or her - inappropriate
> decission. One way to do so could be a somehow anonymised vote.
Is discussing thin
> My take away from Anthony's last email is basically: "We're going to have a
> CoC whether you like it or not. You are welcome to offer feedback to make
> the CoC better after we propose it, but any feedback that says a CoC is bad
> will be viewed as non-constructive and ignored."
That would be f
Hi John,
> And it is *not* acceptable.
May I ask who put you in charge to determine whether something is "acceptable"
or "reprehensible"?
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On January 12, 2016 at 7:05 PM Adam Howard wrote:
>
> Can we please move on past this and get back to actual code. Because if
> not, perhaps PHP Internals has outgrown the email format and should migrate
> to a forum type format.
Agreed.
Sascha
--
PHP Internals - PHP Runtime Development Ma
> For what it's worth, I find the description 'rules for misconduct' extremely
> telling and fairly horrible way to describe a Code of Conduct, as I'm sure any
> people involved with education would agree.
Agreed.
> > But we don't really have an alternative process for this currently
> > establis
> > PHP already offers bin2hex()/hex2bin() and base64_encode()/base64_decode().
> > This covers part, but not all, of RFC 4648.
> >
> > I'd like to extend the coverage to include, at minimum, Base32.
>
> What's the use case for it? Is anybody using base32 now?
I'd have a few times if the functio
> That's something to consider, but please keep in mind a sense of
> perspective: Anthony measured a _negligible_ performance hit (5 * 10^-6
> seconds).
>
> Are there any real-world applications that would suffer tremendously from
> this academic slow-down?
Yes, but that is a micro-benchmark. Re
Hi Derick,
there is no * or nl1 record in the php.net zone, so I cannot change it.
I guess that it is done on the easydns side.
Cheers
Sascha
> So I guess we (I) need to modify that script to not CNAME these to the
> respective mirrors, but instead to star-php-net.ax4z.com. instead? I can
> work on that (tomorrow).
Sounds good.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
Will be fixed in a few minutes. Thanks for the report.
Sascha
Looks better now.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fixed people.php.net as well.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As there are other protocols beside http/https running on news.php.net (NNTP),
we unfortunately cannot switch the whole subdomain to the cdn.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>
> > >
> > > How would you like to switch to the CDN? By DNS? Or we need to
> > create a
> separate DNS-Entry for NNTP (nntp.php.net). I'd need to check how much
> reconfiguration that'd mean though... And that might mean that others
> will need to change their endpo
https://news-web.php.net/
Does it work for you? I don't know the application, so if there are any direct
references to http://news.php.net they would need to be fixed, as we do not
rewrite the HTML.
Sascha
Alright, the apache2 configs for news/lists redirect to
https://news-web.php.net now.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Cannot we nuke that subdomain?
# ls -la /local/www/sites/downloads.php.net/
total 8
drwxr-xr-x 2 root root 4096 Nov 6 2014 .
drwxr-xr-x 4 root root 4096 Jul 18 2018 ..
The apache config apparently just redirects everything somewhere else.
Sascha
--
PHP Internals - PHP Runtime Development Ma
Cert is fixed on the machine now.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Please try again.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I have disabled SNI for the upstreams on svn2.php.net.
If the problem persists, please provide a way to reproduce the issue.
Thanks
Sascha
Who can we add as moderators?
Sascha
> Nikita Popov hat am 3. September 2019 um 16:58
> geschrieben:
>
> On Sat, May 18, 2019 at 12:06 PM Joe Watkins < krak...@php.net
> mailto:krak...@php.net > wrote:
>
> > > Hi all,
> >
> > Does anyone know what is the cause of all th
When sending an email to php-announce@ ..
ezmlm-store:_info:_qp_26188/ezmlm-clean:_info:_qp_26206/Old_format_or_corrupted_index._Run_ezmlm-idx!_(#5.3.0)/ezmlm-warn:_info:_qp_26212/ezmlm-warn:_info:_qp_26219/ezmlm-warn:_info:_qp_26220/did_0+0+10/
I ran ezmlm-idx, looks better now.
Regarding deliv
We have enabled the normal php.net spam protections for lists.php.net - this is
test message 1.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
And this would be test message 2. Sorry about this.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Looking good (test 3).
Please alert syst...@php.net if you have issues sending emails to
*@lists.php.net.
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Confirming that most spam got nicely reduced now. Thank you for
> enabling spam filters. There are now only few of those spam mails
> passing through but I guess reading one or two messages with pharmacy
> and similar content can be ignored and deleted on the mods side.
Thanks for the feedback.
Everyone,
Ecelerity has been retired for close to two years (Feb 2015).
The MX for php.net is a single, well-maintained Postfix instance.
If there are any issues, please let me know and Cc systems@
Thanks
Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
1 - 100 of 229 matches
Mail list logo
