[#55222] [ruby-trunk - Feature #8468][Feedback] Remove $SAFE — "shugo (Shugo Maeda)" <redmine@...>
20 messages
2013/06/01
[#55230] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55252] [ruby-trunk - Feature #8468] Remove $SAFE
— "spatulasnout (B Kelly)" <billk@...>
2013/06/02
[#55276] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation — Tanaka Akira <akr@...>
2013/5/31 zzak <ko1@atdot.net>:
9 messages
2013/06/03
[#55278] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/03
[#55285] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
The original wording was:
[#55288] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55289] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Zachary Scott <zachary@...>
2013/06/04
I fail to see the difference, please provide a patch to make it more clear.
[#55290] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— David MacMahon <davidm@...>
2013/06/04
[#55291] Re: [ruby-changes:28951] zzak:r41003 (trunk): * process.c: Improve Process::exec documentation
— Tanaka Akira <akr@...>
2013/06/04
2013/6/4 David MacMahon <davidm@astro.berkeley.edu>:
[#55297] [ruby-trunk - Bug #8486][Open] Random segmentation fault — "manudwarf (Emmanuel Bourgerie)" <manu.dwarf@...>
4 messages
2013/06/04
[#55305] [ruby-trunk - Bug #8489][Open] Tracepoint API: B_RETURN_EVENT not triggered when "next" used — deivid (David Rodríguez) <deivid.rodriguez@...>
7 messages
2013/06/04
[#55312] [ruby-trunk - Bug #8495][Open] include/ruby/win32.h assumes that __STRICT_ANSI__ isn’t set — "now (Nikolai Weibull)" <now@...>
4 messages
2013/06/05
[#55330] [ruby-trunk - Feature #8499][Assigned] Importing Hash#slice, Hash#slice!, Hash#except, and Hash#except! from ActiveSupport — "mrkn (Kenta Murata)" <muraken@...>
30 messages
2013/06/06
[#55416] CI failures: Test IO and cleanup failures — Luis Lavena <luislavena@...>
Hello,
3 messages
2013/06/10
[#55528] [ruby-trunk - Bug #8538][Open] c method not pushed into the callstack when called, but popped when returned — deivid (David Rodríguez) <deivid.rodriguez@...>
9 messages
2013/06/17
[#55530] [ruby-trunk - Feature #8539][Open] Unbundle ext/tk — "naruse (Yui NARUSE)" <naruse@...>
10 messages
2013/06/17
[#55557] [ruby-trunk - misc #8543][Open] rb_iseq_load — "alvoskov (Alexey Voskov)" <alvoskov@...>
47 messages
2013/06/19
[#65574] [ruby-trunk - Feature #8543] rb_iseq_load
— billk@...
2014/10/09
Issue #8543 has been updated by B Kelly.
[#55578] [ruby-trunk - Feature #8553][Open] Bignum#size (and Fixnum#size) — "akr (Akira Tanaka)" <akr@...>
6 messages
2013/06/21
[#55580] [CommonRuby - Feature #8556][Open] MutexedDelegator as a trivial way to make an object thread-safe — "headius (Charles Nutter)" <headius@...>
19 messages
2013/06/21
[#55590] [ruby-trunk - Bug #8560][Open] CSV, skip_lines option causes error when passing a string — "kstevens715 (Kyle Stevens)" <kstevens715@...>
5 messages
2013/06/22
[#55638] [CommonRuby - Feature #8568][Open] Introduce RbConfig value for native word size, to avoid Fixnum#size use — "headius (Charles Nutter)" <headius@...>
18 messages
2013/06/24
[#55678] [ruby-trunk - Feature #8572][Open] Fiber should be a Enumerable — "mattn (Yasuhiro Matsumoto)" <mattn.jp@...>
13 messages
2013/06/28
[#55690] [ANN] Developer Meeting - 12-07-2013 at 23:00 UTC — Aaron Patterson <tenderlove@...>
Hi everyone!
7 messages
2013/06/28
[#55699] [ruby-trunk - Feature #8579][Open] Frozen string syntax — "charliesome (Charlie Somerville)" <charliesome@...>
20 messages
2013/06/29
[ruby-core:55360] [ruby-trunk - Feature #8490] Bring ActiveSupport Enumerable#index_by to core
From:
"Eregon (Benoit Daloze)" <redmine@...>
Date:
2013-06-07 16:53:47 UTC
List:
ruby-core #55360
Issue #8490 has been updated by Eregon (Benoit Daloze).
rosenfeld (Rodrigo Rosenfeld Rosas) wrote:
> I'd prefer index_by! to raise an exception instead...
! is not used for exception-raising methods in ruby core and stdlib.
> What if you know that any duplicate would actually map to the same object?
There should be some possibility to merge duplicates like Hash#merge in that case.
But is it worth the complexity? If you need some merging strategy,
the operation is no more mere "indexing", and I would favor the current approach ("h={}; enum.each { |e| h[e.k] = e if ... }").
> Also, you can't judge how my ORM should work (anyway, all the ORM I've worked with, both in Ruby, Groovy and Java have a very similar API when it comes to fetching a list of records, there's nothing special on this regular requirement)...
Well, the ORM (or whatever you use between DB and code) could do this.
And having something like "index = {}; each_record { |record| index[record.key] = record }; index"
could be useful I guess. For instance, Sequel has some Dataset#select_hash which is somewhat similar.
> Sometimes I'm working in something that would take advantage of some caching of records by id that I'll use somewhere, but that doesn't mean I always need to index by id... This was just a use case, it doesn't mean that every time I need to index a list of objects it comes from the database...
Yes, of course. I agree it would be useful to have something like index_by.
But maybe, as in the #cache_fetch example, it would be useful to be able to change/map the values too.
(if the name has "map" in it, it should map values as well.)
> So I can't understand why you're so sure that "I should use a different technique in the code" as you don't even know my code...
I am not "so sure", I started with "I think".
Of course there are special cases and I can not know your code.
But to me using keys like that for databases record does not seem the most appropriate way to do it at first sight (probably best iterating on the properly sorted result set).
----------------------------------------
Feature #8490: Bring ActiveSupport Enumerable#index_by to core
https://bugs.ruby-lang.org/issues/8490#change-39776
Author: rosenfeld (Rodrigo Rosenfeld Rosas)
Status: Rejected
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version:
It seems to be a common sense to have the useful implementation of Enumerable#index_by as in ActiveSupport.
index_by acts like group_by but only maps a single record, instead of an array, keeping the last match only. It's usually used in places where you shouldn't have more than a single match for each key.
Would you consider its inclusion to core Enumerable module?
--
http://bugs.ruby-lang.org/