Re: [racket-users] New to Racket
Thanks Jens! I appreciate. The package looks very promising. Kind regards Rohan On Thursday, February 18, 2021 at 12:49:28 PM UTC+2 Jens Axel Søgaard wrote: > Den tor. 18. feb. 2021 kl. 08.09 skrev Rohan Posthumus < > rohanpo...@gmail.com>: > >> I am a data analyst and uses a lot of data science packages in Python. >> In order to learn Racket, I want to translate some of these into Racket. >> I need some help with where to start. >> >>- I finished "Beautiful Racket" and wonder whether I should make a >>data science DSL? >>- I read up a bit on Typed Racket and this seems like another option. >>The dynamic type checking seems to give overhead? >>- Translate some of these into Racket with classes and objects >>(similar to Python). >> >> Any advice? >> > > I would start with plain Racket to begin with. It's simpler, and you can > switch to Typed Racket > a module at a time at a later date if you find the need. > > Just in case you haven't found them already, if you need matrices over > real floating points, > take a look at: > > https://docs.racket-lang.org/manual-flomat/index.html > > /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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7c1b0b3c-7640-451c-9de5-838cb131c27fn%40googlegroups.com.
[racket-users] When are rackunit tests delayed? (different between 7.8 and 8)
Below is an example that behaves "correctly", as in all tests run and are counted as failured or errors correctly, in Racket 7.8, but which crashes in Racket 8. > #lang racket > > (require > rackunit > rackunit/log) > > (define (suite1) > (test-suite >"" >(test-begin > (check-not-equal? (error "actual") (error "expected") > > (define (suite2) > (test-suite >"" >(check-not-equal? (error "actual") (error "expected" > > (module+ test > (require rackunit/text-ui) > > ;; Correctly counts the tests as errors in 7.8 and 8.0 > (check-pred >integer? >(run-tests (suite1))) > > ;; Counts the tests as errors in 7.8, but crashes in 8.0 > (check-pred >integer? >(run-tests (suite2))) > > ;; Gets run in 7.8, but not in 8.0 > (check-equal? 0 0)) This has something to do with when test-suite delays a test, which seems inconsistent across the Racket versions. I'm not sure whether the problem was some undefined behaviour in test-suite or not. I'm a bit confused about the semantics of test-suites and tests, since the documentation claims a test (unlike a check) is delayed, yet test-case and test-begin do not delay tests, while test-suite does produce a delayed suite of tests. However, test-begin DOES seem to delay a test in the context of a test-suite. I'd appreciate any insight. -- William J. Bowman -- 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/YDSeU7C3PUQzRdCk%40williamjbowman.com.
Re: [racket-users] Ubuntu PPA also updated to v8.0
On 2021-02-22 10:56:48 -0800, Asumu Takikawa wrote: > It looks like this change broke package upgrades. I should be able to > fix the packages later by adjusting the dependency flags. I believe this issue with broken upgrades should be fixed now with version 8.0+ppa1-6 of the package. If anyone still has any upgrade issues with this version please let me know (you can comment on the github issue https://github.com/takikawa/racket-ppa/issues/10). Cheers, Asumu -- 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/2021015625.dlzzltwd3qfy5yre%40nixos.
Re: [racket-users] Ubuntu PPA also updated to v8.0
On 22. 02. 21 19:56, Asumu Takikawa wrote: > On 2021-02-18 21:44:30 -0800, Asumu Takikawa wrote: >> Due to changes in how the new CS compiler works, some files have been >> moved between the three .deb packages that are in the distribution. > > It looks like this change broke package upgrades. I should be able to > fix the packages later by adjusting the dependency flags. > > In the meantime, if you get an error on upgrade you should be able to > work around it by just uninstalling the racket packages and > re-installing the latest ones. > Actually `apt-get -f install` fixed that without having to manually uninstall/install anything. D. -- 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/e00bca5f-faf4-14aa-7bb8-208badbb8b53%40trustica.cz.
Re: [racket-users] Ubuntu PPA also updated to v8.0
On 2021-02-18 21:44:30 -0800, Asumu Takikawa wrote: > Due to changes in how the new CS compiler works, some files have been > moved between the three .deb packages that are in the distribution. It looks like this change broke package upgrades. I should be able to fix the packages later by adjusting the dependency flags. In the meantime, if you get an error on upgrade you should be able to work around it by just uninstalling the racket packages and re-installing the latest ones. Cheers, Asumu -- 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/20210222185648.cppkm5b3cpxp6qtl%40nixos.
Re: [racket-users] the future of #lang web-server
On Sun, Feb 21, 2021 at 2:35 PM je...@lisp.sh wrote: > > #lang web-server is brilliant. This #lang is, in my view, a really excellent > example of Racket's take on language-oriented programming. I find that the > performance of continuations is just fine, given my limited use of them, and > after a while you get used to the limitations and just program around them. Thanks, a lot of people contributed a ton to it, specifically: Greg Pettyjohn, John Clements, Joe Marshall, Shriram Krishnamurthi, Matthias Felleisen. > > One thing that always bothers me about #lang web-server, though, is that > there are a lot of provisos in the documentation. I'm talking about section > 3.2, "Usage Considerations", of > https://docs.racket-lang.org/web-server/stateless.html, in the part after > "However, there are some considerations you must make." Here a couple of > questions: > > + " [#lang web-server] will create an immense number of lambdas and > structures your program did not normally contain. The performance implication > of this has not been studied with Racket." > > This seems to me like an interesting research question. Has this question > been taken up? I've tried taking a look on Google Scholar for any follow-up. > I looked at citations of Jay's "Automatically RESTful web applications" and > "The two-state solution: native and serializable continuations accord", but > nothing stuck out to me (...which is not to say that there may have missed > something). I never did any more research about this. I think you could take the traditional Scheme benchmarks --- https://github.com/racket/racket/tree/master/pkgs/racket-benchmarks/tests/racket/benchmarks/common --- and add `#lang web-server` to the top and see what happens. > > + Some limitations of #lang web-server seem don't seem obviously necessary, > at least to someone who's not very familiar with the precise details of the > underlying program transformations. You get used to them, but you wonder if > there's some accessible world in which they work. For example: "You may not > use parameterize, because parameterizations are not serializable." Is that > inherently so (that is, there's no way around that, no matter how clever you > tweak the program transformations on which #lang web-server rests), or is > that just a conequence of the particular approach taken (maybe it's possible, > but no one has done it yet). Has there been any fresh thinking about these > limitations? In some sense, everything is possible, because we can just change the way the VM works... the existing `#lang web-server` is designed to never require modifications down there. In the case of `parameterize`, the problem is a matter of security. Consider the following program: ``` #lang racket (define p (make-parameter #t)) (define (launch-the-missiles!) (when (p) .)) (define (run-code-downloaded-from-youtube f) (parameterize ([p #f]) (f))) ``` We don't want the code from YouTube to be able to launch the missiles. Suppose that parameterizations were serializeable, then the YouTube code could be something like: ``` (lambda () (call-with-parameterization (read (with-input-string (hack-the-planet (with-output-to-string (lambda () (write (current-parameterization) launch-the-missiles!)) ``` where `hack-the-planet` changes the `#f` to `#t`. That's why you can't inspect parameterizations or enumerate the keys in a continuation mark set. In general, all of the limitations of `#lang web-server` are because of things like this. 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/CAJYbDam9-SkkRrKQSWzmAUuJTf0%3D5wAXOjJDAY0aaDe95XK-Wg%40mail.gmail.com.
