Re: [racket-users] typed racket backend/ir & gpu computing
Neil, what you’re looking for are — Stephen Chang’s Turnstile — Michael Ballantyne’s core language projects. The first one is an alternative way to add types to an eDSL. You can get all the type information you need and you can perform all the static checking you want. The second one is aimed at providing a comprehensive framework for elaborating a complete eDSL (that also benefits from Racket’s extensibility) into a language that doesn’t have Racket’s semantics (and may even be shipped to a totally different backend). Both are research products, the second much more so than the first. Both can benefit from feedback by someone who’s willing to play and invest time. — Matthias > On Dec 17, 2018, at 2:17 PM, Sam Tobin-Hochstadt wrote: > > Typed Racket does not have an IR in the sense you describe, and the > Typed Racket internals are not exposed in a way that's intended for > general consumption. More generally, I think Typed Racket's type > system is not likely to be a good fit for GPU computation. > > If you want to give it a try, though, you should take a look at the > Typed Racket optimizer, and see if the type information there is what > you are looking for. You might start by looking at: > https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/optimizer/fixnum.rkt > which has optimizations on Fixnums. > > Sam > On Sun, Dec 16, 2018 at 1:40 AM Neil Van Dyke wrote: >> >> Is there a specified/stable Typed Racket intermediate representation >> that has all the type info resolved, and which separate projects could >> build upon, for other target backends or analysis? >> >> Reason for asking... >> >> I was idly thinking of various ways to do GPU/TPU "supercomputing" from >> a normal Racket program, or to specify GPU bits in a Racket-ish source >> language. >> >> One general way involves compiling a normal Racket/-ish program to both >> Racket VM and (at least some of the procedures or closures, or parts of >> same) to a language/IR like for OpenCL (or one of the other >> existing/emerging ones). From there, even a simple implementation might >> be able to do things like automatically run a chunk/extent of algorithm >> on the GPU, when a static/dynamic heuristic suggests that the overhead >> of going to GPU is worthwhile. >> >> Having very little time for this weekend side project, and not wanting >> to spend it reimplementing type inferencing or annotation... Is there a >> specified/stable IR of Typed Racket that would be easy to work with for >> this? (Or would it be easier to do something simple from scratch in >> Racket (like a syntax transformation-heavy `#lang`), or to try to adapt >> the Pre-Scheme C target for this purpose?) >> >> (I'm aware we could write numerical bits in, say, a C-like OpenCL >> language, and then do Racket FFI of the OpenCL API to run the GPU bits >> from our program otherwise coded in Racket. I'm more interested in the >> problem of ways of compiling a Racket-ish language to run on the GPU.) >> >> (Motivation: I have a new GPU computer toy, >> "https://www.neilvandyke.org/machine-learning/";, and, while some of my >> old Racket packages are still great for scraping/importing data for >> what's now called "data science", I then have to switch over to various >> growing stacks of software tools in other languages. Top-down, I could >> write wrappers to use some of those other tools from Racket. But I >> wonder whether there are opportunities being missed, from a potential >> Racket bottom-up, while most people are busy with the big ML/stats >> toolkits and the algorithmic languages that are currently popular in >> data science. Also, there is only so much Jupyter Notebook in a Web >> browser that a person can take, before they want to also understand more >> about the new metal. :) >> >> -- >> 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. >> For more options, visit https://groups.google.com/d/optout. > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are contracts incompatible with Typed Racket?
Thanks for providing a definitive answer to my question, Sam. I'm glad to see integrating the two is an active goal. Best of luck! On Monday, December 17, 2018 at 6:45:03 AM UTC-9, Sam Tobin-Hochstadt wrote: > > Hi Jake, > > Unfortunately, Typed Racket doesn't currently support the contract > library. We've made a bunch of progress on integrating them, but that > work is still (slowly) ongoing here: > https://github.com/racket/typed-racket/pull/420. > > Depending on what you're looking for, refinement types may be able to > support some of the use cases you have. > > Sam > On Sat, Dec 15, 2018 at 5:24 PM > > wrote: > > > > I recently started learning Racket and quickly switched to Typed Racket. > For the most part I've been very happy with it, but I'm unclear on whether > it's possible to create contracts in Typed Racket (for expressing > constraints other than type requirements). I've been unable to find an > explicit answer to my question in the docs for either contracts or Typed > Racket, but I've run several experiments and it seems that contracts are > incompatible with Typed Racket. This discussion seems to support my > conclusion. > > > > If you can't create your own contracts in Typed Racket, are you meant to > limit all of your contract-related needs to type requirements? Or just use > vanilla Racket if you need a full-fledged contract system? Additionally, > could someone point me to the documentation that would have answered by > question (if it exists)? > > > > 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...@googlegroups.com . > > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] typed racket backend/ir & gpu computing
Typed Racket does not have an IR in the sense you describe, and the Typed Racket internals are not exposed in a way that's intended for general consumption. More generally, I think Typed Racket's type system is not likely to be a good fit for GPU computation. If you want to give it a try, though, you should take a look at the Typed Racket optimizer, and see if the type information there is what you are looking for. You might start by looking at: https://github.com/racket/typed-racket/blob/master/typed-racket-lib/typed-racket/optimizer/fixnum.rkt which has optimizations on Fixnums. Sam On Sun, Dec 16, 2018 at 1:40 AM Neil Van Dyke wrote: > > Is there a specified/stable Typed Racket intermediate representation > that has all the type info resolved, and which separate projects could > build upon, for other target backends or analysis? > > Reason for asking... > > I was idly thinking of various ways to do GPU/TPU "supercomputing" from > a normal Racket program, or to specify GPU bits in a Racket-ish source > language. > > One general way involves compiling a normal Racket/-ish program to both > Racket VM and (at least some of the procedures or closures, or parts of > same) to a language/IR like for OpenCL (or one of the other > existing/emerging ones). From there, even a simple implementation might > be able to do things like automatically run a chunk/extent of algorithm > on the GPU, when a static/dynamic heuristic suggests that the overhead > of going to GPU is worthwhile. > > Having very little time for this weekend side project, and not wanting > to spend it reimplementing type inferencing or annotation... Is there a > specified/stable IR of Typed Racket that would be easy to work with for > this? (Or would it be easier to do something simple from scratch in > Racket (like a syntax transformation-heavy `#lang`), or to try to adapt > the Pre-Scheme C target for this purpose?) > > (I'm aware we could write numerical bits in, say, a C-like OpenCL > language, and then do Racket FFI of the OpenCL API to run the GPU bits > from our program otherwise coded in Racket. I'm more interested in the > problem of ways of compiling a Racket-ish language to run on the GPU.) > > (Motivation: I have a new GPU computer toy, > "https://www.neilvandyke.org/machine-learning/";, and, while some of my > old Racket packages are still great for scraping/importing data for > what's now called "data science", I then have to switch over to various > growing stacks of software tools in other languages. Top-down, I could > write wrappers to use some of those other tools from Racket. But I > wonder whether there are opportunities being missed, from a potential > Racket bottom-up, while most people are busy with the big ML/stats > toolkits and the algorithmic languages that are currently popular in > data science. Also, there is only so much Jupyter Notebook in a Web > browser that a person can take, before they want to also understand more > about the new metal. :) > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] hackernews
On Mon, Dec 17, 2018 at 06:11:09AM -0800, Jérôme Martin wrote: > I'm also occasionally writing posts about Racket on my blog. Only one is > public for now, and is a multi-parts tutorial about writing DSLs in Racket. > > I'm trying to summarize and reformulate some of the things I learned by > making small languages in Racket. If you already read Beautiful Racket, I > guess there's nothing new to learn, because I'm mostly targeting developers > not aware of lisp languages. > > You can find the first part here: > http://rilouw.eu/article/the-programming-language-of-your-dreams-part-1 > Feel free to contact me if you want to share some advice and feedback! Definitely not ready yet. You've written a start to an exposition on how write a #lang module, and actually showed how to do it in an incremental way, testing and checking what you do while you do it. An exposition I'd very much like to read the rest of. I too have racket tweaks I'd like to implement. (1) You start out with an imaginary UI language (which hapens to look like XML; I noticed that!) and you seem to indicate that you're going to show how Racket can choke that down. (2) But all you do is show how you can, via your (incomplete) ui-lang.rkt module, get Racket to behave like Racket. This isn't likely to impress. Since I already know about Racket and appreciate it, I can appreciate what you've accomplished, and how this is a reasonable base for further development. But the non-Racket-initiate isn't going to get that. And he's likely not to get around to episode #2 of your exposition. (3) In the end, you present a different language from the one at the beginning -- something that's not XML. It might have been better not even to mention the XML version at the start, but instead mention the one you are actually going to implement. XML, for the reader you are targetting, is old-hat anyway. I'm not at all sure how to rewrite this in a style that is likely to grab and maintain the interest of the reader you are aiming for. Writing is *hard*. Maybe you need to use the textual freedom the web gives you and, early on, have links to the actual implementation details. Or mention the translation of this special-purpose language is. Or how it's executed. Or what the menus look like (a screen-shot, maybe?) Anywaay, I'd like to see the rest of what you're doing. Perhaps just email me the actual implementation code so I can look it over before you rewrite your short series of article. I'll be happy to provide prepublication critique of what you write -- what works for me, what doesn't work, and what I do and don't think will work for the intended audience. -- hendrik > > I'm not confident the article is worth a post on HN for now, and I don't > know if my Racket server will sustain a mention on HN anyway, but if you > feel it's worth posting, feel free to do so. > > On Monday, December 17, 2018 at 2:30:55 AM UTC+1, Alex Harsanyi wrote: > > > > > > > > On Sunday, December 16, 2018 at 12:48:09 AM UTC+8, Peter Schmiedeskamp > > wrote: > >> > >> I’m probably guilty of already being part of this task-force. To add, I > >> wonder if there’d be value in some longer, blog-form replies to > >> interesting > >> HackerNews queries. > >> > >> For example, someone was extolling the virtues of some new system for > >> building and packaging simple GUI apps for Linux using Python. I’ve poked > >> around with the GUI and packaging facilities of Racket enough to feel like > >> Racket has a pretty good story to tell, at least for smaller > >> cross-platform > >> apps. A short blog showing the end-to-end creation of a small GUI app, > >> with > >> emphasis on showing the symbiosis of the GUI library and the excellent > >> raco > >> packaging and distribution facilities would be a great “reply” to such an > >> article on HN. > > > > > >> I wonder if there's a way that these use cases could at least be > >> collected... maybe as an RFB—Request For Blog. Time is always at a > >> premium, > >> but I could imagine picking off a blog post here and there even though I’m > >> a decidedly rank novice Racketeer. > >> > >> Maybe there’s already a list somewhere? Maybe RFBs could be a section of > >> the Racket Blog? > >> > > > > > > I have written a few blog posts on Racket GUI topics and I have a few more > > planned. They cover some more advanced uses of the GUI library -- I think > > the basics are already well documented. You can find them here: > > > >https://alex-hhh.github.io/tags/racket.html > > > > Alex. > > > > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket
Re: [racket-users] Reasons not to use match or define/match?
On Mon, Dec 17, 2018 at 11:53 AM Jack Rosenthal wrote: > > On Mon, 17 Dec 2018 at 07:58 -0800, Will Jukes wrote: > > After learning more Haskell I've been playing around with match and > > define/match, and I'm wondering if there's any particular reason to > > prefer more traditional Scheme forms over match (I vastly prefer match > > in most cases). Glancing at the match module it looks the process of > > expanding a match clause is pretty intricate, and the documentation > > mentions that match lacks the time complexity guarantee of case, but > > beyond that it's not immediately clear whether match imposes some > > unacceptable overhead or etc., or to what extent it does if so. > > You can always use "expand" or "expand-once" to look at the code > generated by the use of a match. Usually, it's just a bunch of nested > conds and lets, with a function and call to check the next pattern. > > Haskell's pattern matching is probably compiled to something more > efficient (anyone want to test this hypothesis?), but Racket's works > when you need it, and has some really nice features (e.g., list-no-order > and quasiquote matches). One goal of the `match` library is that it generates code as good (performance-wise) as you could have written by hand. For almost everything, it achieves this goal (major exceptions include some hash table patterns and list-no-order, which is very hard to do efficiently in general). The implementation of `match` uses the same algorithms for compiling pattern matching as Haskell does, and performs some optimizations that I think GHC does not do. However, Haskell can implement some things more efficiently than Racket, in particular checking which kind of data something is, using a combination of static type information and algebraic data types. This is not a limitation of `match`, though -- any other Racket program you write will have the same limitations. Sam -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Reasons not to use match or define/match?
On Mon, 17 Dec 2018 at 07:58 -0800, Will Jukes wrote: > After learning more Haskell I've been playing around with match and > define/match, and I'm wondering if there's any particular reason to > prefer more traditional Scheme forms over match (I vastly prefer match > in most cases). Glancing at the match module it looks the process of > expanding a match clause is pretty intricate, and the documentation > mentions that match lacks the time complexity guarantee of case, but > beyond that it's not immediately clear whether match imposes some > unacceptable overhead or etc., or to what extent it does if so. You can always use "expand" or "expand-once" to look at the code generated by the use of a match. Usually, it's just a bunch of nested conds and lets, with a function and call to check the next pattern. Haskell's pattern matching is probably compiled to something more efficient (anyone want to test this hypothesis?), but Racket's works when you need it, and has some really nice features (e.g., list-no-order and quasiquote matches). -- Jack M. Rosenthal ( http://inside.mines.edu/~jrosenth Graduate Student, Computer Science ) http://jack.rosenth.al One of the main causes of the fall of the Roman Empire was that -- lacking zero -- they had no way to indicate successful termination of their C programs. -- Robert Firth -- 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. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: [racket-users] Reasons not to use match or define/match?
Den man. 17. dec. 2018 kl. 16.58 skrev Will Jukes : > After learning more Haskell I've been playing around with match and > define/match, and I'm wondering if there's any particular reason to prefer > more traditional Scheme forms over match (I vastly prefer match in most > cases). Glancing at the match module it looks the process of expanding a > match clause is pretty intricate, and the documentation mentions that match > lacks the time complexity guarantee of case, but beyond that it's not > immediately clear whether match imposes some unacceptable overhead or etc., > or to what extent it does if so. > The use of match often leads to both more concise and more readable code. However if you add a field to a struct foo, then you need to a new field to all patterns matching foos. If on the hand you used foo-bar then adding a field baz requires no changes to the existing code. /Jens Axel -- 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. For more options, visit https://groups.google.com/d/optout.
[racket-users] Reasons not to use match or define/match?
After learning more Haskell I've been playing around with match and define/match, and I'm wondering if there's any particular reason to prefer more traditional Scheme forms over match (I vastly prefer match in most cases). Glancing at the match module it looks the process of expanding a match clause is pretty intricate, and the documentation mentions that match lacks the time complexity guarantee of case, but beyond that it's not immediately clear whether match imposes some unacceptable overhead or etc., or to what extent it does if so. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Are contracts incompatible with Typed Racket?
Hi Jake, Unfortunately, Typed Racket doesn't currently support the contract library. We've made a bunch of progress on integrating them, but that work is still (slowly) ongoing here: https://github.com/racket/typed-racket/pull/420. Depending on what you're looking for, refinement types may be able to support some of the use cases you have. Sam On Sat, Dec 15, 2018 at 5:24 PM wrote: > > I recently started learning Racket and quickly switched to Typed Racket. For > the most part I've been very happy with it, but I'm unclear on whether it's > possible to create contracts in Typed Racket (for expressing constraints > other than type requirements). I've been unable to find an explicit answer to > my question in the docs for either contracts or Typed Racket, but I've run > several experiments and it seems that contracts are incompatible with Typed > Racket. This discussion seems to support my conclusion. > > If you can't create your own contracts in Typed Racket, are you meant to > limit all of your contract-related needs to type requirements? Or just use > vanilla Racket if you need a full-fledged contract system? Additionally, > could someone point me to the documentation that would have answered by > question (if it exists)? > > 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. > For more options, visit https://groups.google.com/d/optout. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] hackernews
I agree that it would be much better to write good blog posts about Racket. They don't need to be fantastic, they don't need to be better than the documentation, they only has to be interesting. I usually prefer post with one or two big relevant graph (or photos when there is hardware involve), I like images. (It doesn't have to be very interesting, sometimes an article is more interesting than what you expect) Have you recently solved some interesting problem (using Racket)? It's better if it's a real life problem, but a nice toy problem can be interesting too. Sometimes translating an interesting article to Racket can be a good idea, if the translation shows some unique feature, like a smart use of macros or a library that are not available in other languages. (Don't post too often. Unless you are very good writing, you can't write more than one interesting article per week(/month(/year)).) --- The problem of going to HN to write comments about Racket is that the community has a lot of unwritten rules. (No jokes. No kittens. No astroturfing/sockpupet/meatpupets. No onliners. [1] . No voting rings. No asking for votes in other platforms.) There is no problem if an article gets popular and the author goes to the site to answer the questions. The unwritten rules are not too strict and they don't apply if the author can give some interesting relevant answers and more information. *Don't be afraid of answering questions there.* Some types of bad comments: * photobomb unrelated threads with a reference to Racket. (For example, in an article about regular expression in PHP, posting "Racket has two types of regular expressions"). * astroturfing comments (For example in an article about something in Racket, posting "I use it too and it is fantastic" [there is also an unwritten rule about too many exclamation marks].) * fake questions in unrelated articles (like "I wonder if it possible to write this in Racket?") * "Why didn't they use Racket instead?" "Why don't they rewrite this in Racket?" ([bonus negative points if it is another Scheme-like language]) Gustavo [1] You can write onliners in HN, but it's very difficult to write good onliners. It's much easier to add more information and more context. Jokes are also legal, but it must be a very good original joke, so better avoid jokes. On Sat, Dec 15, 2018 at 1:48 PM Peter Schmiedeskamp wrote: > I’m probably guilty of already being part of this task-force. To add, I > wonder if there’d be value in some longer, blog-form replies to interesting > HackerNews queries. > > For example, someone was extolling the virtues of some new system for > building and packaging simple GUI apps for Linux using Python. I’ve poked > around with the GUI and packaging facilities of Racket enough to feel like > Racket has a pretty good story to tell, at least for smaller cross-platform > apps. A short blog showing the end-to-end creation of a small GUI app, with > emphasis on showing the symbiosis of the GUI library and the excellent raco > packaging and distribution facilities would be a great “reply” to such an > article on HN. > > I wonder if there's a way that these use cases could at least be > collected... maybe as an RFB—Request For Blog. Time is always at a premium, > but I could imagine picking off a blog post here and there even though I’m > a decidedly rank novice Racketeer. > > Maybe there’s already a list somewhere? Maybe RFBs could be a section of > the Racket Blog? > > Best, > Peter > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > On Sat, Dec 15, 2018 at 1:48 PM Peter Schmiedeskamp wrote: > I’m probably guilty of already being part of this task-force. To add, I > wonder if there’d be value in some longer, blog-form replies to interesting > HackerNews queries. > > For example, someone was extolling the virtues of some new system for > building and packaging simple GUI apps for Linux using Python. I’ve poked > around with the GUI and packaging facilities of Racket enough to feel like > Racket has a pretty good story to tell, at least for smaller cross-platform > apps. A short blog showing the end-to-end creation of a small GUI app, with > emphasis on showing the symbiosis of the GUI library and the excellent raco > packaging and distribution facilities would be a great “reply” to such an > article on HN. > > I wonder if there's a way that these use cases could at least be > collected... maybe as an RFB—Request For Blog. Time is always at a premium, > but I could imagine picking off a blog post here and there even though I’m > a decidedly rank novice Racketeer. > > Maybe there’s already a list somewhere? Maybe RFBs could be a section of > the Racket Blog? > > Best, > Peter > > -- > You received this
Re: [racket-users] hackernews
I'm also occasionally writing posts about Racket on my blog. Only one is public for now, and is a multi-parts tutorial about writing DSLs in Racket. I'm trying to summarize and reformulate some of the things I learned by making small languages in Racket. If you already read Beautiful Racket, I guess there's nothing new to learn, because I'm mostly targeting developers not aware of lisp languages. You can find the first part here: http://rilouw.eu/article/the-programming-language-of-your-dreams-part-1 Feel free to contact me if you want to share some advice and feedback! I'm not confident the article is worth a post on HN for now, and I don't know if my Racket server will sustain a mention on HN anyway, but if you feel it's worth posting, feel free to do so. On Monday, December 17, 2018 at 2:30:55 AM UTC+1, Alex Harsanyi wrote: > > > > On Sunday, December 16, 2018 at 12:48:09 AM UTC+8, Peter Schmiedeskamp > wrote: >> >> I’m probably guilty of already being part of this task-force. To add, I >> wonder if there’d be value in some longer, blog-form replies to interesting >> HackerNews queries. >> >> For example, someone was extolling the virtues of some new system for >> building and packaging simple GUI apps for Linux using Python. I’ve poked >> around with the GUI and packaging facilities of Racket enough to feel like >> Racket has a pretty good story to tell, at least for smaller cross-platform >> apps. A short blog showing the end-to-end creation of a small GUI app, with >> emphasis on showing the symbiosis of the GUI library and the excellent raco >> packaging and distribution facilities would be a great “reply” to such an >> article on HN. > > >> I wonder if there's a way that these use cases could at least be >> collected... maybe as an RFB—Request For Blog. Time is always at a premium, >> but I could imagine picking off a blog post here and there even though I’m >> a decidedly rank novice Racketeer. >> >> Maybe there’s already a list somewhere? Maybe RFBs could be a section of >> the Racket Blog? >> > > > I have written a few blog posts on Racket GUI topics and I have a few more > planned. They cover some more advanced uses of the GUI library -- I think > the basics are already well documented. You can find them here: > >https://alex-hhh.github.io/tags/racket.html > > Alex. > > -- 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. For more options, visit https://groups.google.com/d/optout.
