@samth has the snapshot build failed?

@greg I am getting from travis racket: Did the build fail? Check the logs at <https://plt.eecs.northwestern.edu/snapshots/current/log/>

Except that url doesn’t exist.

@pocmatos Huh. Well, <https://plt.eecs.northwestern.edu/snapshots/current/log/> is the URL provided in tiny print as “Build Logs” near the bottom of https://plt.eecs.northwestern.edu/snapshots/ — I’m guessing the build failed harder, or, the build went fine but there’s some HTTP and/or network issue

@greg understood. just wanted to let you know of the issue really. I understand that most likely something failed on the racket side.

No worries it’s good to double-check.

@florence Not a big deal at all, just curious: Is that check-the-logs message still good or does it need updating? (Asking you b/c you know more about this than me, b/c you added this a year ago :smile: https://github.com/greghendershott/travis-racket/commit/1df1d73d9432e2e93bf89e7cfc936521deb74427)

@mflatt I see you tried cross compiling chez in https://github.com/cisco/ChezScheme/pull/267#issuecomment-371478100

@mflatt was this successful ?

the reason I ask this is because for me it fails due to the simple fact that Mf-cross includes Mf-${xm}, which does not exist in $M/s. So, in principle it should fail.

oh wait… I just noticed that in your specific case, it won’t fail because you’re not crossing. Your $m == $xm…

I think it’s still fine! Unless that link changed which seems unlikely to me

Something unexpected happened. I am trying to create a binary package, so I write raco pkg create --binary --dest tmp ., it turns out however that a zip file is created and it contains all of the source files, not just the binary ones.

Thanks!

@pocmatos everything seems to be there at the relevant site

/cc @greg

I believe that the site may not atomically update, which might explain that

The Build Logs link is no longer 404 for me.

same here

i guess me and @greg found a time window where things were broken but now all seems ok.

Oh, instead of updating atomically does it use green energy? That’s cool.

OK I feel dirty but I spent hours trying to get this to work some “right” way: https://github.com/greghendershott/racket-mode/commit/2308f71d2be67042f98188590627e42452292ea8

(The get/set! in question is the sort of thing that gui-debugger/annotate annotate-for-single-stepping returns.)

@greg can you provide a little more background?

Maybe there isn’t any “right” answer to how do you annotate 3D syntax? :slightly_smiling_face:

Oh, I’m working again on step-debugging in racket-mode.

And one thing I wanted to do, is while you’re at a break, the REPL turns into a special debug REPL. Where you can refer to local variables in scope, and even set! them.

So it’s getting syntax from current-read-interaction, and wrapping it in a let-syntax with make-set!-transformer for each local.

And that works fine for non-TR, and even for the get case of TR, because the stx is just literal value

But I couldn’t figure out how to make a set! transformer. TR would understandably complain that the type of get/set! was Any, and I couldn’t ann or cast or anything to make it happy.

@samth That’s the basic situation.

can you just give get/set! a type?

for example, with unsafe-require

Oh I didn’t really know about unsafe-require. I’ll take a look.

Will that work at the top-level inside a TR #%top-interaction wrapper? Defining a module and unsafe-requiring it?

I’ll try and see.

Why does the module need to be inside the TR #%top-interaction wrapper?

Because this is all happening inside a current-prompt-read handler inside read-eval-print-loop.

Maybe I’m making a dumb mistake but this toy example at a normal Typed Racket REPL prompt doesn’t seem to work: typed.rkt> (begin (module m racket/base (provide (all-defined-out)) (define (set n) (void))) (unsafe-require 'm [set (-> Any Void)]) (set 12)) ; stdin::825: type-check: type name used out of context ; type: -> ; in: (-> Any Void) ; at: -> ; in: (-> Any Void)

Maybe the hack I did is fine. If a debugger allows you to bypass type-checking, is that a bug or feature? (I’m partly rationalizing, but partly serious.)

sorry, it should be unsafe-require/typed

Ah OK. That error fooled me. Same error with unsafe-require/typed, but neglecting to (require typed/racket/unsafe).

yes, that’s the same issue that was discussed recently wrt syntax-parse and _

Oops got side-tracked by Travis CI error. Not what @pocmatos reported. Now it’s SSL cert failures. I can repro locally on macOS: $ curl -L <https://mirror.racket-lang.org/installers/7.0/racket-7.0-x86_64-linux.sh> curl: (60) SSL certificate problem: Invalid certificate chain More details here: <http://curl.haxx.se/docs/sslcerts.html> curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option.

urg

yeah, appears to be expired

<http://mirror.racket-lang.org\|mirror.racket-lang.org> uses an invalid security certificate. The certificate expired on August 28, 2018, 9:09:43 AM GMT-4. The current time is August 28, 2018, 10:24 AM. Error code: SEC_ERROR_EXPIRED_CERTIFICATE

@jeapostrophe ping

@pocmatos That comment is about using the cross-compilation setup for bootstrapping, which is not “cross” in the sense of multiple platforms. I’ve only cross-compiled (in that sense) boot files, which goes something like this: https://programmingpraxis.com/2017/09/15/compile-chez-scheme-on-android-arm/ Overall, Chez Scheme’s build process… well, let’s just say that Racket-on-Chez will need to offer simpler entry points, such as make cs in the Racket repo’s top level.

@mflatt Thanks, I will take a look. I was pretty confident there was a bug somewhere in the Makefiles but it seems to go smoothly in the reference you linked to, so I need to dig deeper.

raco exe docs say The raco exe command embeds a module, from source or byte code, but how is this choice made? If bytecode is available, bytecode is chosen, otherwise source?

Yes. If only source is available, it is compiled to bytecode for embedding.

ah, but it’s nonetheless compiled. It’s not like the source file is inserted verbatim and compiled later somehow at execution time. Thanks.

@greg btw, the certificate issue is fixed

Is there a way to get a backtrace in racket? I have a contract violation and need to find the source of the error.

usually the backtrace will be printed by default if you’re using DrRacket, click the triple cross icon in the REPL if you’re using racket REPL, either use (require errortrace) or ,errortrace to turn on errortrace (for more detailed backtrace)

(in racket REPL, ,bt also shows more context information)

In racket-mode in Emacs you can set racket-error-context to 'high, although errortrace makes your program run slower. Or, you can leave it at 'low or 'medium normally and use C-u prefix to temporarily set it to 'high for one run. So, normally C-c C-c to run, and if you get an unsatisfying error you can C-u C-c C-c to run again and get a hopefully better one. https://github.com/greghendershott/racket-mode/blob/master/Reference.md#run

What’s the complexity of hash-ref for (equal?) hash maps? If I have a hash map whose keys are lists of length k, would hash-ref become O(k)?

oh, the hashing function is already linear for lists anyway…

Right. hash-ref is O(1) for mutable hashes and effectively O(1) for immutable ones, though that doesn’t include the cost of the hashing itself. For equal? hashes, each use of hash-ref incurs one use of equal-hash-code and possibly many equal? comparisons in the case of collisions.

sounds about right :disappointed:

(For immutable hashes, hash-ref is actually O(log n), but it works out so that log n is never larger than the constant 62, so it’s essentially constant time.)