“If you could have a wish granted, what would you like to see next in Racket?”

[Stephen De Gabrielle]

“If you could have a wish granted, what would you like to see next in Racket?”

https://www.reddit.com/r/Racket/comments/hwe49b/if_you_could_have_a_wish_granted_what_would_you/?utm_source=share&utm_medium=ios_app&utm_name=iossmf or [original twitter](https://twitter.com/racketlang/status/1286020900660404232?s=20)

--

----

[George Neuner]

SIMD ops.  !!!

Limits on resources used by individual VMs.  ulimit works only at the
process level (so only indirectly affects in-process "thread" places),
and Windows has no simple equivalent:  I am aware of Windows "job
objects", but there are no user controls for them.


George

[Laurent]

Just in case (not sure how relevant this is to you): 

https://docs.racket-lang.org/reference/Sandboxed_Evaluation.html?q=with-limits#%28form._%28%28lib._racket%2Fsandbox..rkt%29._with-limits%29%29

Works pretty well, but there are some caveats: if an object can be reached outside of the `with-limits` scope, it's not counted.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/8b3d3265-616d-e93e-4cd3-01b3ca91a474%40comcast.net.

[George Neuner]

Hi Laurent,

No, "sandboxing" isn't what I want - at least not usually.  I want to be able to limit the VM process itself ... particularly the heap size but occasionally other things as well.  I often have the need to squeeze a Racket application into the corner of a small cloud VM, and I would like is more fine-grained control over Racket processes.

Also, sandboxing only notices the overrun when it's too late.  If the memory is known limited from the beginning, it would be used differently, e.g., GC'd more often.


Without a lot of details about the memory use of various features[*], "ulimit -H -d ..." at best is a guess.  "ulimit -H -m ..." works to limit memory use, but it can't be used without swap, and without limiting the data segment as well, it's easy to start thrashing code vs data and kill performance.

"cgroups" helps with multiprocess applications, but it is complicated to set up properly.

But in Windows there is no built-in user control for resource use ... there are some 3rd party utilities, but many admins won't permit using them.  I work a lot with various DBMS, and things may get easier as SQL Server is available for Linux, but most people who run it still run it on Windows.


And, of course, containers can limit (at least) memory and CPU, but they have their own sets of issues, and the container system itself can require substantial resources.  Generally I prefer to avoid containers and run on the bare machine wherever possible.

YMMV,
George


[*] particularly JIT:  e.g., application mapped files are "data" from the POV of the OS regardless of whether the mapping is executable.  So JIT'd code really is data for "ulimit" purposes.

[unlimitedscolobb]

A more powerful Typed Racket: covering more of Racket (e.g. generics) and with type classes, as in Haskell.

From what I've seen though, work is underway in this direction, and I also plan to contribute once my Racket-fu is up to snuff.

-

Sergiu

[Ray Racine]

Wish tradition dictates the granting of three: 

1. Full blown threaded concurrency and parallelism via the CS Chez runtime's native thread support.  Whether this is Futures without caveats or via other means.

2. Unification of Typed Racket with Turnstile.  If some new language opts to use Turnstile for typing, e.g. Typed Syndicate, ideally Typed Racket module functions should be usable in the Turnstile typed language being type checked without being bridged across via untyped racket with contracts. Less ambitious but worthy would be Type Classes, Typed Units across module boundaries, and Generics  

3. Reboot of GUI / DrRacket - There is a ton of really good base "machinery" in there that could take the Gui system and DrRacket to the next level in terms of new widgets and new  IDE capabilities.  Having a true cross platform UI capability, which Racket is blessed to have, is such a struggle in so many languages.  On the other hand, I suspect a lot has been learned with regard to some weaknesses in the current architecture and design that could be tackled with fresh ideas.

[Jimmy Ruska]

ANTLR 4 Grammars working at compile time with racket

https://github.com/antlr/grammars-v4

Then after parsing, getting back an s-expression tree with structs that you can walk through.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAGHj7-Ldv6bULdc6DD7x4r9w1brUzj5RVzpgjLvZs6P3EW5asQ%40mail.gmail.com.

[wanp...@gmail.com]

Faster load time and less memory consumption.

[Marc Kaufmann]

1. More how-to guides/good practice guides and discussions of some Racket specific features: continuations (especially for the web); Typed Racket; parameters/dynamic scope. Maybe macros, but I don't use them, so can't comment on whether I'd miss how-tos for it. I like "the 4 types of documentation" (https://documentation.divio.com/), and think Racket does great on reference, well on tutorials, and when one knows where to look for also often on 'discussion' - but how-to's are too sparse for me, so I end up with stupid code for situations that feel fairly standard.

2. I am interested in using Racket for symbolic maths/simulations/etc and Rosette seems to provide one big useful block. It would be great to have support for numerics in Racket, probably by integrating well with the Python/R/Julia universe of packages. There is no point in rebuilding much of it from scratch, it seems too huge, but it would be nice to use Racket's features in a way that integrates nicely with the numerics. Julia apparently has a good macro system, but I would be surprised if it was on par with Racket's macro and type system, but who knows?

[unlimitedscolobb]

> but I would be surprised if it was on par with Racket's macro and type system, but who knows?

I worked through the Julia user manual last year and my impression is that their macro system is probably less powerful than Racket's, but that their types are more powerful than Racket's.  When reading the chapter on types [0], I felt like I was doing Haskell.

Disclaimer, though: I never really developed anything in Julia, and my Racket development experience is still quite limited.

-

Sergiu

[0] https://docs.julialang.org/en/v1/manual/types/