Re: [racket-dev] having zo files from two versions
Dan Liebgold wrote on 01/06/2015 02:00 PM: What is a straightforward way to designate the compiled directory to look for zo files in that can be based on the Racket version? I'd like to have Racket 5.2.1 and 6.1 running in parallel to aid in upgrading our version. Thanks! I'd like for this to be the default behavior for Racket. One possible way: Insert a directory level between the `compiled` directory and its contents, with the directory named with the Racket version number with which the code is compiled. Only that Racket version will run that compiled code. (When I've been using Racket version A to run a code tree, and then use Racket version B with the same code tree, I don't mind waiting for a recompile of the code tree, and I'd really prefer it not disturb the code compiled with Racket version A. I also don't mind cluttering disk space with compiled code for Racket versions that I no longer use; I can always make a script to clean those up.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
I don't think I need charity. I thought the vision for the new package system had already been explained adequately. I would be very interested to learn how the model is well-suited to third-party developers like me. But -- I mean this constructively -- I'd be happy if someone simply came out and said this model is great for core developers, we still have to figure out everyone else, and maybe the model isn't great for everyone else. The reason is that I've looked at the new package system seriously 5-6 times since it was announced, and I keep being told that the model is intended for non-core people like me, and that someone else knows my needs better than me. Open source reuse was an especial area of interest to me, the package system is very important, and I've given the benefit of the doubt 5-6 times now. (This has actually stalled most of my public Racket work, one way or another, for about 2 years.) I'm not harshing on Racket; just on how the new package system was sprung on non-core people, and the narrative. It doesn't look typical of Racket. Racket is usually in the position that it could say we have a better idea (on, e.g., module system sophistication, various syntax extension mechanisms and mixed languages support, various aspects of DrRacket, the related pedagogic projects, etc.), and usually that doesn't have to be said, because the superiority of Racket is immediately apparent. That's why I've been a Racketeer for 13 years and counting. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
I think this what's the matter with conflicts, and an arbitrary package putting things wherever it wants, and not having a notion of non-backward-compatibility is similar to what's the matter with using eval for everything or what's the matter with defmacro or what's the big deal about having subroutines in a language. The questioner's position works for them, some other person thinks it's a very bad idea, and you can trot out hypothetical scenarios and anecdotes, but -- since it can be argued to reduce to pragmatic tradeoffs involving unknowns -- you can't (at least I can't) persuade someone who thinks they know better. How about we just say that the module system was originally designed as something that core Racket developers would like to use, having a low friction to moving an individual core developer's side projects into the tidy-looking core, or to doing other kinds of shifting they would like to do in core Racket? Without an acknowledgement that not all third-party package developers will be working like that, nor that everyone wants to make the substantial compromises to facilitate that low friction. For third-party developers like me, I can layer something to work around some of the drawbacks, and, pragmatically, that's what I'll have to do. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Line editing in the default REPL
Eli Barzilay wrote on 12/02/2014 09:31 PM: On Tue, Nov 25, 2014 at 1:29 PM, Leif Andersen l...@leifandersen.net wrote: Just to clarify a bit, we were more thinking of extending the default repl to have line editing features, rather then making xrepl the default, If you're talking about implementing line editing yourself, then my personal reaction to that would be wonderful, but doing it properly is something that is difficult and easy to underestimate I agree fully with Eli. Also, separate from practical benefit of having basic `readline`-like line editing in pure Racket, you could go gratuitously coolness factor on this. For example, I don't think I've seen a non-full-screen character-terminal REPL do syntax coloring, matching paren highlighting, and full up/down cursor navigation within a single REPL input. That's labor-of-love coolness, and all who behold it will respect your name. (http://www.neilvandyke.org/racket-charterm/; would help with some primitives and device portability, but you'd still have to layer a lot of work atop that. Offhand, the most nonobvious tricky part I can think of is not getting program confused about where text and your cursor are on the screen. Different terminals will have different behavior when cursor is in the last column, or cursor is in the last row and column, or you're inserting/deleting characters or lines (which some terminals will support differently, and others not at all). You also have to decide how you want to handle the user experience of some kind of Ctrl-L redraw, since terminal screens get corrupted often by text written by other processes, Ctrl-L also helps mitigate terminal quirks you don't yet handle, and terminal-savvy people will expect a Ctrl-L. It's possible to make a self-healing character terminal display, on those terminals that permit reading screen addresses and that have sufficient idle bandwidth, but I haven't heard of anyone doing that yet, and everyone just has a Ctrl-L.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] new package system collections and conflicts
Given the example from the documentation, of the `tic-tac-toe` package and conflicts (quoted at end of this email), instead, why isn't the norm to do: (require tic-tac-toe) Or, when necessary: (require tic-tac-toe/matrix) Why, when one installs a package named `tic-tac-toe`, would one be referencing modules of the package as `data/matrix`? I don't recall ever seeing a situation in which I wanted different third-party Racket packages to be stomping over each other's module-naming namespaces. For people who want to release lots of well-behaved reusable packages, using good practices, with minimal effort and head-scratching, things like this are a problem. 2 Package Concepts A package is a set of modules in some number of collections. Modules installed using the Racket package manager are required like any other modules. For example, if the package tic-tac-toe contains the module matrix.rkt in a data collection, then after tic-tac-toe is installed, (require data/matrix) [...] 2.5 Package Conflicts Two packages are in conflict if they contain the same module. For example, if the package tic-tac-toe contains the module file data/matrix.rkt and the package factory-optimize contains the module file data/matrix.rkt, then tic-tac-toe and factory-optimize are in conflict. A package may also be in conflict with Racket itself, if it contains a module file that is part of the base Racket implementation. For example, any package that contains racket/list.rkt is in conflict with Racket. For the purposes of conflicts, a module is a file that ends in .rkt, .ss, or .scrbl. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] new package system and versions
Any chance of revisiting the new package system's stances on versions -- specifically, on the two issues: 1. Can subsequent versions of a named package (which has an identity) be non-backward-compatible? 2. Can a Racket setup (and even an individual program) have multiple versions of a package at the same time? Regarding #1, the requirement to never make a non-backward-compatible version of a package without giving up package identity is a burden, and a deterrent to third-party package releases. For a real-world example, see http://planet.racket-lang.org/;, where it looks like most of the familiar names (who were going to a good amount of trouble to release already), managed to release packages marked as non-backward-compatible (i.e., PLaneT major version number other than 1). Wouldn't requiring them to never break backward compatibility be a deterrent to releasing at all? Or, if they still released, would `dherman`, following the instructions of Racket to create a new package identity for any backward-incompatible version, have given us packages `javascript`, `javascript2`, ... `javascript9`, rather than `javascript` versions `1.x` through `9.x`. No-backward-incompatibility might make sense for core Racket (although even core Racket has broken this multiple times), but it's a big deterrent to researchers, and to industry developers who are willing to open source components of their larger systems in lightweight ways. Regarding #2, I suggest that should be revisited if #1 is revisited. I think PLaneT got both of these a lot closer to right, at least for third-party packages. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Sam Tobin-Hochstadt wrote on 11/30/2014 10:55 AM: Another example where this happens (and in a way that couldn't be fixed by combining packages) is with typed versions of libraries. If I release a package with the collection `foo`, and then someone else produces a typed version of it, that will probably be named either `foo/typed` (and thus be in the `foo` namespace) or `typed/foo` (and thus be in the `typed` namespace). Personally, I'd much rather have packages respect namespace boundaries, and have a simpler model, and let people call that TR library `foo-typed` or `typed-foo`. (Or, TR comes up with a better scheme for providing TR and non-TR interfaces to a module, and reduces DRY problems in specifying APIs at the same time.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Jay McCarthy wrote on 11/30/2014 12:13 PM: The documentation cited is making clear that there is NO connection between the name of a package and the provided modules. There is no such thing as a package namespace. I'd really like there to be. For third-party packages. Packages may find it convenient to build and provide reusable functionality with many organizational names. This is particularly true of data, as many packages may have useful data structures. Of course, as such support code becomes very useful and developed, it makes sense to sprin it off into its own package. Are you saying that `data` is some kind of classification of what this module is about, and in this case specifically, this module, which is part of some more specific package, happens to be regarding general-purpose data structures, so we're putting it over here in the `data` area of a shared namespace hierarchy? If so, I don't understand why that would be considered a good idea. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Jay McCarthy wrote on 11/30/2014 12:30 PM: On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org mailto:n...@neilvandyke.org wrote: Jay McCarthy wrote on 11/30/2014 12:13 PM: The documentation cited is making clear that there is NO connection between the name of a package and the provided modules. There is no such thing as a package namespace. I'd really like there to be. For third-party packages. I do not know what a third party package is. I'm thinking of *non*-core-Racket-developers. Who have different needs than core Racket developers. It's good that Racket is blurring the distinction, but the needs still aren't necessarily the same. I say third-party as shorthand familiar to me, but perhaps there's a better term. Packages may find it convenient to build and provide reusable functionality with many organizational names. This is particularly true of data, as many packages may have useful data structures. Of course, as such support code becomes very useful and developed, it makes sense to sprin it off into its own package. Are you saying that `data` is some kind of classification of what this module is about, and in this case specifically, this module, which is part of some more specific package, happens to be regarding general-purpose data structures, so we're putting it over here in the `data` area of a shared namespace hierarchy? Yes, although this is just for the benefit of search and reading docs; it has no technical enforcement. If so, I don't understand why that would be considered a good idea. It is a principle to create general purpose reusable code in the package ecosystem rather than little archipelagos with lots of private code that gets duplicated and has clever names. I keep wanting to encourage lots-and-lots of packages, and they can be packaged and released in a very lightweight yet well-conceived manner. To go back to your example, if it's a useful general-purpose data structures library, then that's another package, which should be very easy to do. If the package author isn't ready to split it out, then they're not ready to split it out, so no sense talking about it. As far as I can tell, in no case is this `data` namespace relevant. Side note: I really don't think ontological classification of package topics belongs in package names. Topical classifications evolve over time, and independent of the objects themselves. Classifications belong in directories, not in names. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new package system collections and conflicts
Sam Tobin-Hochstadt wrote on 11/30/2014 12:52 PM: Are you saying that `data` is some kind of classification of what this module is about, and in this case specifically, this module, which is part of some more specific package, happens to be regarding general-purpose data structures, so we're putting it over here in the `data` area of a shared namespace hierarchy? Yes, the idea is that it makes sense for `data/hamt` to come from the hamt package, and for `data/fector` to come from the fector package (this is currently the case on pkgs.racket-lang.org). If so, I don't understand why that would be considered a good idea. Because the client of these modules shouldn't have to think about which package they belong in to use them. This gives the package developer freedom to combine or split packages without requiring code changes from clients. I think this might be centralized, core-Racket-developer, thinking. I think that some people might be trying to herd decentralized development to build what looks then like a tidy, centralized library. This would also explain why the new package system originally advised to use generic names for packages, which I think is not a great match for organic, decentralized development. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] generic API names considered harmful
Roman Klochkov wrote at 07/06/2014 10:15 PM: What about 3rd party modules? For example, should http://planet.racket-lang.org/package-source/dherman/syntactic-closures.plt/1/0/syntactic-closures.ss provide syntactic-closures-compile, syntactic-closures-execute and syntactic-closures-scheme-syntactic-environment ? Idiomatic names might be compile-syntactic-closures, execute-syntactic-closures, etc. If this library became a very common thing to use, familiar to most Racket programmers, maybe someone would come up with catchier names eventually (like call-with-current-continuation became call/cc). Collections may be renamed. Eventually collection names will become longer, because they have to be unique (like in java: org.apache.commons.lang.builder.ToStringBuilder). Besides we have modules and prefix-in. I suspect that, in practice for the foreseeable future, if we use non-generic names, we won't have many collisions. With the level of third-party reuse that I and my consulting clients have been doing over the last 10 years with Racket, I found that we only rarely use prefix-in. This is out of over 1,000 Racket modules and over a million of lines of Racket code, written by several people of varying background and style. My recollection offhand is that, when we have used prefix-in, it's for improving code readability when: * using the profiler (due to its use of generic names like render, used in large modules that often dealt with more prominent/likely ``render'' concepts), * using the old SSAX/SXML PLaneT packages (due to not-entirely-idiomatic API and packaging), and * using some SRFI implementations (due to name conflicts), * doing Scheme/Racket dialect language work (to keep straight what dialect's identifiers we're talking about in a module). All other times I can think of, having sensible non-generic names and not needing the headache of prefix-in has seemed to be a win. Granted, I have a research interest in much more heavy fine-grain reuse, and if that's ever realized, I assume we'll see more identifier collisions and more confusing overloading of terms (e.g., the several different kinds of date objects I've seen in various code). I couldn't say for certain that generic names and prefix-in (or some other facility) wouldn't start to be practical at that time; I'd have to wait and see. Of course, the programming language technology is not the only way that these problems are solved, but can be solved in the ecology of development and reuse (e.g., as development and reuse sophistication increases, we might actually see fewer different kinds of things called date than we see now, since one kind might mature more, and consequently people might less often have occasion to make an alternative one). Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] generic API names considered harmful
For documented public API of modules that are part of core Racket, shouldn't pretty much all the identifiers be descriptive enough to be unique within the scope of core Racket? (Excepting name conflicts from SRFIs and teaching languages?) I've now noticed generic API names like make and render in core Racket modules written by, I think, 3 different very smart core Racket developers. I don't understand why we're still doing this. Was it for use with the unitssignatures (which are more trouble than they're worth, IMHO)? For code using these APIs, for readability (since any generic names in a module are relative to what that module is about, not the possibly many modules that module uses), I end up using prefix-in on modules with generic API names, which is still harder to read than natural identifiers. And even if I do the prefix-in like foo-lib:, with a colon on the end, foo-lib:make is still harder for someone reading the code to look up the identifier in Racket doc search, compared looking up a unique API identifier like make-foo or foo-make. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
Loop syntax and sugar is fine. And having #:continue and #:break keywords at the top of the form is sufficient warning of surprises ahead, IMHO. I do have a minor ongoing concern that people coming from other languages lately latch onto the for family of forms from the start, don't get enough exposure to named-let, and/or mutually/self-recursive procedures, and then end up shoehorning problems into the for forms (with flag variables and redundant checks and such). break and continue can be good shoehorns. I still half-seriously like the idea of having unlockable language feature achievements, like unlockable equipment in video games. I might play with that idea soon. Neil V. attachment: neil.vcf_ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
If adding breakcontinue features to your fancy iteration syntax, I propose that any uses of these features in source code be somehow very prominent. For example, perhaps there is a keyword that must be at the top of the fancy iteration form, something like #:enable-continue-here-because-programmer-cannot-be-bothered-to-write-this-in-idiomatic-racket. This prominence warns readers of the code to be on the lookout for surprise control flow (like they would on the rare occasion that they saw a call/ec around a loop). It also hints to newbie programmers that they are discouraged from simply transliterating syntax from other languages (rather than learning better control flow and structuring techniques). Neil V. attachment: neil.vcf_ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] lab notebook on learning process
Jens Axel Søgaard wrote at 05/06/2014 02:02 PM: Sam: Could we - warn people when they use `time` in DrRacket? - provide a performance mode that runs programs out-of-process, or just in another place? - something else? I like this. DrRacket has a performance mode already (disable profiling and debugging) in the (hidded part) of the language dialog. The casual beginner is not likely to recognize it as such though. How about an extra button, a Run Benchmark button? In addition to these, would it make sense for the REPL banner in the Interactions pane to indicate when DrRacket debugging and profiling are on? This would be a hint to people about some of the common parameters affecting performance, along with Racket version, memory limit, GC, JIT,general platform, CPU arch, and maybe number of cores Racket knows about. When showing the run of some timed code on the email list, we can even copypaste this banner with it, as a quick way to convey some of the pertinent parameters of our setup. Maybe don't show this info in student languages, but show it everywhere else. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] lab notebook on learning process
Just remember, any self-respecting benchmark feature of a platform will detect standard benchmarks and substitute hand-tuned assembler. :) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] comments on comments on learning Racket
Sam Tobin-Hochstadt wrote at 04/26/2014 07:26 PM: On this topic (which is about the Choose a language language that DrRacket starts in when newly installed), I think we should just delete all of this code, and start in the Racket language. How about make Run and other very language-specific DrRacket operations require a #lang line? When the operation is invoked and there isn't a #lang line, pop up an explanatory dialog box that lets user click on button for desired language. Button inserts #lang at top of file before continuing with operation. (I like this better than having a default #lang line, because you'll get people accepting the wrong default, different people with different defaults, etc.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] comments on comments on learning Racket
Sam Tobin-Hochstadt wrote at 04/26/2014 08:06 PM: On Sat, Apr 26, 2014 at 7:58 PM, Neil Van Dyke n...@neilvandyke.org wrote: Sam Tobin-Hochstadt wrote at 04/26/2014 07:26 PM: On this topic (which is about the Choose a language language that DrRacket starts in when newly installed), I think we should just delete all of this code, and start in the Racket language. How about make Run and other very language-specific DrRacket operations require a #lang line? When the operation is invoked and there isn't a #lang line, pop up an explanatory dialog box that lets user click on button for desired language. Button inserts #lang at top of file before continuing with operation. (I like this better than having a default #lang line, because you'll get people accepting the wrong default, different people with different defaults, etc.) This isn't quite about the issue I'm talking about, although I think this is a good idea for helping people deal with (some) problems with having the wrong language. What I'm referring to is that when you download DrRacket for the first time, and open it, it puts you in a situation where nothing works, until you choose a language. I think we should get rid of that, and switch to defaulting to the current Racket language. Yes, but I thought what I described addresses that problem as well. (And avoids making a new default from the first run, which I think is problematic.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] comments on comments on learning Racket
Sam Tobin-Hochstadt wrote at 04/26/2014 08:13 PM: I'm confused about what you're suggesting, then. Is there a difference, under your suggestion, between opening DrRacket for the first time, entering `1` in the definitions window, and hitting run, and doing that same thing in an existing DrRacket where we've already selected the Racket language? No difference. No default/preference setting for language. People will learn what they want and either type the #lang line, or click the button. Until people know what they want, they'll keep getting the explanatory dialog popup. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] pi, was: Re: [plt] Push #28592: master branch updated
Matthias Felleisen wrote at 04/22/2014 01:37 PM: I think we should dedicate this commit to Kate Bush's PI song (or vice versa?): https://www.youtube.com/watch?v=kZSHr5E7fZY Are Kate Bush dedications a slippery slope? Software developers will tend to work towards the metrics. Soon the canonical Kate Bush catalog gets exhausted, and some desperate programmer winds up coding Bagger 288. http://www.youtube.com/watch?v=azEvfD4C6ow Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] class implementation and make-primitive-class
For purposes of your course project, couldn't you make your own class-instance object system, atop structs or hashes, that gives you whatever dynamic programming features you want? It's very-very easy to do a basic one (with single inheritance and single dispatch), until you get into speed optimizations. Or, if Swindle has a MOP, you could use that. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] planet bug tracking system spam
Robby Findler wrote at 04/14/2014 01:27 PM: I think that the problem Neil is having with it is the ridiculous amount of spam that gets trapped inside it. (But correct me if I'm wrong, Neil!) I also have other objections to it. But if Doug is still using it, I guess leaving it running makes sense. Making an opt-out at this late date doesn't make sense. I will find some other way to punish it. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] planet bug tracking system spam
Can the PLaneT bug-tracking system be shut down, please? (I have never wanted my packages to be in the PLaneT bug-tracking system. It has never been anything for me but counterproductive and annoying. It was not there when I first added my packages to PLaneT. I really-really want to opt-out of it. But maybe whoever maintains it will decide that shutting it down is less work than adding an opt-out feature.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] zoom-to-fit-width text in new documentation layout
In the new documentation layout, the zoom-to-fit-width behavior is bad. I mentioned this before (http://lists.racket-lang.org/users/archive/2013-November/060480.html;), but I don't recall hearing any rationale, and it doesn't seem to have changed. Is this going to be changed, or do I have to write a Greasemonkey script? Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
* Is anyone up to auditing the C code? To support my earlier concern (http://lists.racket-lang.org/dev/archive/2014-February/013935.html;), you've probably heard in the last few days about a C oops bug in OpenSSL that has compromised the private keys of 2/3 of the Internet for over a year now. I think we are going to keep seeing exploits like this in SSL/TLS/etc. implementations, because some of the protocols are hairy, and the implementations don't seem to be perfect like they we need them to be. * Are all the new (to Racket) OpenSSL code paths enabled by this change disabled *entirely* by default, or are there some new-to-Racket code paths that can be negotiated by the other party with the default Racket use of OpenSSL? The reason I ask is that I believe that the fewer unnecessary OpenSSL code paths available, the fewer OpenSSL vulnerabilities available. (BTW, I'm not harshing on OpenSSL entirely. OpenSSL been indispensible for some of my work, dealing with myriad oddball security protocols that no one wants to take the huge development cost hit of coding and validating from scratch. But I don't have a high level of confidence in the code.) Neil V. Edward Lee wrote at 04/09/2014 04:20 PM: I previously submitted this patch in late January; I've not received any progress updates with regards to this patch recently - did this patch get lost between then and now? This patch adds Perfect Forward Secrecy to Racket's OpenSSL bindings. This patch has been tested on Ubuntu 12.04 (and appears to work correctly in a production environment). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ECDHE patch for Racket's OpenSSL bindings.
Edward, your patch sounds OK to me, FWIW. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Too many license files
For at least third-party packages (though you might want something trickier for core Racket)... I'm not a lawyer, but I figured that, for most packages I author, I probably don't *need* to include the full text of a well-known license (e.g., LGPLv3). Instead, I give the copyright notice, state that the license using the recognized full name of the license (and a URL), and then some disclaimers. I include this legal info in metadata in info.rkt, and McFly makes it appear automatically in the documentation (with, e.g., LGPLv3 at the top of the document, and the free-form legal blurb at the end of the document). Example at: http://www.neilvandyke.org/racket-roomba/ I've started to also add a one-line copyright notice at the top of each source file in the package, something like ;; Copyright Neil Van Dyke. See file info.rkt. (I might have to move to a legal notice comment block at the top of each file, but I'd really rather not. Notice blocks don't seem to be a barrier to abuse anyway.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [patch] OpenSSL ECDH(E) + DHE support.
Edward Lee wrote at 02/08/2014 05:52 PM: [...] Racket's OpenSSL bindings do not currently enable the ECDH(E) and the DHE ciphers, which are needed for perfect forward secrecy. I've attached a patch that: [...] First, thanks for taking the initiative and contributing. Second, I feel a little embarrassed saying this, since I don't have time to volunteer myself right now, but I think the following is important... I suggest that any contributions touching SSL in the core need careful auditing by someone who understands the mechanics fully. If Edward is an expert on this aspect of OpenSSL, his audit would be fine, but otherwise someone else has to audit it. To emphasize: The SSL infrastructure and OpenSSL are both hairy, and a small mistake can defeat SSL altogether without being detected for years. This has actually happened before, notably with SSL traffic on Debian and Ubuntu systems being compromised for over a year by a one-line mistake (https://www.schneier.com/blog/archives/2008/05/random_number_b.html;). From a Racket extension perspective, in addition to possible logic errors of API usage, there's also possible C memory errors through the FFI. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket v5.92
The 5.92 CSS also doesn't seem to differentiate the different link types by color or other visual emphasis. IMHO, this is a step backwards, especially when it comes to visually distinguishing the three kinds of links: (1) identifier definition; (2) tech, and (3) everything else. As I said in an earlier message on the CSS, overall I think the CSS is an improvement, but the new links appearances are a poor for reading typical Racket docs with their plethora of links. Neil V. Asumu Takikawa wrote at 01/27/2014 10:54 AM: BTW, the 5.92 docs are missing some of the recent CSS changes from HEAD. Could we cherry-pick some of those for 6.0? For example, the blue boxes don't work here: http://docs.racket-lang.org/inside/Evaluation.html [...] _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] new package system status
What's the status of the package system? This morning I thought I'd compromise, and use the new package system for a package that would only ever need one version installed per Racket installation (though I still really want multiple-installed-version support for libraries, like PLaneT has in some form). This was the fourth time I tried to use the new package system, and what I found was: * The documentation for the package system in 5.3.6 does not seem to reflect previous discussion, and the chapter title still says (Beta). * https://pkg.racket-lang.org/; has roughness like requiring JavaScript to navigate, which is not only bad for browsers but bad for search engines. (Usually, for this kind of site, we'd want to start with a page structure, and then add in backward-compatible JS for slickness.) * How are people even supposed to view package documentation while browsing packages on https://pkg.racket-lang.org/;? For example, I looked at a package that I knew had documentation (someone had put an old version of one of my PLaneT packages into pkg.racket-lang.org[*]), and the only way one could view the documentation in any form is if they knew to navigate several clicks through the Github repository to find the .scrbl source file buried in one of the directory trees. I understand that PLaneT was a pain to package for, especially without McFly, and so people releasing packages like that the new package system means less immediate work for them (just put github repo URLs for them all, and let G-d sort 'em out), but it's unclear that the new package system is improving its third-party packages story. Is it still focused on breaking up core Racket, and someday we'll see more thinking about third-party packages? [*] Ahem, in the process of someone forking my package into the new thing, they lost my name from the metadata, broke my legal notices, and added a LICENSE file that claimed copyright to their name. I'm sure that was just a careless accident, since that package has some of the very first Scheme code I ever wrote, and nobody would claim ownership of it intentionally. :) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] reading :foo as keyword in Racket 6.0?
Any chance that 6.0 will read symbols beginning with : (other than : exactly) as keywords? (I was thinking that a major version number might be a good time to do this change, in case anyone is concerned that the change might break some code somewhere. IIRC, someone said there was a SRFI implementation that kludged its own keywords from symbols and might need a small tweak in response to this change. I'm not aware of any other code that would be affected by this change. Racket could continue to *write* keywords with #: for now, if that makes the change easier.) P.S., This change would make this the most magical holiday season ever. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] should package X imply package X-test?
I'm speaking of third-party packages only; I don't know about the packages that make up core Racket. (But perhaps whatever is done for any special needs of core Racket can avoid complicating things for third-party packages.) For third-party packages, for the audience of technical users of Racket, I think that getting documentation, source code, and tests by default is a good thing. Not only do technical users often want those things, but IMHO we should be encouraging people to use those things. This could be the simple case. For use or installation of third-party packages on very small devices, such as on an OpenWRT router, or for packaging shrinkwrap apps, maybe there should be a directive in info.rkt for what files can be excluded in ``tiny'' installations, in addition to not including docs. This seems like an unusual case, but seems like there is a simple solution, while also keeping the usual case simple. For third-party package authors who want to avoid some big dependency in the tests (e.g., huge data set, or dependencies on some other packages), maybe the solution is the same as ``tiny'' above, maybe they need to separate out some of their tests into a separate package, or maybe the dependency is not all that necessary. This too seems like an unusual case to me, although I do have one package myself that kinda runs into it (non-small test files in http://www.neilvandyke.org/racket-mediafile/;). Again, it seems to me like the solution for this unusual case is simple and keeps the usual case simple. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revising Racket's home page
Sam Tobin-Hochstadt wrote at 08/20/2013 09:40 AM: Are you referring to the Quick tutorial? I don't think that's aimed at children, per se -- just people who have no experience w/ Racket. OK, I can only offer a single data point: to me, one glance at the Quick tutorial looks like educational language for children; close browser tab and find another thing to look at. I don't know how anyone else perceives it. I also don't think we need to give up and assume that we can't create a page that works for everyone. OK. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revising Racket's home page
Sam Tobin-Hochstadt wrote at 08/20/2013 09:52 AM: Can you say more about why this is? Is it the pictures? Yes, I scroll down the page and I see pictures and a simple picture language, and it seems to be using them to introduce some pretty simple and familiar concepts, so I assume it's for children. How does it compare to one of these tutorials for Processing: http://processing.org/tutorials/ ? Processing is considerably cooler, in a hipster-designer way, than Racket. Processing has street cred before people ever see a tutorial. Cool kids start from a very different position than us nerds, and even if they shouted, Look at my circles, pledge dog, look at them!, people would lap it up. And the Processing circles probably would be cool circles. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] racket 5.3.6 db/postgresql ssl performance fix
Did a PostgreSQL SSL performance fix get into 5.3.6 pre-release in some form? In the pre-release I just downloaded, I don't see Ryan's original fix to collects/db/private/postgresql/connection.rkt. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket 5.3.6 db/postgresql ssl performance fix
Thanks, Ryan. And thanks for the earlier reminder for me to test the pre-release; I was distracted with other work, and probably would've missed this pre-release. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
Matthew Flatt wrote at 07/13/2013 02:56 PM: Others seem overwhelmed by the details, unsure of how it will all work out, and disconcerted by conflicting messages from others who seem to understand the issues. BTW, I don't know whether I'm involved in anyone being disconcerted. If I am, please let me clarify that I agree that this effort looks like a win for development of variations on core Racket, and for packaging of shrinkwrapped apps built with Racket. (Praisecondolences to those people doing a lot of non-fun work to achieve those goals.) In addition to those goals, I also had some research and advocacy goals that are affected by the package system model. Now is not the time to get into that, but perhaps we can discuss at a later date, as the model evolves in subsequent versions of Racket. Much secondarily, there are lots of little details, about which different people will feel differently. I suspect we'll all quickly get accustomed to the little details, and if any little detail becomes ornery for lots of people, it could be refined. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Matthew Flatt wrote at 06/18/2013 07:59 AM: In principle, you should add a versioned dependency on racket to indicate that the package does not work with version 5.3.4, and so users of v5.3.4 should get an earlier revision of the package. Just a general comment... For production use, I try not to have libraries push people to new versions of Racket without good reason. Despite my general awareness and practice, I was actually bit by this problem recently. A consulting client who used one of my open source libraries in production had a problem that I had addressed in a new version of the library. But it turned out that an interim version of the library added a dependency on some new Racket feature, and client's production setup would be disrupted if they had to move Racket versions (increases unknowns). I ended up forking my own library for the client, and merging the fix into their fork. In the more distant past, I think I've also had at least one situation in which I made a Racket (or PLT Scheme) library version use some new Racket feature, then in a subsequent version I reversed this change, so that it could work with an older Racket version. This doesn't have to be a big encumbrance -- I do adopt new Racket features when they are win (e.g., submodules, define-logger), but I try to make small efforts to avoid requiring newer Racket versions than I really need, since pushing people to new Racket versions does seem to cause problems in practice. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ready for the package switch?
Carl Eastlund wrote at 06/18/2013 01:36 PM: rantI don't understand why version control systems don't take directories and renames more seriously, because this stuff is part of the development cycle and should be recorded like any other change./rant This doesn't help, but... I think the reason is that it's hard to do, so most SCM systems haven't even tried. It's very common for a rename to be a delete-plus-add in the model. Or, in an RCS/SCCS/etc.-backed system like CVS, for someone to simply rename the files in the repository server's filesystem and break any branches that did not want those files renamed. Perhaps the most sophisticated SCM I've used, Atria ClearCase (a descendant of Apollo DSEE) in the early-mid 1990s, had a much more sophisticated model than the others, and, IIRC, even did fancy things like monitoring filesystem operations(?), but it cost a lot of money and required a lot of sys-admin. Git's free-ness and popularity makes it the obvious choice to use nowadays, but in my limited experience with it, Git seems to have a lot of evolution of let's add on yet another somewhat different concept to our numerous existing concepts that originally built upon some scripts that Linus found useful for managing kernel patches, rather than nailing a clean and sufficient model from the start. This is a source of frustration to those of us who have used a dozen other SCM systems and recall basic things being easier to do in the past. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Laurent wrote at 06/07/2013 02:12 AM: What I'd really like, for the sake of flexibility / ease of use, is to have no explicit keyword argument, but all arguments are implicit ones, so that you can call a function by mixing by position and by name as you like, without having specified so in the function's header. (Visual Basic[1] and Python[2] do something along these lines.) I have used this in Python, and it is kinda neat and has its uses, but overall, I prefer the current way in Racket. One reason I prefer the current way in Racket is that, if every argument can be positional, then you have to keep this in mind when adding keyword arguments to a procedure that is used by other code: new arguments can only be added at the end of the list, even if that does not make the most sense for documentation purposes. Another reason is that the keyword arguments restrict the syntax somewhat, so, when a mistaken extraneous sexp is where we'd expect a keyword, it is flagged as an error, rather than be considered a positional argument. Related to the previous reason, if the programmer is *intentionally* intermixing keyword arguments with positionals, such as (foo 37 #:x 41 74 #:a 34), that seems error-like that I wish they would get an error and change their ways. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
I've been hesitant to comment on any of this, for three reasons: (1) I've read the new package system documentation on at least 3 separate occasions, and -- perhaps because I'm biased by having already formed some ideas about where I'd like things to go -- I've had trouble understanding the rationale behind a lot of the decisions; (2) I'm not familiar enough with DrRacket internals to know whether there's some unusual barrier to keeping things simpler than it seems like people have been talking about, so I can't help with that; and (3) I'm confused about what's already decided and what's open to discussion, and suspect it would take many more hours to understand. Since I'm heavily invested in Racket packages but lost in the current discussion (sorry), all I can offer right now are some comments that start from the concepts of the original PLaneT, in case anyone who understands the new system sees anything of interest in this quick brain dump... For all of my packages, as well as any package I can imagine, I think that the original PLaneT got many things right or close to right: * Some kind of unique package-name controlled by a developer. * Multiple versions for a given package-name (I'll call them package-versions in this email) can be installed, and there is some version selection mechanism. * Files from a package-version end up grouped together in the directory structure, specific to that package-version, and certainly not mixed into directories with files from package-versions of different package-names. * Flat namespace (let's ignore the PLaneT package-owner part for now), without attempt to name packages according to some topical ontology. * Metadata in info.rkt. I was expecting to use this original PLaneT as a starting point, and evolve it in ways like the following... * In addition to the (planet ...) require-specs, package-versions also can come from http:, https:, and git: URLs. (github: would also be OK.) Each such URL would identify trees or a tarball. Then we see how people choose the PLaneT server vs. HTTP vs. Git over time. * Simple web-of-trust package-version public-key signing of package-versions (e.g., URLs plus hashes of contents), to start with, perhaps initially with only centralized repository for signatures. Soon build distributed web-of-trust, plus multiple repositories so organizations have option to keep their signatures separate. Build mechanisms atop that, including advancing the state of the art. * Maybe improve the version-selection and compatibility support. Investigate whether it's worthwhile to separate out the backward-compatibility information from the static package-version distribution (and especially from the version number), or whether in practice there are simpler ways that are satisfactory. * Maybe a facility in info.rkt to provide aliases for require specs. Otherwise, people writing nontrivial multi-file code that uses other packages from PLaneT/whatever end up having to make wrapper modules so that we don't goof our require-specs and accidentally depend on multiple package-versions for the same package-name. Note that, with URLs, these aliases *might* be the only actual package-name construct in the HTTP/Git system as distinct from URL similarities of package-versions. This info might be implicit in a package-version's info.rkt's reference to a previous package-version, perhaps coming from an assertion of compatibility info. This might be simpler than it might sound, but it has some interesting implications, including for forking and web-of-trust.) * Automate and simplify releasing in general. With PLaneT, it's been not-unusual for even core Racket developers to avoid releasing some add-on code to PLaneT, perhaps because the clerical stuff was a headache. For the old PLaneT, I was simplifying this with McFly, but with new a package mechanism, I would start with that and then ask what clerical parts still need help. (For example, if doing development in an SCM repository that's accessed directly via require-specs, then releasing a package-version might consist mainly of adding a tag/label. planet-lang.org's directory might even update automatically, given info about a previously-released package-version of the same package-name.) * Use submodule support to support single-file packages, at least for the HTTP/Git package-versions. (module+ info ...). It seems from Emacs history that some people really like the single-file module, it lowers barriers, and now submodules give us an easy way to finally do it. * Do whatever is necessary to avoid blocking the program for few/several-minutes while documentation is reformatted, when requiring an uncached package-version. Maybe even moving it to an async process that's run when idle (Unix nice?) would work. * To put it vaguely: keep things simple in most cases, but don't dumb-down in practically restrictive ways, and
Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.
Mayank, paredit-like features for DrRacket would be good. You might also want to look at some similar work from around the same time as paredit was created: http://cs.brown.edu/research/plt/software/divascheme/ Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.
Asumu Takikawa wrote at 06/08/2013 05:26 PM: (maybe you can port paredit by replacing the emacs text buffer manipulation function calls with method calls into these interfaces) If you wanted to make it even more cool... One of the original goals of Guile (a Scheme implementation that was once intended to be the new GNU language, including for Emacs) was to implement backward-compatibility interpreter for existing Emacs Lisp add-ons code. If someone made a Racket #lang emacs-lisp that used DrRacket text buffers -- even if only a small subset of Emacs Lisp operations -- I think that would earn them some kudos, besides being a fun exercise for Racket's language support. (The hardest part might be translating some of the Emacs Lisp dynamically-scoped variables into Racket parameters. You don't need the dynamic scoping for most of them, though, but you have to decide which ones.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
I'm calling for making Racket and package source transparently accessible, even though not actually bundled into distribution downloads... Racket has a research and education bent, and also attracts some of the more sophisticated developers. For all of these audiences, there's a tradition of accessibility of source, and arguably value in that. I think transparent navigability to source would be appropriate for Racket. Transparent navigability to source could mean that DrRacket will download source on-demand for any binary package that is installed, rather than source having to be bundled with the package, or requiring user to go get source separately. Admittedly, I think source accessibility is not as important in Racket as in Emacs. (Because, for general programming, the Racket documentation is sufficient and the source wouldn't help. And for extension of the programming environment, which was one of Emacs's greatest achievements, extending DrRacket is much harder; plus, the DrRacket source is not much help if you didn't previously tackle the manuals on frameworks and such, which almost no one does.) But there are uses for source accessibility, especially for independent add-on packages, and the principle of being able to easily pop the hood still has value. Example: Imagine I'm in the middle of writing a Racket program and am wondering about characteristics of some kind of I/O port in Racket. With transparent source accessibility, I can just click on an identifier in my program in DrRacket to start browsing the implementation. Maybe I see a possible improvement, or seeing the source pre-empts yet another email list question that otherwise only Matthew could answer, or I feel empowered to go add a new feature. If the source is not as accessible, then I'm more likely to be a mere naive user of the tools, rather than to understand the tools and help improve them. Side note: I'm also looking forward to seeing how this new packaging works out, especially if it leads to me being able to ship small binary packages for iPhone/Mac/Windows, implemented in Racket. (I don't care about open source principles on those very closed platforms; I just want their money. Which is totally different from what I want from an intellectually-inclined open source development platform.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
Juan Francisco Cantero Hurtado wrote at 05/20/2013 11:20 PM: I also think that git submodules are a bad idea for packages. One git repo per package is more simple and less problematic. Do people expect to often do commits involving changes across these package boundaries? If so, would another option be to keep a single repo, not use these Git submodules, and just have Racket translate the Git paths behind-the-scenes for packages coming from this core Racket repo? Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Symlink trouble
Matthew Flatt wrote at 04/17/2013 10:39 AM: It would be great if we could normalize every path to a canonical form, but path normalization in general seems to intractable due to the possibilities of soft links, hard links, multiple mount points, case-sensitivity choices, and probably other twists that I'm forgetting. Agreed intractable, and agreed with your approach. Just FYI for anyone who Googles this in the future and wants a limited but tractable pretty-good path canonicalization for their application (at least on Unix-y filesystems)... canonicalize-path from the following library might be good enough: http://www.neilvandyke.org/racket-path-misc/ (I wrote this for scan-mediafiles in http://www.neilvandyke.org/racket-mediafile/;, and put it in a separate PLaneT package because I've needed such a procedure from time to time.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] amd64 out of memory
On these out-of-memory conditions, you might want to look at the kernel logs for what the OOM-killer said about what processes were running, their sizes, and who it thought the culprit was. If the OOM logs show GB of virtual memory missing, but not used by any userspace process, you might want to email me privately so we can compare notes. I've seen multiple instances of this quite recently, on multiple systems. My prime person-of-interest is a particular kernel service that is used actively by only a small minority of GNU/Linux installations. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] planet2
Jay McCarthy wrote at 12/10/2012 02:22 PM: On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke n...@neilvandyke.org mailto:n...@neilvandyke.org wrote: * I'm very concerned about discarding support for mixing versions of packages. PLaneT 1 didn't fully nail this, but I suspect planet2 is punting needlessly, rather than getting data and solving problems (perhaps due to changing mission, as speculated in next two points). My rationale is that what OSes provide is good enough for wide uses and we can more easily build the right versioned package system on top of this than a non-versioned package system on top of one that is versioned. Perhaps some multiple version support can be grafted on later satisfactorily. I'm just surprised by abandoning the problem, after PLaneT made a credible first attempt, and before Racket actually got much experience with apps built from lots of independently-developed packages. I still suspect that multiple versions support is a good thing and doable. I wonder whether the design of a new packaging system would benefited from having worked through the versioning problem in the earlier stages of design, rather than after migrating people from one system to a new one. I don't really know. For example, the various library collections on P1 (like scheme, unlib, etc) seems to me a product of the pain of P1 deployment encouraging monolithic packages. There are also lots of small, loosely-coupled packages in PLaneT. Certainly, getting things into PLaneT is tricky, and sometimes, even if people got one version into PLaneT, sometimes they'd tell people a better version is in Git because they didn't want to go through PLaneT hoops again. And there are other reasons people make monolithic libraries -- this is not at all peculiar to PLaneT. Which is part of why I was planning in my book to push people to developing around loosely-coupled reusable modules, with very low friction to moving the module to PLaneT. I was working on tools to make that a reasonable story. * Related to previous point, it also looks like there *might* (unclear) be a desire to increasingly centralize or canonicalize some of the kinds of library work that I've been thinking are generally best done in a more decentralized and organic manner. If so, have to be careful with this. I assume you are referring to the suggestion to (a) use known collections like data, (b) not give things cute names, and (c) not name things after developers. No, it looked like it might be an implicit, pervasive influence. This would, for instance, make it so that we have net/soap package rather than roap, unroap, and super-soap. I think this is a good thing. We should be encouraging collaboration to produce excellent packages rather than having many 20% solutions. If one has the resources to pull this off, more power to one. I'm not sure Racket has the resources. (One way you could do it is if PLT Design hired expensive full-time engineers who don't have research/teaching commitments. Or you could do it as projects for undergrad team software engineering courses, but I suspect the quality of design and implementation would often not be up to what people come to Racket for.) I suspect there's still a big place for grassroots library development for Racket. So I hope the design of the new package system hasn't been biased away from grassroots needlessly. Above are my main points. Rest of this email is asides, some supporting, and some tangential. All can be skipped. If you want me to see a response, please CC me. * * * Aside #1: On your net/soap example... I think a generally better practice would be to name it soap rather than try to munge a conceptual taxonomy into the name as net/soap, unless net/ is some intertangled framework (which it doesn't seem to be). The taxonomies change over time -- more frequently than the names should. I think one of the PLT lists discussed this before. Thankfully, people nowadays avoid putting these taxonomies as part of the key for most purposes. For example, package namespaces for various GNU/Linux distros are flat, even if they tend to use taxonomies for UI purposes elsewhere. For a negative example fresh in my mind, CDDB is reviled for using genre as part of its key, rather than showing more foresight with their namespace. Aside #2: Don't be *too* hard on the cutesy names. Even when projects do the officially blessed module with boring name, they tend to wind up with better modules arising separate from the official one. If they do eventually move to bring the iconoclast into the fold, blessing it with an official generic name, sometimes they tack a 2, new, ng, or other suffix/prefix onto the old generic name, or sometimes they simply break backward compatibility, so you get people talking about which version of a language you used for an app when they're really asking
[racket-dev] planet2
My biggest comments on planet2... * I like the general ideas of permitting more decentralized sharing of packages (such as through some kind of Git URLs). * I like the idea of making it easier to modify the source of a package and share changes with upstream (which is needlessly cumbersome with PLaneT 1). * I'm very concerned about discarding support for mixing versions of packages. PLaneT 1 didn't fully nail this, but I suspect planet2 is punting needlessly, rather than getting data and solving problems (perhaps due to changing mission, as speculated in next two points). * Other than GitHub support, a lot of what I saw in the planet2 documentation was not intuitive to me, wrt how I was thinking would be a good direction for Racket grassroots package development. It looks like maybe planet2 is biased towards the way core developers work (e.g., centralized, large, monolithic code base, with single version), and/or towards modularizing Racket distributions, rather than towards grassroots package development. * Related to previous point, it also looks like there *might* (unclear) be a desire to increasingly centralize or canonicalize some of the kinds of library work that I've been thinking are generally best done in a more decentralized and organic manner. If so, have to be careful with this. * We'd talked about planet2 on-and-off for years, but I didn't realize planet2 was imminent, so I recently somehow managed to spent a lot of unpleasant time working on PLaneT tools and such that now look moot in light of planet2. Every now and then, the rug gets pulled out from under a non-core developer (this has happened a few times that I know of), and it can be a waste of energy and morale, so we should keep trying to avoid rug-pulling when practical. I have numerous small comments, (like, just from glancing at currently open browser window) you probably don't want to call anything PNS, and the names galaxy, solar-system, and planet would be confusing (something else already called planet that is very related, plus running into HtDP world, universe, etc.). Before I'd nitpick at that small level of issue, I'd need the bigger questions above addressed, and then I'd have to get practical experience with planet2 and comment on that level of issue. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revision to the Language Dialog
Matthias Felleisen wrote at 11/05/2012 10:14 PM: * racket/base (for scripting) * racket (for programming) After thinking about it, I think I see what you mean with the distinction between ``for scripting'' and ``for programming''. But I think this might be confusing. (Explanation... I have been thinking of it the other way around: #lang racket is what you use when you want to just start typing and have everything available and type less text, in a scripting-language kind of way, and #lang racket/base is what one uses when putting a little more care into engineering, and doesn't mind the extra thinking and text. For example, when making a reusable PLaneT package, I think it's good practice to go to the extra effort to use #lang racket/base instead of #lang racket; otherwise, you doom all users of your package to pull in all of #lang racket, which they might have engineering reasons not to do. But I guess you were speaking only of process load times -- that people would use racket/base so that standalone ``scripting'' programs would load quicker from the command line -- not about a quick-scripting nature of the programming activity?) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #25466: master branch updated
John Clements wrote at 10/16/2012 04:51 PM: Data point: I have no idea what define/match does, and the name by itself does nothing to enlighten me. Another data point: If define/match expands to a define of a procedure that dispatches to a set of implementations based on a pattern-match of actual arguments... then the name is exactly what I'd expect for such a feature in a Scheme dialect. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.3 pre-release impressions?
Thanks, Doug. From talking with a few people, it sounds like 5.3 is shaping up pretty normally for a release, and the releases have been high-quality. I was just a little spooked by running into two bugs very quickly (two points determine a line, after all), but I haven't found any since those. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?
Matthew Flatt wrote at 07/26/2012 06:36 PM: I've pushed a repair. Thanks for the report! Thanks, Matthew. Today, I plan to run a large pile of code through the 20120727 pre-release. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] possible 5.2.900.1 bug involving rest argument
Looks like a minor compiler/optimizer bug in Friday's 5.2.900.1 pre-release. I haven't yet found a simpler test case, but you can reproduce by installing a particular PLaneT package as shown below. The line 1275 it's complaining about is the following, which starts a procedure definition that is later applied at toplevel in the same module: (define (charterm-make-keydec keydec-id . keysets) The demo program for this PLaneT package seems to run correctly despite these install/compile-time error messages. Racket 5.2.1 does not give these install/compile-time errors, as is also shown below. $ /usr/local/racket-5.2.900.1-20120727/bin/raco planet remove neil charterm.plt 3 0 [...] $ /usr/local/racket-5.2.900.1-20120727/bin/racket -p neil/charterm:3:=0 andmap: contract violation expected: list? given: '(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 keydec-id . #syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 keysets) argument position: 2nd other arguments...: #procedure:void andmap: contract violation expected: list? given: '(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 keydec-id . #syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 keysets) argument position: 2nd other arguments...: #procedure:void raco setup: error: during making for planet/neil/charterm.plt/3/0 (CharTerm) raco setup: andmap: contract violation raco setup: expected: list? raco setup: given: '(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 keydec-id . #syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 keysets) raco setup: argument position: 2nd raco setup: other arguments...: raco setup: #procedure:void raco setup: error: during Building docs for /home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/doc.scrbl raco setup: andmap: contract violation raco setup: expected: list? raco setup: given: '(#syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:30 keydec-id . #syntax:/home/user/.racket/planet/300/5.2.900.1/cache/neil/charterm.plt/3/0/charterm.rkt:1275:42 keysets) raco setup: argument position: 2nd raco setup: other arguments...: raco setup: #procedure:void $ $ /usr/local/racket-5.2.1/bin/raco planet remove neil charterm.plt 3 0 [...] $ /usr/local/racket-5.2.1/bin/racket -p neil/charterm:3:=0 [...no output...] $ Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket 5.3 pre-release impressions?
Regarding Racket 5.3, I am more cautious than I recall being about a previous Racket minor version release. The information I have so far is mixed, rather that overwhelmingly reassuring. If anyone has comments on their sense of 5.3 reliability at this point, that might help me. Some good news: one of my consulting clients had me do some preliminary testing of their large code base with the Racket 5.3 pre-release, and there has been no problem with that testing so far. However, in testing 5.3 pre-releases with my personally-owned code, rather than clients' code, so far I've found what looks like 2 bugs in the 5.3 pre-release. This was surprising to me, since I expected 0 bugs. I have not yet tried the majority of my personally-owned code. Until I get a better sense, I would expect to keep production servers at 5.2.1 for a while after the 5.3 release. I'm also probably going to go to some trouble to avoid using new 5.3 features in some code that might be deployed to production in the very near term. More information might be reassuring to me. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket 5.3 pre-release impressions?
FWIW, I just tested 16 or so additional PLaneT packages in DrRacket 5.3 pre-release, and no problems. Neil Van Dyke wrote at 07/28/2012 02:56 PM: Regarding Racket 5.3, I am more cautious than I recall being about a previous Racket minor version release. The information I have so far is mixed, rather that overwhelmingly reassuring. If anyone has comments on their sense of 5.3 reliability at this point, that might help me. Some good news: one of my consulting clients had me do some preliminary testing of their large code base with the Racket 5.3 pre-release, and there has been no problem with that testing so far. However, in testing 5.3 pre-releases with my personally-owned code, rather than clients' code, so far I've found what looks like 2 bugs in the 5.3 pre-release. This was surprising to me, since I expected 0 bugs. I have not yet tried the majority of my personally-owned code. Until I get a better sense, I would expect to keep production servers at 5.2.1 for a while after the 5.3 release. I'm also probably going to go to some trouble to avoid using new 5.3 features in some code that might be deployed to production in the very near term. More information might be reassuring to me. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?
Anyone know offhand why this error with 5.3 pre-release from yesterday? UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573] context...: /usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: loop /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: %html-template:transform /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0 I built Racket from source. 32-bit x86 on Debian Stable. I don't think there are any old versions of code in compiled directories being picked up, but I might have missed some, but I'd expect get an error message about the version mismatch. PLaneT html-template:1:1 is currently a bit messy with syntax objects and phases, and might be doing something questionable that 5.2.1 permitted. This works fine with Racket 5.2.1. Unfortunately, I don't have time to debug at this moment. I'm posting now because I understand that a release is close, and I don't know how likely it is that this is a Racket bug. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?
Definitely looks like a Racket bug (or really broken hardware/OS)... If I start DrRacket 5.2.900.1-20120725 and load up the below file, the first few clicks on the Run button give the ill-formed code error, and then, after trying the Run button for 10+ seconds, suddenly Run starts working. #lang racket/base (require (planet neil/html-template:1:=1)) (html-template (hr (@ (clear all) (id foo If I quit DrRacket and start it back up, the problem is reproducible. Problem with background optimizing of some kind? That's all I can spend on this right now; hopefully other people can reproduce based on this info. Neil V. Neil Van Dyke wrote at 07/26/2012 05:18 PM: Anyone know offhand why this error with 5.3 pre-release from yesterday? UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573] context...: /usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: loop /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: %html-template:transform /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0 I built Racket from source. 32-bit x86 on Debian Stable. I don't think there are any old versions of code in compiled directories being picked up, but I might have missed some, but I'd expect get an error message about the version mismatch. PLaneT html-template:1:1 is currently a bit messy with syntax objects and phases, and might be doing something questionable that 5.2.1 permitted. This works fine with Racket 5.2.1. Unfortunately, I don't have time to debug at this moment. I'm posting now because I understand that a release is close, and I don't know how likely it is that this is a Racket bug. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket-5.2.900.1-20120725 read ill-formed code error ?
This version :2:0 is a better test case than :1:1 : #lang racket/base (require (planet neil/html-template:2:=0)) (html-template (hr (@ (clear all) (id foo Neil Van Dyke wrote at 07/26/2012 05:33 PM: Definitely looks like a Racket bug (or really broken hardware/OS)... If I start DrRacket 5.2.900.1-20120725 and load up the below file, the first few clicks on the Run button give the ill-formed code error, and then, after trying the Run button for 10+ seconds, suddenly Run starts working. #lang racket/base (require (planet neil/html-template:1:=1)) (html-template (hr (@ (clear all) (id foo If I quit DrRacket and start it back up, the problem is reproducible. Problem with background optimizing of some kind? That's all I can spend on this right now; hopefully other people can reproduce based on this info. Neil V. Neil Van Dyke wrote at 07/26/2012 05:18 PM: Anyone know offhand why this error with 5.3 pre-release from yesterday? UNKNOWN: : read (compiled): ill-formed code [./../src/validate.c:1573] context...: /usr/local/racket-5.2.900.1-20120725/lib/racket/collects/racket/private/map.rkt:53:19: loop /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:103:0: %html-template:transform /home/user/.racket/planet/300/5.2.900.1/cache/neil/html-template.plt/1/1/html-template.rkt:523:0 I built Racket from source. 32-bit x86 on Debian Stable. I don't think there are any old versions of code in compiled directories being picked up, but I might have missed some, but I'd expect get an error message about the version mismatch. PLaneT html-template:1:1 is currently a bit messy with syntax objects and phases, and might be doing something questionable that 5.2.1 permitted. This works fine with Racket 5.2.1. Unfortunately, I don't have time to debug at this moment. I'm posting now because I understand that a release is close, and I don't know how likely it is that this is a Racket bug. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Official PLaneT account?
Sam Tobin-Hochstadt wrote at 07/20/2012 07:23 AM: I was thinking that it'd be more appropriate to put the 'parser-combinator' and 'tex2page' packages under such an account rather than under mine. Note that it's probably easier for people who need these packages to use them from GitHub with 'raco link', since then they wouldn't need to change any `require` lines. Shouldn't everyone try to eat PLaneT brand dog food? (Not subsist off of Git brand dog treats.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Official PLaneT account?
Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM: On Fri, Jul 20, 2012 at 7:36 AM, Neil Van Dyken...@neilvandyke.org wrote: Shouldn't everyone try to eat PLaneT brand dog food? (Not subsist off of Git brand dog treats.) Whether or not that's the case in general, in 5.2.1 you can do: (require combinator-parser) which can't be replicated with a PLaneT package, but can be replicated with a library set up with `raco link`, so this may be more useful for existing users of this now-deprecated code. In the August release, should collection links support PLaneT versions (whether coming from PLaneT server or PLaneT dev links)? (I don't know the answer; I don't know the philosophy of how these links are supposed to fit with PLaneT.) Regarding the case in general, occasionally it seems to me like there is a dogfood issue there. Which is why I jump on any additional precedent for using Git instead of PLaneT -- jump like an alpha Shih Tzu. Neil _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Official PLaneT account?
Sam Tobin-Hochstadt wrote at 07/20/2012 07:44 AM: Shouldn't everyone try to eat PLaneT brand dog food? (Not subsist off of Git brand dog treats.) Whether or not that's the case in general, in 5.2.1 you can do: (require combinator-parser) which can't be replicated with a PLaneT package, but can be replicated with a library set up with `raco link`, so this may be more useful for existing users of this now-deprecated code. In the August release, should collection links support PLaneT versions (whether coming from PLaneT server or PLaneT dev links)? (I don't know the answer; I don't know the philosophy of how these links are supposed to fit with PLaneT.) Regarding the case in general, occasionally it seems to me like there is a dogfood issue there. Which is why I jump on any additional precedent for using Git instead of PLaneT -- jump like a bloodthirsty Shih Tzu. Neil _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24958: master branch updated
I spent some time working with taxonomies and ontologies, and switched to generally preferring that the permanent names for things be in a flat namespace, and that any organizations (e.g., hierarchical) be separate, indirect, and more fluid. One possible exception is when there is a strong, exclusive, permanent ``part of'' relationship. For example, I think that the PlaneT categories are already getting outdated, and I am glad that the categories are not used in naming. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Robby Findler wrote at 07/10/2012 05:20 PM: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu wrote: - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as these are here for legacy reasons. New code should use XYZ with specific pointers and helpful advice. I'm still using some mzlib in *new* code. Specifically, getpid, this-expression-source-directory, gethostname, and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
If someone has a good reason to get rid of this-expression-source-directory, I'm mostly indifferent. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Error message structure (error-message overhaul)
Eli Barzilay wrote at 06/19/2012 08:11 PM: * There's a whole range of tools that work with the usual file:line:vol: message per line format -- Emacs compilation buffer, the on-line-check-syntax-like error highlighting, log parsers, etc. (The emacs on-line checking is something that two people already noticed as a victim...) FWIW, I think I can make the Emacs stuff work better with the new error message format. On a related matter, it's helpful when file names in error messages contain a complete path. (Prior to these new error messages, for example, raco setup would produce a mix of relative and absolute paths in error messages.) Performance-wise, for exceptions involving paths, if resolving a complete path happens to be expensive... If the site that constructs an exn that includes a relative path also has a way to include in the struct a complete path to which the path in question is relative, that would let error message rendering show a full path without slowing things in cases in which the exception is handled without rendering the path. Or maybe resolving a complete path is relatively inexpensive in cases in which we'd want to raise and handle an exception with a path. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] check-syntax hack: patch to show how many uses an identifier has
John Clements wrote at 06/20/2012 10:48 PM: When I'm using online check syntax, I often look at the lines leaving an identifier and wonder: is that just one line, or are there two or three? When lines overlap, there's no easy way to tell. This can be important in refactoring decisions, or in debugging (how many uses of this thing are there to check?). Yes, I've wondered this too. And in large files, it's often really hard to tell, like in your first screenshot. Maybe, if the mouse hovers over the center point of a binding identifier, there's a tooltip that shows useful info, such as how many references (maybe in what procedures?), and whether it's provided by the module. (I haven't thought about submodules, though.) Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] scribble formatting tweak?
Thanks, Matthew! I really like this. (And I know it was a lot of work to wrangle the HTML and CSS in this case.) It looks good to me as it is, although Robby's suggestion of lowercase sounds good too. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Potential search improvement
Eli Barzilay wrote at 05/29/2012 07:17 AM: I have made a possibly useful improvement to the JS search code. It's not pushed, yet, but I dropped the revised JS code on the pre-built pages so you can try it out here: http://pre.racket-lang.org/docs/html/search/ [...] Eli, looks like a noticeable improvement over 5.2.1 search to me so far. Thank you for working on this. Here's a small quirk on pre: searching for scribble doesn't get the Scribble manual as the first hit, but the incremental search as you're typing gets you the Scribble manual as the first hit for scri through scribbl. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax
Laurent wrote at 05/09/2012 06:55 AM: * Line-width In GEdit, there's an option to show a thin vertical line at 80 chars (modifiable number). I find it of great help to avoid writing long lines, which I tend to not do otherwise or often (inconveniently) look at the column number to see where I am. Such a vertical line might be a good idea for DrRacket. This has come up before. I doubt anyone would complain if someone implemented this and made it optional. Some people (including me) would very much like it. I think that the least-controversial default preference settings would be 80 characters, light gray, and disabled. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
Asumu Takikawa wrote at 05/09/2012 06:13 PM: Any thoughts or suggestions? When you say dictionaries, sequences,, are you including the Racket types hash, vector, and list? If so, would current performance for those Racket types be affected? And does this have implications for what optimizations the compiler would likely make in the foreseeable future? Thanks, Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Marijn wrote at 05/07/2012 10:54 AM: How about prefixing a tilda (~) instead of current-? It looks like a current ;P and also like a snake (parameters could be thought to ``snake'' through the code). Alternatively the at-sign (@) to represent currentness. To make them stand out more (if that is desirable) the same symbol could be postfixed as well. In conclusion, some options are: ~error-port @error-port ~error-port~ @error-port@ I don't mind having stdout, stderr, and stdin as aliases for their current names. As a naming convention for all parameters, however, I wouldn't mind keeping the existing one (current- prefix), although it is a little cumbersome. And even though it's a little cumbersome, a little cumbersome is good, considering that I think parameters are for special occasions only. I was thinking before about alphabetic naming convention, rather than using symbol characters. For one reason, I'd like to save the few remaining ASCII symbol characters for other linguistic purposes, especially considering that Racket is also a language experimenter's platform, and we should leave some characters for future expansion. For another reason, I think that alphabetic names can be less cryptic-looking (and easier to pronounce) than symbol characters, so I try to use symbol characters with hesitation only. I'm not in love with any of the alternative alphabetic naming conventions I've thought of: cur- prefix, -param suffix, -parm suffix, -parameter suffix. (And, if -parm suffix, I'd end up using chicken-parm as an example in language tutorials, making them gratuitously obtuse.) Thinking about this has me coming back around to thinking that current- is not so bad, after all. The main drawback is that one's demos look verbose, when one wants to win over the half-dozen people using Arc. Incidentally, starting an identifier with @ is a little bit problematic because of how the reader handles ,@ (unquote-splicing). Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Matthias Felleisen wrote at 05/04/2012 10:41 AM: On May 4, 2012, at 10:34 AM, Laurent wrote An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Heresy. Racket is actually well-suited for this task. (At the risk of stating the obvious... Well, you have to do some of the mechanics of directory tree traversal manually, unless someone's already written a directory-fold or similar. Other than that, just call the reader for each Racket file, building a hash of symbols to appearance counts, then run down that hash and another of some candidate renaming scheme, doing the arithmetic. A Unix shell script, on the other hand, would be kludgey even for an expert, and probably take one at least as long to write.) Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Eli Barzilay wrote at 05/03/2012 03:48 PM: (parameterize ([stderr (stdout)]) ...) I'm not sure how I feel about shortening these, but an additional consideration is that a naming convention for parameters (so far, prefixing with current-) has been useful. I think a naming convention can help remind people that this won't work with renaming alone: (fprintf stderr Oops!) Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
Matthias Felleisen wrote at 05/03/2012 10:57 PM: I don't think Eli is proposing an elimination of the old names but supplementing the code base with new ones. I am in favor -- Matthias Would be good to have a shorter naming convention for all parameters. The current- prefix is not short, but it's what I've been using when coding new parameters, because that's the convention. Of course, a naming convention is much less important when we have static checking of argument types, but we usually don't. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] skip release
One opinion: I appreciate the diligence and caution. That Racket's releases are high quality is one of the attractions of the platform. I can wait a few more months for submodules. Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] consistency in names and signatures
FWIW... * I have no strong opinion on whether it would be worthwhile, if done in a backward-compatible way. * If done in a *non*-backward-compatible way, it might be a headache. I know of systems in production with millions of lines of PLT/Racket code, and -- although PLT/Racket have been pretty good about backward compatibility -- it seems like every little non-backward-compatible change to a PLT/Racket version, my big clients feel it significantly. I make a little money every time a platform change inflicts pain, since I have to fix it, but it's a net loss for me when goodwill for the platform is eroded. (And perhaps eroded goodwill for me, who is implicitly endorsing the platform, and who has sometimes been asked directly to explain *why* such-and-such changed happened. I would rather be paid to invent and build new stuff, not be responding to the platform breaking.) * I am sympathetic to the idea of being more explicit about types in identifiers. In nontrivial code, I do sometimes end an identifier as -or-false or -or-f, and sometimes I have /error or /exn variants of procedures. It helps me keep track of whether the value can be #f. I usually avoid being this explicit in identifiers in APIs, because it's a little ugly-looking, it has not been idiomatic Racket thus far, and it hasn't seemed necessary. * If we're going to have exception-raising and #f-producing variants of a procedure, how about accommodating both the little language and big language people by having *three* variants: /exn and /f (or /false) for the big language people who want to be explicit, and no-suffix for the littler language people who don't need or want all that clutter. * Would this new world of naming conventions be a good time to replace the somewhat clunky-looking - naming convention with or something else? numberstring? number-to-string? number-as-string? (No non-ASCII, unless I can get an APL keyboard for my ThinkPad.) * Maybe we should consider otherwise simplifying some of these identifiers. To use an example, bytes-string/utf-8 is already a mouthful for a pretty common thing, even before we start adding suffixes onto it. (bytes-string/utf-8 might be too easy an example, since UTF-8 encoding would be an appropriate default for a bytes-string nowadays, and consistent with Racket's current behavior when writing a string to a bytes port.) * Will there be more consistency in how / in an identifier should be read? It seems that X/Y sometimes reads as X with behavior Y, sometimes as X with a Y argument, sometimes as X or Y, and sometimes as something else. Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Fwd: [racket-bug] all/12642: #lang slideshow gets error message module: this function is not defined
How about a change to the purpose of the Languages control? Currently, I think of the control *selecting how to determine* which language to use. Example settings whatever #lang says, Beginning Student, etc. The control could be changed to *present the determination* (by #lang or by some default), and only secondarily as a means to *change the determination* (which might mean automatically changing the #lang in the file). The list of override alternatives would be something like the languages that this DrRacket instance knows about. There would not be a whatever #lang says alternative, since that behavior is always the case. For determining the language when no #lang is present (such as when opening a file without a #lang, or when creating a new file), the default could be a preference setting, with alternatives like Guess, beginning-student, advanced-student, racket, racket/base... and whatever other languages this DrRacket knows. Default alternative would be Guess, which I suspect will work fine for most people. The Guess alternative in this preference could be some heuristics like Emacs and the file command use (later on we could make these heuristics extensible by packages that implement languages), and default to the last #lang used. I suspect last-#lang-used would be fine, and any heuristics are a bonus. (The heuristics might determine language of the file as distinct from #lang languages, and for each file language, keep track of a last-#lang-used. So, a heuristic might recognize Scheme as the file's language, and then Guess would go and find what #lang the user last used for a Scheme file. Again, last-#lang-used, with no heuristics, is fine 95%+ of the time; heuristics are mostly for delighting the user with DrRacket's cleverness the other 5% of the time.) Robby's suggestion of *always* requiring #lang is tempting, and I am close to that, except that it would be nice to support languages that don't syntactically permit #lang. For example, if we wanted to load up JavaScript, XML, HTML, or Java files in DrRacket. Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Robby Findler wrote at 03/08/2012 08:00 PM: I think that the issue probably does not predate Kevin's recent push (distributed places). If you'd like to audit the push security concerns, I'm sure that'd be welcome. I meant that I might need to take a look at it because the example we saw would raise eyebrows with some of my consulting clients. Sounds like it was just a documentation example that is being removed before release, so a non-issue. Separate from that, I wouldn't mind taking a look at security implications of whatever this mechanism, but I doubt I'd notice anything that a PLTer who designed the mechanism hadn't already identified. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Robby Findler wrote at 03/08/2012 05:45 PM: Looks like something is trying to ssh while building the docs? Can whoever figures this out let the list know, or email me privately? Thanks. If it turns out that a use of SSH made it into a *released* version of Racket source, I might have to take a look at it, regardless of how legitimate it is. (Looks like something is trying to SSH, and localhost's fingerprint disagrees with user's SSH known_hosts. So might have been going on for a while, quietly, and only noticed now because of the unusual situation of the fingerprint being different. And noticed because someone was paying attention to the raco setup logs (if that indeed raco setup process was the source, rather than some other process that just had a handle for the stdio/terminal). I don't grep an obvious use of SSH in the 5.2.1 sources I'm using right now.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] odd error message in race setup
Probably mere coincidence, but GitHub has disclosed a security vulnerability of their service, which was exploited to target Rails developers and unnamed others: https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation Neil Van Dyke wrote at 03/08/2012 06:32 PM: Robby Findler wrote at 03/08/2012 05:45 PM: Looks like something is trying to ssh while building the docs? Can whoever figures this out let the list know, or email me privately? Thanks. If it turns out that a use of SSH made it into a *released* version of Racket source, I might have to take a look at it, regardless of how legitimate it is. (Looks like something is trying to SSH, and localhost's fingerprint disagrees with user's SSH known_hosts. So might have been going on for a while, quietly, and only noticed now because of the unusual situation of the fingerprint being different. And noticed because someone was paying attention to the raco setup logs (if that indeed raco setup process was the source, rather than some other process that just had a handle for the stdio/terminal). I don't grep an obvious use of SSH in the 5.2.1 sources I'm using right now.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Any notion of .jar files for Racket?
Brian Mastenbrook wrote at 03/06/2012 03:43 PM: On my system, DrRacket 5.2.1 opens almost 1800 files to start. The vast majority (1376) are .zo files, and another 133 are uncompiled .rkt files from the Racket distribution. It gets much faster once the files are in OS caches, which helps with successive invocations of the command-line tools. The uncached accesses going over NFS could be especially painful, such as if you are running a copy of DrRacket from a slow NFS home dir. (I feel for anyone who has to use NFS nowadays, such as some university communal computers are no doubt still set up to use. NFS and AFS were great 20 years ago, at least when the servers and the network were non-flaky and not oversaturated. Today, we usually want to be using our own computer with a local copy of files (or a USB flash drive with communal computers), not having every file access go out to centralized server. Popular SCM systems like Git and Subversion are good ways to replicate most of our files among systems, and permit disconnected operation in between. I'd still offer students an NFS dir they're free to use, especially new students working from lab computers, but encourage them to use their own local storage for most things. And I'd provide a big Git server with private accounts, which students may use for coursework if they wish.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
Matthew Flatt wrote at 02/29/2012 11:20 AM: So far, I haven't managed to replicate the problem on my machine. Do you have any hints on how to configure Apache to trigger the problem or a server that I might try? I'm afraid I don't have that test setup or notes anymore. I do recall it was with PLT 4.2.5 (CGC collector) on Debian Stable (Lenny) 32-bit x86 machine with the Apache that Debian packaged, in a pretty stock configuration. (This was likely also tested on other systems, but I can't say for certain.) As noted in the email thread back then, every other HTTPS client tool I tried with the same files and server worked fine. It's possible that I made a bug in the Scheme code, but everything I did was pretty straightforward, and I could not see a bug. Unfortunately, I couldn't share a complete test case for a PLT bug report at the time, or perhaps we could have figured it out then. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
Timur Sufiev wrote at 02/27/2012 08:58 AM: [...] Raw ports were wrapped with SSL successfully, but then program has hung up between 2 last actions: sending the request to server and reading its reply. Further investigation showed that in the course of SSL processing the server had requested session renegotiation from the client and would provide it with requested data if the client sent negotiation info to server. [...] This sounds like a problem that I had over a year ago with having Racket (PLT Scheme) send HTTPS client certificates: http://lists.racket-lang.org/users/archive/2010-September/041519.html I did not solve that exact problem. A consulting client had an urgent need, so I worked around the problem by making a Racket module that provided an abstraction over external curl processes, and used that module instead. (Which also probably increased app performance, when that client moved to Web SCGI with Racket and added some new behavior, since large HTTPS and file I/O that happened in the background of Web requests could bypass the Racket process and could also be scheduled by the host OS on other processors.) That particular Racket curl module is not currently open source, but you might find a similar Racket library, or implement your own simple library pretty easily. Also, a tip on one way to decrypt the SSL traffic: http://www.neilvandyke.org/weblog/2010/09/#2010-09-12 Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] collections with no one responsible
Sam Tobin-Hochstadt wrote at 02/17/2012 05:38 PM: 2. We keep it where it is, and don't maintain the code other than fixing life-threating bugs. This is basically the status quo, and I think it means people who report other, non-life-threatening bugs should be informed that we're not maintaining the code, and thus their bug isn't going to get fixed. Side comment, which will probably sound odd: I'm not sure if you mean life-threatening literally in this case, and I'm not criticizing that use, but I think probably best if people don't adopt this term and start using it loosely on the Racket email lists. I believe that some people on Racket lists also work on life-critical or safety-critical systems, and are all kinds of serious about it. Please to be gentle with delicate sensibilities of engineers. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Neil Toronto wrote at 02/14/2012 03:37 PM: Here's the deal, though. This one, even just the lambda r. in a circle, is pushing complexity. We've been approaching logo design too much like language design, trying to cram as much semantic content as possible into a small space or into the fewest shapes. A logo exists primarily to make a good impression on outsiders. Filling it with too much meaning works actively against this. Good point. This full banner would be good printed as a big stripe across light gray T-shirts and hoodies (like university-branded merchandise using unofficial visuals), but is pretty busy as the canonical logo. It's not a bad allusion to Racket's quality of we've crammed a lot of clever stuff into this thing, and you'll need to spend a lot of time going through all of it. The lambda r. in a circle part alone is not bad. I wonder how well it could work with more of a nod to the long-time red and blue of the PLT logos. And I still like the only-slightly-odd-looking parenthesis added to current logo, to make an R idea. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
Eli Barzilay wrote at 02/12/2012 01:50 AM: An hour ago, Michael W wrote: http://img513.imageshack.us/img513/5233/lambdarechopng.jpg http://tmp.barzilay.org/cr.png Yes! I think that cr.png has nailed the design. lambdarechopng.jpg especially got my attention before, but I thought it needed major aesthetic changes to fit Racket better. I think cr.png is a big step in the aesthetic fit direction. cr.png also has nice continuity of evolution from the current Racket logo and preceding PLT Scheme logos. cr.png is a bit geeky and slightly awkward -- moreso than the current Racket logo -- but it's supposed to represent a computer programming platform that grew out of Scheme, so a bit geeky is appropriate. And it has more character (no pun) than the current Racket logo. I could see cr.png as a rough draft of a good final version of the logo, with the design being pretty much complete, and needing only some experimentingtweaking of subtleties of the rendering (in the graphic artistry sense). (I don't mean to discourage further ideas with this opinion; maybe someone has an even better refinement, or some different ideas.) -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket logo
Eli Barzilay wrote at 02/09/2012 09:27 PM: ([2] What Neil VD said.) It's just Neil V. -- no social diseases. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket logo
Of these two, I like the second (plastic) one a bit better. The blue in the glass is distracting to me. Careful that it doesn't look too much like the new Pepsi logo, which has its own burden: http://blowatlife.blogspot.com/2009/02/pepsi-logo-response.html I still like the current lambda logo. Though the lowercase 'R' letter would hang out better with the typical icons for Twitter and Facebook. And peeve Ruby and R people. Marijn wrote at 02/09/2012 11:17 AM: On 09-02-12 02:18, Robby Findler wrote: John Clements and Neil Toronto have put together a new Racket logo that I've just put on the DrRacket splash screen. See what you think. Ooh, shiny! Marijn _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
Another variation, if you're thinking about cloud infrastructure today: you could pretty easily make your own faux PLaneT server that either is for a single app or takes the identity/profile of the app as part of the URL the app uses to access the PLaneT server. The faux server can be a tiny HTTP server process, as it only has to perform a single, simple REST operation. This faux PLaneT server would *enforce* the same profile of PLaneT package versions for the app, and also serve the packages from a trusted cache at app compile time. Or you can use the careful-crafted ~/.racket/ directory approach. I suppose the choice depends on which is easier to do well in your existing infrastructure. It's good to see interest in Racket from cloud people. Feel free to ask lots of questions on the Racket users and dev email lists as you work through your solution. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] dependencies and racket
Daniel Farina wrote at 12/29/2011 07:59 PM: The goal is that a program written, say, three years ago should be able to run the same way it did when it was written, so it's really useful to freeze all the dependencies into the file system somehow and preserve it. Someone else can comment on any automated ways of ``compiling in'' PLaneT packages, and solutions like that. A so-so solution I *don't* recommend... If you preserved the exact PLaneT linkage table, and were very careful, then I think you could preserve the exact versions of PLaneT modules used (required directly, and indirectly). This assumes either: (1) integrity of the PLaneT server, and trust in your connection to it; or (2) preservation of the pertinent parts of ~/.racket. Then you'd want to disable attempts to access the PLaneT server. Perhaps, if you were to automate this, it could be done safely and reliably. Something that has been done for a large Racket-based Web app on production servers is to manually determine all the PLaneT packages that are used, downloaded and extract these packages (in a directory scheme that preserves naming and version info), check it all into their configuration management system, change all the PLaneT module references to filesystem ones, check it into CM again, and audit. PLaneT server access is always blocked, except for the manual download. You can make simple tools to help automate the more mechanical parts of this (I don't know of any such tools publicly available at this time), but the audit is mostly human expertise-intensive. This cloning of PLaneT packages is not something that most people need to do, and it totally spoils the buzz of ``I'll just add a (require (planet ...)) and bam!,'' but it's not too hard to do if you choose to. PLaneT isn't my baby (I think Jay and Eli are leading it right now), but I'm looking into funding so that I can put solid chunks of time into helping with ways to improve PLaneT security. Security is usually a constant consideration in my Internet consulting work. Part of this tentative work will address your concerns about stability, and (in my current thinking) about having the option of removing PLaneT server dependencies for an app. Much of this work has implications for some other network software distribution methods, so PLaneT is both a research testbed and an early practical beneficiary (much like Racket in general). Stay tuned (I have a lot more experience in solving problems than in writing research grant proposals). -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Is it possible / How to use racket in C++ Applications?
x...@ncdy.org wrote at 12/22/2011 03:42 AM: I opened the question on StackOverflow http://stackoverflow.com/questions/8599844/is-it-possible-how-to-use-racket-in-c-applications They pointed me to mailing list, so I want to know if that possible to run racket in such embedded mode? Yes. See: http://docs.racket-lang.org/inside/overview.html#%28part._embedding%29 Note that embedding Racket like this is unusual. Usually you develop the entire application in Racket, or develop most of the application in Racket and then call out to a C library or two. (Reply-To set to the Racket users email list.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
Eli Barzilay wrote at 12/20/2011 01:45 PM: and there no sane way to debug it other than viewing it in all browsers. Asumu, it seems like you're on a good track, but after you get the layout how you like it in your browser, I don't envy you the cross-browser testing to which Eli refers. :) FWIW, this has a few layout problems in the (rebranded) Firefox that's in Debian Stable. Two most obvious problems: font sizes appear wrong, and then change to different wrong when switching to single-column mode, some blocks are overlaid. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
Matthias Felleisen wrote at 12/20/2011 08:02 AM:
I wouldn't mind a second Racket site that has some of what Asumu proposes, say
Racket-fans.org
BTW, I recently registered racket-club.{org,com}, mainly for the humor
potential. If there is a site that someone has been aching to see
happen, which for some reason can't be part of racket-lang.org, let me
know.
(I'd like to see racket-lang.org (hopefully someday racket.org) be
the one-stop shopping center for all things Racket, not fragment that
without a good reason. Ad revenue is not a good reason to fragment.)
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket home page proposal
Asumu Takikawa wrote at 12/20/2011 12:34 AM: How would people feel about adding more content below the fold on the website? Seems OK to me, but two points: 1. Don't let the Twitter and such dominate the page visually. Things like Twitter are for bringing people in, not sending them away or distracting once they're already at the page where we can tell them what we most want to tell them. 2. Don't use the Twitter, Facebook, etc. Web bugs. They already track individual's browsing behavior in detail across most Web sites, but Racket can be better than that, on principle. You can implement this in server-side Racket code. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] scribble -- an ncurses game
Jon Rafkind wrote at 12/13/2011 06:27 PM: A user of mine alerted me to the fact that 'scribble' is a crossword puzzle similar to scrabble. He had it installed in ubuntu so when he typed make in my source tree he ended up playing a game instead of generating documentation. Given how massive Debian (and, therefore, Ubuntu) is, it's not too surprising that something is already called Scribble, but it's a pain. I don't know what PLT wants to do about this, but a Debian maintainer will probably eventually make the call if PLT doesn't first. Here's a Debian package name search, showing multiple Scribbles: http://packages.debian.org/search?keywords=scribble Here's where it looks like that scribble executable is coming from, as /usr/games/scribble, from an optional games package of the current Debian stable release (unless Ubuntu put it elsewhere): http://packages.debian.org/squeeze/all/scribble/filelist http://packages.ubuntu.com/oneiric/all/scribble/filelist Based on past experience, I think that, if a Debian package maintainer is trying to package Racket, and they see that there is already a scribble executable, they will rename Racket's scribble executable to something else, like racket-scribble. Two workarounds for this particular user: 1. Edit the appropriate shell initialization file, such as ~/.bashrc, to put the directory containing Racket's scribble ahead of /usr/games in the PATH environment variable. (/usr/games should be at the end anyway, if it appears at all, just for good practice.) 2. For Makefiles and build scripts, put the full file path to the desired scribble executable. (You would want to do this anyway, if your app has an official Racket version is currently is tested with, and you put your Racket version numbers in your Racket install tree directory names.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] www.racket-lang.org/learning.html
I think that mention of the old Scheme Cookbook wiki should be removed from http://www.racket-lang.org/learning.html;, because it hurts much more than it helps. Right now, it's in one of the most prominent positions on the page. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Missing pregexp syntax in Racket
1. Everyone should acknowledge the JWZ quote, Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems. Regular expressions are Perl's hammer that makes most problems look like a nail. 2. Before someone spends too much time putting the finishing touches on old Unix/Perl regular expression syntax, they might want to look at Olin Shivers's SREs. Sexp-based regular expression syntax can be a big readability win when your regexps get complicated. http://www.ccs.neu.edu/home/shivers/citations.html#sre -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] regexp-split produces immutable cons when rnrs/base-6 is required
As an immediate solution, I suggest simply not trying to use R6RS compatibility libraries with Racket, and instead just use the Racket language. Spend your energy on your application. (I don't want to get into why right now, but my book will have an entire section or chapter entitled Don't Use R6RS.) If you have some super-good reason for wanting to use R6RS, a few more comments... The particular problem you're having is due to rnrs/base-6 wanting to use mutable pairs, while libraries implemented in Racket want to use immutable pairs. They *could* be made more interoperable, but all the ways I can think of would have other undesirable costs, and you'd either end up getting bugs in other places or get really lousy performance. As a workaround if you *really* want to use R6RS, but also use regexp-split, is to make a tiny #lang racket/base module that wraps Racket's regexp-split to convert any pairs in the return value to mpairs. BTW, if you want to parse input like this from a port, you can use Racket regexp operations or a grammar-based parser directly on the port, rather than reading a line and then doing a regexp-split on the line. The latter way is a Perl idiomatic way of parsing a language like this, and that way will also work in Racket, but there are arguably better ways. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] I/O scheduler change --- epoll(), kqueue(), etc.
I already relayed this good news (and the good news about byte I/O recently) to one of my clients, who is a large user of Racket for Web apps. I suspect this improvement will mean noticeably better responsiveness for them under load, and perhaps fewer servers. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
