@ryanc hi Ryan, I would like to contribute a pull request in the near future to improve the 'multiple statements given' error message being returned from db package when working with Sqlite3 databases. My changes involve the connection.rkt and ffi.rkt files in collects/db/private/sqlite3 directory in the main racket repository. Since those files aren’t in the db repository, where would be the appropriate place to put tests in? My guess is the db repository but wasn’t sure.

@abmclin: I’m not ryanc, but I’d assume that would be the place: https://github.com/racket/db/tree/master/db-test/tests/db

that was my first thought, I’d need to submit separate pull requests against the db repo and the racket repo, is that fine?

@abmclin yes, that’s fine

ok thank you

mflatt: I get a really weird error building old versions of Racket on Ubuntu 16.04 — https://gist.github.com/jeapostrophe/b8f7256657d490f83f5a453db049bf5a — I’ve got it on 5.92, 5.93, 6.0 and 6.3

@abmclin, confirming stamourv’s and samth’s answers

the same error is here — https://github.com/racket/racket/issues/1222

so the problem is that back then we used a different compiler, so there wasn’t a problem. very weird!

@ryanc would it be reasonable to disable the 4 failing tests here: http://drdr.racket-lang.org/40417/racket/share/pkgs/macro-debugger/tests/macro-debugger/all-tests.rkt

@jeapostrophe the xform step works by knowing that various functions are predefined and won’t trigger a GC; that approach interacts badly with C headers that expand things that look like functions in different ways, since xform is looking at preprocessed input

Ya, I think I understand the problem. I’m thinking about how to effectively warn users that old versions are broken because GCC isn’t backwards compatible. It’s a weird problem.

probably you just want to annotate the definitions of mz_long_double_eqv and double_eqv with XFORM_SKIP_PROC, which goes after the argument list and before the function’s opening {

Oh – you’re not just looking for a way to make the compile go through?

mflatt: correct, i know how to make it work. i’m thinking about what to do about people that email saying all the old versions are broken because they are trying to build on a modern linux distribution.

I think we don’t get those requests because old software generally doesn’t build

I have a sort of diabolical abuse of the macroexpander that produces an unbound identifier error, and I don’t understand why. Here’s a pasterack link, though pasterack produces a different error: http://pasterack.org/pastes/92495

The actual error I get when really running the program is this: the-binding2: unbound identifier; also, no #%top syntax transformer is bound

I don’t understand why the identifier is unbound, though. I think I must be missing something about how scopes get introduced in this sort of situation, but I don’t know how to debug this problem.

@mflatt or @samth, might either of you be able to help me with this? I realize this program is pretty bizarre, but yes, it is a reduction of a real (admittedly quite evil ;)) thing I am trying to do in Hackett.

@lexi.lambda you seem to have #@plain-app where you mean #%plain-app

Yeah, I noticed that, but it doesn’t affect the program.

Here’s a fixed paste: http://pasterack.org/pastes/48560

I don’t really understand what’s going on there, but it looks like the usual issue where you communicate the identifier behind the back of the macro expander and thus it doesn’t have the right scope

Yeah. I’m just not sure in this case how to arrange for the right scope, or even what scope is getting added or removed.

I think that to do this “right” might require some additional cooperation from the macroexpander, so right now it’s pretty hacky. :)

the problem is that when you expand the lambda that bind generates, it adds a scope to the binder and to the body

but that isn’t there on the reference, since the reference is hidden from the expander in a parameter

that makes sense. so I might be able to expand the lambda, then stash the identifier with the extra scope on it.

yes

hmm, that gives me an identifier used out of context error, though I could be doing something else wrong.

really you want to put the identifier in some macro in the body of the lambda, and arrange for that macro to put it in the parameter

yeah. I should probably explain the actual motivation behind this whole thing, since it’s pretty gross and there might be a better way.

@lexi.lambda Like this? [(#%plain-app @%bind-id ~! e:expr) (let ([id-to-bind (generate-temporary 'the-binding)]) (exp #`(λ (#,id-to-bind) (let-syntax ([result-transformer (make-variable-like-transformer (parameterize ([current-id #'#,id-to-bind]) (exp (walk+expand #'e))))]) result-transformer))))]

@mflatt: Thanks, that works in that case, but it doesn’t seem to work in my real situation. I’ll fiddle with it a bit and see if I can make it work.

All this is actually part of typeclass dictionary elaboration. I need to perform a sort of “delimited expansion” where I leave placeholders in the expansion where typeclass dictionaries will be inserted later. However, I can’t call local-expand with a stop-list, since that won’t recursively expand.

right, what @mflatt said, although I have often wrapped that pattern in a macro called something like (put-in-parameter id-to-bind expr)

Yep, that seems to have worked. Thanks @samth and @mflatt. I think this local-expand abuse is probably not the best solution to what I’m doing, but I admit I am not 100% sure what I’m doing, and it seems to sort of work so far. :stuck_out_tongue:

I think, with those changes, I have working typeclasses in Racket. :)