Is there a way to do interface inheritance? For example, I want to provide the customer with an interface to implement but I want to force him to implement not only the functions of the interface itself but also gen:equal+hash. So, I want my interface to include functions from other interfaces as well.

@pocmatos yes interface supports multiple inheritance, you can include as many super-interface-expr as you want in the interface expression. https://docs.racket-lang.org/reference/createinterface.html

@abmclin Those are interfaces for classes, I was talking about generic interfaces for structs. define-generics seems to be the closest we have to interface but for structs.

@greg do you know how to disable auto pair mode with either paredit or smartparens. I can’t understand how anyone likes that. I much prefer the drracket way where once on a top of a paren (which I insert) I get the paren region highlighted. Do you know how to achieve this? i.e. not just highlight the open paren but the whole region?

@pocmatos ahh yeah I don’t know much about struct inheritance mechanisms

@pocmatos By “auto pair mode” do you mean the behavior of paredit, smartparens, or electric-pair-mode where typing e.g. a ( where none exists adds the )? Or something else?

that’s it.

I can’t disable it in any of the modes and I have tried both paredit and smartparens.

idk about smartparens but in paredit it’s effectively a requirement — paredit pretty much depends on the buffer being a valid sexpr at all times

oh… shame. Oh well. I will disable them. I really don’t like the behaviour. :slightly_smiling_face: Thanks.

FWIW I tried paredit — and gave up on it — probably four or five times over the course of a couple years.

Then I tried it again, and it stuck hard ¯_(ツ)_/¯

so you use smartparens with this electric behaviour?

I use paredit

oh… stuck hard…

i read suck hard. :slightly_smiling_face:

Oops. :slightly_smiling_face: Yeah my point it is I thought it sucked hard until eventually I thought it was brilliant.

I can’t deal with it at the moment, drives me crazy to see all those parens growing after my cursor.

You also mentioned highlighting. highlight-parentheses-mode only highlights the parens. It probably wouldn’t be hard to hack it to highlight the whole region. But. When I use paredit mode, I trust the sexpr navigation so much I barely “see” the parens. So, I don’t use any highlighting.

Also: If you’re using racket-mode, and disable paredit mode, you could try this DrRacket ripoff: https://github.com/greghendershott/racket-mode/blob/master/Reference.md#racket-smart-open-bracket

Yeah, I have the highlight-parentheses-mode but it’s not enough. I really would like to get the whole region highlighted.

Or maybe that’s more auto-magic-pixie-dust you’d rather avoid :slightly_smiling_face:

highlight-parens-mode does have hl-paren-background-colors (defaults to nil) but alas that only sets the background color of the parens themselves, not the region between

I have a feeling that’s already enabled in racket-mode for me because I have that feature and no smartparens or paredit.

Yeah, need to find a way to highlight the region between as well. I wonder if I can sort something out using hightlight.el https://www.emacswiki.org/emacs/HighlightLibrary

One could use highlight-parentheses.el as a starting point. It uses two Emacs “overlays” to highlight the open and close. Moves them. Instead could use one overlay, that you move and resize over the region. Something like that.

Yes, my elisp-fu is pretty rusty but it’s not much code so I will give it a try. :slightly_smiling_face:

A lot of the code by volume seems to support the configuration options. (Isn’t that always the case. Stupid user preferences complicating our elegant code. :smile:) So if this will be just hardcoded to @pocmatos then it might get even simpler.

… reading about overlays. :slightly_smiling_face:

Ok so I made a silly procedure and I’m wondering if it already exists somewhere or if we should add it to racket/function: (define (thunkpose . thunks) (if (pair? thunks) (thunk ((car thunks)) ((apply thunkpose (cdr thunks)))) void)) Behold the marvelous thunkpose! A mix of thunk + compose!

It’s obviously more imperative than functional, because composing thunks is mostly about creating (begin ...) clauses and wrap’em in lambdas, but I needed a way to build processes that will execute later in a specific order.

I think you could write that more easily just by writing: (define ((thunkpose . thunks)) (for ([thunk (in-list thunks)]) (thunk)))

Definitely better :smile:

I love the name thunkpose

@andreiformiga: Re feature-profile: from the error, it looks like the program you’re trying to profile has its own expectations wrt command-line arguments (i.e., none) that conflict with raco feature-profile. You may want to try calling feature-profile from inside your program instead.

Does anybody have any example of the use of id/c created by a define-generics? I can’t understand how to use this. The documentation exists but it’s not entirely clear to me. Github search isn’t of much help.

@pocmatos the tests have some examples https://github.com/racket/racket/blob/master/pkgs/racket-test/tests/generic/contract.rkt

@asumu true, the code helps. thanks.

Yeah the docs should probably be more clear on its use. I’m also not sure it turned out to be a very useful feature…

@mflatt Following up on yesterday. Launching Dr. Racket today gave the usual splash screen. However, the problem with missing menu items remains. The keyboard equivalents (CMD - and CMD = ) work as intended. Any hints? Please let me know if there is any information you need or debugging steps you would like me to take. Thank you.

I meant to follow up: this problem should be fixed for the next release. Please try a snapshot from http://pre.racket-lang.org\|pre.racket-lang.org to see if it works on your machine. (Note: since the snapshot archives are still not signed, you’ll need to drag the DrRacket app out of its folder and back in – which tells the OS that you trust the application enough that right-clicking and “Open” should work. Really.)

The problem was related to the on-demand callback for menu items, where the technique to detect a mouse click on the menu bar doesn’t work with Mac OS 10.13.

@mflatt Thank you for the quick follow-up. Unfortunately, I’m getting the same problem.

Just to make sure, the version that DrRacket shows is “7.0.0.1”?

@mflatt yes

@stamourv thanks, I think this is the issue

@ghoetker Another long shot, but what does this program print when you run it (in any version of Racket)? #lang racket/base (require ffi/unsafe ffi/unsafe/define) (define appkit-lib (ffi-lib (format "/System/Library/Frameworks/AppKit.framework/AppKit"))) (define-ffi-definer define-appkit appkit-lib) (define-appkit NSAppKitVersionNumber _double) NSAppKitVersionNumber

@mflatt, @robby, or @jeapostrophe (not sure which), are you aware that you can’t compile Racket 6.12 from the repo?

I am aware

you want @stamourv

@dan may be able to help with the right incantations if this is a question about how to get it working and not a bug report

Ah, okay.

@leif I think there’s a bug report on the racket repo somewhere that has the instructions

or a mailing list post

In this case, @stamourv> Ya. When I do:

git clone git@github.com:racket/racket.git
cd racket
git checkout v6.12
make

I get: Using cached15288364681528836468332 for <git://github.com/racket/plot/?path=plot-compat> raco pkg install: version mismatch for dependency for package: 2d-lib mismatch packages: base (have 6.12, need 6.90.0.19) make[1]: *** [plain-in-place] Error 1 make: *** [in-place] Error 2

@samth Instructions on how to get around this?

yes

we know that what you just posted is what happens

if you want racket 6.12 from source, then I recommend downloading it from http://download.racket-lang.org\|download.racket-lang.org

see https://github.com/racket/racket/issues/2022 and linked issues for more discussion of this

@mflatt Running the provided code in either version of Dr. Racket (7.0.0.1 or 6.12) gives the same answer: 1561.4. Please let me know what else I can do to help debug, if anything. Thank you.

@samth Hmm..okay, thanks.

@leif: FWIW, this will be fixed in 7.0 and subsequent releases.

Still looking for differences between your setup and mine… Does your machine have multiple screens? Or a Retina display?

@mflatt Okay, now we’re just in the world of weird. I have a MacBook Pro with a retina display. My issues to date have been while running DrR with the notebook closed and two 23-inch (1920 x 1080) displays attached. I unplugged one display, launched DrR (6.12) and all was well. Shut DrR down, reconnect the other monitor, launch DrR again and…everything seems to work as normal, even though I once again have two monitors attached. I’ve tried this dance several times and the problem seems to be staying fixed!? Actually, there was one time that the menu spots were initially blank, but filled the second time I opened the View menu. That’s different from before. I’ve not been able to recreate it. It is stuck on being fixed which is (a) great for me and (b) lousy for debugging. Do you want to declare victory or is there anything I can do to help continue debugging?

Ah, that seems like useful information. The implementation of on-demand involves checking whether a click hits the menu bar, but I have to implement the check at a lower level in the graphics pipeline than I usually get to use. I’m not clear on all the relevant coordinate transforms that I need to apply. I may be able to provoke problem and sort out coordinate issues by working with multiple displays and changing the relative positions of the displays. Thanks!

One more test would be helpful, if you have time, because I don’t have a Retina display for my High Sierra machine: When you’re using just the laptop screen, does the menu look right when you click at the highest possible point in the menu name? At the lowest possible point? Unfortunately, you’ll need to restart DrRacket between those tests to get an accurate result. The intent of this test is to help check whether I need to worry about scaling, as opposed to just offsets.

On just my laptop screen, I am now seeing no problem whether I click at the menu on its highest or lowest point. I restarted DrR between tests as you indicated. Just ask if I can try anything else.

I’ve pushed changes to accommodate multiple screens, and a snapshot will be ready tomorrow morning U.S. time. I’m assuming that you have the default Mac OS display settings where there’s a separate menu bar at the top of each screen. In that case, as of yesterday’s snapshot, only one of the menu bars would have worked right, and now both should work right. (So it wasn’t a coordinate-system problem, but that I forgot how menu bars work with multiple displays in modern Mac OS.)

@mflatt Wonderful. Thank you. Should I grab it from http://pre.racket-lang.org\|pre.racket-lang.org to give it a test?

Yes, when the snapshot changes to one that starts “20180613”.