Re: [racket-users] Racket Slack archive [help wanted]
D. Ben Knoble > 1) It wasn’t immediately clear to me that the links were the names of > channels. It seems painfully obvious to me now, but perhaps it’s worth > starting all the names with hashes? Great idea, thanks. > 2) Clicking on the channel name “general” appears to melt down somehow, > presumably because the page is really really really big. Is pagination near > the top of most-desired-new-features? Yeah, this is one of my top priorities. I’m thinking I’ll break it down by date. But I may want to rewrite the static generation in Racket first (to get it off Ruby + Jekyll, which may be unfamiliar to the community). > Again, I think it’s great that you’re doing this! 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/A2CF171A-71F5-4C75-9705-53A0F1419F00%40gmail.com.
Re: [racket-users] Racket Slack archive [help wanted]
Hearing about this for the first time, seems like a fantastic idea. 10 seconds of experience: 1) It wasn’t immediately clear to me that the links were the names of channels. It seems painfully obvious to me now, but perhaps it’s worth starting all the names with hashes? 2) Clicking on the channel name “general” appears to melt down somehow, presumably because the page is really really really big. Is pagination near the top of most-desired-new-features? Again, I think it’s great that you’re doing this! John > On Jun 8, 2021, at 08:16, D. Ben Knoble wrote: > > In case you missed it/aren't on Slack: > > The latest version of the Slack archive is up-and-running at > https://benknoble.github.io/racket-slack-archive/ (extends through roughly > 2021-06-07). > > The site is now built using a mix of > - Racket (data processing, mostly the json, hash, and unzip modules) > - Jekyll/Ruby (site-generation; a plugin makes pages out of all the channel > directories, which are then rendered via a set of HTML templates) > > I have some todos to make a nicer experience, and help is welcome. Also if > anyone wants to start working porting the Jekyll + Ruby stuff to Racket, feel > free. > > -- > 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/a8efd2e6-ffb9-48d3-8b98-2d3da9551e70n%40googlegroups.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/b25be9f7-e01d-4f9e-a1dc-5d1c6b94cfd0%40mtasv.net.
[racket-users] Racket Slack archive [help wanted]
In case you missed it/aren't on Slack: The latest version of the Slack archive is up-and-running at https://benknoble.github.io/racket-slack-archive/ (extends through roughly 2021-06-07). The site is now built using a mix of - Racket (data processing, mostly the json, hash, and unzip modules) - Jekyll/Ruby (site-generation; a plugin makes pages out of all the channel directories, which are then rendered via a set of HTML templates) I have some todos to make a nicer experience, and help is welcome. Also if anyone wants to start working porting the Jekyll + Ruby stuff to Racket, feel free. -- 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/a8efd2e6-ffb9-48d3-8b98-2d3da9551e70n%40googlegroups.com.
[racket-users] Re: Racket v8.1
Hi Greg, I can run Racket on my Android phone via https://github.com/t184256/nix-on-droid , but last time I tried I couldn't get raco to work because of some weird file paths in Android/Termux. I have never tried running DrRacket though. - Sergiu On Tuesday, June 8, 2021 at 12:40:12 AM UTC+2 greg.d...@gmail.com wrote: > How can I run Racket 8.1 on Android? I'd love to run DrRacket natively > and/or run raco under Termux. Where can I find out more information? > Thanks, _Greg > > On Wednesday, May 5, 2021 at 9:39:22 AM UTC-7 johnbclements wrote: > >> -- >> Racket version 8.1 is now available from >> >> https://racket-lang.org/ >> >> >> - DrRacket tabs can be dragged, and have new close buttons. >> >> - Racket CS supports cross-compilation using `raco exe`. >> >> - Racket CS supports Android on 32-bit and 64-bit ARM processors. >> >> - The database library supports running queries in OS threads. >> >> - Check-Syntax arrows correctly identify the definition site of >> identifiers with contracts. >> >> - Racket CS performance has improved for structure predicates and >> accessors >> >> - Racket CS is faster at multiplying extremely large numbers and >> dividing large integers. >> >> - Racket CS allows callbacks to raise exceptions if they are annotated >> with `#:callback-exns?`. >> >> - New ephemeron hash tables simplify the implementation of tables where >> keys can refer to values. >> >> - Typed Racket supports for/foldr. >> >> - The stepper works for #lang htdp/*sl. >> >> - Struct signatures work for the ASL teaching language. >> >> The following people contributed to this release: >> >> Alex Harsányi, Alex Knauth, Alexander Shopov, Alexis King, Andrew >> Mauer-Oats, Anish Athalye, Ben Greenman, Bert De Ketelaere, Bob Burger, >> Bogdan Popa, Brian Adkins, Cameron Moy, David Van Horn, Dexter Lagan, >> Dominik Pantůček, Fred Fu, Greg Hendershott, Gustavo Massaccesi, Hazel >> Levine, Ismael Luceno, Jack Firth, Jarhmander, John Clements, Jörgen >> Brandt, Laurent Orseau, Lazerbeak12345, Matthew Flatt, Matthias >> Felleisen, Micah Cantor, Mike Sperber, Noah Ma, Patrick McCarty, Paulo >> Matos, Pavel Panchekha, Philip McGrath, Philippe Meunier, R. Kent >> Dybvig, Robby Findler, Ryan Culpepper, Ryan Kramer, Sam Tobin-Hochstadt, >> Sergiu Ivanov, Shu-Hung You, Sorawee Porncharoenwase, Stephen De >> Gabrielle, William J. Bowman, bmitc, xxyzz, yjqww6, and ymdarake >> >> Feedback Welcome >> -- >> >> -- 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/51e8dccf-385a-49e1-8a5d-9f3e6fba95c4n%40googlegroups.com.
[racket-users] Re: Embedded Racket reimplementation for constrained hardware?
On Sun, 6 Jun 2021 07:26:09 -0700 (PDT), "schle...@gmail.com" wrote: >I think in such an environment I would like to control memory usage myself, >or maybe have a #lang that allows very fine grained and low level control >over resources. (outputting lowerlevel code than racket/base). >If you need persistent data-structures they are nice, but often times you >don't need them. >Basically I would use a smaller language and build only the things I really >need, instead of starting with racket and stripping away everything I don't >need. >(although if you manage to create a tool that accomplishes this in a very >radical manner that could be cool as well, I just don't think that is easy) I doubt Racket can be used directly as it was not designed to work with programmer managed memory, but it could be used as a cross development environment. For reference there is Scheme48 which was designed for embedded use. Scheme48 compiles to C and does /not/ use GC but rather forces the programmer to manage memory explicitly. However, there's no particular need to go through C if you're willing to write your own compiler and runtime. >That would boil down to partially evaluating racket specializing it to the >target program, I don't think tools like `raco exe`, `raco distribute` etc. >go so far that they would try to eliminate >base language features, which probably aren't "unused" anyway in any >reasonably complex program. Yeah, I think some significant work would have to be done to separate 'base' into smaller libraries ... if that even can be done at all. >Said another way: I think in a lot of cases it is easier to start creating >a program with a language with less features, than trying to get rid of >certain features after the program was already written using these >features. If you start out without the features it is easier to reason >about what features are worth implementing, for the particular program and >what is over-engineered for the use-case. >That is just my perspective, I think there are many approaches to this, >depending on the circumstances and concrete goals. > >Simon As a technical matter, GC works fine in small memory as long as it is designed for that purpose. The problem is that the GCs employed by (BC and CS versions of) Racket were /not/ designed for particularly small systems. But the design space of GC is large, and collectors have been designed to work in almost every environment except HRT with sub-millisecond deadlines. There are systems that are completely deterministic and which can be used for HRT as long as the periods when the mutator must be stopped are short enough for the purpose. YMMV, George -- 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/mmhubg92kiggthhlrfp483sfu0hga86r79%404ax.com.
