On Sun, Jun 5, 2011 at 01:00, Andi Gutmans wrote:
>
> In parallel I'd also see if there are any key extensions which we think are
> mainstream, stable and well maintained enough to be included. For example,
> http comes to mind.
>
People have been "afraid" of suggesting new exts to core due to
How about the Yaml extension?, it looks well maintained enough:
http://pecl.php.net/package/yaml
Regards,
David
On Sun, Jun 5, 2011 at 2:33 AM, Hannes Magnusson wrote:
> On Sun, Jun 5, 2011 at 01:00, Andi Gutmans wrote:
> >
> > In parallel I'd also see if there are any key extensions which we
Hi!
As far as I can see, bug 39863 was fixed in 5.3, but the fix still not
in trunk/5.4.
Should we merge the same patch into trunk/5.4 or somebody is
volunteering to fix it, e.g. like described here:
http://news.php.net/php.internals/50191?
See also the about it discussion:
http://www.serverp
hi,
Not apparently, it was not fixed in trunk.
There was a discussion about using zend_arg for paths and additional
function or macros to be used instead of duplicating the tests
everywhere. But no consensus or agreement have been reached.
Cheers,
On Sun, Jun 5, 2011 at 10:25 AM, Stas Malyshev
hi,
It sounds like persons doing these inquiries do not know PHP, its
environment and how it works, neither they know that 99% of the linux
distribution (and in some extend on windows too) provide most of the
modern extensions with their standard distribution.
For general purposes extensions or
On Sun, Jun 5, 2011 at 12:57, Pierre Joye wrote:
> However, for technologies specific extension, be hyped or not, I see
> no reason to bundle them. It makes no sense to bundle mongodb,
> memcached clients or whatever other specific features.
I can't think of a statement I would disagree more with
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson
wrote:
> I can't think of a statement I would disagree more with. These are
> exactly the ones we should be bundling.
>> My reasoning is simple. The key for bundling extensions is to have
>> them available for most hosting solutions. If a shared h
Am 05.06.2011 10:59, schrieb Stanislav Malyshev:
> stas Sun, 05 Jun 2011 08:59:24 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=311824
>
> Log:
> This method doesn't seem to be very useful without scalar types, so reverting
> it too
It
Am 05.06.2011 12:57, schrieb Pierre Joye:
> The last point is that pecl allows a much more flexible release
> management than the core will even do.
in theory
> So instead of doing some marketing/communication actions by bundling some
> known extensions, we should better promote pecl better.
hi,
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the core will even do.
>
> in theory
>
>> So instead of doing some marketing/communication actions by bundli
On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the core will even do.
>
> in theory
No, that's a fact. You can do releases whenever you want, at your own
wish.
Am 05.06.2011 13:40, schrieb Pierre Joye:
> hi,
>
> On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald wrote:
>> Am 05.06.2011 12:57, schrieb Pierre Joye:
>>
>>> The last point is that pecl allows a much more flexible release
>>> management than the core will even do.
>>
>> in theory
>>
>>> So inste
On Sun, Jun 5, 2011 at 1:00 AM, Andi Gutmans wrote:
> For starters I would bundle ext/mongo which is very well maintained; see if
> we can get "thrift_protocol" contributed to PECL and included (support HBase
> and Cassdandra and used by a few PHP SDKs integrating with these data stores).
I se
On 06/05/2011 08:50 AM, Reindl Harald wrote:
>> Also some exts are simply not used anymore or do not have active
>> developers
>
> but they compile with recent versions and if not
> the build will stop and someone fix it
Sorry, but that doesn't actually happen. Only commonly used core things
are
2011/6/5 Sebastian Bergmann
> Am 05.06.2011 10:59, schrieb Stanislav Malyshev:
> > stas Sun, 05 Jun 2011 08:59:24 +
> >
> > Revision: http://svn.php.net/viewvc?view=revision&revision=311824
> >
> > Log:
> > This method doesn't seem to be very useful without
hi,
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald wrote:
>> Being in core is not a sign of good maintenance. There are so many
>> poorly maintained part in core as well.
>
> but they are running through some autotests
> a fucking PECL extension which is not updated
> for years and where bugrepor
Smells like a memory leak if gc_collect_cycles() doesn't fix it.
David
On 05.06.2011, at 00:01, Mike van Riel wrote:
> Hey David,
>
> That gives me the following output:
>
>int(640720)
>int(244001144)
>
> Mike
>
> On Sat, 2011-06-04 at 23:51 +0200, David Zülke wrote:
>> What does
>>
Am 05.06.2011 13:58, schrieb Rasmus:
> On 06/05/2011 08:50 AM, Reindl Harald wrote:
>>> Also some exts are simply not used anymore or do not have active
>>> developers
>>
>> but they compile with recent 3versions and if not
>> the build will stop and someone fix it
>
> Sorry, but that doesn't a
On Jun 3, 2011, at 4:43 AM, Derick Rethans wrote:
On Fri, 3 Jun 2011, Stas Malyshev wrote:
- a call to vote is easily drowned out on the ML with all the noise
I read the same ML as you do :) Using threaded email client it is very
easy to separate new threads and see calls for votes.
That is
Hi,
2011/6/5 Pierre Joye
> hi,
>
> Not apparently, it was not fixed in trunk.
>
> There was a discussion about using zend_arg for paths and additional
> function or macros to be used instead of duplicating the tests
> everywhere. But no consensus or agreement have been reached.
>
>
Should http:/
On Sun, Jun 5, 2011 at 1:09 PM, Hannes Magnusson wrote:
> On Sun, Jun 5, 2011 at 12:57, Pierre Joye wrote:
> > However, for technologies specific extension, be hyped or not, I see
> > no reason to bundle them. It makes no sense to bundle mongodb,
> > memcached clients or whatever other specific
On Sun, Jun 5, 2011 at 1:50 PM, Reindl Harald wrote:
>
>
> Am 05.06.2011 13:40, schrieb Pierre Joye:
> > hi,
> >
> > On Sun, Jun 5, 2011 at 1:37 PM, Reindl Harald
> wrote:
> >> Am 05.06.2011 12:57, schrieb Pierre Joye:
> >>
> >>> The last point is that pecl allows a much more flexible release
> >
Seems like leak.
Try disabling ZendMM to see if something noticeable happens (memory
peak should be lower).
USE_ZEND_ALLOC=0
Cheers,
Julien
On Sun, Jun 5, 2011 at 2:01 PM, David Zülke
wrote:
> Smells like a memory leak if gc_collect_cycles() doesn't fix it.
>
> David
>
>
> On 05.06.2011, at 00:
On Sat, 2011-06-04 at 23:00 +, Andi Gutmans wrote:
> Hi,
>
> I've been getting quite a few inquiries re: PHP's "lack" of support
> for modern technologies such as NoSQL databases (for lack of better
> term). There is some (mistaken) perception that PHP is behind on this
> front.
I'm in the b
> On Jun 4, 2011, at 3:07 AM, Pierre Joye wrote:
>
> > On Sat, Jun 4, 2011 at 5:46 AM, Stas Malyshev
> wrote:
> >
> >> [VOTE] is a good idea, let's make it [VOTE].
> >>
> >>> There is no plugin used for it yet, and that's my problem with it.
> >>
> >> Well, votes aren't announced yet either :)
On 06/05/2011 09:06 AM, Reindl Harald wrote:
> Am 05.06.2011 13:58, schrieb Rasmus:
>> On 06/05/2011 08:50 AM, Reindl Harald wrote:
Also some exts are simply not used anymore or do not have active
developers
>>>
>>> but they compile with recent 3versions and if not
>>> the build will sto
On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski wrote:
> Some of you may have followed the twitter conversation that Pierre and I had
> at the end of last week; In my opinion, this dry (or partially wet) run that
> we had in the last few days of a voting process pointed to several
> deficiencie
On Sun, Jun 5, 2011 at 17:20, Pierre Joye wrote:
> On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski wrote:
>
>
>> Some of you may have followed the twitter conversation that Pierre and I had
>> at the end of last week; In my opinion, this dry (or partially wet) run
>> that we had in the last few d
On Jun 5, 2011, at 8:20 AM, Pierre Joye wrote:
> I'd to say that I'm very happy to finally see such discussions
> happening, let sort the base (99% is done by our existing RFC about
> release process, let adopt it already!) and move on with 5.4.
This is a prime example of what we're talking abo
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
That can lead to quite a bit of simplifications in code where you now have to
check for is_array/is_callable/instanceof Closure and such. I like it.
On Sun, 5 Jun 2011 12:52:45 -0300
Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009 which
> po
2011/6/5 Benjamin Eberlei
> That can lead to quite a bit of simplifications in code where you now have
> to check for is_array/is_callable/instanceof Closure and such. I like it.
>
>
Exactly, and since our current $x = 'hello::world'; $x(); doesn't support
method calls, the array one can help on
On Sun, Jun 5, 2011 at 5:46 PM, Hannes Magnusson
wrote:
> On Sun, Jun 5, 2011 at 17:20, Pierre Joye wrote:
>> On Sun, Jun 5, 2011 at 4:18 PM, Zeev Suraski wrote:
>>
>>
>>> Some of you may have followed the twitter conversation that Pierre and I
>>> had at the end of last week; In my opinion, t
On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson wrote:
>> I'd to say that I'm very happy to finally see such discussions
>> happening, let sort the base (99% is done by our existing RFC about
>> release process, let adopt it already!) and move on with 5.4.
>
>
> This is a prime example of what we're
I consider this an improvement in terms of consistency w.r.t.
callbacks, so +1 from me, good job!
Best,
On Sun, Jun 5, 2011 at 18:21, Felipe Pena wrote:
> 2011/6/5 Benjamin Eberlei
>
>> That can lead to quite a bit of simplifications in code where you now have
>> to check for is_array/is_callab
+1, very good job!
On Sun, Jun 5, 2011 at 5:52 PM, Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009 which
> points to an interesting feature that I think makes sense for us, since we
> are now working with $f() using objects and strings, and th
On Sun, 2011-06-05 at 12:42 -0400, Pierre Joye wrote:
> +1, very good job!
>
> On Sun, Jun 5, 2011 at 5:52 PM, Felipe Pena wrote:
> > Hi all,
> > Reading our bug tracker I noticed a good feature request [1] from 2009 which
> > points to an interesting feature that I think makes sense for us, sinc
Fixed crash in fastcgi due startup order...
SIGG() were being used before tsrm_startup().
2011/6/4 Felipe Pena
> Fixed invalid sigaction() call passing NSIG as signal number.
>
> - for (signo = 1; signo <= NSIG; ++signo) {
> + for (signo = 1; signo < NSIG; ++signo) {
>
> Detected by Valgrind:
(Andi - I sent this before going out this morning - but I can't see it on the
list this evening ... )
Andi Gutmans wrote:
I think one of the problems is that in the past we always ensured that the
extensions for key current technologies were bundled with PHP i.e. mysql, json&
soap/xml. This
On Sun, Jun 5, 2011 at 5:52 PM, Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009
> which
> points to an interesting feature that I think makes sense for us, since we
> are now working with $f() using objects and strings, and the array('class',
Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
around.
Thanks
Olivier (iPhone)
Le 2011-06-05 à 04:37, Reindl Harald a écrit :
> Am 05.06.2011 12:57, schrieb Pierre Joye:
>
>> The last point is that pecl allows a much more flexible release
>> management than the
done
http://pecl.php.net/bugs/bug.php?id=2274
BTW:
that PHP 5.3.5 is the highest version in the dropdown for bugreports
does not provide the feeling of maintaining
Am 05.06.2011 20:39, schrieb Olivier Hill:
> Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
> around.
Hi!
It is still useful for array | class/interface name. Or?
Not really, since it returned only "array" or "object", while real class
is returned by getClass() and isArray() returns if it's an array. We
could have method that returns class name or "array" if it's an array,
but that'd be d
Hi!
Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
(beyond changing others function parse args, fixing the tests,
include+require part)?
$ sapi/cli/php -r 'fopen("a\0b", "r");'
Warning: fopen() expects parameter 1 to be valid path, string given in
Command line code on line
2011/6/5 Stas Malyshev
> Hi!
>
>
> Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
>> (beyond changing others function parse args, fixing the tests,
>> include+require part)?
>>
>> $ sapi/cli/php -r 'fopen("a\0b", "r");'
>>
>> Warning: fopen() expects parameter 1 to be valid
On Sun, Jun 5, 2011 at 9:13 PM, Felipe Pena wrote:
> 2011/6/5 Stas Malyshev
>>
>> Hi!
>>
>>> Should http://felipe.ath.cx/diff/parse_arg_null_path.diff be enough
>>> (beyond changing others function parse args, fixing the tests,
>>> include+require part)?
>>>
>>> $ sapi/cli/php -r 'fopen("a\0b", "
Hi!
Of course, I was just checking if it's what you guys are thinking first.
Well, there was basically two ideas:
1. Add filename length to streams and check inside streams
2. Check inside argument parser
Both have downsides: (1) does not capture cases when we don't use
streams (such as dire
Hi!
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
Looks good. Only question I have is that we seem to have that code
(calling a function based on variable) in two places instead of one, I
wonder if it's necessary and if we could unify them.
> -Original Message-
> class Hello {
>public function world($x) {
> echo "Hello, $x\n"; return $this;
>}
> }
>
> $f = array(new Hello, 'foo');
> $f();
Am I the only one who doesn't understand what this one is supposed to do..?
Zeev
On Sun, Jun 5, 2011 at 9:52 PM, Zeev Suraski wrote:
>> -Original Message-
>> class Hello {
>> public function world($x) {
>> echo "Hello, $x\n"; return $this;
>> }
>> }
>>
>> $f = array(new Hello, 'foo');
>> $f();
>
> Am I the only one who doesn't understand what this one is su
Hi,
recently I was surprised this didn't work. so +1 from me.
johannes
On Sun, 2011-06-05 at 12:52 -0300, Felipe Pena wrote:
> Hi all,
> Reading our bug tracker I noticed a good feature request [1] from 2009 which
> points to an interesting feature that I think makes sense for us, since we
> are
Hi,
2011/6/5 Zeev Suraski
> > -Original Message-
> > class Hello {
> >public function world($x) {
> > echo "Hello, $x\n"; return $this;
> >}
> > }
> >
> > $f = array(new Hello, 'foo');
> > $f();
>
> Am I the only one who doesn't understand what this one is supposed to do..?
Pierre,
I'm happy that we agree pretty much completely about the clarifications &
updates needed for the RFC.
I do however want to point out that the problematic way the short array syntax
RFC was executed was the key reason that made me feel these updates were in
fact necessary - I don't thin
Ok, that makes much more sense. Given how everyone loved it I was beginning to
wonder whether I’ve become too old to understand simple pieces of code ☺
Zeev
From: Felipe Pena [mailto:felipe...@gmail.com]
Sent: Sunday, June 05, 2011 11:02 PM
To: Zeev Suraski
Cc: internals
Subject: Re: [PHP-DEV]
For those of you who lost these proposals in the flood of RFC related emails of
recent days, here they are again:
---
First, we need to make sure that the RFC is properly evaluated by the members
of internals@, and that there's enough time for the RFC to be discussed here on
the list. As Phil
Hi!
I'd still like to hear from others what they think about my proposal.
I'd like to update the Release Process RFC with these suggestions if
people like them.
I think these voting process additions totally make sense. But I am not
sure it makes sense to put everything in one release RFC. Th
Hi,
2011/6/5 Stas Malyshev
> Hi!
>
>
> So, I wrote a patch [2] that allow such behavior to be consistent with
>> arrays. See some examples:
>>
>
> Looks good. Only question I have is that we seem to have that code (calling
> a function based on variable) in two places instead of one, I wonder i
Hi!
We have the code to initialize the call from a object variable, and string
variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME, which
now treat the array case as well, there is no other place doing such stuff.
What about call_user_func() implementation? It must be doing p
I'm fine if the entire 'Feature selection and development' part goes out of the
RFC, but if there's any reference to how features are determined, we'd better
get it right.
Making changes once we've approved this RFC is going to be much tougher. This
is big stuff - it's no coincidence we didn't
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates wrote:
> Please read, and if you have a comment that is not already covered in the
> RFC, raise it here. I'm definitely open to discussion, but I would really
> love to keep this discussion civil.
TBH, I dropped half-way t
Hello,
On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano wrote:
> Thanks for working on this.
>
> On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates wrote:
>> Please read, and if you have a comment that is not already covered in the
>> RFC, raise it here. I'm definitely open to discussion, but I would re
Ok, I found that Ruby added support for a new JSONy syntax a little while
ago, this is interesting:
http://www.strictlyuntyped.com/2010/12/new-ruby-19-hash-syntax.html
http://webonrails.com/2009/02/06/ruby-191-hash/
But it doesn't have anything to do with JSON interoperability.
On Sat, Jun 4, 20
2011/6/5 Stas Malyshev
> Hi!
>
>
> We have the code to initialize the call from a object variable, and string
>> variable (function only) in this exact opcode ZEND_INIT_FCALL_BY_NAME,
>> which
>> now treat the array case as well, there is no other place doing such
>> stuff.
>>
>
> What about cal
Hello everyone,
The following categorizes bundled/enabled/core, and lists extensions as they
stand today (compiled via snaps). I don't exactly know what this means, but
writing this feels appropriate:
- Bundled : An extension that is bundled
* ./configure --enable-ext (or --with-ext) is a
I like the idea of supporting both "=>" and ":". Would this work?:
$foo = {
'bar' : function(){
echo 'baz';
}
};
$foo->bar();
And I'm guessing this shouldn't work:
$array = array('foo' : 'bar');
Regards,
David
On Sun, Jun 5, 2011 at 4:11 PM, Chris Stockton wrote:
> He
> -Original Message-
> From: dukeofgaming [mailto:dukeofgam...@gmail.com]
> Sent: Monday, June 06, 2011 12:18 AM
> To: Chris Stockton
> Cc: Jordi Boggiano; Sean Coates; PHP internals
> Subject: Re: [PHP-DEV] Object and Array Literals
>
> I like the idea of supporting both "=>" and ":". Wou
On 2011-06-05, Pierre Joye wrote:
> On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson wrote:
>
>>> I'd to say that I'm very happy to finally see such discussions
>>> happening, let sort the base (99% is done by our existing RFC about
>>> release process, let adopt it already!) and move on with 5.4.
>>
>> $foo = {
>>'bar' : function(){
>> echo 'baz';
>>}
>> };
>>
>> $foo->bar();
>
> I guess it's not yet too late to surpass Perl in the front of obscurity...
Since the stuff to the right of the assignment operator (`:` in this case) is
valid PHP, I don't see why this wouldn't be
+1
~Hannes
Hi!
Honestly there are other parts about the voting process that are much
hotter potatoes than the points I brought up - such as who gets to
vote, is 50%+1 enough or do we need stronger majorities for
substantial language changes (67%/75%), can someone who failed
passing an RFC just put it up fo
Hi!
1. We do not use zend_fcall_info stuff in the VM (which zend_is_callable
works in)
2. We have to use zend_do_fcall_common_helper instead of
zend_call_function() in the VM
Yes, I know, I just have a feeling we have two pieces of code doing the
same in different way. But I think your propos
On Sun, Jun 5, 2011 at 10:55 PM, Zeev Suraski wrote:
> I'm fine if the entire 'Feature selection and development' part goes out of
> the RFC, but if there's any reference to how features are determined, we'd
> better get it right.
Getting it totally out makes little sense as it brings us to the
Can't bundle geoip with the database due to the license on it. Would make it a
pretty useless extension to have in that case.
S
On 5 Jun 2011, at 11:39, Olivier Hill wrote:
> Could you open a bug for GeoIP? Being aware of bugs helps more than bitching
> around.
>
> Thanks
>
> Olivier (iPho
hi Zeev,
On Sun, Jun 5, 2011 at 10:05 PM, Zeev Suraski wrote:
> Pierre,
>
> I'm happy that we agree pretty much completely about the clarifications &
> updates needed for the RFC.
Same here :)
> I do however want to point out that the problematic way the short array
> syntax RFC was executed
Hi!
On 2011-06-05, Pierre Joye wrote:
On Sun, Jun 5, 2011 at 5:52 PM, Philip Olson wrote:
I'd to say that I'm very happy to finally see such discussions
happening, let sort the base (99% is done by our existing RFC about
release process, let adopt it already!) and move on with 5.4.
This i
> Currently the "Feature selection and development" basically says "we'd have
> a public vote on features". It doesn't specify how exactly is the process for
> a
> vote, and while again I think your proposal is good, I don't see why it has
> to be
> part of this RFC - e.g., if we agree that we ha
there is no need to bundle GeoIP or the databae
GeoIP is part of the os-deployment and the database have
to be updated every month with a script, the problem here
was only that nobody cared about the extension over years
Am 06.06.2011 00:21, schrieb Scott MacVicar:
> Can't bundle geoip with the d
[resending as the list appears to reject bit.ly URLs]
> As I agree on everything you wrote here, I don't feel like we need to redo it.
> The votes result is pretty clear, despite 2-3 people not willing to
> vote for whatever reasons:
>
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
Take a
test for brain dead SURBL
--
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
As ordered, I will stick to what I feel are community issues and try
to be impersonal.
If PHP users want to be clear that we have made an educated choice to
use/maintain the language, we should appear impeccably well-versed in
the technologies which complement and compete with PHP. I f
take #4..
Hmmm, not sure I like the comparison (with Egypt).
> Major parts in the process weren't executed properly (I've spelled them out
> so I won't repeat them).
> It's quite possible that if they were executed properly, we'd have different
> results. Perhaps not, maybe even probably
Hi!
The way I see it, we can't employ the voting part of this RFC unless
we can agree on rules on how this voting works; It's fine that we
don't decide exactly how we're going to do it. But then, it means
that we don't get to do it until we do decide.
Well, we'd have to vote somehow, e.g. on
Hi everybody,
if you know how to do some weird things to PHP¹s parser and like
functional¹ish elements in PHP, please read further.
I¹ve finally found some time to put together a first draft of an RFC for
currying (https://wiki.php.net/rfc/currying). This is basically meant as a
starting point to
+1
On Jun 5, 2011, at 6:02 PM, Pierre Joye wrote:
> test for brain dead SURBL
>
> --
> Pierre
>
> @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Inte
On Sun, Jun 5, 2011 at 6:06 PM, Sanford Whiteman <
sa...@cypressintegrated.com> wrote:
>
> -- I do not feel that the acronym JSON has any clarifying nor edifying
> place in the RFC describing this syntax.
>
> Rather, I would suggest one of the following:
>
> · JavaScript-like [object|array] literal
On Mon, Jun 6, 2011 at 1:16 AM, Stas Malyshev wrote:
>> The way I see it, we can't employ the voting part of this RFC unless
>> we can agree on rules on how this voting works; It's fine that we
>> don't decide exactly how we're going to do it. But then, it means
>> that we don't get to do it un
On Sat, Jun 4, 2011 at 4:52 AM, David Zülke
wrote:
> Yes, I know. Then why are you and others demanding that the resulting syntax
> be fully compatible with JSON so it could be parsed by other JSON parsers?
> That makes no sense at all. A file with just ["foo"] in it won't be
> interpreted by P
Am 05.06.2011 22:05, schrieb Zeev Suraski:
> - There wasn't sufficient time, or nearly any time at all - between when
> Brian pulled it off the attic, and when a vote was called. If my proposal is
> accepted, there'll have to be at least two weeks between when a clearly
> marked [RFC] email hit
dukeofgaming wrote:
Ok, I found that Ruby added support for a new JSONy syntax a little while
ago, this is interesting:
http://webonrails.com/2009/02/06/ruby-191-hash/
But it doesn't have anything to do with JSON interoperability.
I'd rather no have to learn ruby either, but a scan of that do
89 matches
Mail list logo
