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=-2.2 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=no 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 6E22F1F609 for ; Wed, 28 Nov 2018 21:36:34 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 373F212140D; Thu, 29 Nov 2018 06:36:32 +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 5DD0E12138F for ; Thu, 29 Nov 2018 06:36:30 +0900 (JST) Received: by filter0021p3iad2.sendgrid.net with SMTP id filter0021p3iad2-4776-5BFF0A5A-32 2018-11-28 21:36:26.570307767 +0000 UTC m=+437007.881935302 Received: from herokuapp.com (ec2-54-161-168-181.compute-1.amazonaws.com [54.161.168.181]) by ismtpd0020p1iad2.sendgrid.net (SG) with ESMTP id k8Wb35hGRPKIVejwghSIaA Wed, 28 Nov 2018 21:36:26.569 +0000 (UTC) Date: Wed, 28 Nov 2018 21:36:27 +0000 (UTC) From: Greg.mpls@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 65535 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15348 X-Redmine-Issue-Author: MSP-Greg X-Redmine-Sender: MSP-Greg 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS7fNSnWeDCzhsnPb2Vaa4izyJGumrEm7dm8bB 6qmZdYNt3f6LL3GctSIcoElyLeX/fWFxd2aYinfKseYbpjjPX4JrtdSzpyWmMmXom4FwCcXY6CRGTE 5BK1IJBgivIFwinLGdPBwGoFot7hvBrYzIVJaXzybcQ/J917Rl0GAUNZng== X-ML-Name: ruby-core X-Mail-Count: 90138 Subject: [ruby-core:90138] [Ruby trunk Bug#15348] r66003 Support targetting TracePoint - MinGW 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 #15348 has been updated by MSP-Greg (Greg L). @ko1 Koichi, I did another ruby-loco build, and it also passed. The 'test repo' I did is here: https://ci.appveyor.com/project/MSP-Greg/ruby-loco-test/history Currently it runs three versions of the failing specs. In the first build, done before your fix, two of the three versions silent SEGV'd, and the third failed. The four builds (#2 thru #5) were done after the fix, all three versions passed in each. IOW, your fix certainly seems solid. @k0kubun When Appveyor is slow, it's very common for one or more TestJIT tests to fail running parallel but pass on retry. I've found the total build time (not test), along with the bootstraptest time are good indicators of how well test-all will go (or how busy Appveyor is). Both of the 'post-fix' ruby-loco builds completed TestJIT when running parallel. The second build was slow for both 'indicators', but TestJIT still had no parallel failures. Thought I'd mention it, as I know you've wrestled with intermittent test issues on mingw/mswin... Thanks to both of you for your work, Greg ---------------------------------------- Bug #15348: r66003 Support targetting TracePoint - MinGW https://bugs.ruby-lang.org/issues/15348#change-75254 * Author: MSP-Greg (Greg L) * Status: Open * Priority: Normal * Assignee: * Target version: * ruby -v: * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- This has caused failures in spec/ruby/core/main/using_spec.rb, specifically the first spec. On Appveyor, trying several versions of both specs, the first one (`eval('using', TOPLEVEL_BINDING)`) fails, the second one (`eval('using "foo"', TOPLEVEL_BINDING)`) passes. Locally (Windows 10), all versions of both specs have always passed using the same build (saved as an artifact) from Appveyor... -- https://bugs.ruby-lang.org/