Re: [racket-dev] Accessing OpenType MATH information through racket/draw

On Sun, Jan 9, 2022 at 3:48 PM Jens Axel Søgaard wrote: > It seems to me that the ideal solution would be hybrid. > > 1. Expose public but explicitly *unsafe* direct access to Cairo and > Pango contexts. > 2. Implement a safe API in racket/draw that provides the necessary > low-level acce

[racket-dev] Accessing OpenType MATH information through racket/draw

Hi all, I have recently been tinkering with an implementation of an OpenType math renderer in Racket. Doing this properly requires consulting font metrics stored in the OpenType MATH table . There is no direct interface to access thes

Re: [racket-dev] Efficient implementation of delimited control

Apologies for the delayed response to this—I had a busy week, then got sick at the end of it—but this is all incredibly helpful. There’s a lot of reading I still need to do to catch up on all of this, but that’s exactly what I was hoping for: there’s a lot of useful information here I hadn’t fou

[racket-dev] Efficient implementation of delimited control

If I may ask one more question of you, Matthew: following up from the thread on `dynamic-wind`, I would love to pick your brain on what you think are the state of the art implementation techniques for delimited continuations. When I went looking for resources, I mostly found two papers: “A Mona

Re: [racket-dev] CI improved for Racket

Hi Paulo, The work you’re doing is really cool, though I admit most of it is over my head. Thank you for putting in the time to set it all up. One thing I have noticed, however, is that the GitLab pipeline seems to almost always fail or timeout, which causes almost every commit on the commits p

Re: [racket-dev] Release Announcement for v7.1

> On Oct 14, 2018, at 15:35, Vincent St-Amour > wrote: > > Alexis King > - support for kw arguments in curry: d1b8ecb3e0edab3ac455486802646b930e88677f > @ racket `curry` from racket/function supports currying functions with keyword arguments, and `procedure-arity` and `

Re: [racket-dev] require: namespace mismatch while dealing with syntax-local-value of a syntax property

I realized I probably also ought to post my workaround, which I use in Hackett: I just don’t use preserved syntax properties at all (only unpreserved ones). I found that sticking syntax objects in preserved syntax properties was unreliable, probably for the reasons Matthew mentioned in the aforemen

Re: [racket-dev] require: namespace mismatch while dealing with syntax-local-value of a syntax property

I am not sure what could be causing this problem, but it seems related to something I ran into about a year ago[1], though I was getting slightly different behavior. At the time, Matthew had the following to say on the subject: > On Oct 25, 2016, at 4:28 PM, Matthew Flatt wrote: > > Putting iden

Re: [racket-dev] Chez Scheme as the Racket VM

I second other voices that this is both fascinating and exciting. Your technical efforts are always inspiring and much appreciated, and your detailed transparency around them perhaps even more so. These sorts of things are always extremely interesting to read. I have a question to add, myself: if

[racket-dev] Getting `template` out of experimental

It’s no secret that I love syntax/parse, but I’m a little less vocal of my love of syntax/parse/experimental/template, mostly because of that scary “experimental” in the name. Really, though, template is great, and it’s to syntax what syntax-parse is to syntax-case. Is there anything blocking makin

[racket-dev] Make range cooperate with for loops?

A question[1] was asked on Stack Overflow today that used `range` from racket/list in a for loop, then was baffled as to why it was so slow compared to a manually written loop using named let. To some extent, confusion of this sort is unavoidable, since it stems from a confusion about the differ

Re: [racket-dev] pkgs.racket-lang.org not work

Yes, something seems to be broken with pkgs.r-l.org right now; I seem to have the same problem. Someone mentioned they were having problems on the IRC channel the other day, then on the racket-users list, and it still seems to be broken. This seems pretty important to fix ASAP. > On Dec 19, 2016,

Re: [racket-dev] Misuse of terminology in `parser-tools/lex`?

> On Dec 9, 2016, at 10:23, Matthew Butterick wrote: > > 2) Relatedly: is the field ordering used by the `srcloc` struct — line > / column / position / span — recommended for other interfaces to > follow, or considered arbitrary? IMO, I would say “just use the srcloc struct” if you need srclocs,

Re: [racket-dev] what predicate is true for syntax objects with lexical context, and false for those without?

> On Dec 2, 2016, at 11:21 AM, Alex Knauth wrote: > > Does that mean it will yell at you when used with langs like afl, curly-fn, > and sugar/debug? > > Or are you using this because you'll end up calling strip-context anyway? This is a bit off-topic, and I don’t want to hijack this thread, bu

Re: [racket-dev] Release Announcement for v6.7

> On Oct 15, 2016, at 05:39, Vincent St-Amour > wrote: > > Alexis: - private repo support in pkg (racket @ > d409fb5e2ec8b29932cde718b8383ffa0ce071e3 > 8de889df5ea3e0859cd01f1fcd39cdca5a7f949c > 6d63e4443ffad0b73c9632033dbf2adcb0871658) The package system supports installing Git packages that re

Re: [racket-dev] Why is collections is failing pkg-build?

> On Oct 14, 2016, at 1:49 PM, Matthew Flatt wrote: > > I'll work on this as soon as I can. Meanwhile, you might have intended > for "functional-lib" to depend on "collections-lib", and it's possible > that change avoid the bug in the dependency calculation. Wonderful, thank you for the explanat

[racket-dev] Re: Why is collections is failing pkg-build?

Can anyone answer this? I’d really like to get my packages’ documentation indexed again, but I really have no idea what’s wrong. > On Oct 6, 2016, at 9:15 PM, Alexis King wrote: > > I recently split up my collections package into the usual lib, doc, and > test packages, and I notice

[racket-dev] Why is collections is failing pkg-build?

I recently split up my collections package into the usual lib, doc, and test packages, and I noticed today that pkg-build seems to be barfing on it in such a way that is causing its dependencies to have issues, too. Unfortunately, I can’t seem to figure out what’s wrong. If I look at http://pkg-bui

Re: [racket-dev] Release for v6.7 is about to begin

I would like to request that somebody take a look at this[1] pull request that adds support for private git repos to the package system before the release process. It’s not really urgent, so if people have any concerns with it, I’m happy to leave it out of this release, but if people think it looks

Re: [racket-dev] Using private github repositories as package sources?

Alright, I’ve opened a pull request that adds support for authentication to net/git-checkout, which appears to be able to successfully clone private GitHub repositories. Presumably, adjusting the package system to use this information is not terribly technical difficult, but I’m finding myself fair

[racket-dev] Using private github repositories as package sources?

I have been looking for a way to use Racket at work, and we’ve found a couple places where it might be useful for documentation or tooling. As part of this, it would be very nice to keep our source code private, but it would still be helpful to make use of the package manager to handle dependency r

[racket-dev] Command-line REPL for a custom #lang?

Currently, it does not seem like there is any option to open a new command-line REPL for a particular #lang. Based on what already exists, I’m not sure if this is a bug or if it’s intended (or perhaps overlooked) behavior. The -I command line flag to the racket executable states that sets the , wi

[racket-dev] Performance of Racket in R7RS benchmarks

Hello, I maintain the Racket r7rs package, which as far as I know, has not gotten much use. Recently, however, someone has put together a set of R7RS benchmarks and run it against various Scheme implementations, including Racket, using my r7rs-lib package. The benchmarks themselves are here: http

[racket-dev] pkgd.r-l.org certificate expired?

I am getting certificate errors when attempting to log in to pkgs.racket-lang.org. Specifically, the certificate appears to have just expired. I am able to manually override my browser’s security mechanism, but obviously this isn’t a particularly good (or easy) solution. I would imagine the certifi

Re: [racket-dev] Could there be a O(1) type-of operator for Racket builtins?

Ok, I’m happy to take a crack at it if you think that’s a good approach. I am quite comfortable with C, but I have basically no idea how Racket’s internals work, so that’d be the real barrier. I think one of the less-technical questions would also just be how to expose this information in Racket.

[racket-dev] Could there be a O(1) type-of operator for Racket builtins?

This is something that has bothered me for a little while. As far as I know, there is no way in Racket to determine the type of some built-in structure in constant time. Traditionally, the solution is to just use predicates, but this is obviously linear in the number of predicates to be tested. It

Re: [racket-dev] pkg-build.racket-lang.org

Builds are run daily for all packages that have been updated since the previous build (it would be nice if any updates immediately kicked off a build, but right now they just get run at 6:00 EST(?) every day). If all goes well, the pkg-build service should pick up your changes in a few hours. > On

Re: [racket-dev] Generic collections and the printing of streams

Yes, this precisely the sort of thing I envisioned when considering how to create smarter generalizations of `known-finite?`. A good approach, however, is not yet clear to me; I need to spend more time experimenting. I’ve tried to find prior art in this area, but I haven’t been particular successfu

[racket-dev] Re: Streams and stream printing

I’ve looked into the internals of streams before, and my understanding is that they are, in large part, ported from a different Scheme implementation. Hence the use of mutable pairs and lack of promises, as well as some degree of compatibility with SRFI 41. I cannot comment on individual implement

[racket-dev] Generic collections and the printing of streams

As anyone familiar with my collections library is aware, my library makes very heavy use of streams. So far, they seem to have served it well, but there is one obvious problem that has to do with how streams are printed. Having the ability to inspect values in the REPL is obviously useful, but Rack

Re: [racket-dev] Documentation Categories

Ooh, this is very nice. I’ve consulted the list of categories a few times, and I’ve never really found anything obvious to use for any of my packages aside from the default 'library. Are there plans to move any of the packages in the main distribution into other, more specific names with this chang

Re: [racket-dev] report from December leadership meeting

> A related issue is that examples in the documentation sometimes > fail in a way that indicates a bug. By having that failure be a > documentation-build failure, instead of rendered as an error > message in the documentation, we can avoid some errors in a > release. Matthew will add a re

[racket-dev] Questions about scribble/examples

I’ve noticed the recent addition of scribble/examples to scribble-lib. First of all, I’m super excited about having a more robust interface to scribble/eval, and from the documentation, it looks great. I do have a couple questions, though. 1. Should the name of this module be scribble/examples

Re: [racket-dev] colon keywords

> I think that Racket 6.3 would be a great time to make `:abc` read the same as > `#:abc`. This sounds like an incredibly breaking change. I support it in general, I think, but it seems like another feature that makes sense for Racket 2/Remix/whatever it ends up being called. I’m sure there are

Re: [racket-dev] marking stuff deprecated in documentation

> I'm curious to know the answer to Alexis' question: Semantics aside, > how do I simply make something with a standard warning appearance? In > many cases that's probably sufficient. I went looking for examples of > this in the docs, so I could go look for its Scribble. But I couldn't > find any

Re: [racket-dev] marking stuff deprecated in documentation

I know this is at least somewhat orthogonal to the points you’ve made, but perhaps it would be best to standardize how “warning” messages are rendered in documentation. For example, the “unstable: may change without warning” messages are quite useful, but I have no idea how I’d render those in m

Re: [racket-dev] Racket Cheat Sheet

> On that topic, are there any opinions on changing the name from > `define-simple-macro` to something else? It's always struck me as odd. +1 for changing the name. It definitely comes off as strange in both the “simple” and “macro” terminology. ;) > define-syntax-parse > define-rule > define-

Re: [racket-dev] Racket Package Server Security Vulnerabilities

> * Change your password on the http://pkgs.racket-lang.org site. For anyone confused about how to do this, I just spent a few minutes trying to figure it out, myself. You have to log out, then log back in with your email address and intentionally specify an incorrect password. The package serve

Re: [racket-dev] Package versioning

> To do that, you can put the package source for the specific version (instead > of the name) in the deps specification, and if the package isn't already > installed, it goes to that package source instead of through the catalog. > That doesn't work if the user already has the newer version inst

Re: [racket-dev] Package versioning

> Take a bigger stab. Post code. Submit pull requests. It’s on my list of Racket projects to work on! ;) My recent updates to my Heroku buildpack and my release of my environment variable manager actually came out of working with the web server. I’m playing with it, but I haven’t gotten very f

Re: [racket-dev] Package versioning

The frustrating thing about this problem is that it is a problem that seems to be fundamentally *solved*. PLaneT didn’t do it quite right, it’s true, but the current package system doesn’t, either. In fact, in a number of ways, the new system is catastrophically worse than the old one (it doesn’

[racket-dev] Creating a language that extends typed/racket

(Disclaimer: I think this question may have been visited before on this mailing list, but I couldn’t find any resolution, so I’m going to ask again.) I would like to write a language that extends typed/racket or typed/racket/base. Specifically, I have a collection, called “envy”. I would like t

Re: [racket-dev] try the new macro expander

Oh wow, thanks for the prompt update. I was in the process of trying to pick my way through the C code to figure out how I might be able to implement it myself, but I must admit I wasn’t getting anywhere fast. ;) > On Jul 25, 2015, at 1:40 PM, Matthew Flatt wrote: > > Yes, those uses rely on t

Re: [racket-dev] try the new macro expander

> That makes sense in retrospect. Adding an extra scope makes > `syntax-original?` produce #f for everything in whole module, and that > makes DrRacket ignore the identifiers. > > I think `make-syntax-introducer` should probably accept an optional > argument to specify that the new scope should *n

Re: [racket-dev] try the new macro expander

One more thing: introducing a new scope with make-syntax-introducer seems to break DrRacket’s Check Syntax arrows for the whole module. I don’t understand exactly how DrRacket’s arrows work, but my preliminary debugging in the macro stepper has left me a little confused. Whether I’m using curly

Re: [racket-dev] try the new macro expander

I have been testing mostly using a combination of DrRacket and `raco test`. However, with that begin-for-syntax bug fixed, I’ve determined what seems to be the problem (and is reminiscent of a similar problem in the previous version). This works: #lang curly-fn racket (begin-for-syntax

Re: [racket-dev] try the new macro expander

I’ve just taken the time to reimplement how my curly-fn package handles the transformation in an attempt to make it a little less unwieldy. Specifically, the transformation itself is now done via macro expansion rather than being performed at read-time. This means that the curly brace syntax its

[racket-dev] Ambiguous binding error in my curly-fn package under the new macro expander?

I’ve found an error that I believe is the fault of my curly-fn package under the new macro-expander, but it’s a little bit odd, and I’m having trouble figuring out exactly what the problem is. Specifically, the error doesn’t occur within the curly-fn package itself, only a package that depends o

[racket-dev] Could (or should) we add sugar for submodule paths?

Exposing submodules is becoming more prevalent in Racket, and I think that may be a good thing. The downside is that the syntax for requiring a submodule outside of its defining module is a bit clunky (the use of `submod` is necessary). The same would be true for `lib`, but Racket already has sugar

Re: [racket-dev] shadowing imports with definitions

It continues to be my opinion that the package system needs versioning with dependency version resolution. The NPM system wouldn’t work, since it can maintain multiple different versions in a project at the same time, but that’s probably a bad idea, anyway. The Bower, Clojure, and Ruby package v

Re: [racket-dev] shadowing imports with definitions

Would it perhaps be possible to support compilation “warnings” in addition to flat-out errors? I think the logic behind this change is good—simply adding exports being a potentially breaking change is problematic—but being completely silent about it is also possibly confusing. Having a concept o

Re: [racket-dev] Racket generics and generic collections

With regards to generics, I don’t think anyone is actively working on them. I was interested in potentially attempting them a while back, but I realized it was probably far too big of a project for me to try and research right now. I think the primary problem of consideration was ensuring sound

[racket-dev] Re: Racket generics and generic collections

I’ve been thinking about this more, and I think I’ve come up with a reasonable syntax for this. There are still a few annoying cases that I haven’t worked out yet with regards to the intended semantics, but I think this would be a good interface for the majority of use-cases. I’ve thrown togeth

[racket-dev] Re: Racket generics and generic collections

I’ve turned my attention to this once again, and I think I need to illustrate the current roadblock I’ve hit to seek some advice. Currently, there is no way to specify that implementing one generic interface automatically provides an implementation of another generic interface. This is actually

[racket-dev] Racket generics and generic collections

I’ve recently made an attempt to implement a generic collection library for Racket using racket/generic. My implementation is a work in progress, but you can find it here: https://github.com/lexi-lambda/racket-alexis-collections Docume

Re: [racket-dev] Generics in Typed Racket?

Thank you both for your replies on this. Matthias, I think your description is spot-on, and I absolutely agree with that attitude. I think there is something of an internal struggle within me that really wants Racket to be a practical general-purpose programming language that’s applicable now, b

Re: [racket-dev] Generics in Typed Racket?

Thank you for your warnings. I certainly didn’t anticipate it to be straightforward, but yes, it’s also probable I’m not up to the task. I definitely haven’t tried very much just yet, and I’m still undecided if I want to pursue this at all (at least for the time being). I do want to take a mome

Re: [racket-dev] Generics in Typed Racket?

> FWIW, so do I. IMO, the transition from functions+structs style to > structs+generics style is smoother than to methods+objects. > > It would be nice to also have a smooth structs+generics to > methods+objects transition, but I don't know how that would work yet. I’m glad to hear you agree. I

[racket-dev] Generics in Typed Racket?

So as it turns out, I have found myself sorely wanting generic interface support in Typed Racket. I understand that the class/object system seems to be the usual method of implementing interface-like polymorphism in Racket, but I actually much prefer the style of polymorphism that generics have