[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>

Feature #2032: Change the license to "GPLv2+ or Ruby's original".

51 messages 2009/09/02
[#25368] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Kazuhiko Shiozaki <redmine@...> 2009/09/04

Issue #2032 has been updated by Kazuhiko Shiozaki.

[#25461] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Gregory Brown <gregory.t.brown@...> 2009/09/07

On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<redmine@ruby-lang.org> wrote:

[#25463] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yukihiro Matsumoto <matz@...> 2009/09/08

Hi,

[#30610] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Shyouhei Urabe <redmine@...> 2010/06/06

Issue #2032 has been updated by Shyouhei Urabe.

[#30611] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

Hi,

[#30614] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/06

> To avoid enbugging a new bug, we must choose the another solutions.

[#30616] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

2010/6/6 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#30652] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/08

(2010/06/06 20:27), Yusuke ENDOH wrote:

[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>

Feature #2033: Move Core Development to Git

75 messages 2009/09/02
[#25290] [Feature #2033] Move Core Development to Git — Yui NARUSE <redmine@...> 2009/09/02

Issue #2033 has been updated by Yui NARUSE.

[#25297] Re: [Feature #2033] Move Core Development to Git — Jon <jon.forums@...> 2009/09/02

> Some commiter of Ruby live on Windows.

[#25342] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Jon wrote:

[#25343] Re: [Feature #2033] Move Core Development to Git — Michal Suchanek <hramrach@...> 2009/09/03

2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#25345] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Michal Suchanek wrote:

[#25299] Re: [Feature #2033] Move Core Development to Git — Eric Hodel <drbrain@...7.net> 2009/09/02

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>

Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support

16 messages 2009/09/03

[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <drbrain@...7.net>

On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:

10 messages 2009/09/05

[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>

Bug #2054: Onigurma Isn't Documented

17 messages 2009/09/05

[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>

Is there a way in 1.9 to turn off only indentation warnings? I like

19 messages 2009/09/06
[#25510] Re: turning off indentation warnings — Nobuyoshi Nakada <nobu@...> 2009/09/10

Hi,

[#25511] [Bug #2079] win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined — Bruno Antunes <redmine@...>

Bug #2079: win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined

18 messages 2009/09/10

[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>

Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

12 messages 2009/09/19

[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>

Bug #2131: f(not x) => syntax error

16 messages 2009/09/22

[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>

I have a challenge for anyone who wants to discuss, propose

25 messages 2009/09/25
[#25782] Re: A challenge: Enumerator#next in JRuby — Tanaka Akira <akr@...> 2009/09/26

In article <f04d2210909251312q46bd51c0teacc4b0a8c417f0c@mail.gmail.com>,

[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>

Feature #2152: Split functionality of Float#inspect and Float#to_s

32 messages 2009/09/28

[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>

Bug #2160: JSON can't parse input where top-level object is a string

11 messages 2009/09/29

[ruby-core:25867] Re: [Bug #2160] JSON can't parse input where top-level object is a string

From: Caleb Clausen <caleb@...>
Date: 2009-09-29 23:09:59 UTC
List: ruby-core #25867
Brian Mitchell wrote:
> On Tue, Sep 29, 2009 at 14:14, Caleb Clausen <caleb@inforadical.net> wrote:
>> Tim Bray wrote:
>>> Per RFC4267, http://www.ietf.org/rfc/rfc4627.txt, "foo" isn't legal JSON.  Top level has to be an object {} or array [].  So unparse should refuse to process "foo".  This isn't just a theoretical standards-wonk problem, I got bitten trying to interop with Java JSON libraries on this one.
>> Do you (or anyone else) have any idea why it was specified this way? It
>> seems kind of inconvenient.
> 
> JSON is designed for sending structured data. Being a glorified format
> for just a string seems like overkill. I recommend wrapping it in an
> object or array in any case because if it is just a string it seems
> like it lacks that self-describing aspect of well structured data.

In the general case, if I want use json to serialize+deserialize objects
(where the precise type isn't specified ahead of time), then I don't
want to be bothered with restrictions like this. I don't like having to
always wrap my data in an array just because I might want to encode a
string.

I should think Json ought to handle all objects equally... whether their
actual class be Array, Hash, String, or Fixnum. Granted, there will be
some restrictions imposed by the fact that JSON is a subset of
JavaScript, so some concepts just aren't available. For instance,
JavaScript has no symbols, so there's no way ruby's Symbol is going to
be perfectly supported in JSON. But why should that apply to Strings?

To put it another way, lack of structure is itself a kind of structure.

Having said all that, I'd like to thank Kornelius Kalnbach for revealing
the reason(s) why it is the way it is. I might prefer it a different
way, but at least there is a valid reason.

In This Thread