Re: [racket-users] Licence guidance
On 09/26/2018 05:32 PM, Deren Dohoda wrote: > I put a package up but it has no license info in the code. I would add > one which is the most permissive possible that wouldn't cause conflict. > I guess this is BSD? MIT? In this case, don't license your code, declare it to be in the public domain. -- Anthony Carrico -- 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] Making evaluators / handin server setup
Dear Racketeers, I’m writing about difficulties using make-evaluator in Racket v7.0 with a module that selectively (or not) re-exports bindings from an existing language. This is related to work I’m doing with the handin server. - the short version - Create this file, and use as follows: ; beginner-lang.rkt ; #lang racket (require lang/htdp-beginner) (provide (all-from-out lang/htdp-beginner)) ; Interactions, launched from the same directory: ; > (require racket/sandbox) > (make-evaluator "beginner-lang.rkt") . . ../../../../../../../../Applications/Racket v7.0/collects/racket/private/kw-file.rkt:102:2: open-input-file: `read' access denied for /Users/jteach/Library/Racket/7.0/pkgs/.LOCKpkgs.rktd ; end code ; Q: Can you tell me why I’m seeing this behavior? - the longer version, with context - After a couple years of just having my small classes email me their work, I’m trying the handin server again. For the next assignment, students are writing BSL code that uses 2htdp/image and the animate function from 2htdp/universe. Their code also uses bitmap/url to load an image I provided via the class website. In doing a trial run of submitting my test solutions, I found my checker.rkt signaling errors from the check: form: Using :language '(special htdp-beginner), I get an error from the student’s (require 2htdp/image) line, saying that image? is being imported twice. Q: How do I make the import “just work”, as it ordinarily does in DrRacket? Going further, I’ve kludged together a wrapper lib that imports all the needed functions while taking care to remove clashes, at which point I got the odd read-access error above. Here’s that code: ; img.rkt ; #lang racket (require racket/require) ; for subtract-in (require (combine-in [except-in lang/htdp-beginner require image?] [subtract-in [except-in 2htdp/image bitmap/url] lang/htdp-beginner])) (provide (all-from-out lang/htdp-beginner) (all-from-out 2htdp/image) bitmap/url animate (rename-out [%require require])) (define-syntax-rule (%require . blahblah) (void)) ; ignore student's requires (define (animate _) (void)) ; ignore student's calls to animate from universe (define (bitmap/url url) ; replace bitmap/url with something harmless (rectangle 50 35 'solid 'lavender)) ; end img.rkt; I am using it in checker.rkt as follows: ; (check: :language "../../img.rkt" ; escape to assignment base dir ...) ; end ; This approach works for now, but seems like an ungainly way to do it, and I’ll be surprised if this level of manual disambiguation is what everybody’s been doing for years. Is there a more elegant way? Best, Jordan -- 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] 2018 SIGPLAN Software Award
Dear Racketeers, Racket has just received the 2018 ACM SIGPLAN Software Systems Award We are honored by this award, but it belongs to more than the core group of people named in the citation. Many people have invested time and energy into this language. The language is what it is now because of you. Looking back at the modest beginnings in January 1995, we want to acknowledge some contributors specially: John Clements, for constructing the incredible stepper back in the late 90s and thus helping distinguish DrScheme from all other pedagogic IDEs, for maintaining the beast for 20 years, and taking on many other library projects; Cormac Flanagan, for using PLT Scheme to create MrSpidey, which placed our little language into the web of SIGPLAN research and awareness way way back; Matthew Butterick for "Beautiful Racket", code, languages, volunteer teaching, and faithful evangelizing; Vincent St-Amour, Ryan Culpepper, Paul Steckler, and Mark Krentel for managing the Racket world of software for many years; and Vincent also for his tender love and care for RacketCon. Many, many others have contributed to Racket over the past two decades through implementation, teaching, and research. We have collected many names at the end of this post, but our memories are probably flawed and, in recent years, the contributor community has grown tremendously. This doesn't mean we aren't thinking of you and thanking you today --- and not just today, but every time we launch our wonderful DrRacket and run beautiful Racket programs. THANK YOU ALL. We are looking forward to many more years of Racketeering! - Matthew with Eli, Matthias, Robby, Shriram, Jay, and Sam Contributors: Claire Alvis, Leif Andersen, Yavuz Arkun, Ian Barland, Gann Bierner, Stephen Bloch, Filipe Cabecinhas, Corky Cartwright, Stephen Chang, Richard Cleis, Richard Cobbe, Greg Cooper, Christos Dimoulas, Eric Dobson, Carl Eastlund, Moy Easwaran, Will Farr, Dan Feltey, Michael Filonenko, Burke Fetscher, Kathi Fisler, Spencer Florence, Daniel Friedman, Tony Garnock-Jones, Sebastian Good, Paul Graunke, Kathy Gray, Ben Greenman, Dan Grossman, Arjun Guha, Dave Gurnell, Tobias Hammer, William Hatch, Bruce Hauman, Greg Hendershott, Dave Herman, Jim Hollan, Blake Johnson, Andrew Kent, Gregor Kiczales, Alexis King, Casey Klein, Alex Knauth, Geoffrey S. Knauth, Mario Latendresse, Xiangqi Li, Guillaume Marceau, Gustavo Massaccesi, Jacob Matthews, Mike T. McHenry, Philippe Meunier, Albert Meyer, Scott Owens, David T. Pierson, Jon Rafkind, Prabhakar Ragde, Norman Ramsey, Jamie Raymond, Grant Rettke, Guido Rößling, Emmanuel Schanzer, Paul Schlie, Dorai Sitaram, Francisco Solsona, Sarah Spall, Mike Sperber, Stevie Strickland, James Swaine, Jens Axel Søgaard, Neil Van Dyke, David Van Horn, Anton van Straaten, Asumu Takikawa, Kevin Tew, Neil Toronto, Milo Turner, Dale Vaillancourt, Dimitris Vyzovitis, Mitch Wand, Stephanie Weirich, Noel Welsh, Adam Wick, Danny Yoo, Shu-Hung You, and ChongKai Zhu. -- 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] Licence guidance
If you want a permissive license, the FSF itself says that "Apache 2.0 is best" because it addresses patent issues: https://www.gnu.org/licenses/license-recommendations.html#small -Philip On Wed, Sep 26, 2018 at 4:32 PM Deren Dohoda wrote: > I put a package up but it has no license info in the code. I would add one > which is the most permissive possible that wouldn't cause conflict. I guess > this is BSD? MIT? > > On Tue, Sep 25, 2018, 12:30 PM Neil Van Dyke wrote: > >> BTW, I don't know the status of possible new GPL and LGPL versions in >> progress, but, if any Racket people have some insights into how to >> improve the "linking" concepts or some other aspect, in the spirit of >> FSF goals, the FSF has seemed open to comments. If you don't know who >> else to contact, you can always email RMS. >> >> You can get as technical as necessary. Organizationally, besides the >> FSF being founded by and attracting some high-powered techies, some >> advisors are very noteworthy Scheme people. Also, a Scheme with >> multiple `#lang`s (though it wasn't called `#lang`) was actually a >> central part of the GNU roadmap, from early on. (And probably would've >> been in popular use atop Linux for over a decade now, but for another >> party's business decision, outside of FSF's control, not a technical or >> acceptance reason.) >> >> -- >> 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] Licence guidance
I put a package up but it has no license info in the code. I would add one which is the most permissive possible that wouldn't cause conflict. I guess this is BSD? MIT? On Tue, Sep 25, 2018, 12:30 PM Neil Van Dyke wrote: > BTW, I don't know the status of possible new GPL and LGPL versions in > progress, but, if any Racket people have some insights into how to > improve the "linking" concepts or some other aspect, in the spirit of > FSF goals, the FSF has seemed open to comments. If you don't know who > else to contact, you can always email RMS. > > You can get as technical as necessary. Organizationally, besides the > FSF being founded by and attracting some high-powered techies, some > advisors are very noteworthy Scheme people. Also, a Scheme with > multiple `#lang`s (though it wasn't called `#lang`) was actually a > central part of the GNU roadmap, from early on. (And probably would've > been in popular use atop Linux for over a decade now, but for another > party's business decision, outside of FSF's control, not a technical or > acceptance reason.) > > -- > 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] Compilation/Embedding leaves syntax traces
On Wed, Sep 26, 2018 at 1:36 AM Paulo Matos wrote: > I am keen on hearing about alternatives. The reason to do like this is > to minimize friction with clients. Clients in the area of development > tools expect something that they can execute and generally are not too > keen on scripty calls like `python foo.py`, so if I said: Please run the > program with `racket s10.rkt` ... it would very quickly lower my > possibility of a sale. Racket distribution creates essentially the > package that they expect, something they can run out of the box without > thinking much about dependencies in something that looks like an > executable - even if it's just more or less a racket shell. Your product > appearance is important and therefore I want to give something they are > already used to. > I definitely understand wanting users to be able to run the application in a way that feels as normal as possible to them: I think about this even with internal tools that I develop for collaborators with a limited technical background. I think the approach I brought up would be compatible with making distributions. What I had in mind (but see below) was something like: ;; x86_64-no-contracts.rkt #lang racket/base (require "../run-program.rkt") (run-program #:arch 'x86_64 #:contracts? #f) ;; i386-with-contracts.rkt #lang racket/base (require "../run-program.rkt") (run-program #:arch 'i386 #:contracts? #f) Then `raco exe`/`create-embedding-executable`/whatever can work on either version. > Most seriously, depending on exactly how you use these compile-time > > environment variables, it seems like you could negate some of the > > benefits of the "separate compilation guarantee," particularly if you > > are assuming that all of your modules are compiled at the same time. > > > > Why would that be a problem? > This is a longer discussion and I am by no means an expert, but I can point you to the "separate compilation guarantee" docs ( http://docs.racket-lang.org/reference/eval-model.html#(part._separate-compilation)) and Matthew Flatt's paper "Composable and Compilable Macros: You Want it *When?*" (https://www.cs.utah.edu/plt/publications/macromod.pdf). I don't think what you are doing circumvents the separate compilation guarantee per se, because you don't produce "external effects" (e.g. I/O) during compilation and then rely on those side-effects during run-time. But, while I have not thought especially deeply about this, using environment variables this way seems to be sort of the mirror image: the state of the universe external to the Racket runtime system has effects on the compilation of your modules, and it seems like that might introduce similar problems. In particular, "the practical consequence of [the separate compilation] guarantee is that because effects are never visible, no module can detect whether a module it requires is already compiled. Thus, it can never change the compilation of one module to have already compiled a different module." This has all kinds of nice benefits that are detailed in the paper. In your case you seem to assume that all of the modules are compiled at the same time (i.e. with the same set of environment variables). You do seem to put in the effort to actually uphold that assumption, and maybe there are compelling reasons to do so in your case, but I would suggest thinking carefully about that decision. > That is a possibility but I run into the problem of having too many > modules as the number of possibly configurations can easily explode as I > add more configurations and backends to my application. Getting one file > per compile-time configuration is essentially not workable. > > My CI script currently creates 48 configurations for testing. That's 4 > boolean options plus 3 backend architectures that I either completely > support or are under development. If I get a couple of customers wanting > different architectures, I can easily go to maybe 5 or 6 backends and > have more than 100 configurations to test. I would probably have to stop > testing _every_ config at some point and choose which configs are more > important but this seems to be the problem with this kind of choice - in > GCC world we have the same problem and ended up having to create several > tiers of backends/configurations to be able to do a proper job at > testing and releasing. > > If I am missing some fundamental way Racket can help with this, I am > open to other options but it all boils down to moving as many things to > compile time config so I can drop unnecessary code and try to make this > as fast as possible. > Yes, I see the issue here. I don't have a fully worked-out solution and probably can't without knowing your requirements in detail, but I have a few general thoughts. How much of this configuration really needs to happen at compile-time vs. runtime? In the examples you've sent, you effectively turn "S10_ENABLE_CONTRACTS" and "ARCH" into runtime constants. If it's just a matter that you
[racket-users] Scribble warnings in package documentation
I have a long package documentation and get lots of warnings - see
below. Other than that, the docs work fine, should/can I ignore them?
What do they mean anyway?
Best,
Erich
WARNING: collected information for key multiple times: '(exporting-libraries
#f); values: '(appy/gui) '(appy)
WARNING: collected information for key multiple times: '(exporting-packages
#f); values: '("appy") '("appy")
WARNING: collected information for key multiple times: '(exporting-libraries
#f); values: '(appy/storage-interface) '(appy/storage)
WARNING: collected information for key multiple times: '(exporting-packages
#f); values: '("appy") '("appy")
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: no declared exporting libraries for definition
WARNING: collected information for key multiple times: '(index-entry (part
"Overview")); values: (list '("Overview") (list (element #f '("Overview")))
(part-index-desc)) (list '("Overview") (list (element #f '("Overview")))
(part-index-desc))
WARNING: collected information for key multiple times: '(part "Overview");
values: '#(("Overview") (part "Overview") (1) (collects #"appy" #"scribblings"
#"manual.html") #f) '#(("Overview") (part "Overview") (1 4 2) (collects #"appy"
#"scribblings" #"manual.html") #f)
--
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] Compilation/Embedding leaves syntax traces
On 25/09/2018 23:38, Ryan Culpepper wrote: > On 9/25/18 1:11 PM, Alexis King wrote: >> [] Personally, I would appreciate a way to ask >> Racket to strip all phase ≥1 code and phase ≥1 dependencies from a >> specified program so that I can distribute the phase 0 code and >> dependencies exclusively. However, to my knowledge, Racket does not >> currently include any such feature. > > `raco demod -g` seems to do that, but the `-g` option is marked with a > warning. > > Ryan > Once you have this new demod'ed zo file, how do you run it? On the example of my original post, I get the demod'ed file, and try to run it with racket. It doesn't crash but it also prints nothing. -- Paulo Matos -- 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] Compilation/Embedding leaves syntax traces
On 25/09/2018 23:44, Philip McGrath wrote: > On Tue, Sep 25, 2018 at 3:46 PM 'Paulo Matos' via Racket Users > mailto:racket-users@googlegroups.com>> > wrote: > > OK, so I understand now that what I want is an unimplemented feature, > but in most compilers these days and certainly those based in LLVM and > GCC there's a feature called whole-program optimization or link time > optimization. Basically the compiler will get the whole program in > memory after compiling each module/file and run the optimizations on the > whole thing again therefore being able to optimize things it wasn't able > to optimize before when it only had a module/file view. > > > I know that `raco demodularize` can flatten a whole program > (https://docs.racket-lang.org/raco/demod.html). I think I remember > reading a paper that looked at using this as the basis for whole-program > optimization, but I don't remember the results of the paper, much less > anything about doing this in practice. > You are right, and as Ryan mentioned in another post -g will re-compile after the de-modularization - in effect doing whole-program optimization. I am amazed and scared at the same time. :) If you recall the paper please let me know. > > >> My software has several compile time options that use environment > >> variables to be read (since I can't think of another way to do > it) so I > >> define a compile time variable as: > >> > >> (define-for-syntax enable-contracts? > >> (and (getenv "S10_ENABLE_CONTRACTS") #true)) > >> > >> And then I create a macro to move this compile-time variable to > runtime: > >> (define-syntax (compiled-with-contracts? stx) > >> (datum->syntax stx enable-contracts?)) > >> > >> I have a few of these so when I create a distribution, I first > create an > >> executable with (I use create-embedding-executable but for > simplicity, > >> lets say I am using raco): > >> S10_ENABLE_CONTRACTS=1 raco exe ... > > > More broadly, the thing that first struck me is that most Racket > programs don't seem to use this sort of build process. I do think they > should be /able/ to, and there may be good reasons to do that in your > case, but I've been trying to think about what it is about this that > strikes me as un-Racket-ey and what alternatives might be. > I am keen on hearing about alternatives. The reason to do like this is to minimize friction with clients. Clients in the area of development tools expect something that they can execute and generally are not too keen on scripty calls like `python foo.py`, so if I said: Please run the program with `racket s10.rkt` ... it would very quickly lower my possibility of a sale. Racket distribution creates essentially the package that they expect, something they can run out of the box without thinking much about dependencies in something that looks like an executable - even if it's just more or less a racket shell. Your product appearance is important and therefore I want to give something they are already used to. > I think one part of it is that compiling differently based on > environment variables seems to go against the principle that "Racket > internalizes extra-linguistic mechanisms" > (http://felleisen.org/matthias/manifesto/sec_intern.html). For a > practical example, environment variables are vexing on Mac OS for GUI > programs. Not sure about Mac OS because I never used one but I hadn't had the need before this project to do something like this and when I started I was pointed to how contracts are doing this: (define-for-syntax enable-contracts? (and (getenv "PLT_TR_CONTRACTS") #t)) in https://github.com/racket/typed-racket/blob/1825355c4879b6263b0c8fe88b30e11d79fc0d31/typed-racket-lib/typed-racket/utils/utils.rkt#L43 So, I created a racket app to pack my application, so you can actually do something like: racket create-s10-distribution.rkt --with-contracts --with-statistics ./release-folder This will put an S10 release in release folder that can be moved to another system. Side note: This is also useful for benchmarking as I can easily dockerize it, and get it running on a big AWS machine without worrying about installing racket, etc. > > Another issue is that this approach means that only one compiled > configuration exists at a time. In some cases maybe that's right: I've > had files in which I manually switch the definition of a macro to, say, > add some `printf`s that I only want when I'm actively working on that > specific file. But more often, if it makes sense for multiple versions > of a program to exist—say, your example of different architectures—I > think it also makes sense for them to be able to exist simultaneously. > At the moment I have no issues with this. I usually run it in debug mode with say: --with-contracts --with-places-debug --with-statistics --with-timing etc. Then when I push a change, CI will compile quite a few different
Re: [racket-users] Compilation/Embedding leaves syntax traces
On 25/09/2018 23:38, Ryan Culpepper wrote: > On 9/25/18 1:11 PM, Alexis King wrote: >> [] Personally, I would appreciate a way to ask >> Racket to strip all phase ≥1 code and phase ≥1 dependencies from a >> specified program so that I can distribute the phase 0 code and >> dependencies exclusively. However, to my knowledge, Racket does not >> currently include any such feature. > > `raco demod -g` seems to do that, but the `-g` option is marked with a > warning. Wow, ok, I am officially amazed - but at the same time slightly scared of trying it on a very large application. :) What do you mean 'marked with a warning'? raco demod --help just says: -r, --recompile : Recompile final module to re-run optimizations There's no warning there. -- Paulo Matos -- 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.
