Re: [racket-dev] Unlucky with Racket 6.0 (2/2)
On 13/03/14 03:38, Matthew Flatt wrote: At Wed, 12 Mar 2014 23:14:14 +, Paulo Matos wrote: However, I notice a top-level Makefile in racket/, after taking a peek and reading INSTALL.txt it seems that now I need to use this Makefile to build everything. So, I try (as mentioned in the INSTALL.txt): make in-place in-place is not a target. I'm stumped on this one. Is `in-place` not on line 38 of your copy of Makefile? I have no good explanation for what I did yesterday. Today it works. My guess is that I was doing it inside racket/racket and didn't notice I was in the wrong directory. I wish bash history could provide me with the cwd I was at when I ran a command. Sorry for this. Trying just `make` builds racket in place successfully. I get the same SEGFAULT mentioned in my previous post with same title. Is there a way to compile this with debug information? You can provide flags like `--enable-noopt` via `CONFIGURE_ARGS_qq'. But I've set up a 32-bit Kubuntu VM and I can replicate the crash there, so I'll investigate more. Excellent, that's good news. The crash here happens on a 64bit Kubuntu btw. Thanks, -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Unlucky with Racket 6.0 (1/2)
I've pushed a repair for the crash. The crash was due to a hack that extracts a private child from a Gtk widget that implements a `choice%`. The child is extracted so that callbacks can be attached to the child widget. The reference count on the extracted child wasn't managed correctly, and so an implementation or configuration of the widget that changes the child (as appears to be the case on Kubuntu) could cause a crash. Although the repair should avoid crashes, it is not complete. The intended signals are not caught if the child is changed, so some GUI elements do not work correctly. For example, the font menu is not populated in the DrRacket preferences dialog. I'll continue to work on that, but it will take more time. At Wed, 12 Mar 2014 22:45:42 +, Paulo Matos wrote: On 12/03/14 22:38, Sam Tobin-Hochstadt wrote: On Wed, Mar 12, 2014 at 6:35 PM, Paulo Matos pa...@matos-sorge.com wrote: So, I decide to run the gracket command under gdb but now it segfaults immediately without displaying drracket window. $ gdb --args /home/pmatos/local-install/racket-6.0/bin/../lib/gracket -N local-install/racket-6.0/bin/drracket -J DrRacket -l- drracket/drracket.rkt Racket uses page faults to manage memory, so you need to do: (gdb) handle SIGSEGV nostop noprint and then continue, and if there's an error, it will halt in `abort()`. Thanks, you're right. Got there when entered the Preferences screen: Program received signal SIGABRT, Aborted. 0x77323f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x77323f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x773275e8 in __GI_abort () at abort.c:90 #2 0x0068927e in fault_handler () #3 signal handler called #4 0x72e595b9 in g_type_check_instance () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #5 0x72e4e3f7 in g_signal_connect_data () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #6 0x00687548 in ffi_call_unix64 () #7 0x00686e8d in ffi_call () #8 0x0067896c in ?? () Not very useful. Need to setup drracket with debugging to understand this. -- PMatos _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Changing the default error display handler to use
At Wed, 12 Mar 2014 18:05:03 -0700, Eric Dobson wrote: A common issue I have is that the default error handler does not display error message's exn:srcloc if it has it [...] Is this reasonable to add to the default error handler, and if so do people have suggestions on the format? You mean the default error display handler, right? I think this change may be worth a try, but there are many exception-generating, exception-handling, and exception-printing parameters to worry about, both in their interactions and how they're currently used. For example, does DrRacket use the default error display handler? If so, it will start printing source locations that it's already showing a different way, and I think that's not what you intend. Or some other program harness might be worse off if the default display error handler starts showing source locations. Then again, the whole point is that you want to change the display of errors. Trying to change some things and not changes others --- and having enough extension points to accommodate certain combinations of changes and non-changes --- is why the existing set of parameters and handlers is complex. I will not be surprised if we end up with yet another parameter here. If the change makes sense, probably the handler should not print the first returned source location for `exn:fail:read`, `exn:fail:syntax`, and `exn:fail:contract:variable` exceptions --- because that location is supposed to be built into the error-message text, unless the `error-print-source-location` parameter has a false value. Awkward, I know; see the previous paragraph. The right format is likely to print an extra field: detail, similar to the way that the default error display handler prints context lines (if the `error-context-display-depth` parameter is not 0). I imagine that the source-location lines should precede the context lines, but follow the exception's error message. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Changing the default error display handler to use
You'll want to check DrRacket in both Debugging and No Debugging and Profiling mode to see if you're happy with the results (and I can help change them if you're not happy with them). Robby On Thu, Mar 13, 2014 at 8:34 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 12 Mar 2014 18:05:03 -0700, Eric Dobson wrote: A common issue I have is that the default error handler does not display error message's exn:srcloc if it has it [...] Is this reasonable to add to the default error handler, and if so do people have suggestions on the format? You mean the default error display handler, right? I think this change may be worth a try, but there are many exception-generating, exception-handling, and exception-printing parameters to worry about, both in their interactions and how they're currently used. For example, does DrRacket use the default error display handler? If so, it will start printing source locations that it's already showing a different way, and I think that's not what you intend. Or some other program harness might be worse off if the default display error handler starts showing source locations. Then again, the whole point is that you want to change the display of errors. Trying to change some things and not changes others --- and having enough extension points to accommodate certain combinations of changes and non-changes --- is why the existing set of parameters and handlers is complex. I will not be surprised if we end up with yet another parameter here. If the change makes sense, probably the handler should not print the first returned source location for `exn:fail:read`, `exn:fail:syntax`, and `exn:fail:contract:variable` exceptions --- because that location is supposed to be built into the error-message text, unless the `error-print-source-location` parameter has a false value. Awkward, I know; see the previous paragraph. The right format is likely to print an extra field: detail, similar to the way that the default error display handler prints context lines (if the `error-context-display-depth` parameter is not 0). I imagine that the source-location lines should precede the context lines, but follow the exception's error message. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Changing the default error display handler to use
Yes the default error display handler. Ok, I'll put this on my list of things to do, and hopefully have a version for review at some point. On Thu, Mar 13, 2014 at 7:22 PM, Robby Findler ro...@racket-lang.org wrote: You'll want to check DrRacket in both Debugging and No Debugging and Profiling mode to see if you're happy with the results (and I can help change them if you're not happy with them). Robby On Thu, Mar 13, 2014 at 8:34 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 12 Mar 2014 18:05:03 -0700, Eric Dobson wrote: A common issue I have is that the default error handler does not display error message's exn:srcloc if it has it [...] Is this reasonable to add to the default error handler, and if so do people have suggestions on the format? You mean the default error display handler, right? I think this change may be worth a try, but there are many exception-generating, exception-handling, and exception-printing parameters to worry about, both in their interactions and how they're currently used. For example, does DrRacket use the default error display handler? If so, it will start printing source locations that it's already showing a different way, and I think that's not what you intend. Or some other program harness might be worse off if the default display error handler starts showing source locations. Then again, the whole point is that you want to change the display of errors. Trying to change some things and not changes others --- and having enough extension points to accommodate certain combinations of changes and non-changes --- is why the existing set of parameters and handlers is complex. I will not be surprised if we end up with yet another parameter here. If the change makes sense, probably the handler should not print the first returned source location for `exn:fail:read`, `exn:fail:syntax`, and `exn:fail:contract:variable` exceptions --- because that location is supposed to be built into the error-message text, unless the `error-print-source-location` parameter has a false value. Awkward, I know; see the previous paragraph. The right format is likely to print an extra field: detail, similar to the way that the default error display handler prints context lines (if the `error-context-display-depth` parameter is not 0). I imagine that the source-location lines should precede the context lines, but follow the exception's error message. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
