[#65451] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
9 messages
2014/10/07
[#65458] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/07
[email protected] wrote:
[#65502] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/08
Eric Wong <[email protected]> wrote:
[#65538] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
Eric Wong <[email protected]> wrote:
[#65549] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— SASADA Koichi <ko1@...>
2014/10/09
On 2014/10/09 11:04, Eric Wong wrote:
[#65551] Re: [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string
— Eric Wong <normalperson@...>
2014/10/09
SASADA Koichi <[email protected]> wrote:
[#65453] [ruby-trunk - Feature #10328] [PATCH] make OPT_SUPPORT_JOKE a proper VM option — ko1@...
Issue #10328 has been updated by Koichi Sasada.
3 messages
2014/10/07
[#65559] is there a name for this? — Xavier Noria <fxn@...>
When describing stuff about constants (working in their guide), you often
7 messages
2014/10/09
[#65560] Re: is there a name for this?
— Nobuyoshi Nakada <nobu@...>
2014/10/09
On 2014/10/09 20:41, Xavier Noria wrote:
[#65561] Re: is there a name for this?
— Xavier Noria <fxn@...>
2014/10/09
On Thu, Oct 9, 2014 at 1:59 PM, Nobuyoshi Nakada <[email protected]> wrote:
[#65566] [ruby-trunk - Feature #10351] [Open] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been reported by Shyouhei Urabe.
3 messages
2014/10/09
[#65741] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race — Nobuyoshi Nakada <nobu@...>
On 2014/10/16 10:10, [email protected] wrote:
5 messages
2014/10/16
[#65742] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Eric Wong <normalperson@...>
2014/10/16
Nobuyoshi Nakada <[email protected]> wrote:
[#65750] Re: [ruby-cvs:55121] normal:r47971 (trunk): test/ruby/test_rubyoptions.rb: fix race
— Tanaka Akira <akr@...>
2014/10/16
2014-10-16 12:48 GMT+09:00 Eric Wong <[email protected]>:
[#65753] [ruby-trunk - Feature #10333] [PATCH 3/1] optimize: "yoda literal" == string — ko1@...
Issue #10333 has been updated by Koichi Sasada.
3 messages
2014/10/16
[#65818] [ruby-trunk - Feature #10351] [PATCH] prevent CVE-2014-6277 — shyouhei@...
Issue #10351 has been updated by Shyouhei Urabe.
3 messages
2014/10/20
[ruby-core:65932] [ruby-trunk - Bug #10416] Create mechanism for updating of Unicode data files downstreams when we want
From:
duerst@...
Date:
2014-10-28 03:30:17 UTC
List:
ruby-core #65932
Issue #10416 has been updated by Martin D=C3=BCrst. Yui NARUSE wrote: > For years, file structures of Unicode Data was changed some times. > Therefore there's no guarantee that Unicode 12 can work with the current = script. I agree (but see last paragraph of this comment). But that's not what this = issue is about. What I'm talking about is that next year, at some point in time, we decide = that ruby trunk is upgraded to Unicode 8.0 (and so on probably every year).= This was the case this year for Unicode 7.0, see issue #9092. We do this after checking that the new Unicode data files work with the cur= rent script (first the beta files and then the final releases), and if they= don't work, then we upgrade the script. Then we commit, and everybody on t= runk gets the changes when they update. But currently, this is not the case= for the Unicode data files, and people on trunk will have to use a special= effort to upgrade. Besides committing lib/unicode_normalize/tables.rb (nobu reverted it but di= dn't give any reason why), there's another way to achieve this goal: Note in a file the versions or timestaps of the 'official' version of the R= uby trunk Unicode data files. This could be part of a .mk file, or a new fi= le. Of the three files we currently download, two have a header (first two = lines) like this: # NormalizationTest-7.0.0.txt # Date: 2013-11-27, 09:54:41 GMT [MD] So we could note the version and/or date we want people on trunk to use, an= d check against it. But one file, UnicodeData.txt, doesn't contain the info= rmation in the file, so we have to rely on the date of the Last-Modified ht= tp header (which we already use to avoid repeated downloads of the same fil= e). The reason why UnicodeData.txt doesn't contain is these header lines is tha= t this is a very old file and the Unicode Consortium is actually quite care= ful to not make any changes that could affect the users of a file. If data = of a different type is needed, then it is provided in a separate file. ---------------------------------------- Bug #10416: Create mechanism for updating of Unicode data files downstreams= when we want https://bugs.ruby-lang.org/issues/10416#change-49667 * Author: Martin D=C3=BCrst * Status: Open * Priority: Normal * Assignee: Nobuyoshi Nakada * Category: build * Target version: current: 2.2.0 * ruby -v: ruby 2.2.0dev (2014-10-22 trunk 48092) [x86_64-cygwin] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- The current mechanism for updating Unicode data files will create the follo= wing problem: Downstream compilers/packagers will download Unicode data files ONE time (t= hey may already have done so). However, if they don't activate ALWAYS_UPDATE_UNICODE =3D yes, these files = will never get updated, and they will stay on Unicode version 7.0 even if i= n five years Unicode is e.g. on version 12.0. On the other hand, if they activate ALWAYS_UPDATE_UNICODE =3D yes (and assu= ming issue #10415 gets fixed), they constantly update to the latest version= of Unicode. That's good for those who actually want this, but now what our= current policy is. What's missing is that we (Ruby core) can make sure downstream checkouts up= date to a new Unicode version when we want then to do so (as we e.g. can do= for other parts that are based on Unicode data, see e.g. https://bugs.ruby= -lang.org/issues/9092), without sending an email to everybody and hoping th= ey read and follow it. [Currently, the only solution I know will work is the one pointed out by Yu= i Naruse in https://bugs.ruby-lang.org/issues/10084#note-17, but I'm okay w= ith any other solution.] --=20 https://bugs.ruby-lang.org/