[#80974] [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit — ko1@...
Issue #13517 has been updated by ko1 (Koichi Sasada).
4 messages
2017/05/02
[#81024] Re: [Ruby trunk Feature#13517] [PATCH] reduce rb_mutex_t size from 160 to 80 bytes on 64-bit
— SASADA Koichi <ko1@...>
2017/05/07
sorry for late response.
[#80996] [Ruby trunk Feature#13544] Allow loading an ISeqs sequence directly from a C extension without requiring buffer is in an RVALUE — sam.saffron@...
Issue #13544 has been reported by sam.saffron (Sam Saffron).
3 messages
2017/05/04
[#81016] [Ruby trunk Bug#13526] Segmentation fault at 0x0055c2e58e8920 ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-linux] — s.wanabe@...
Issue #13526 has been updated by wanabe (_ wanabe).
3 messages
2017/05/07
[#81048] Re: [ruby-cvs:65788] normal:r58614 (trunk): rb_execution_context_t: move stack, stack_size and cfp from rb_thread_t — SASADA Koichi <ko1@...>
It causes compile error on raspi 3.
3 messages
2017/05/09
[#81201] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle — "U.NAKAMURA" <usa@...>
Hi, Eric
4 messages
2017/05/16
[#81202] Re: [ruby-cvs:65935] normal:r58761 (trunk): test/test_extilibs.rb: do not check the existence of fiddle
— Eric Wong <normalperson@...>
2017/05/16
"U.NAKAMURA" <usa@garbagecollect.jp> wrote:
[#81427] Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534) — SASADA Koichi <ko1@...>
Hi,
6 messages
2017/05/28
[#81428] Re: Fwd: [ruby-changes:46809] normal:r58924 (trunk): test for IO.copy_stream CPU usage (r58534)
— Eric Wong <normalperson@...>
2017/05/28
SASADA Koichi <ko1@atdot.net> wrote:
[ruby-core:81323] [Ruby trunk Feature#8631] Add a new method to ERB to allow assigning the local variables from a hash
From:
takashikkbn@...
Date:
2017-05-22 03:50:41 UTC
List:
ruby-core #81323
Issue #8631 has been updated by k0kubun (Takashi Kokubun).
> Or maybe ERB.new(str, locals: {a: b}).result?
For this case, it would have the same problem as ERB.new(str).result(locals: {a: b}) because it can have both binding and locals. In that case, adding locals to given binding is hard to maintain. Also, if we want to avoid the situation, raising error for that case does not seem a good idea (method should be separated in that case, especially for "3").
> I'm just not sure which name would be best. I like result_with_hash, but it could be result_from_locals or result_from_hash.
Then, the remaining problem is only the name of result_with_hash counterpart. Possible choices are:
- result_with_hash
- result_from_locals
- result_from_hash
What this method does is "rendering result with a context that given local variables are set". It's not result derived from only local variables. While "locals" is longer than "hash", it describes not type of argument but its actual content.
So I prefer "result_with_locals" ("render_with_locals" may be better but it should be unified with "result"). If you use the method with that name, I'm okay to add that.
----------------------------------------
Feature #8631: Add a new method to ERB to allow assigning the local variables from a hash
https://bugs.ruby-lang.org/issues/8631#change-65011
* Author: rosenfeld (Rodrigo Rosenfeld Rosas)
* Status: Feedback
* Priority: Normal
* Assignee: k0kubun (Takashi Kokubun)
* Target version: 2.5
----------------------------------------
It would be interesting if ERB could allow a hash instead of a binding for processing the template.
We wouldn't have to do hacks like:
b = OpenStruct.new(hash).instance_eval{ binding }
---Files--------------------------------
feature-8631.pdf (27.7 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>