[racket-users] Re: Racket2 possibilities

[Ray Racine]

Over the years I have loved Racket ... except for those parens ... if 
only.   I don't know when it happened but one day parens and I made a peace 
treaty, mind melded, became enlightened or just got tired of fighting, but 
right now I can't see a Racket without parens (s-exps). I have, in fact, 
grown rather fond of them.

There is the bottom up approach to grow Racket2 from examples and snippets 
of syntax all to be compared and endlessly debated.

Rhetorical mullings from the top down perspective is interesting.

Assume a Racket2 will not be another Ruby or Python as Racket is a BIG 
language and could not be compressed down to a simplistic Python or simple 
lisp without parens Ruby.  And what is the point of Racket2 being a Ruby or 
Python wanna-be anyway?  Would the world move to a better Python/Ruby?

Assume it will not be some variation of a Swift, Java or C#.

If moving from s-exp to traditional in-fix and f(x,y,z) function 
application makes sense to seek wider adoption, would not moving from 
functional to imperative also make sense? After all, all the popular 
languages are imperative, therefore, to enhance the likelihood of wide 
adoption should Racket2 be imperative as well?

But then wouldn't Racket2 be Algol2 or Ada2 with macros?

If it stays functional and expression based with macros then isn't Racket2 
then Dylan2?

Of the three axioms of Racket2, the f(x,y,z) proscription prohibits some of 
the cleaner syntax out there as used in SML and Haskell.  Is it a hard 
requirement to ensure full macro support can happen?

If Racket2 moves to be even more functional in thrust, drops the f(x,y,z) 
proscription and adopts currying then isn't Racket2 a polished up nextgen 
SML2?

Maybe a nextgen SML2 for semantics and typing but with the lighter Haskell 
syntax (no laziness)?

What will be the magic twist for widespread adoption that Algol, Ada, 
Dylan, SML, Haskell and s-exp Racket, all with quality implementations, 
failed to achieve?  

How much of a languages adoption success is just shear dumb luck, the right 
place at the right time independent of the languages overall quality and 
capability? Does Javascript even need to mentioned here?

Should we cover all possible bases and make Racket and its "make languages" 
core a nextgen DotNet and put together a whole suite of languages, a Lisp 
like, an Algo like, a SML like, a Haskell like, a Java/Swift like, an 
Erlang like, ... all interoperable.   If that all of that happened tomorrow 
by magic would the world embrace Racket(2...).









-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/c8abfd8b-3304-4ed5-9e23-bf2f1d7da8cb%40googlegroups.com.

Re: [racket-users] on reducing barriers in the Racket community

[Stephen De Gabrielle]

Thank you.

S.

On Sun, 21 Jul 2019 at 21:46, Matthew Butterick  wrote:

> I'm not a member of Racket management. But I spend a lot of time using &
> promoting Racket. Most recently, I taught the Beautiful Racket Workshop as
> part of Racket Week 2019.
>
> I care a lot about Racket — the technology, but especially the human
> community that makes it possible.
>
> I've heard from a few people that events before, during, or after Racket
> Week left them questioning Racket's commitment to making everyone feel
> welcome. And to be honest, it wasn't the first time.
>
> This saddens me. It's not consistent with my own values. It's not what I
> want Racket to stand for. I want everyone to feel welcome, wanted, and
> valued.
>
> In a nearby thread, Matthew Flatt talked about the importance of "reducing
> barriers" in a technical sense. But it matters in a community sense too, of
> course.
>
> If Racket is putting up social barriers — even unwittingly — that are
> frustrating newcomers (or existing members) then we ought to be able to
> hear this with an open mind & heart, and make adjustments. This is our duty
> as empathetic, moral members of a community.
>
> I'm not sure what I can do to improve this situation. I'm open to
> suggestions. I can at least offer the following (I would rather risk
> looking foolish than doing nothing):
>
>
> 1) If you've had an experience where the Racket community made you feel
> less than totally welcomed, I invite you to add it to this thread, or
> contact me privately. If you want details of your story shared, in some
> anonymized way, I can do that.
>
> I recognize the irony of making this offer on the racket-users mailing
> list — those who've had a bad experience are likely long gone. But I also
> know there are people here who, like me, want to help make Racket better,
> even on rough days.
>
>
> 2) Gently, I suggest that we work together to reduce the volatility of
> these conversations. I know that some feel that these matters are better
> handled away from the racket-users list. But this is counterproductive: it
> amounts to saying that we should feel free to harvest the benefits of
> Racket-the-technology while avoiding obligations to Racket-the-community.
> As a matter of logic and ethics, I can't see how they are divisible.
>
>
> 3) Today, I'm a reasonably well-adjusted adult (or at least my dog thinks
> so). But a long time ago, I was a fat and dorky and smart kid. For years, I
> was physically and verbally bullied at school. It was relentless and
> terrifying. But as was true for a lot of kids like me during that era,
> computers were a refuge. They never judged me. They rewarded my curiosity.
>
> I mention this not to put my experience on a footing with anyone else's.
> But it reminds me that while our contributions to Racket may be public,
> what Racket MEANS to each of us is necessarily private. Right now, there
> are people in our community for whom Racket is a bright spot in difficult
> times. If you haven't been there yet — you will.
>
> To my mind, discussing these matters openly is about preserving the
> paramount virtue of a community based on sharing knowledge: to accept
> everyone just as they are. When we're falling short in this regard, we
> shouldn't avoid these facts, lest we make a virtue of ignorance. Or if we
> can't do this, and people bypass Racket in preference to other communities,
> then we'll have no one to blame but ourselves.
>
> With much gratitude to everyone who makes Racket possible.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/8964B1F7-C0A5-44BA-AFE3-FF87E038F3CE%40mbtype.com
> .
>
-- 


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAGHj7-JeGBpGcJUyuH7zHk18Ra33Apq%2BZ%2Bjvx2qYRYsthPYGgg%40mail.gmail.com.

Re: [racket-users] DrRacket UI question ...

[Ryan Culpepper]

On 7/21/19 10:41 PM, Tim Meehan wrote:
When hovering over names in a program that I downloaded to examine, I 
noticed a purple question mark that I had not remembered seeing before. 
I am used to hovering over a name and seeing where else it is used, 
etc., but I don't remember seeing the purple question mark before ...


I searched for DrRacket documentation in the "Racket Documentation" app, 
and also at Northwestern 
, 
but didn't see anything that described it. I'm going to try and attach a 
screenshot - but I am not sure that it will survive the mailing list 
process. In case it does not survive, I was looking at Matthias 
Felleisen's implementation of the 7GUIs tasks, specifically, task-2.rkt 
. I 
was hovering over "render" in line 27. The question mark shows up when 
pointing to the usage of "render" on line 25. I suppose that if I had to 
guess, it might have something to do with the usage being in a 
"define-syntax-rule."


Yes. The purple arrow is drawn to identifiers in syntax constants 
(things that eventually wind up in a quote-syntax form). It's different 
from a blue arrow because it shows a *potential* reference, but 
depending on how the syntax is used it may or may not turn into an 
actual reference.


Here's a simple example that shows potential references to `x` (with 
purple arrows) that do not become actual references:


  #lang racket
  (define x 12)
  (define-syntax-rule (id)
(lambda (x) x))

Ryan

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/53a8b8cd-cc36-2127-c6e5-d1ff15b46e12%40ccs.neu.edu.

[racket-users] on reducing barriers in the Racket community

[Matthew Butterick]

I'm not a member of Racket management. But I spend a lot of time using & 
promoting Racket. Most recently, I taught the Beautiful Racket Workshop as part 
of Racket Week 2019. 

I care a lot about Racket — the technology, but especially the human community 
that makes it possible.

I've heard from a few people that events before, during, or after Racket Week 
left them questioning Racket's commitment to making everyone feel welcome. And 
to be honest, it wasn't the first time. 

This saddens me. It's not consistent with my own values. It's not what I want 
Racket to stand for. I want everyone to feel welcome, wanted, and valued. 

In a nearby thread, Matthew Flatt talked about the importance of "reducing 
barriers" in a technical sense. But it matters in a community sense too, of 
course. 

If Racket is putting up social barriers — even unwittingly — that are 
frustrating newcomers (or existing members) then we ought to be able to hear 
this with an open mind & heart, and make adjustments. This is our duty as 
empathetic, moral members of a community.

I'm not sure what I can do to improve this situation. I'm open to suggestions. 
I can at least offer the following (I would rather risk looking foolish than 
doing nothing):


1) If you've had an experience where the Racket community made you feel less 
than totally welcomed, I invite you to add it to this thread, or contact me 
privately. If you want details of your story shared, in some anonymized way, I 
can do that. 

I recognize the irony of making this offer on the racket-users mailing list — 
those who've had a bad experience are likely long gone. But I also know there 
are people here who, like me, want to help make Racket better, even on rough 
days.


2) Gently, I suggest that we work together to reduce the volatility of these 
conversations. I know that some feel that these matters are better handled away 
from the racket-users list. But this is counterproductive: it amounts to saying 
that we should feel free to harvest the benefits of Racket-the-technology while 
avoiding obligations to Racket-the-community. As a matter of logic and ethics, 
I can't see how they are divisible. 


3) Today, I'm a reasonably well-adjusted adult (or at least my dog thinks so). 
But a long time ago, I was a fat and dorky and smart kid. For years, I was 
physically and verbally bullied at school. It was relentless and terrifying. 
But as was true for a lot of kids like me during that era, computers were a 
refuge. They never judged me. They rewarded my curiosity. 

I mention this not to put my experience on a footing with anyone else's. But it 
reminds me that while our contributions to Racket may be public, what Racket 
MEANS to each of us is necessarily private. Right now, there are people in our 
community for whom Racket is a bright spot in difficult times. If you haven't 
been there yet — you will.

To my mind, discussing these matters openly is about preserving the paramount 
virtue of a community based on sharing knowledge: to accept everyone just as 
they are. When we're falling short in this regard, we shouldn't avoid these 
facts, lest we make a virtue of ignorance. Or if we can't do this, and people 
bypass Racket in preference to other communities, then we'll have no one to 
blame but ourselves.

With much gratitude to everyone who makes Racket possible.


-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/8964B1F7-C0A5-44BA-AFE3-FF87E038F3CE%40mbtype.com.

[racket-users] Re: Racket2 possibilities

[Michael Myers]

I'm somewhat reluctant to write this, as I am more conscious then ever of 
my limitations in terms of what time/energy I can commit and the 
consistency with which I can do so. But insofar as Honu was mentioned, I 
feel a bit obligated to at least chime in with some of my knowledge and 
observations of it, and some related possible strategies.

At the moment, aside from Matt and Jon, I think I have the most direct 
experience of Honu's inner workings. I've also spent a good number of years 
trying to toy with what I feel is a simpler and more modular approach, but 
I've often gotten caught up in bike shedding about names, interfaces and 
what to expose where. For various reasons, this is a domain which 
unfortunately makes it *very* easy to do so. My efforts so far can be found 
here: https://pkgs.racket-lang.org/package/infix-syntax, it is 
unfortunately under documented though. That being said, I would really 
recommend reading the source if possible, as it manages to do a lot in a 
really astoundingly little amount of code (the core logic that drives 
everything is a 7-line function). Specifically this 
https://github.com/mromyers/infix-syntax/tree/master/infix-syntax/private/core 
.


Anyhow, regardless of the exact approach chosen, there are a couple of 
issues I forsee with trying to integrate honu-like features into racket-X. 
These aren't meant to be objections, just things that need to be worked on.

The most trivial one is that define-primitive-splicing-syntax-class 

 
really should graduate out of experimental, since Honu depends really 
crucially on it for its nice integration with syntax-parse. While this 
function hasn't changed in years, the fact that it's in experimental does 
speak to some uncertainty about the interface it provides, which should be 
addressed one way or another. I do dislike the interface slightly, as 
requiring the number of items consumed is slightly awkward in Honu's case, 
introducing a slight inefficiency in redundantly needing to traverse the 
same input list a couple of times, but that's a minor annoyance at worst.

A more general problem is one of style. In racket currently, it seems to be 
encouraged to define keywords in a macro (using ~literal instead of 
~datum), as in 'else' for cond. This has the nice result of allowing you to 
rename keywords. Unfortunately, this introduces a couple headaches in 
something like Honu, which ends up making some things less flexible.

As an example, suppose you have the C ternary operator 'x ? y : z' . If you 
define : as a keyword, either everyone else that uses : as a keyword, like 
a list comprehension macro, will need to use the same one, or you can't use 
both simultaneously. In the best case scenario, : is defined either in 
core, or in a very central library, so most macros that use : as a keyword 
will use the same one. However, if someone later wants to define a : 
operator in a non-core library, using it will break every macro that uses : 
, since it's not the ~literal they're looking for.

The same problem exists for normal macros of course, but in practice it's 
not as much of a problem, because for one there just aren't that many of 
them, since #:keywords fill most of their role. No one seems to grumble for 
instance about the fact that their lovely 'else' function silently breaks 
all of their cond expressions. For operators however, you're usually 
drawing from a much smaller set, and so collisions are a bit more painful. 
Naturally, the solution is to just match : as a datum when it's used as a 
keyword, though this does prevent renaming the keyword if someone should 
wish. Still, I think as a matter of style and convention it's worth 
thinking about good rules of thumb and best practices for deciding when to 
define a keyword literal, and when to just use a datum.

This also ties into one of the other major sore points surrounding scope 
and collision. In languages like haskell and sml, one can 'upgrade' an 
already defined function to an operator with infixr / infixl statements. 
These are fairly convenient to work with, but it's hard to get something 
similar working in Racket, and would require greatly complicating how 
parsing works. The status quo is, if you want to define a new + function, 
one needs to do something like either:
(require (rename-in racket/base [+ add]))
(define-id-operator + add #:left- assoc #:prec 3)

or define the operator as add and use rename-out.

Now, you might not see this as too much of a hassle, but it does add a bit 
of mental overhead and room for user error compared to just, say, 
(declare-infixl + #:left-assoc #:prec 3)
The most natural way to implement something like the latter would be 
something like chez scheme's define-property, so this would be very nice to 
have if at all possible. It does require 

Re: [racket-users] web develpment

[Neil Van Dyke]

Job H wrote on 7/21/19 1:46 PM:

hello friends,

how do you generate the frontend of a website with Racket?


There are many ways.  You might want to start with a tutorial on one way 
-- "https://docs.racket-lang.org/continue/index.html"; -- and then decide 
what you like and don't like about that, and then go from there.


Quick comments on some of my Web frontend/fullstack work in Racket...

I have some complicated Racket Web projects in production that, for 
historical reasons, use SCGI 
("https://www.neilvandyke.org/racket/scgi/";), and they generate HTML of 
various kinds (including a full HTML5 Offline app that pushes some 
limits) using something similar to 
"https://www.neilvandyke.org/racket/html-writing/"; as well as generating 
JS, using handwritten CSS and JS, and using some off-the-shelf JS 
toolkits, and then uses JSON-based and other kinds of Web services 
implemented in Racket for when the app is online.


That HTML of that HTML5 Offline app is actually generated and updated 
(and cached in the usual HTML5 Offline way) automatically, and can 
change dramatically, during running of the server, based on some changes 
in "meta" schema (for a typically large and complicated data model) that 
can change dynamically.  (Which is not something that many frameworks 
can handle, but it was doable in Racket, because we understand and 
control the Web stack, and can make it do what we want, and apparently 
with a dramatically smaller amount of human resources than such a 
product would normally take.)  Also, certain handheld companies that 
like controlling app stores seemed to have mixed feelings about how well 
they want W3C standards for more Web-ish apps to work, but, with the 
power of Racket and way too much JS wrangling and polyfilling, we made 
it work. :)


On the side, I have an unreleased Web site software in Racket, for 
incrementally publishing a series of topical book chapters as more like 
blog posts, with a kind of table of contents navigation in addition to 
the temporal one.  It uses a bit of an inline DSL that translates to 
SXML for `html-writing`.  It also uses the ancient 
"https://www.neilvandyke.org/racket/uri-old/"; (because I wanted 
anti-resolve for the framework, and didn't want to get distracted by 
rethiking the URI library like I really want to).  The HTML and CSS are 
designed carefully, to work on both desktop and handheld, for reading 
long-ish form text, and no off-the-shelf frameworks that time.


I've also used the `html-template` package for small static HTML 
generation tasks, though the intention was to use it for just-in-time 
HTML serving, and to have site-specific structural/semantics macros 
layered on it (at the cost of losing some of the dynamic flexibility of 
the `html-writing` approach): 
https://www.neilvandyke.org/racket/html-template/


Of course these can work with most off-the-shelf slick frontend 
frameworks, as well, with Racket code generating some of the input to 
those frameworks, or simply doing Webservice backend.


There are a lot of other valid ways to do Web frontends in Racket, and 
I'll let the people with experience in those talk about them.


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/f13dbb2d-3f1e-9d86-8fe0-578dc01a1eba%40neilvandyke.org.

[racket-users] web develpment

[Job H]

hello friends,

how do you generate the frontend of a website with Racket?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/1d60ab19-8956-4323-9880-7413f60cdc3f%40googlegroups.com.

Re: [racket-users] Racket2 possibilities

[Jay McCarthy]

On Sun, Jul 21, 2019 at 1:12 PM Alexis King  wrote:
> It is easy to foresee a transition away from s-expressions as a restriction 
> on what can be expressed via macros, mostly since non-s-expression languages 
> with macro systems (such as Haskell and Elixir, to name just two) usually 
> impose such restrictions. But that is what is so remarkable about Honu: its 
> macros allow what is really a superset of Racket’s current syntactic 
> flexibility. I think the paper has a good explanation of why this is, I just 
> don’t think it points out the implications explicitly enough, so if this is a 
> surprise to you, go back and take another look.

This point by Alexis, IMHO, is the big reason for thinking about
Racket2 for me. The parenthesis notation of Racket is a restriction to
make certain things easy, but we now know a lot more than we did in
the past, so we can keep those things easy while removing the
restriction that keeps us from doing more interesting things.

Jay

--
Jay McCarthy
Associate Professor @ CS @ UMass Lowell
http://jeapostrophe.github.io
Vincit qui se vincit.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CAJYbDamD75CtipY3TQLaNDsVAGq4Os8kziqzZqBT0ZjATiZTzg%40mail.gmail.com.

Re: [racket-users] Racket2 possibilities

[Alexis King]

> On Jul 21, 2019, at 00:19, Matthew Flatt  wrote:
> 
> I have in mind "Honu: Syntactic Extension for Algebraic Notation through 
> Enforestation", GPCE 2012. It shows how we can bridge the relatively linear 
> structure of non-() programs to the tree structure of S-expressions. 
> Specifically, the bridge is called "enforestation". It sits roughly between 
> the reader and the expander, but enforestation needs to be interleaved with 
> expansion to get the level of expressiveness that Racketeers would expect.

To add a few of my own thoughts on this: in light of recent events, I reread 
the Honu paper more closely this past week, and I would strongly encourage 
anyone who is invested in surface syntax to do the same. It is a beautiful 
paper. Crucially, it is beautiful not because it does anything complex but 
because it solves a hard problem in a simple, elegant way. If you have any 
misgivings about what might happen to the expressiveness of the macro system if 
we were to move away from s-expressions, it is required reading.

What the paper does not do is editorialize (as it shouldn’t), so I will do so 
myself. The techniques described in the Honu paper are dramatically superior to 
alternative approaches I have seen, for two reasons:

“Automatic parenthesis insertion” approaches like sweet, wisp, liso, etc. 
invariably demand users think about the desugared, parenthesized form. Macros 
are ultimately still defined by parsing syntax objects built from 
s-expressions, so every extra pair of parentheses suddenly matters, even if 
they’re invisible and no reasonable built-for-purpose syntax would care about 
them. This is a terrible experience, and it forever condemns these approaches 
to be second-class citizens.

Honu’s macros, in contrast, operate much closer to the concrete syntax, and 
they don’t require thinking about implementation details of the language. We 
demand our Racket macros be real abstractions, and Honu lets them stay that way.

It is easy to foresee a transition away from s-expressions as a restriction on 
what can be expressed via macros, mostly since non-s-expression languages with 
macro systems (such as Haskell and Elixir, to name just two) usually impose 
such restrictions. But that is what is so remarkable about Honu: its macros 
allow what is really a superset of Racket’s current syntactic flexibility. I 
think the paper has a good explanation of why this is, I just don’t think it 
points out the implications explicitly enough, so if this is a surprise to you, 
go back and take another look.

Of course, it’s not all roses. The existing Honu implementation lays sturdy 
foundations, but it doesn’t include a syntax/parse equivalent: there’s no 
Honu-native DSL for writing Honu macros. A lot of the ideas in syntax/parse 
should carry over, but there are more than a few new wrinkles to be ironed out. 
On top of that, there are open questions about everything from documentation to 
tooling to what the appropriate syntax for the base language ought to be.

I understand that many people in the Racket sphere are very fond of 
s-expressions for a variety of reasons, something that was made abundantly 
clear to me in the several dozen replies I got to a twitter comment I made on 
the matter.  I 
certainly can’t assuage all fears of losing them, but I sincerely hope that the 
second point I made above sinks in for others like it has for me: there are 
ways a change in syntax can be enabling, not simply a compromise for some 
non-specific “other people.” Wouldn’t it be wonderful if we could design new 
languages, embedded or otherwise, with whatever syntax we wish as easily as we 
can design them in Racket today using s-expressions? Going down this path has 
the potential to move us much closer to that reality, and I, for one, think 
that’s exciting.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/FE3BEE8D-4380-4540-B478-F0BB424A5C4E%40gmail.com.

Re: [racket-users] dogfood a simple structured discussion forum in racket

[Bogdan Popa]

In case someone sets out to do this, here are some things I have open
sourced (from my closed source projects) in the web space that may help:

  * koyo[1]: a general toolking built on top of web-server-lib that adds
many of the things you need in a real web application (CSRF, CORS,
database utils, flash messages, localization, profiling, sessions,
and others -- the documentation is still a little rough, but if
there is interest then I can spend some more time on improving it)

  * deta[2]: a library for mapping between database tables and Racket
structs

  * forms[3]: declarative web form (and JSON) validation -- different
from formlets in that validation and presentation are separate

  * north[4]: database migrations

  * marionette[5]: control Firefox programmatically; great for
end-to-end tests

  * postmark-client[6]: a client for https://postmarkapp.com

  * sentry[7]: runtime error reporting via https://sentry.io (they also
offer an open source variant of the software which the client will
work with just fine)

  * geoip[8]: geolocation using the MaxMind databases

And a couple that are a little more niche and may not apply here:

  * mobilpay[9]: a client for a popular credit card gateway in Romania

  * twilio[10]: a client for the https://twilio.com API

And some libraries I myself have found extremely helpful:

  * sql[11]: s-expression combinators for generating SQL

  * struct-plus-plus[12]: structs on steroids

  * gregor[13]: my personal favorite; a library for working with dates
and times


[1]: https://koyo.defn.io/
[2]: https://deta.defn.io/
[3]: https://docs.racket-lang.org/forms/index.html
[4]: https://pkg-build.racket-lang.org/doc/north@north/index.html
[5]: https://docs.racket-lang.org/marionette/index.html
[6]: https://pkg-build.racket-lang.org/doc/postmark@postmark-client/index.html
[7]: https://pkg-build.racket-lang.org/doc/sentry@sentry-doc/index.html
[8]: https://docs.racket-lang.org/geoip/index.html
[9]: https://github.com/Bogdanp/mobilpay
[10]: https://github.com/Bogdanp/racket-twilio
[11]: https://pkg-build.racket-lang.org/doc/sql@sql/index.html
[12]: https://docs.racket-lang.org/struct-plus-plus/index.html
[13]: https://docs.racket-lang.org/gregor/index.html

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/m21ryjl602.fsf%40192.168.0.139.

[racket-users] Re: #lang something // infix, optionally indentation-sensitive experimental Racket syntax

[Tony Garnock-Jones]

On Sunday, July 21, 2019 at 3:57:56 PM UTC+1, Tony Garnock-Jones wrote:
>
> Recent threads have reminded me I never properly announced "#lang 
> something", an experiment from back in 2016. 
>

I forgot to mention I also made a recording of #lang something/shell in 
action back in 2016: https://asciinema.org/a/83450

Cheers,
  Tony

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/a86f3f0f-03fe-471b-a05c-004900089aba%40googlegroups.com.

[racket-users] dogfood a simple structured discussion forum in racket

[Neil Van Dyke]

If someone wants to do a useful and doable Web application in Racket...

You could make threaded discussion Web forum (or email) software.

(Implementation suggestions... Use Racket `db` interface, and deploy in 
PostgreSQL by default.  Consider storing each threaded comment in its 
own row (with IDs for things like parent comment), and keeping a cache 
representation of each threaded topic as a blob in a separate 
table/memory/file, so save you from some nasty querying every time you 
want to show someone the topic.  The cache for each topic can be 
s-expression/objects (which lets you someday apply user-specific 
personalization on the server before sending), HTML that's later pasted 
into a page (traditional), or (less-traditional-Web-friendly, but 
more-Webservice-friendly) JSON that's then turned into DOM/HTML by JS on 
the client.  You might have multiple caches per topic, such as for 
different sorting criteria, if that's a thing.)


After the basic threaded Web forum is done, you can make an email 
gateway/notifications for it, and/or RSS/Atom, to keep people engaged 
rather than them having to keep monitoring and going to a Web site.


There's also a dogfooding aspect.  A basic threaded Web forum should be 
able to be doable enough in Racket to be suitable for a book example 
project, and maybe a tutorial.


An alternative to the above would be to reverse the priorities, and the 
order in which you build it: make a discussion email server that mirrors 
to a Web archive/reader (and maybe the Web archive permits posting 
comments).


Bonus: Racketeers will get warm-fuzzies from using something homegrown 
in Racket (compared to feverish indigestion, from having to use certain 
other things).


--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/6f364c1b-c153-3d53-f092-c09f1b1fe574%40neilvandyke.org.

[racket-users] #lang something // infix, optionally indentation-sensitive experimental Racket syntax

[Tony Garnock-Jones]

Hi everyone,

Recent threads have reminded me I never properly announced "#lang
something", an experiment from back in 2016.

The main idea is S-expressions, but with usually-implicit parentheses
and support for prefix/infix/postfix operators. Indentation for grouping
is explicitly represented in the S-expression returned from the reader.

  + keeps a semi-structured input format: reader yields ordinary syntax
  + macros Just Work
  + you can do "if ... then ... else ...": [1]
  + you can do "... where ...": [2]
  - uses indentation (though it doesn't have to; see for example [3])
  - the function syntax isn't `function(arg, ...)`

[1]
https://github.com/tonyg/racket-something/blob/4a00a9a6d3f5aab4f28b03c53555b87e21d7/examples/if-then-else.rkt
[2]
https://github.com/tonyg/racket-something/blob/4a00a9a6d3f5aab4f28b03c53555b87e21d7/examples/where.rkt
[3]
https://github.com/tonyg/racket-something/blob/4a00a9a6d3f5aab4f28b03c53555b87e21d7/src/something/shell2.rkt

(More links at the bottom of this message)

In addition to the reader, `#lang something` provides a small selection
of special forms that take advantage of the new syntax, and `#lang
something/shell` adds Unix-shell-like behaviour and a few associated
utilities.

This program:

#lang something
for { x: 1 .. 10 }
  def y: x + 1
  printf "x ~a y ~a\n" x y

... reads as this S-expression:

(module something-module something/base
  (#%rewrite-body
   (for (block (x (block (1 .. 10
(block (def y (block (x + 1)))
   (printf "x ~a y ~a\n" x y)

The `#%rewrite-body` macro, together with its companion
`#%rewrite-infix`, consults an operator table, extendable via the
`def-operator` macro, to rewrite infix syntax into standard prefix
S-expressions.

The `block` syntax has many different interpretations. It has a macro
binding that turns it into a Racket `match-lambda*`, and it is used as
literal syntax as input to other macro definitions.

For example, here's one possible implementation of that `for` syntax:

#lang something

provide
  for

require
  for-syntax something/base
  prefix-in base_ racket/base

def-syntax for stx
  syntax-case stx (block)
_ (block (v (block exp)) ...) (block body ...)
  (syntax (base_for ((v exp) ...) body ...))

def-operator .. 10 nonassoc in-range

Notice how the `block` S-expressions are rewritten into a normal
S-expression compatible with the underlying `for` from `racket/base`.

Generally, all of these forms are equivalent

x y z  x y z:  x y z { a; b }
  a  a
  b  b

and they are read as

(x y z (block a b))

and are then made available to the normal macro-expansion process (which
involves a new infix-rewriting semi-phase).

Colons are optional to indicate a following suite at the end of an
indentation-sensitive line. Indentation-sensitivity is disabled inside
parentheses. If inside a parenthesised expression,
indentation-sensitivity can be reenabled with a colon at the end of a line:

a b (c d:
  e
  f)

= (a b (c d (block e f)))

a b (c d
  e
  f)

= (a b (c d e f))

Conversely, long lines may be split up and logically continued over
subsequent physical lines with a trailing `\`:

a b c \
  d \
  e

= (a b c d e)

Semicolons may also appear in vertically-laid-out suites; these two are
equivalent:

x y z
  a
  b; c
  d

x y z { a; b; c; d }

Suites may begin on the same line as their colon. Any indented
subsequent lines become children of the portion after the colon, rather
than the portion before.

This example:

x y z: a b
  c d
  e

reads as

(x y z (block (a b (block (c d) e

Square brackets are syntactic sugar for a `#%seq` macro:

[a; b; c; d e f]→(#%seq a b c (d e f))

[   →(#%seq a (b (block c)) (d e f))
  a
  b
c
  d e f
]

Forms starting with `block` in expression context expand into
`match-lambda*` like this:

{
  pat1a pat1b
exp1a
exp1b
  pat2a
exp2
}

→ (match-lambda*
[(list pat1a pat1b) exp1a exp1b]
[(list pat2a) exp2])

The `map*` function exported from `something/lang/implicit` differs from
`map` in `racket/base` in that it takes its arguments in the opposite
order, permitting maps to be written

map* [1; 2; 3; 4]
  item:
item + 1

map* [1; 2; 3; 4]
  item: item + 1

map* [1; 2; 3; 4]: item: item + 1

map* [1; 2; 3; 4] { item: item + 1 }

A nice consequence of all of the above is that curried functions have an
interesting appearance:

def curried x:: y:: z:
  [x; y; z]

require rackunit
check-equal? (((curried 1) 2) 3) [1; 2; 3]

Anyway, thought it worth mentioning.

A few more links:

 - The repository: https://github.com/tonyg/racket-something

 - Imple

Re: [racket-users] Racket2 possibilities

[Hendrik Boom]

On Sat, Jul 20, 2019 at 08:53:17PM -0700, Andrew Gwozdziewycz wrote:
> 
> I'm in favor of a different syntax if it doesn't add new semantics
> along with it. I'm also in favor of an s-expression based syntax that
> uses less parens all together. In other words, I think a way to
> proceed might be to have syntax be actually surface, and completely
> inter-changeable, such that if I prefer s-expressions, Dr Racket
> allows me to edit that way. If I prefer an infix representation, Dr
> Racket can read the s-expressions and convert it to infix, and convert
> it back on save (Or the other way around depending on the code base
> preferences).

Scribble is an example of how two syntaxes can coexist in one source file.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20190721134310.r275b7qt2vji3igl%40topoi.pooq.com.

Re: [racket-users] Racket2 possibilities: Honu

[Hendrik Boom]

On Sat, Jul 20, 2019 at 06:07:40PM -0400, Christopher Lemmer Webber wrote:
> Hi Matthew,
> 
> As someone who (unintentionally) caused maybe some of the debate to get
> out of hand (or did I?) I would like to open by saying that both your
> last email to the prior thread and also this email are both very
> encouraging.
> 
> I'll skip everything else and jump straight to:
> 
> Matthew Flatt writes:
> 
> > How to Proceed
> > --
> >
> > Ideally, we would first decide on whether we want to try changing
> > surface syntax ever. Then, only if we have enough consensus that it's
> > worth a try, we could move on to setting overall goals and picking a
> > roadmap. Finally, if the planing of the roadmap succeeds, we could
> > follow it while getting into the details.
> >
> > Unfortunately, it doesn't work like that. We need concrete examples to
> > discuss the possibility of changing syntax, potential roadmaps to see
> > whether there's anywhere we want to go, and so on. Some of the
> > discussion will necessarily put a cart before a horse. Delving into
> > some details may incorrectly give the impression that prerequisites
> > are a foregone conclusion. We've seen all of that already, starting
> > with my attempt to open up the discussion in the middle of RacketCon
> > and probably continuing with this message. Perhaps we can just accept
> > that this is all okay in the spirit of working together.
> >
> > I originally thought that we should have a more specific process in
> > place for discussion at this point, but I think I've been proved
> > wrong. Let's just discuss, for now. I'll be posting more myself.
> 
> For the sake of discussion, maybe it's easiest to just assume "Racket
> attempts a move to a Honu derivative" as its surface syntax, which I'll
> call ~Honu for now.  (I'm not saying that we know that will happen, I
> just think it's a good place to start discussing.)  As you have already
> said, this will not prevent the existance of "#lang racket" keeping the
> syntax many in the community (including myself) already love.
> 
> As you said, changing the surface syntax is high-risk, possibly
> high-reward.  I agree with that, though I think Racket is uniquely
> positioned to lower the risk dramatically *because* of the #lang
> infrastructure.  Is a "try it before we fully buy it" approach maybe
> possible?  Maybe, for one thing, this could reduce community anxiety
> and improve our chances to explore.
> 
> Here, maybe is a way it could be done:

I found a page about Honu here: https://docs.racket-lang.org/honu/index.html

It looks elegant.  But I'd have to try it out on some serious problem 
to see if it's as elegant as it looks. 

> 
>  - First, port the teaching languages and etc over to Honu.  Try
>teaching some classes with just-Honu syntax.  This is *before*
>trying to switch the "internals" of Racket over.

I'd start "porting" the main language over.  It's essential to get 
early experience with nontrivial use.

>  - Encourage a large portion of the community to try to write as many
>tools using ~Honu as possible.  How do people like it?  What can be
>improved?
>  - Begin switching the core docs over, maybe even as a fork.  It might
>be a pain to maintain two doc forks, but maybe it is worth it.
>I suspect that Scribble might even make the task easier, since
>autogenerating two manuals from mostly the same source might not
>be too hard.

You would wnt a fork, if only to keep the *large* collection of 
existing #lang racket users ans developers happy.

If you are careful in maintaining line-by-line integrity between Racket 
documentation and Honu documentation, you might not find it difficult 
to merge Racket documentation updates into the Honu documentation 
repository.

And you would want to be able to autogenerate *three* manuals:  a 
Racket manual, a Honu manual, and a manual for both together.  It's 
quite likely people will want to use the two together.

>  - Switch all the default examples on racket-lang.org over to ~Honu.
>  - Are people happy?  Is this meeting their needs?  Get community input.
>At this point, if the community is happy enough, and if it appears
>that *newcomers* (including in the educational space) are happy
>enough, now we can focus on switching the core Racket system over
>to ~Honu-as-the-basis.
> 
> What do you think?  This seems like a clean transition plan to me that
> also allows for us to test, readjust, and even allows us to "stage
> before we commit", which seems like a big win.
> 
> Thoughts?
>  - Chris

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/20190721133827.625ekvgc74aya5sy%40topoi.pooq.com.

Re: [racket-users] Racket2 possibilities

[Matthew Flatt]

At Sat, 20 Jul 2019 18:07:40 -0400, Christopher Lemmer Webber wrote:
> As you said, changing the surface syntax is high-risk, possibly
> high-reward.  I agree with that, though I think Racket is uniquely
> positioned to lower the risk dramatically *because* of the #lang
> infrastructure.  Is a "try it before we fully buy it" approach maybe
> possible?  Maybe, for one thing, this could reduce community anxiety
> and improve our chances to explore.
> 
> Here, maybe is a way it could be done:
> 
>  - First, port the teaching languages and etc over to Honu.  Try
>teaching some classes with just-Honu syntax.  This is *before*
>trying to switch the "internals" of Racket over.
>  - Encourage a large portion of the community to try to write as many
>tools using ~Honu as possible.  How do people like it?  What can be
>improved?
>  - Begin switching the core docs over, maybe even as a fork.  It might
>be a pain to maintain two doc forks, but maybe it is worth it.
>I suspect that Scribble might even make the task easier, since
>autogenerating two manuals from mostly the same source might not
>be too hard.
>  - Switch all the default examples on racket-lang.org over to ~Honu.
>  - Are people happy?  Is this meeting their needs?  Get community input.
>At this point, if the community is happy enough, and if it appears
>that *newcomers* (including in the educational space) are happy
>enough, now we can focus on switching the core Racket system over
>to ~Honu-as-the-basis.

I agree that the process would have to be something like that.

I'm skeptical of starting with teaching languages in the sense of BSL,
ISL, and ASL. That sets up some different problems --- ones that Pyret
has directly addressed/explored. (Obviously, we should pay attention to
Pyret.)

But a separate branch to try porting examples and modules and to
explore new documentation certainly makes sense at some point.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d3461aa.1c69fb81.a32b9.44c1SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2

[Matthew Flatt]

At Fri, 19 Jul 2019 08:54:41 -0700 (PDT), Brian Adkins wrote:
> This may seem like a nitpick, but I think there would be a *huge* shift in 
> attitudes if the suggestion for an infix syntax was framed in a similar 
> manner to Typed Racket as opposed to Racket 2. The latter seems to imply a 
> premature conclusion, where the former proposes a question to be answered 
> by the community i.e. if people do flock to #lang infix, then the people 
> will have spoken. Let #lang infix win by merit, not by decree!

I agree that the process would have to be something like that. Compared
to projects like Typed Racket, a syntax change in Racket2 probably
requires more people. Also, Typed Racket took on the design constraint
that it should fit Racket as-is as much as possible, while a syntax
change would come with more expectation of migration. It's maybe just a
difference of degree, though.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d34617a.1c69fb81.383c7.0155SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

Re: [racket-users] The case, and a proposal, for elegant syntax in #lang racket2

[Matthew Flatt]

At Tue, 16 Jul 2019 15:45:36 -0300, Gustavo Massaccesi wrote:
> Also, it would be nice to have a rough timeline. 5 years?

N years, anyway. 5 years seems like too long for a plan, although fine
as an actuality. I'd aim for 2 years and try to believe that, so maybe
it could actually happen in 3-4 years.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/5d346179.1c69fb81.ac125.4c66SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

Re: [racket-users] Re: Problem with `copy` method of image-snip%

[Robby Findler]

Maybe because get-extent in the super class vaches some information and
that cache doesn't get maintained if you override the method.

Robby

On Sun, Jul 21, 2019 at 12:09 PM Alex Harsanyi 
wrote:

>
> I am not entirely sure why (because I already spent more than 15 minutes
> on this :-) ), but the problem is with the `get-extent` method: just remove
> it, and let `image-snip%` handle the method.
>
> The `copy` method is not used in this case.
>
> Also, in your `on-char` and `on-event` methods, you might want to pass
> back any un-handled events back to the editor's `on-default-event` and
> `on-default-char` methods, otherwise, you will notice that the editor stops
> responding to some events since your code discards them.
>
> Alex.
>
> On Tuesday, July 16, 2019 at 11:01:41 PM UTC+8, Kshitij Sachan wrote:
>>
>> Update:
>>
>> I've narrowed down the problem to the `copy` method of the snip. When I
>> delete the copy method, I can see the snip perfectly, but it can't be
>> resized (because no copy method implemented).
>>
>> I removed the GL component, so now I'm only attempting to extend the
>> image-snip% class to resize a custom bitmap I load in (in my case just a
>> plain red circle I drew). When I highlight over the snip with my cursor, I
>> can see the bitmap below and it is resizing as well on a click (using
>> `set-bitmap`). However, if I don't highlight over the snip it appears plain
>> white.
>>
>> Another observations that may or may not help is:
>> Calling (send s get-bitmap) always returns the bitmap of the same size,
>> even if I've pressed on the snip several times to resize it.
>>
>> Here's the simplified code:
>> (require racket/gui
>>  racket/gui/base)
>>
>> ;; bitmap stuff
>> (define bits (make-bitmap 250 250))
>> (define bits-dc (new bitmap-dc% [bitmap bits]))
>> (send bits-dc set-brush "red" 'solid)
>> (send bits-dc set-pen "black" 3 'solid)
>> (send bits-dc draw-ellipse 1 1 248 248)
>>
>> (define snip (make-object image-snip% bits))
>>
>> ;; snip stuff
>> (define scroll-snip%
>>   (class image-snip%
>> (init bit-init)
>> (define snip-bitmap bit-init)
>> (inherit/super get-admin set-flags set-bitmap)
>> (init-field [w 100] [h 100])
>>
>> (super-make-object snip-bitmap)
>> (set-flags (list 'handles-events))
>>
>> (define/override (get-extent dc x y width height descent space lspace
>> rspace)
>>   (define (maybe-set-box! b v) (when b (set-box! b v)))
>>   (maybe-set-box! width w)
>>   (maybe-set-box! height h)
>>   (maybe-set-box! descent 1.0)
>>   (maybe-set-box! space 1.0)
>>   (maybe-set-box! lspace 1.0)
>>   (maybe-set-box! rspace 1.0))
>>
>> (define/override (on-char dc x y editorx editory event)
>>   (cond
>> [(equal? (send event get-key-code) 'down)
>>  (define admin (get-admin))
>>  (set! w (+ w 20))
>>  (set! h (+ h 20))
>>
>>  ;; brush/pen/draw ellipse
>>  (define new-bits (make-object bitmap% w h))
>>  (send bits-dc set-bitmap new-bits)
>>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>>  (set! snip-bitmap new-bits)
>>
>>  (when admin
>>(send admin resized this #t))]
>> [(equal? (send event get-key-code) 'up)
>>  (define admin (get-admin))
>>  (set! w (- w 20))
>>  (set! h (- h 20))
>>
>>  ;; brush/pen/draw ellipse
>>  (define new-bits (make-object bitmap% w h))
>>  (send bits-dc set-bitmap new-bits)
>>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>>  (super set-bitmap new-bits)
>>
>>  (when admin
>>(send admin resized this #t))]
>> [(equal? (send event get-key-code) 'escape)
>>  (define admin (get-admin))
>>  (set! w 150)
>>  (set! h 150)
>>
>>  ;; brush/pen/draw ellipse
>>  (define new-bits (make-object bitmap% w h))
>>  (send bits-dc set-bitmap new-bits)
>>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>>  (super set-bitmap new-bits)
>>
>>  (when admin
>>(send admin resized this #t))]))
>>
>> (define/override (on-event dc x y editorx editory event)
>>   (cond
>> [(send event button-down?)
>>  (define admin (get-admin))
>>  (set! w (+ w 20))
>>  (set! h (+ h 20))
>>
>>  ;; brush/pen/draw ellipse
>>  (define new-bits (make-object bitmap% w h))
>>  (send bits-dc set-bitmap new-bits)
>>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>>  (super set-bitmap new-bits)
>>
>>  (when admin
>>(send admin resized this #t))]))
>>
>> (define/override (draw dc x y left top right bottom dx dy draw-caret)
>>   ;; brush/pen/draw ellipse
>>   ;(define new-bits (make-object bitmap% w h))
>>   ;(send bits-dc set-bitmap new-bits)
>>   ;(send bits-dc draw-ellipse x y (- w 2) (- h 2))
>>   ;(set! snip-bitmap new-bits)
>>  

[racket-users] Re: Problem with `copy` method of image-snip%

[Alex Harsanyi]

I am not entirely sure why (because I already spent more than 15 minutes on 
this :-) ), but the problem is with the `get-extent` method: just remove 
it, and let `image-snip%` handle the method.

The `copy` method is not used in this case.

Also, in your `on-char` and `on-event` methods, you might want to pass back 
any un-handled events back to the editor's `on-default-event` and 
`on-default-char` methods, otherwise, you will notice that the editor stops 
responding to some events since your code discards them.

Alex.

On Tuesday, July 16, 2019 at 11:01:41 PM UTC+8, Kshitij Sachan wrote:
>
> Update:
>
> I've narrowed down the problem to the `copy` method of the snip. When I 
> delete the copy method, I can see the snip perfectly, but it can't be 
> resized (because no copy method implemented).
>
> I removed the GL component, so now I'm only attempting to extend the 
> image-snip% class to resize a custom bitmap I load in (in my case just a 
> plain red circle I drew). When I highlight over the snip with my cursor, I 
> can see the bitmap below and it is resizing as well on a click (using 
> `set-bitmap`). However, if I don't highlight over the snip it appears plain 
> white.
>
> Another observations that may or may not help is:
> Calling (send s get-bitmap) always returns the bitmap of the same size, 
> even if I've pressed on the snip several times to resize it.
>
> Here's the simplified code:
> (require racket/gui
>  racket/gui/base)
>
> ;; bitmap stuff
> (define bits (make-bitmap 250 250))
> (define bits-dc (new bitmap-dc% [bitmap bits]))
> (send bits-dc set-brush "red" 'solid)
> (send bits-dc set-pen "black" 3 'solid)
> (send bits-dc draw-ellipse 1 1 248 248)
>
> (define snip (make-object image-snip% bits))
>
> ;; snip stuff
> (define scroll-snip%
>   (class image-snip%
> (init bit-init)
> (define snip-bitmap bit-init)
> (inherit/super get-admin set-flags set-bitmap)
> (init-field [w 100] [h 100])
> 
> (super-make-object snip-bitmap)
> (set-flags (list 'handles-events))
> 
> (define/override (get-extent dc x y width height descent space lspace 
> rspace)
>   (define (maybe-set-box! b v) (when b (set-box! b v)))
>   (maybe-set-box! width w)
>   (maybe-set-box! height h)
>   (maybe-set-box! descent 1.0)
>   (maybe-set-box! space 1.0)
>   (maybe-set-box! lspace 1.0)
>   (maybe-set-box! rspace 1.0))
>
> (define/override (on-char dc x y editorx editory event)
>   (cond
> [(equal? (send event get-key-code) 'down)
>  (define admin (get-admin))
>  (set! w (+ w 20))
>  (set! h (+ h 20))
>
>  ;; brush/pen/draw ellipse
>  (define new-bits (make-object bitmap% w h))
>  (send bits-dc set-bitmap new-bits)
>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>  (set! snip-bitmap new-bits)
>  
>  (when admin
>(send admin resized this #t))]
> [(equal? (send event get-key-code) 'up)
>  (define admin (get-admin))
>  (set! w (- w 20))
>  (set! h (- h 20))
>
>  ;; brush/pen/draw ellipse
>  (define new-bits (make-object bitmap% w h))
>  (send bits-dc set-bitmap new-bits)
>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>  (super set-bitmap new-bits)
>  
>  (when admin
>(send admin resized this #t))]
> [(equal? (send event get-key-code) 'escape)
>  (define admin (get-admin))
>  (set! w 150)
>  (set! h 150)
>
>  ;; brush/pen/draw ellipse
>  (define new-bits (make-object bitmap% w h))
>  (send bits-dc set-bitmap new-bits)
>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>  (super set-bitmap new-bits)
>  
>  (when admin
>(send admin resized this #t))]))
>
> (define/override (on-event dc x y editorx editory event)
>   (cond
> [(send event button-down?)
>  (define admin (get-admin))
>  (set! w (+ w 20))
>  (set! h (+ h 20))
>
>  ;; brush/pen/draw ellipse
>  (define new-bits (make-object bitmap% w h))
>  (send bits-dc set-bitmap new-bits)
>  (send bits-dc draw-ellipse x y (- w 2) (- h 2))
>  (super set-bitmap new-bits)
>  
>  (when admin
>(send admin resized this #t))]))
>
> (define/override (draw dc x y left top right bottom dx dy draw-caret)
>   ;; brush/pen/draw ellipse
>   ;(define new-bits (make-object bitmap% w h))
>   ;(send bits-dc set-bitmap new-bits)
>   ;(send bits-dc draw-ellipse x y (- w 2) (- h 2))
>   ;(set! snip-bitmap new-bits)
>   (super draw dc x y left top right bottom dx dy draw-caret))
>
> (define/override (copy)
>   (make-object scroll-snip% snip-bitmap))
> ))
>
> (define s (make-object scroll-snip% bits))
> s
>
> I believe there must be a problem with the default implementation of th