From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Zach Shaftel Newsgroups: gmane.emacs.devel Subject: Re: GSoC project - Improving ELisp Traceback and Debugging Information Date: Sat, 06 Jun 2020 14:20:46 -0400 Message-ID: <878sh0rr7m.fsf@gmail.com> References: <87eeqv6d30.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="11312"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.8; emacs 28.0.50 Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 06 20:21:21 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jhdRZ-0002qW-4Z for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 20:21:21 +0200 Original-Received: from localhost ([::1]:41200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jhdRY-0004NE-6h for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Jun 2020 14:21:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhdR4-0003xQ-J4 for emacs-devel@gnu.org; Sat, 06 Jun 2020 14:20:50 -0400 Original-Received: from mail-qk1-x72e.google.com ([2607:f8b0:4864:20::72e]:42046) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jhdR3-0000d3-Or for emacs-devel@gnu.org; Sat, 06 Jun 2020 14:20:50 -0400 Original-Received: by mail-qk1-x72e.google.com with SMTP id s1so13199805qkf.9 for ; Sat, 06 Jun 2020 11:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version; bh=hSSorgTy4ZzMu5A+IfbrdBSbWcp+xhz9aXpqUduJuXQ=; b=Qfl7cfcX7/cudDCRKXFYj51lrMBI0Ms2l7CO1L8M61FMyaUk2HEBqomBrv9ACV/DIl Z6o/G9VNwfyLIcIXgiZR7Tkybb+Msy8Wmop2fzXzLoVVwWqlbQCbd4/UJVcSL0cpYHjj rowl5TxkbrZrRYXA/QnqVGoXXZ9NM1E/bK7srTplKiduxur25t9Nm8Uw6/Nm7rgzjfkr PyvTaa6RndvZrZaA+qw/I+cOHJnzDG4A9JGqqdUXwj5Ef9ZsJ0AOIcXE28rQFwzjUIwv jiyfHeHM0vaOWx8OFH7hWiqgcW0Lw4s0oXAW06vg469EvOgToDZ2Y/sy/yQ3KptZJCdQ vPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=hSSorgTy4ZzMu5A+IfbrdBSbWcp+xhz9aXpqUduJuXQ=; b=Wf0m/zNTYlaGRk9YqltU7pq7Bl2bNGwaSlOSBMRzBwvHIRyDtqIkHKLGZ7Ca4ZTUJ8 rhx3H+QwB7z2O42k22wesXsPwYxPkAMHhBRX0edIWxMj7PTTyuKNxLZS0URA1aASrzF1 cU4n2AmwmslZ13nm0MxOmUfTsDT+9hT8zgnk3F/kjoHZwZPN7anFo88wRmCKQA+Rn7y1 0Av156HskDnlPSE6l3vA3qcR0UQUS+yMnq8hME6Si5P1RT20pWME75bkL8KW0HZnSWbK empJYF6DJvt0m+73ZaMhAfV2Dl6k3Kt9oXKp+aMGXjJInc2VtNXJYBsyFIde/djKBCig R/cA== X-Gm-Message-State: AOAM533F0040AEuuhOhZPQ4O0/GbJPBhfzml1+oV89JLteQ3KcDDyHwP TZpjqDF+D2BR7euqAuW1e7gbEK2I X-Google-Smtp-Source: ABdhPJz2iq2hZ/FHlMs9rFL6DLbKAap2NJqA5GKaATJU3zVFsqeplzEiZyyXLWVcz5FYXiLS5oKq9w== X-Received: by 2002:a05:620a:1396:: with SMTP id k22mr15590959qki.28.1591467648017; Sat, 06 Jun 2020 11:20:48 -0700 (PDT) Original-Received: from arch-thinkpad ([2604:2000:2f41:2d00::1]) by smtp.gmail.com with ESMTPSA id v69sm2712771qkb.96.2020.06.06.11.20.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 06 Jun 2020 11:20:47 -0700 (PDT) In-reply-to: Received-SPF: pass client-ip=2607:f8b0:4864:20::72e; envelope-from=zshaftel@gmail.com; helo=mail-qk1-x72e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:251957 Archived-At: > I don't see this branch on Savannah; there's a > feature/soc-bytecode-in-traceback from 2020-04-27, but > apparently > doesn't contain all this. Ah my mistake, Rocky Bernstein had pushed that branch, I'm still waiting to hear back from copyright-clerk@fsf.org so I don't know if I can push to Savannah just yet. The repo is available at https://github.com/SwiftLawnGnome/emacs-gsoc/tree/feature/soc-bytecode-in-traceback-specbinding if you'd like to take a look. > Anyway, just wanted to say, that it would nice if bytecode to > bytecode > calls would not leave the exec_byte_code function. Those calls > should > push the necessary frames and continue the interpreter loop. > That way > the bytecoe PC doesn't need to be saved redundantly on the C > stack and > the specbinding stack. That's an excellent idea. That would make the logic cleaner and should speed up the interpreter to boot. I'll get to work on that right away. > Instead of annotating symbols I would annotate cons cells. The > reader > could keep a hash table on the side an record the source > position of > cons cells. That was also mentioned in this thread https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00444.html discussing this project. I'll be looking into this option but as Alan Mackenzie mentioned in that thread it might not be plausible, largely due to the sheer number of cons cells created during compilation and macroexpansion. Keeping that information across all those source transformations seems nigh impossible without some very convoluted logic. I'm also not so keen on the symbols approach because it splits symbols into two different types, annotated and bare, which to me just seems unnecessarily complicated. But this could be changed so that it isn't transparent to the user like it is in that branch. I'll be looking at how other Lisp compilers record source code locations. SBCL is what I'm most familiar with but that compiler is very complex, and uses an intermediate code representation during compilation that makes recording this type of information easier. Ideally I would teach the byte compiler to do something as advanced as this as well, but that would probably entail a complete overhaul that wouldn't fit into the span of my project. Perhaps, once the offset is readily available, I could start this undertaking and continue work on it after GSoC ends. -Zach