From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [IPv6:2a01:4f8:1c0c:6b10::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 529CC1F44D for ; Wed, 17 Apr 2024 18:54:15 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=UyPbRHSJ; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=gXjkPFB8; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 6275B84385; Wed, 17 Apr 2024 18:54:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1713380047; bh=4SzN5Wvfdv+yANBAWDx8raDuGRf7kkIeixYmZBRN5FI=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=UyPbRHSJvCLN0aFZ+cp3RwmvHSD+b/iOUMXmuBefVHfhn3FHPzOKCCGWgQKyI7jqE kDCZ0chZhMBzHuW/ogfswgiQ1hc4iH5keDEAqoVzyNe3OpDNolTS8fHGzUiZcrL6kv nuJMlxR7K1hcfId9eL0y6CzK7Uq1iFQ+Zz0zejRA= Received: from s.wfbtzhsw.outbound-mail.sendgrid.net (s.wfbtzhsw.outbound-mail.sendgrid.net [159.183.224.105]) by nue.mailmanlists.eu (Postfix) with ESMTPS id E88D984373 for ; Wed, 17 Apr 2024 18:54:03 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=gXjkPFB8; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=u35ueciN2S2dCeNCnnF8aRzmIx7MMqnnRZsXS02ybrs=; b=gXjkPFB82QG0/kzyQGQXQHwQvGo0ps4rWrSSBWIcOEy4G0dUB5VB/B6AF4GDx7LagV1+ eaOckqZgNpD/WDBMEn5rFghvtWTLAmPmCR/v8mxDzYFNk9Xk0uS5pPNHp2hlq9S47RVxl4 xWTQNOhb2Sjg66HGcw9EKWepgrD6KgCJeluyL2XYTAsnAFtygIbNzAkDpl01MINjBKpuAA xWPs04fpJ15tXznqD5arTpyFX/bayB056quOQ57m8OGBq0ezm11i+N8yc3GNCtf/cCRdNp 249DAPKUa6auWWMbKhjTIn1N2MTtPPm0YVK/DPytEoh3TS38wj59hQJjLP2Gk8og== Received: by recvd-6b888cd74b-gbltt with SMTP id recvd-6b888cd74b-gbltt-1-66201ACB-2 2024-04-17 18:54:03.006238597 +0000 UTC m=+420812.416017445 Received: from herokuapp.com (unknown) by geopod-ismtpd-18 (SG) with ESMTP id YiLKqp68Sh-93TW4Q1v-Qg for ; Wed, 17 Apr 2024 18:54:02.976 +0000 (UTC) Date: Wed, 17 Apr 2024 18:54:03 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20335 X-Redmine-Issue-Author: byroot X-Redmine-Issue-Priority: Normal X-Redmine-Sender: Eregon 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-Redmine-MailingListIntegration-Message-Ids: 94170 X-SG-EID: =?us-ascii?Q?u001=2EByjZWvxTCjdoV8K03xEuhE7KqN4thWULFLM7+oH78KY30oYB3qFthsDpL?= =?us-ascii?Q?4w4cbYa3ttBh8bAHPOnE=2FkzPba67JNu7Lnrked2?= =?us-ascii?Q?O7K9VQ=2FJax1oMQKrvBCY7fj=2FE20dh5ETUahkdjm?= =?us-ascii?Q?kRPZYSzuqi1CLGAoa0f=2FmTo=2FHmWRjDsddQEqHzd?= =?us-ascii?Q?ZCfv+xtz4sKoh7VgyyAhoz4P5PyPbbNL4tj0edS?= =?us-ascii?Q?C529rwmoZ=2FlNAF2EsvBRDbNhSOsyIhnTm9onLGf?= =?us-ascii?Q?842oxbaFgGKMtMVWIV6VtUjnAw=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: LMCQUD2CFHLDXGQVNH65RESYKLYPDDU5 X-Message-ID-Hash: LMCQUD2CFHLDXGQVNH65RESYKLYPDDU5 X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:117574] [Ruby master Feature#20335] `Thread.each_caller_location` should accept the same arguments as `caller` and `caller_locations` List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "Eregon (Benoit Daloze) via ruby-core" Cc: "Eregon (Benoit Daloze)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20335 has been updated by Eregon (Benoit Daloze). @byroot It's both, but for TruffleRuby I'm pretty sure the first matters much more. These few allocations are no big deal on the JVM, so I would expect similar on JRuby. Walking the stack is also obviously slower with a deeper stack (e.g. Rails), while the object allocations are pretty obvious and simply the number of times the block yielded before the user `break`s/`return`s. I also don't see any valid use case for `Thread.each_caller_location` with a Range with negative begin or end, so that's why I think it's better to prevent it altogether instead of making it a performance trap (i.e. it's `O(stack depth)` instead of the expected `O(number of locations yielded)`). (the only way to make that fast would be to maintain a stack depth field in every frame, but that's overhead in time and memory for every call just for this feature, which seems clearly unreasonable). ---------------------------------------- Feature #20335: `Thread.each_caller_location` should accept the same arguments as `caller` and `caller_locations` https://bugs.ruby-lang.org/issues/20335#change-107974 * Author: byroot (Jean Boussier) * Status: Closed ---------------------------------------- `Thread.each_caller_location` was added to Ruby 3.2 as part of [Feature #16663] and is a very useful API for emitting warnings with a proper source location and similar use cases. However in many of the cases where I used it, or seen it used, it was needed to skip the first, or a couple frames: Examples: Sorbet: https://github.com/Shopify/sorbet/blob/b27a14c247ace7cabdf0f348bfb11fdf0b7e9ab4/gems/sorbet-runtime/lib/types/private/caller_utils.rb#L6-L18 ```ruby def self.find_caller skiped_first = false Thread.each_caller_location do |loc| unless skiped_first skiped_first = true next end next if loc.path&.start_with?("= 1 frames_to_skip -= 1 next end # snipp... ``` ### Proposal I think it would be very useful if `Thread.each_caller_location` accepted the same arguments as `caller` and `caller_locations`: ```ruby #each_caller_location(start = 1, length = nil) #each_caller_location(range) ``` @jeremyevans0 what do you think? -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/