From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 04D751F45A for ; Fri, 16 Aug 2019 12:36:15 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id C9D0F120A4A; Fri, 16 Aug 2019 21:36:07 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 011931209EE for ; Fri, 16 Aug 2019 21:36:05 +0900 (JST) Received: by filter0079p3mdw1.sendgrid.net with SMTP id filter0079p3mdw1-19485-5D56A338-24 2019-08-16 12:36:08.581409769 +0000 UTC m=+42542.169741487 Received: from herokuapp.com (unknown [3.91.250.81]) by ismtpd0040p1iad2.sendgrid.net (SG) with ESMTP id IzOjrEe6SWib-DJDn8BYcw for ; Fri, 16 Aug 2019 12:36:08.515 +0000 (UTC) Date: Fri, 16 Aug 2019 12:36:08 +0000 (UTC) From: dale.hamel@srvthe.net Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 69932 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 12093 X-Redmine-Issue-Author: pavel.evstigneev X-Redmine-Sender: dalehamel X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?6I60bU3pPJ7DjHoXK6S08BOAiq7kYBxI64Rl6S1EsJGoRbrfDKkFZ7XnJpYlIC?= =?us-ascii?Q?yUuLmisCQsaCRpx8TcR+bRP=2FAN+HI4kNhjJC60a?= =?us-ascii?Q?Elcq6d8uOPZCdEOvdd4TPgTr5gnyefOwLKUIClH?= =?us-ascii?Q?aduLN6GgrT8Laqq8zHNf+FD7P7Z0KF7K5oMnuiP?= =?us-ascii?Q?C4VEu0H+Tq15KITWqphQQ9gNiS6xReDmp+w=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 94384 Subject: [ruby-core:94384] [Ruby master Feature#12093] Eval InstructionSequence with binding X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #12093 has been updated by dalehamel (Dale Hamel). Yes when I test out Koichi's sample, the iseq look like: ``` disasm: #@:1 (1,0)-(1,6)> (catch: FALSE) 0000 putself ( 1)[Li] 0001 opt_send_without_block , 0004 putself 0005 opt_send_without_block , 0008 newarray 2 0010 leave ``` So there is no way for the local variables from the binding to be evaluated, as the original instruction sequence expects a method call. I hadn't realized that when compiling the iseq string, methods calls are found in this way. This indicates that yeah, Nobu's comment above appears correct, you must have the binding available when the iseq is compiled. It appears to do so implicitly based on the current binding. ---------------------------------------- Feature #12093: Eval InstructionSequence with binding https://bugs.ruby-lang.org/issues/12093#change-80799 * Author: pavel.evstigneev (Pavel Evstigneev) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Implementing this feature can boost template engine performance Currently Kernel#eval can accept binding argument, so code running with eval will have access to local variables and current instance. This feature used by template languages ERB: https://github.com/ruby/ruby/blob/trunk/lib/erb.rb#L887 Erubis: Can't find code on github, but it uses instance_eval or Kernel#eval Haml: https://github.com/haml/haml/blob/master/lib/haml/engine.rb#L115 My proposal is to make RubyVM::InstructionSequence#eval to recieve binding argument. So it can be used for caching templates. As I see from ERB and Haml, cached template is stored as ruby code string, every time when we render template that string (ruby code) is evaluated, internally ruby will parse it into RubyVM::InstructionSequence and then evaluate. Before I try to implement it myself in ruby, but could not. Lack of experience with C https://github.com/Paxa/ruby/commit/f5b602b6d9eada9675a4c002c9a5a79129df73a6 (not working) ---Files-------------------------------- 0002-Update-iseq.eval-to-accept-optional-binding-FIXES-Bu.patch (4.83 KB) 0001-RubyVM-InstructionSequence-eval_with.patch (2.91 KB) -- https://bugs.ruby-lang.org/