[racket-dev] Racket 6.0.1 make install-both fails: "Racket virtual machine has run out of memory; aborting"
FYI, a 6.0.1 install from source failed. I can't spend any time on it right now. System: 32-bit x86 dual-core, Debian Squeeze, no virtualization, no swap, 3 GB RAM total, almost 2 GB RAM free. $ ./configure --prefix=/usr/local/racket-6.0.1 --enable-both [[...]] $ make both [[...]] $ sudo make install-both [[...]] raco setup: 0 making: /htdp-lib/stepper Racket virtual machine has run out of memory; aborting Aborted make: *** [install-both] Error 134 Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] for loops with interleaved escape continuations
If adding break&continue 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. <>_ 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. <>_ 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 units&signatures (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] 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] 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 <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] 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 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
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] 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] Feature suggestion
Perhaps also worth considering for inspiration is "elsoc", a useful hack that Emacs has had for arguments quick-reference. "eldoc" does a transient display of the args to the innermost function/form that point is in. This display appears in the ``echo area'' of the frame (roughly, status bar at the bottom of the window), so you can glance at it, but it doesn't get in your face while you're looking at the code and typing. http://www.gnu.org/software/emacs/manual/html_node/emacs/Lisp-Doc.html http://www.emacswiki.org/emacs/ElDoc I'm sure that DrRacket would do it not as a hack like "eldoc", but instead use some info that Check Syntax has. :) Neil V. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] comment boxes
I've been kinda hoping that someday the "binary" format is turned into a plain text format that's usable in any editor or other tool. For example, DrRacket comment boxes could be stored as normal Scheme comments with a cookie token in the comment that is a hint to DrRacket to treat it as a comment box when loading. (There could be a simple convention within this comment block for escaping non-comment-terminators that look like terminators.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] comment boxes
Eli Barzilay wrote at 06/29/2010 04:46 PM: 2. Gnats *does* know how to deal with attachements. The problem is that our cgi library cannot handle a multipart/form-data encoding. (If you convince the author to add support for that, I'll do the rest and add a file attachement option to the web form, and changing drracket to send a file is probably easy too.) I implemented "multipart/form-data" reading a couple years ago as part of robust CGI support for a proprietary application. As I recall, the HTTP "post" MIME-reading code is only a little bit application-specific. (It writes file attachments directly to disk, and adds metadata about the attachments to the form field alist in a certain application-specific (constraining) way. It might also do some stuff with character encodings that are not strictly backwards-compatible with Racket's "cgi" library.) If anyone has time and interest in adapting this HTTP "post" MIME-reading code to improve core Racket, I suspect that the copyright owner would be willing and able to contribute it. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] self-documenting feature
Robby Findler wrote at 07/19/2010 12:31 PM: Sure, but if we have the manpower/energy for this, then it would be nice to have, no? I've been wanting something docstring- or javadoc-like for Scheme and Racket since forever. I have had my own kludges for this since forever, but neither myself nor anyone has had time to do it right. If someone does this right, and it's pleasant to use, I will happily convert all my code over to it and shoot my old kludges in the head. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
To add to what Dave said, quick brain dump, hopefully not too unreadable... Most important for me, I'd like to be able to define multiple (what I'll call for now) repositories (like Debian "apt"). So that I can have, for example, a repository for core official blessed Racket components, one for contributed (what's currently PLaneT), and one for packages internal to an organization or project. (Note that Debian has a mess of features for managing using multiple repositories, which most people don't know about, and which aren't necessarily reliable because not all tools respect the policy and some of the policy is kludgey anyway.) Then, somehow I would like to prevent packages in the contributed repository from overriding those in the core and internal repositories. Guaranteeing this through naming, like Java packages, is one way, though that could be cumbersome. It would be nice to be able to set policy in one place, for what packages and versions may be pulled from the non-internal repositories for a particular large system. For example, since there are cost/benefit tradeoffs, to each third-party package we use, including security and quality, a project team might want to declare "this project may only use package foo version 1.3 and package bar versions 2.1-2.3 from the contributed repository, and no others at this time". (I have started to partly approximate this in one large system by having an intermediary "planet-*.ss" for each permitted require from PLaneT, but that alone does not prevent programmers from adding requires directly from PLaneT.) Package signing to authenticate the packager still seems useful, like it did in the beginning, but that could be revisited in context of whatever other improvements are made. When pulling from the contrib repository, we sometimes also need some confidence that version 1.3 today is the same code as when we vetted version 1.3 six months ago. Maybe that's satisfied by us pulling from a transparent copy we made at the time (and not accidentally pulling from the repository). Or maybe we copy the code and permanently disentangle it from PLaneT, which is expensive and stodgy. Or maybe we trust the PLaneT server and our link to it not to be compromised, which we can for some applications but certainly not for all. Or something else. Separately, breaking up the monolithic Racket distribution into PLaneT-ish packages has some appeal to me, though it is not as important to me as the things above. This appeal is partly pragmatic, such as an assumption that the factoring into modules will have a side effect of fitting Racket onto smaller storage, and the (rare, in my case) desire to pull some released improvement into a production system that is mostly frozen at an earlier Racket version. The other part of appeal, at least to me, is aesthetic, in the same way that a self-hosting language implementation is considered elegant, and we might expect practical benefits to someday fall out of that (or perhaps they don't). If numerous PLaneT requests were actually used for the normal way of installing core, however, either all-at-once or on-demand, that could result in a poorer install-time or run-time experience than currently. So I think a monolithic tarball/zip/etc/dmg/etc would still be a good idea, even if internally it's broken up into packages. If breaking up core into packages, and still offering a monolithic distribution tarball, whatever policy affordances the implementation of that monolithic packaging adds to PLaneT caches might also be applicable to purposes mentioned above, like selectively using a few contrib packages and being confident they don't change. I'm guessing that most of this is relevant only to people doing large development, and who are engineering-inclined and looking to safe effort and stress. However, one does not necessarily need these things to do large development successfully in Racket and using contributed PLaneT packages. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
BTW, I said "repositories", roughly like they are used in Debian, for convenience of quick braindump, but this conflates several distinct concepts you might wish to have. For example, you might want to have "authorities" (like "racket-core", individual roles of person/organization authors of contrib packages, one's own organization, etc.) that are the basis for identifying and authenticating packages, and then "repositories" are simply untrusted copies of packages in any of a number of places that bits may be represented. Then, in this particular example, you have to make this setup, which I think implies some kind of signing, noncumbersome for programmers wishing to use or share packages. I do not envy the person who undertakes some of the design problems involved in extending PLaneT to even greater heights. :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Is the audience HtDP students/teachers, professional programmers, hobbyists, someone else, or all of the above? And, if the audience includes HtDP students/teachers, would all the HtDP examples be revised to use P4P? Or would P4P be something to point to, like, "Hey, students have to use the academic parentheses in the student languages, but Racket is not just an academic (i.e., parentheses) language once students graduate." -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Jos Koot wrote at 07/28/2010 04:00 PM: With a good editor, like that of DrSceme, pardon me, RdRacket, I experience no difficulty at all with parentheses. As I believe Shriram said, the problem is the *perceptions* of people who think that parens are bad, not whether parens are actually bad. For decades, Lisp people have been saying "Try parens! You'll like 'em once you try 'em!" but that argument has not been as persuasive as we might've hoped in getting people to try. Regarding P4P, I have no real opinion on whether offering people a parens-free syntax is a good idea, so long as people who wish to use parens are not somehow marginalized somewhere along the line. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Everett wrote at 07/28/2010 06:06 PM:
(map (lambda (x) ...)
lst)
is more readable in the Ruby form:
map(lst) {|x| ... }
or even in Javascript with Prototype:
lst.each(function(x) {
...
});
I'll respectfully differ with that last assertion.
In my JavaScript experience the last couple years (with plain, jQuery,
Dojo, and AIR), subjectively speaking, that boilerplate syntax quickly
gets unreadable once you start nesting syntax nontrivially. And nesting
is commonplace when you're doing normal real-world AJAX-y things like
finding a DOM element to attach a callback that does asynchronous
XmlHttpRequest that has a completion callback that checks some status
and conditionally iterates over some DOM query to apply some
transformation... Even without Scheme syntax extension to simplify
things, the simple economizing of typing "" instead of "});});"
would help, IMHO.
Here's a real-world example that I blogged earlier this year: I had just
then typed the line of code "annosJson);});}});}". (That break in the
pattern is intended.) Actually, I had typed that with JavaScript
idiomatic line breaks and indentation before, and I felt it was even
harder to get right and read with the line breaks. In Scheme, I
would've just hit ")" until paren-matching showed that I'd closed the
syntax to the desired level. And then the conventional Lisp-y
indentation and/or paren highlighting would've made the code more
'visual' than the JavaScript. Again, IMHO.
Regarding the IMHOs, someone roll out the gaze trackers and brain MRIs
already. :)
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
These most recent examples with "let:", "let*:", and "letrec:" highlight that users of P4P still need to know about Racket semantic distinctions that other languages don't provide the programmer. (Instead, they might have a more familiar "var" or "def", for example.) So I bet that Racket code in P4P is still looking obtuse to many of the same people who refuse to try sexp syntax. (I'm not discouraging this P4P line of inquiry, and I'm curious to see where it goes.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
Shriram, you can disregard my point. I didn't do a good job of making the small point I intended: if one of the goals is to remove the kneejerk objection to sexp paren syntax (which I think is a familiarity thing), even after dispensing with sexp parens, you still have the things like the whoa-another-punctuation-character-what-does-it-mean "let*:", etc. making code look unfamiliar. But I see that you've already stated that as not being within your problem scope, and/or you also have the mitigating internal "defvar", so you can disregard my point. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] can racket-lang.org survive a slashdotting?
Can the racket-lang.org Web server(s) handle a huge spike in traffic, such as if it got on the front page of reddit.com? schemecookbook.org somehow got onto the front page of reddit.com briefly, which seems to have killed schemecookbook.org. This is no big loss, since I think schemecookbook.org gives a bad impression even when it's working. However, I'd hate for racket-lang.org to get its potential 15 minutes of fame, but burn out before sifting a new batch of users out of the gazillion casual browsers. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] a pretty funny home page
At some big get-together of Racket developers and users, there should be a group photo, with everyone wearing black duster jackets and serious expressions. Then label it with a logo: "League of Extraordinary Racketeers" -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] status of the new `racket/gui'
Matthew also made this work with the older GTK-related libraries on Debian Stable. So if you tried before and were thwarted, it works now. (Thanks, Matthew.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Added Sierpinski example to wikipedia page
Could someone official please fix the introduction of that Wikipedia page when they get a chance? The text seems to have suffered some bit rot. http://en.wikipedia.org/wiki/Racket_(programming_language) Racket (formerly called PLT Scheme) is a programming language based on Scheme, produced by PLT. It consists of four primary components: * Racket is the lightweight, embeddable, scripting-friendly PLT Scheme runtime system and JIT compiler. * DrRacket is the PLT Scheme program development environment. * TeachScheme! is a PLT project to turn Computing and Programming into an indispensable part of the liberal arts curriculum. * PLaneT is PLT's centralized package distribution system. Visit for a list of user-contributed packages. (Is Racket a programming language and/or something else and/or a second something else? Are those bulleted items really components of the Racket programming language? Why does the text keep referencing PLT Scheme instead of the Racket programming language? What is PLT? As we get into the bullets, we see that something called Racket is a component of the Racket programming language, without acknowledgment of the overloading? Etc.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Language selection considered harmful
Rename "Use the language declared in the source" option to "Declared" (if first-week CS students don't confuse that with "declarative language")? "Automatic" or "Detected" sound a little bit grandiose, but aren't too bad either. Ideally, only students ever have to change this setting, or even be told about it. Also, if nobody uses the legacy language options, removing those would remove some confusion. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] stepper UI question
John Clements wrote at 08/27/2010 05:38 PM: On Aug 26, 2010, at 11:09 PM, Ryan Culpepper wrote: Another, less invasive, way of making the stepper-definition connection might be on every step to scroll the definitions window and highlight the term from which the redex is derived. For function application the function definition could be highlighted too in a different color. The highlighting would require some creativity for forms like cond (maybe de-highlight clauses as they're eliminated?), but it would be a more incremental approach than forcing the stepper UI into the definitions window. This might be awesome, or it might be confusing; I can imagine students seeing the definitions window jumping around and at a minimum being distracted, or even think that the definitions were changing. I guess I'd want to see it, first. If anyone wants to try out a simple stepper for Lisp-ish code that scrolls your window to highlight the current expression in your actual source files, your Emacs has EDebug: http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/edebug.html It actually only highlights if you have some kind of matching-paren highlighting enabled; otherwise it just puts the cursor on the first character of the expression. My favorite for matching paren highlighting in Emacs is to have this in my "~/.emacs", and to elsewhere configure my cursor to be a full-size solid unblinking red background: (setq show-paren-style 'parenthesis) (require 'paren) (show-paren-mode t) In Emacs, experienced users are already accustomed to the current window switching which file/buffer it's showing, so EDebug just does that when moving between files. I don't know whether that's appropriate for DrRacket. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] stepper UI question
John Clements wrote at 08/27/2010 06:29 PM: My earlier comment isn't suggesting that this isn't useful; it's asking whether doing this *simultaneously* with a separate display that's using substitution to evaluate an expression would cause cognitive overload. If none of the languages people has a flash of inspiration, how about finding an HCI or visualization specialist in one of the universities, and enlisting them as a collaborator? (I'd bet that these multiple views could be made intuitive, if approached as an interactive graphical visualization design problem. Maybe they can get a publication out of the approach alone. Whether an alternative approach using only some arrangement of existing GUI widgets could be made accessible enough to students, I could not guess offhand. Were I not saturated with Racket consulting work at the moment, I'd love to tackle this HCI/viz problem myself.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
Eli Barzilay wrote at 09/22/2010 01:18 AM: The punchline is that your desire to use a local copy is in direct contradiction with the desire to get community involvement in improving the docs. No matter what facility is available for the community to discuss and supplement the docs -- if you have to go out of your way to see it, then you (the collective) just won't do it (statistically speaking). I think that you can make online docs sufficiently immediate value-added that people are drawn to use those. This can be done without compromising local-copy docs. If you did the online right, everyone knows that they get immediate benefit from the value-add of the online docs, so they must have a good reason when they use local copy. For a simple example of docs similar to Racket's can be online and participatory to some degree, see PostgreSQL's. They have their well-structured and well-edited manuals, and online you can browse a version with old-school community annotations at the bottom of each page. I've found some of the annotations very helpful, and I'd hope that they feed future versions of the well-edited manuals. You could also go more of a Wikipedia route. But you don't have a million contributors, and you will be spending lots of effort on quality control, and with a relatively small contributor pool you have to be more cautious about alienating people when a contribution really needs to be excised. Whatever you do, I hope that the goodness of well-edited local-copy docs is not compromised. Also keep in mind that some of us think that, when working on library code or documentation, the interface should present both code and doc easily. Usually, with dumb tools, that means JavaDoc-like embedded documentation. I have a goal to make Racket support this better in the future, and I hope that any new online docs thing won't get in the way, and that I can be compatible with that. The best that you'd get is yet another scheme cookbook I think that some of the problems that the Scheme Cookbook encountered are relevant to Racket. One is that a few characters of Perl operators from some Perl Cookbook item, in the Scheme Cookbook could become a huge page full of different verbose, cryptic, and so-so quality attempts to do a comparable thing in Scheme. (Which, in hindsight, should not have been surprising, when Schemers are involved.) I finally decided that most of the cookbook entries would ideally mostly be pointers to reusable code libraries (*not* copy&paste&munge), which led to me to silly extremes like: http://www.neilvandyke.org/tabexpand-scheme/ There were also various quality control problems for various reasons. I got disenchanted after realizing that messes were being created faster than good content, and that it would've been much easier for me to do something correctly from scratch than find a politic way to fix an existing entry or wrestle with the wiki software to reverse some bizarre structure change some user had done. (This is actually much like software development in general.) A problem that the Racket online docs *won't* necessarily have is that of scope: as I recall, the Scheme Cookbook was originally mostly PLT-specific, and some dork (me) advocated strongly that the Cookbook cover other Scheme implementations (e.g., R5RS whenever possible, then separate out the various implementation-specifics within an entry). This turned out to be additional mess and bulk. Racket will still have to decide what to do about version differences, but any mess will be a lot smaller and simpler to organize. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
And also, the wiki software kinda blew in many ways. One of the biggest ways was a small thing with, I think, big implications: the software would by default add an attribution line for each edit, encouraging people to view the page as a dumbed-down Web commenting forum to append a comment to, rather than as a coherent document to refine holistically. Also, depersonalization can be good: when there are no authorship names at all on a page, some people will have less resistance to making improvements. This also removes some of the incentive to contribute for some people, which can cost the document some good contributions but also scare off some low-quality contributions (see, as cautionary tale: Java sites). I think that removing incentive alone is not a net loss, and that depersonalization overall is a big net win. Neil Van Dyke wrote at 09/22/2010 03:53 AM: Eli Barzilay wrote at 09/22/2010 01:18 AM: The punchline is that your desire to use a local copy is in direct contradiction with the desire to get community involvement in improving the docs. No matter what facility is available for the community to discuss and supplement the docs -- if you have to go out of your way to see it, then you (the collective) just won't do it (statistically speaking). I think that you can make online docs sufficiently immediate value-added that people are drawn to use those. This can be done without compromising local-copy docs. If you did the online right, everyone knows that they get immediate benefit from the value-add of the online docs, so they must have a good reason when they use local copy. For a simple example of docs similar to Racket's can be online and participatory to some degree, see PostgreSQL's. They have their well-structured and well-edited manuals, and online you can browse a version with old-school community annotations at the bottom of each page. I've found some of the annotations very helpful, and I'd hope that they feed future versions of the well-edited manuals. You could also go more of a Wikipedia route. But you don't have a million contributors, and you will be spending lots of effort on quality control, and with a relatively small contributor pool you have to be more cautious about alienating people when a contribution really needs to be excised. Whatever you do, I hope that the goodness of well-edited local-copy docs is not compromised. Also keep in mind that some of us think that, when working on library code or documentation, the interface should present both code and doc easily. Usually, with dumb tools, that means JavaDoc-like embedded documentation. I have a goal to make Racket support this better in the future, and I hope that any new online docs thing won't get in the way, and that I can be compatible with that. The best that you'd get is yet another scheme cookbook I think that some of the problems that the Scheme Cookbook encountered are relevant to Racket. One is that a few characters of Perl operators from some Perl Cookbook item, in the Scheme Cookbook could become a huge page full of different verbose, cryptic, and so-so quality attempts to do a comparable thing in Scheme. (Which, in hindsight, should not have been surprising, when Schemers are involved.) I finally decided that most of the cookbook entries would ideally mostly be pointers to reusable code libraries (*not* copy&paste&munge), which led to me to silly extremes like: http://www.neilvandyke.org/tabexpand-scheme/ There were also various quality control problems for various reasons. I got disenchanted after realizing that messes were being created faster than good content, and that it would've been much easier for me to do something correctly from scratch than find a politic way to fix an existing entry or wrestle with the wiki software to reverse some bizarre structure change some user had done. (This is actually much like software development in general.) A problem that the Racket online docs *won't* necessarily have is that of scope: as I recall, the Scheme Cookbook was originally mostly PLT-specific, and some dork (me) advocated strongly that the Cookbook cover other Scheme implementations (e.g., R5RS whenever possible, then separate out the various implementation-specifics within an entry). This turned out to be additional mess and bulk. Racket will still have to decide what to do about version differences, but any mess will be a lot smaller and simpler to organize. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
Eli Barzilay wrote at 09/22/2010 04:30 PM: On Sep 22, Neil Van Dyke wrote: I think that you can make online docs sufficiently immediate value-added that people are drawn to use those. I don't believe that this will ever be effective enough. We have a large number of newcomers (because it's being used in courses there's a constant stream of new students who later move on), and these people will never see it. Can't the the online version can't be the default? Just don't somehow break the local-copy for the people who want it, is all I'm asking. It's OK if the local-copy docs require some savvy to get to. (Also, when used in developing nations and such, online might not be an option.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
There is a privacy/security problem to address: as described, this is phoning home to the mothership, and effectively tracking each user's browsing and searching behavior within the manuals, page-by-page, even though they are using local copies. The tracking situation on the public Web is crazier than even most techies realize, but not many companies put tracking capability into things like local copies of the documentation. Just on principle, I think you wouldn't want Racket to be lowering the bar further, so I think you'd have to address the concern. Everett Morse wrote at 09/25/2010 12:04 PM: User-contributed comments should be annotations to the documentation. They could then be fetched using JS (Ajax) from the local copy when an internet connection is available, -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
Eli Barzilay wrote at 09/25/2010 01:41 PM: Another possibly useful option is to use the local docs and fall back on the remote if they're not installed. This might be a better default -- allowing people to install the local copy and forget about the on-line thing. We don't have to forget about the on-line thing entirely. Even right now, I'd like each page of my local copy of the docs to have a link to the corresponding online page, so that I can continue using my fast local docs but at any time easily give a URL to people. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] safe version of racket/unsafe/ops?
Jay McCarthy wrote at 09/27/2010 06:23 PM: In principle I think it is a good idea, though I expect me and others will quibble over any name you pick. This one is easy to name, for anyone who watched SNL a generation ago: #lang racket/unsafe...NOT!!! -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Possible build platform for ARM
I've found "qemu" to be a godsend for systems work, though very slow compared to real metal, unless you're using virtualization extensions like KVM. I don't know how ARM "qemu" hosted on fast non-ARM hardware compares to native on typical ARM hardware, but I'm not too optimistic about that until someone has numbers. For testing, I think you need not just the target processor but also various OS and chipset/firmware stuff. And you still need to test on the real target device at least some of the time, since there are probably quirks, from which the OS might not insulate you. If you really want to use the Racket collections builds as part of the testing process of Racket, maybe do your frequent Racket builds on big ARM boards or using an emulator on huge hardware, and only occasionally check it against a day-long build running on the real target device. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Matthew Flatt wrote at 10/10/2010 09:39 AM: Any other opinions? No strong opinion, but misc. comments: * When working data in sexps a lot, "#f" taking a lot less space than "#false" can make things a lot more readable. Imagine, for example, a vector of 20 small integers and false values intermixed. * "#f" is often used to represent something like ``none'' or ``null'' rather than ``false'', so spelling it out as "#false" will take some readjustment for some people. * "#true" and "#false" do have the advantage of appearing more like a conventional friendly language. * Regarding friendly languages "#true" and "#false" have the unfriendly "#" (ugly, visually dominating, harder to type, longer). Some conventional programmers will prefer "#f" because, although not as friendly as "false", it's more terse. * It's nice that "#t" and "#f" are the same length, for lining things up, such as in matrices. * "#t" and "#f" can be hard to distinguish from each other visually. Look at a vector of mixed "#t" and "#f" values, for example. * "#t" and "#f" should always be synonymous with "#true" and "#false", for compatibility with other Racket and Scheme code. * There should be a print parameter to force printing as "#t" and "#f", for interoperation with Schemes. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] #true and #false
Jay McCarthy wrote at 10/10/2010 10:58 AM: So overall I think that #true and #false are good there [in teaching languages] and I don't see any problem with them being available elsewhere... just not the default. FWIW, I would occasionally like to spell out "#true" and "#false" in my code. Mainly when giving a Boolean value, rather than "#f" as a ``none'' value; and in something non-cramped, like a default for a variable, rather than each value in a matrix. But for the majority of uses I would prefer to write "#f" in my code, and to also see that as the printed representation most of the time. If "#true" and "#false" were just alternative read syntax for "#t" and "#f", and they always printed as "#t" and "#f" (except perhaps in teaching languages), that would make me happiest. I think it's not too bad if a new programmer types "#true" in their code and later sees the value printed as "#t". They'll figure it out within 2 seconds the first time. (It's a lot more intuitive than how the printing of a pair changes when its CDR is another pair or a null.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] fuzz testing the bytecode reader
Carl Eastlund wrote at 10/19/2010 04:51 PM: Caveat Emptor: be wary of running code designed to produce random, unsafe results if the computer you are running it on has any data you really care about. KVM+QEMU virtual machines are good for dangerous fuzz testing. You can chain copy-on-write (COW) drives to make setting up and running the tests in clean, safe environments easy and (in some ways) fast: Example, just to give to give the flavor to people who haven't used QEMU and KVM before: * One "unchanging" COW drive with your Linux install and other things that don't change often. This drive is represented as a normal file on any host Linux filesystem. * When you want to test a build, make a "build" COW drive linked to the "unchanging" drive. Start a VM and do your build on that drive. * For every test or set of tests for which you want a clean, safe environment, make a COW drive linked to "build" and use that for the tests. (You might use a RAM disk for this last layer of COW, to avoid real disk writes.) Note that, if you're using lots of fresh VMs for tests, rather than doing your test suite in one VM, you do have to wait for each VM to boot Linux. But if you have multiple cores, you can be running VMs in parallel, or just starting them up in parallel. All these things can be done from simple command-line tools or library calls. Whatever you do, avoid XenServer. XenServer is a favorite of pointy-haired "enterprise" IT managers who want to say the "virtualization" buzzword and have a cheaper way to let people run MS Word, but KVM is so much easier to work with. Also, in kernel evolution, KVM is preferred over Xen. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] highlighting function position with an underline.
John Clements wrote at 10/26/2010 02:33 AM: Who thinks it would be helpful, though, if Check Syntax were to, say, underline the function position? Not for the non-beginner languages, please. After thinking about it for a while, I'm currently of the opinion that one serious shortcoming of our syntax is that we fail to distinguish the function position from that of the arguments, something that the traditional f(x) notation does pretty clearly. FWIW, when I was first learning non-Scheme Lisps, I visualized the function name as part of the parentheses pair. So, this is atomic syntax for the application of function "myfunc": (myfunc ) With some background between the parens, and elastic to accommodate arguments, and with the name permanently fixed as part of the left paren. Perhaps the "(myfunc" and its ")" are die-cast metal tags on the ends of a piece of elastic or on parts of a slide rule, though I never thought of it quite that concretely. To reinforce: the ")" are like little handles on the very ends that you can pull and push, and they mark the very ends, too. When I moved to Scheme, I gave up this fairly physical notion of the syntax, since clearly it would discourage me from thinking about procedures as first-class objects, which Scheme seemed to consider important. However, if new students are somehow confused by this syntax, and you want to teach the noble lie that procedures always have names, and therefore that students could use the more physical/visual notion of the syntax that always has parentheses... I suggest that the first thing to do is to make the color of the parentheses pair match the color of the procedure name. Hand-wavey cog-sci: By making parens a different color, as DrRacket does, they are more a different thing than the procedure name things, and then we have to think more about their semantic and spatial relationships with other things. Optionally, in addition to making parens use the same color as their procedures, you could then use hue or brightness or something to indicate nesting depth or syntactic form identity, always keeping the parens matching their procedure. (You have to explain what the color differences mean, then, and worry about whether they interrupt reading flow too much or complicate looking at more than one syntactic construct thing at a time.) Or maybe you don't have change anything in DrRacket, and instead simply tell students some physical/visual ways to conceptualize the syntax itself. Students who have trouble remembering the syntax could latch onto conceptualization that works for them, til they no longer need the training wheels. Or til you have to teach that procedure are first-class. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] corrected sxml.plt 2 1
John Clements wrote at 10/26/2010 03:49 PM: Is there any chance I can upload a new version of this package? Normally, we'd want to have a clear and very restricted process for this (what Debian would call "non-maintainer uploads (NMU)"). PLaneT already has trust/security issues to address, and NMUs affect what trust we do have. On a separate note, to dev: is there any way that schemeunit could be made slightly less of a very large install? A few of use talked recently about PLaneT packages that are involved in extremely slow requires. IIRC, there were multiple fronts on which to attack this: * Make uncached PLaneT requires faster. How documentation is built is probably involved in this. * Encourage people to avoid totally gratuitous dependencies in reusable libraries. (For an imaginary example, let's say that you really like using "if" without an else clause, so all your libraries depend on the "johnsmith/optional-else" PLaneT package, which depends on a test engine plus some utilites that are part of a large library, which in turn depend on a graph of 10 other PLaneT packages, and Racket spends 15 minutes installing these. Just using "and" instead in your package's code would save users a lot of pain.) * Perhaps move some things into core. For example, IIRC, it sounded like one of the expensive packages that multiple people used was believed to compensate for a defect in core, and was felt necessary to produce a correct packaging. A good test engine in core might be another example. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
* I'd like to efficiently support SXML, as well as my new union of SXML and xexprs, by writing while traversing the data structure, without introducing an extra copy by first converting to byte string. Perhaps "response/c" could permit a closure to write the content and perhaps to produce or write the headers, or something similar? (Ideally, this does not require plugging together components using units and signatures; sometimes those tools are indispensable, but they're also cumbersome.) * I'd say that using SXML or xexprs for HTML and XML responses from a Web server is the normal and preferred way to implement most pages. Using these efficiently should be easy for people to do in substantial systems, such as by letting them define their own wrapper procedure or syntax for making a response of their preferred type. Using SXML or xexprs for output should also "give good demo" in tutorials and pilot apps, so it would be nice if people doing "#lang simple-web-server" or whatever could have a simple and terse way of saying "send an HTML response from this SXML or xexpr, with all the continuation magic", such as using one procedure or syntax name, rather than two to four. BTW, SXML and xexprs are a big win for Web development. For one large system in PLT Scheme, the architects have repeatedly mentioned the productivity benefits of SXML for HTML pages as one of the major advantages of using Scheme. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Jay McCarthy wrote at 11/27/2010 05:39 AM: I've just added response/port for this purpose, although it only provides the ability to stream the content, the headers must be produced beforehand. Is that a game breaker? Thanks. Sounds good. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Eli Barzilay wrote at 11/30/2010 06:36 AM: The ones I ran into, at least with xexprs: they rely on lots of quasi/quotes etc and it's easy to end up with things like "nbsp". I make errors of not getting my quotes, backquotes, and commas in the right place sometimes, but those errors tend to be discovered quickly. BTW, in SHTML, my old SXML derivative for HTML, one does "(& nbsp)" instead of xexpr's just "nbsp" for an entity reference. Perhaps there is a little less risk of confusion. I think there would be even less risk of confusion if DrRacket syntax coloring assumed that the quote and backquote characters always introduced a normal Scheme quote/quasiquote context, and colored the literal parts green. A related problem is the difference between contexts that expect a single value and contexts that expect a list of values -- with one solution of changing an `unquote' to `unquote-splicing' and the usual problems that this can lead to, or going with the bad "stuff" hack. I ran into this potential pitfall when I was doing PLT servlets with xexprs. It's not so much an issue in SXML, since (for better or worse) SXML permits unnecessary paren nesting, so you never have to splice. Other solutions/workarounds: * Just be careful, and test. * When I was doing PLT servlets, I just had a naming convention for procs that produced xexprs, so "foo-bar-xexpr-elem" would get unquote and "blort-baz-xexpr-content" would get unquote-splicing. * Ideally, I'd want static type checking of my HTML/SXML forms. This might have been some of the attraction of Haskell to Oleg. * My template language doesn't use unquote or unquote-splicing, and instead uses constructs that I think are less error-prone. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
I don't have any important dependencies on the Web Server right now, but just wanted to add that even small backwards-incompatibilities in PLT/Racket have ruffled feathers of consulting clients of mine in the past. When there are backward-incompats, it's *much* better that they be detected at compile time. Example: renaming the hash table procedures was an annoyance when code wouldn't compile, but the changes to "open-output-file" and friends to use keyword arguments resulted in much more insidious runtime errors. (BTW, Not using Typed Racket yet. Large code base that has been evolving since PLT 1xx/2xx.) When thinking about how you want people to be alerted to incompats, also remember that not everyone reads the release notes. A few times I've seen a programmer install the latest version of PLT to try, which happens to constitute a jump of several versions, and s/he smoke-tests their code with the new version *before* going and reading the release notes for all the intermediate versions. I think that having the platform inform them of incompatibilities through compile-time error messages or compile-time Java-like deprecation warnings gives more confidence in the platform than errors that occur significantly after time T0 in run-time. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Going back to a point I'm sure others have made already... Perhaps you guys have a good sense of how many people would be affected by any incompatibilities in this case? Most people use "open-output-file" and hash tables, so you wanted to migrate all those people gently somehow. A relatively small percentage of people used mutable pairs, at least outside of textbooks, so a harsh migration path was more acceptable there. I assume that the Web Server is somewhere between "open-output-file" and mutable pairs in popularity. If the tradeoff costs of backward-compatibility work and moving the platform forward expeditiously are unclear, perhaps you could poll the stakeholders. Neil Van Dyke wrote at 11/30/2010 01:11 PM: I don't have any important dependencies on the Web Server right now, but just wanted to add that even small backwards-incompatibilities in PLT/Racket have ruffled feathers of consulting clients of mine in the past. When there are backward-incompats, it's *much* better that they be detected at compile time. Example: renaming the hash table procedures was an annoyance when code wouldn't compile, but the changes to "open-output-file" and friends to use keyword arguments resulted in much more insidious runtime errors. (BTW, Not using Typed Racket yet. Large code base that has been evolving since PLT 1xx/2xx.) When thinking about how you want people to be alerted to incompats, also remember that not everyone reads the release notes. A few times I've seen a programmer install the latest version of PLT to try, which happens to constitute a jump of several versions, and s/he smoke-tests their code with the new version *before* going and reading the release notes for all the intermediate versions. I think that having the platform inform them of incompatibilities through compile-time error messages or compile-time Java-like deprecation warnings gives more confidence in the platform than errors that occur significantly after time T0 in run-time. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
YC wrote at 12/04/2010 04:19 AM:
After reading through the README, my vote is for a new "web-server2"
collection and keep web-server frozen as is except to fix bugs.
I'm still wondering how many people are actually dependent on Web Server
right now. I think that this number might grow exponentially, but might
be only a handful of people right now.
FWIW, my priorities regarding Web Server backward-compatibility, most
important to least important:
(1) Keep moving Web Server development forward.
(2) Keep/make *new* Web Server development a good experience, including
giving good demo. ("web-server" is a little preferred to "web-server2".)
(3) Have an idea for how to do backward-compatibility in the future.
Maybe this involves PLaneT-like specs of which version of the API is
used (which, incidentally, would be useful for "#lang racket/base" as well).
(4) Handle migration somehow for people currently using Web Server.
This should not require major changes, but might require them to change
their source to point to a compatibility library/language. The others
are higher priority.
Again, most of my Web work is on architectures predating the Racket Web
Server, and I've only done a couple small apps using Web Server
(research data-browsing/labeling apps), so I'm mostly unaffected.
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
Stevie Strickland wrote at 12/06/2010 11:58 AM: Every time I discuss contracts with a visiting researcher, the first or second thing they always ask is, "What if you coerced to a good value instead of throwing an error?", so I'm not surprised that Jay indeed wants just that. I think he's just found an excellent first use case for it in our own system, and so now we should take a look at supporting such, as you have said above. If you're talking about recovery from programming errors, I think that's an interesting and hard problem. (Example: programming error results in a bad value, which is detected; you now know that something is wrong, but you might not know the cause or impact, and perhaps coercing to a believed good value just creates a bigger problem.) Regarding the current backward-compatibility situation being a good use case for a desirable mechanism, it might be, but I think you will want to flesh out the rationale more at some point. (Example devil's advocacy, just to clarify what I mean: "How is this preferable to simply making a new procedure for the new behavior? How does this relate to multiple dispatch? How is this preferable to the way practitioners have been doing backward-compatibility in mainstream OOPLs?") -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] spam & planet bug reports
One issue to consider with Recaptcha is that it's incidentally a Web bug that helps track people around the Internet. If you don't already have Web bugs in your site, by adding one you increase the cross-site tracking. In the case of PLaneT bug reports, the privacy and security cost of a Web bug seems negligible. However, I think it is good to sanity-check every time you use one of these effective Web bugs. I've seen sites like anonymous discussion boards on sensitive topics doing things like loading Recaptcha for not only posts (goodbye, posting anonymity), but also for every message a user views (hello, centralized detailed profiling). In many cases, I believe that site operators who help implement the tracking are unaware of it, although in other cases they might be indifferent or believe that the tracking will be used only for certain purposes they consider to be good. Now that I'm in my 30s, my interest in this is academic curiosity rather than activist, but I'd like to have at least Racket people aware of the implications when they decide to use an effective Web bug like Recaptcha. FWIW, recaptcha is really easy to set up. Like less than 10 minutes from not knowing anything about it to having a working system. http://www.google.com/recaptcha -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] spam & planet bug reports
You could implement your own captcha. This is hard if the captcha is on sites popular enough to be brought to the attention of very smart programmers who specialize in compromising captchas. This is easy if you don't have to worry about those programmers. Or you *might* be able to use Recaptcha in a privacy-friendly way by serving everything yourself to the client, so that no HTTP request is made by the client directly to Google and no plausibly identifying info is otherwise propagated. That way, privacy-wise, Google gets little more than timing and scale info. I'm not sure that this is permitted, technologically or contractually. Serving it yourself is also more expensive to maintain, and, in absence of guarantees from Google, there is more risk that what works today will not work tomorrow. Matthias Felleisen wrote at 12/11/2010 01:47 PM: How difficult is it to implement one as a Planet lib that avoids tracking? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] (round), etc. in Typed Racket
Maybe someone can figure out a sensible way for modules to specify in which version(s) of the Racket language they are believed to work, and what to do with that information. I'm not sure what's sensible. I could see being able to specify "this module was last developed and working with Racket 5.0.42". Then some person or program coming along later knows how Racket has changed since then and perhaps can inspect the module for problems that would not normally be caught by static checking, and give warnings. Right now, I'm thinking static tools, rather than runtime compatibility modes. Or perhaps instead of specifications of Racket language version used, we could use test suites to assess compatibility of a module with a given version of Racket. If we have *really* good test suites. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] possible bug possibly involving planet development link requires
In case anyone masochistically-inclined wants to investigate a possible bug possibly involving PLaneT requires, or has heard a report of a bug like this but not been able to reproduce... I don't want to overstate the importance. I doubt that I'll see this problem again. It could just be a freak problem with my system and not a bug. Or it might be pilot error, especially given the late hour. 0. Use DrRacket 5.0.2. 1. I had PLaneT development link for package "me/lib:1:=1". 2. Package "me/lib" has a "main.ss" file that does: (require "lib.ss") (provide (all-from-out "lib.ss")) 3. In new file "use.rkt", there is a use of syntax "libform" and a require to get it: (require (planet me/lib:1:=1)) 4. When running "use.rkt", get an error about "libform" not defined. It's defined in "lib.ss", but not provided. 5. Add provide of "libform" to "lib.ss". 6. Attempt to run "use.rkt", but it is still complaining that "libform" not defined. THIS IS A CONFUSING FAILURE. 7. Spend 15 minutes trying in vain to get "use.rkt" to recognize "libform" from "lib.ss", by editing both files and trying many attempts to run, including restarting DrRacket. Also attempt to reproduce the problem with minimal test case, but fail to reproduce. 8. Finally try changing the require form from "me/lib:1:=1" and "me/lib:1:=1/lib.ss". THIS WORKS. 9. Change the require form back to "me/lib:1:=1", which hadn't been working up through moments earlier, but now works. THIS IS A CONFUSING SUCCESS. I'm wondering whether there was a cache of compiled code or some kind of name resolution/linkage (PLaneT-related, or not) that was out of date for some reason. (Note that I might have done a CVS commit of "lib.ss" at some point in there, and it looks like my clock is approx. 2 seconds behind server's.) And perhaps asking for a different file in the PLaneT require caused that cache to be updated? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] up-to-date libgtk for drracket on debian stable?
In case anyone is interested, following are versions of GTK-related libraries on one of my Debian Stable boxes. The GTK API documentation generally tells you in which version an API feature was introduced. I can provide shared library symbol dumps if someone would like that. dpkg -l | grep libgtk ii libgtk1.21.2.10-18.1 The GIMP Toolkit set of widgets for X ii libgtk1.2-common 1.2.10-18.1 Common files for the GTK+ library ii libgtk2-perl 1:1.190-1 Perl interface to the 2.x series of the Gimp ii libgtk2.0-0 2.12.12-1~lenny2 The GTK+ graphical user interface library ii libgtk2.0-bin2.12.12-1~lenny2 The programs for the GTK+ graphical user int ii libgtk2.0-common 2.12.12-1~lenny2 Common files for the GTK+ graphical user int ii libgtk2.0-dev2.12.12-1~lenny2 Development files for the GTK+ library ii libgtkhtml2-02.11.1-2 HTML rendering/editing library - runtime fil ii libgtkmm-2.4-1c2a1:2.12.7-1 C++ wrappers for GTK+ 2.4 (shared libraries) ii libgtksourceview-common 1.8.5-1 common files for the GTK+ syntax highlightin ii libgtksourceview1.0-01.8.5-1 shared libraries for the GTK+ syntax highlig ii libgtksourceview2.0-02.2.2-1 shared libraries for the GTK+ syntax highlig ii libgtksourceview2.0-common 2.2.2-1 common files for the GTK+ syntax highlightin ii libgtkspell0 2.0.13-1+b1 a spell-checking addon for GTK's TextView wi dpkg -l | grep libpango ii libpango1.0-01.20.5-6 Layout and rendering of internationalized te ii libpango1.0-common 1.20.5-6 Modules and configuration files for the Pang ii libpango1.0-dev 1.20.5-6 Development files for the Pango dpkg -l | grep gdk ii gdk-imlib11 1.9.15-7 imaging library for use with gtk -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] drracket and rectangles
A few things for which I switch to Emacs, even when using DrRacket: * M-q to re-flow Racket comments that span multiple lines, to fill to some margin (like 79 or 80 columns). Note that Emacs has fancy "adaptive-fill", but something simple and Racket-comment-specific would be fine. * M-x quack-tidy RET to reindent all lines and tidy up extraneous whitespace. Using the pretty-printer, DrRacket could go a step further, to line-breaking. * Keyboard macros. These can get pretty powerful. Matthias's argument-reordering would be a simple example, and even for that, keyboard macros using sexp movement operations would be more robust than rectangle kill&yank. * Working with (editing, viewing, or doing keyboard macros with) more than 2 or 3 files at once. * Doing version control operations. * Editing non-Racket/Scheme text files. The first two have been on my mental list to add to DrRacket someday. But if any students are bored over winter break... :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A disassembler for Racket
Sam Tobin-Hochstadt wrote at 01/05/2011 05:28 PM: I've been on-and-off working on a disassembler for jitted x86 functions in Racket, This is great, Sam. Thank you. Your problem now is that, while some CL-type people will like to see assembly dumps, they will grumble about any missed optimizations. :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] server availability
I've noticed PLT/Racket servers down a few times over the years. I don't know how frequent the downtime is, but I could imagine downtime of the PLaneT server in particular being disconcerting to someone whose software depends on PLaneT. If anyone is thinking about server availability, for PLaneT, also keep in mind that there is still opportunity to improve the security and trust of PLaneT, and that how you choose to improve availability might complicate improving security. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] A curious question about quote
Like Joe said. I think that this "quote" behavior is a very practical convenience that Scheme inherited, not something about which to hurt one's brain trying to discern the underlying pure truths. There are some confusing bits. For example: #lang racket (equal? (quote 1) 1) ;==> #t (equal? (quote (quote 1)) (quote 1)) ;==> #f This particular confusion, we can clarify or rationalize as "(quote )" being a very different thing than "(quote )". Which, as you said, could be seen as conflating. Taking another look at the above quirk suggests "quote" having simple-minded automagic to decide which of its multiple personalities (number or list) is triggered: (quote 1) ;==> 1 (quote (quote 1)) ;==> (quote (quote 1)) I don't know/recall how CL philosophizes about this. Emacs Lisp people talked about syntax like numeric literals, "nil", and "t" being ``self-quoting.'' Scheme people tend talk about numeric literals being ``self-evaluating,'' but I don't see how that explains the quirk above. If you can work out a clean formalism for the syntax/reader that avoids quirks like these, yet still provides the list construction convenience that permits non-list constants/self-evals elements without extra syntax for quoting or unquoting them, I think that would be good. As long as you're banging around in there, if you can also replace the names "unquote" and "unquote-splicing" (which I believe are hardly ever used literally in application code) with names/syntax that don't stomp on the space of names application code might want to use in, say, quoted or quasiquoteed embedded SXML, that would be even better. :) I wish that RnRS had gotten rid of these at the same time that it blessedly got rid of "nil" and "t". What currently makes more sense to me in Racket is to move to "#unquote" and "#unquote-splicing" (or "#," and "#,@"), keeping the same "," and ",@" shorthand. I suspect that changing to those would be backward-compatible for 99.9% existing code outside of Racket internals. I could be overlooking some case that makes that change a bad idea, of course. Joe Marshall wrote at 01/26/2011 05:17 PM: On Wed, Jan 26, 2011 at 8:02 AM, J. Ian Johnson wrote: I have a historical question about quoted constants. Does anyone know why '1 = 1? My intuition is that this is an artifact of conflating quote with list constructors. Is that indeed the case? I doubt it. More likely it was when someone realized that if (quote 1) is not the number 1, then everyone would be confused. What else would it be? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] tests/eli-tester feedback (Was: Racket unit testing)
Eli Barzilay wrote at 02/15/2011 07:32 AM: * It uses TR -- but it has to be very minimal. (*Extremely* minimal, since it's a candidate for inclusion in the `racket' language, which is why I was thinking of not much more than agreed structs and parameters.) A related consideration is that, the more dependencies the test mechanism has, in theory, the more potential points of failure that could corrupt the test mechanism itself. I doubt that TR, for example, is going to break in a way that causes tests that should fail to pass, but I think that the consideration should be mentioned. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] sxml package takeover/updates?
If Oleg, Kirill, and Dmitry would like someone to take over maintaining the Racket PLaneT packages of SSAX and the SXML tools, I would be happy to volunteer. (Kirill and I talked recently about some changes to the Racket packaging of SSAX that I have done through a wrapper package. Specifically, the wrapper converts SSAX exceptions to Racket "exn:fail?", and captures the SSAX stderr messages and uses them to annotate any forthcoming exception or sends them to "log-warning" calls if there was stderr but no exception. Kirill is still waiting to hear from me. Perhaps it would be easiest to merge this as changes at the same time I generated the Racket-specific packaging from the Sourceforge upstream version.) Neil Robby Findler wrote at 02/15/2011 03:11 PM: On Tue, Feb 15, 2011 at 1:52 PM, John Clements wrote: I understand that PLaneT is not currently set up to make it easy to migrate packages to new owners. It shouldn't be difficult to download a .plt file and re-upload it under another name. This ends up being roughly like a major version increment (things could be better, yes, but at least that's something?). Robby -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
Robby Findler wrote at 02/19/2011 08:00 AM: But I'm starting to think that Matthew's solution is easiest. Lets just punt. FWIW, I see additional reasons to, as Matthew suggested, *not* bundle third-party La/TeX class/style files in with Racket: * If user needs a different version of the file, avoid headache of getting LaTeX to pick up the desired version when there's a name conflict. * If user needs a different version of the file, avoid accidentally getting the Racket-bundled version without knowing. * For each paper, user should probably be archiving the exact class/style files used for the paper anyway, for future reproducibility. So, if they care about versions, they probably shouldn't be relying on whatever version of Racket is installed. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
Robby Findler wrote at 02/19/2011 08:00 AM: Thanks, Robby. Sorry, I was being stupid, and not looking at enough message history to know what was being discussed. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] overwrite
Dunno whether this helps... I haven't looked at the pertinent Racket code, but errors like this often happen in Unix applications because the mtime of the file is in the future relative to the current time clock. Less commonly, because the mtime changed since the file was read by the app or since the app last checked. The most common case can happen because a VC/CM system is updating the times (someone mentioned Git, and some other systems do this), because it's a network filesystem and the server and workstation clocks aren't synced sufficiently, or because NTP or some other mechanism dangerously jumped the current time clock in reverse (usually a good NTP daemon will slow the clock rather than jump in reverse). Robby Findler wrote at 02/26/2011 01:39 PM: Looking at the code, I don't see anything suspicious (assuming that after-save-file and file-or-directory-modify-seconds work properly, that is). -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] LGPL
For people wanting to make it easy for their PLaneT packages to be incorporated into Racket core... should we be using LGPL 2.1, or some other license? (I've been using LGPL 3 for most things lately, but I don't mind going back to 2.1 if that's where Racket wants to be right now.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] LGPL
Eli Barzilay wrote at 03/03/2011 10:10 PM: Distributed under the same terms as Racket Would it be good practice overall to pick a specific, more limited, license for contributors to use? I believe that a copyright holder permitting the convenient "distributed under the same terms as Racket" essentially grants full (nonexclusive) rights to the unnamed distributors of Racket, potentially bypassing the intent of the open source licenses. Some individual contributors will believe strongly in open source licenses, and there's various good reasons why licenses are used rather than public domain in most cases. I'd also bet money that the open-ended granting of rights would draw more consternation from corporate lawyers whose OK is needed to release code, compared to a well-trod standard license with limitations, like LGPL 2.1 or 3. I didn't mind giving full nonexeclusive rights to that CSV parser as "same terms as Racket", just for the sake of expedience on that small contribution. But, going forward in the Racket new world order, I'd like to be comfortable that license stuff is being done in the best way overall. BTW, I think, but am not certain, that the "or (at your option) a later version" bit lets you upgrade the LGPL version without having to contact copyright holders. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] spam trac tickets
Robby Findler wrote at 03/22/2011 11:28 PM: Looks like the spammers have found a way thru google's captcha thing. That's frustrating. I wonder whether a simple homebrew captcha (e.g., varying but simple Racket expression that even beginners understand and can do in their head) would be effective for a while. This is easy for captcha-crackers to break if they look specifically at the Racket site, but it's not vulnerable to some spammer automatically detecting all the sites that are using ReCaptcha and then using their standard exploit for that site (machine vision, farms of humans). -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] spam trac tickets
Eli Barzilay wrote at 03/23/2011 04:20 PM: But the obvious advantage of staying with the common captcha is that many other sites probably suffer, which means that it will get better. (Or the internet will be shut down...) Biodiversity. After Java and Python are wiped out in the coming spam apocalypse, Racket will survive, like cockroaches. :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Top ICFP authors
Eli Barzilay wrote at 04/12/2011 03:46 PM: Do a bing image search on any of the names -- it's a disaster. (One of the first images I get for "matthew flatt" without the quotes is your foot.) Foot? Could be worse: Google Image Search for my name doesn't show me, but the first page does show closeups of toenail fungal infections. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] my '312' this semester, how we compare to others
Matthias Felleisen wrote at 04/21/2011 01:07 PM: -A- I demanded that students deliver their functionality via Unix shell scripts, and so I did so too. My tcsh scripts check the argument number and pass the arguments on to Racket. Firing up one of my clients or servers takes several seconds. All other language implementations appear to bring up their servers or clients instantaneously. I only see slow performance like that from non-GUI Racket when the Racket code is not yet compiled, and perhaps when the files that need to be read (or ELF loaded) by the OS are not in OS caches. The "racket" REPL executable startup *did* seem to get a lot slower a while ago -- a few seconds -- compared to the old "mzscheme" REPL. But 5.1 was less than 1 second to REPL prompt when I tried it just now. Three shell script tips that shouldn't matter much, but might speed you up a little: (1) Consider using "/bin/sh" or "/bin/bash" instead of "tcsh", since the old rule is Bourne for scripting, C-shell for interactive; (2) In the "#!" line, use command line options to disable shell features that load various system and user rc files, since these are slow to read and interpret, and can be huge like completion tables, plus in a production app other people's shell rc files can introduce instability; (3) After your script does the minimal stuff it has to do in shell rather than Racket, use an "exec" to fire off "racket", so that everyone can forget sooner that shell ever happened. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Vincent St-Amour wrote at 04/22/2011 04:26 PM: With this patch, assoc and member are implemented in Racket. They are currently implemented in C. I haven't measured the performance impact of the change, but I can do it if someone believes it's necessary. Testing performance impact of reimplementing these procedures seems appropriate to me. For one thing, they are old RnRS procedures that performance-sensitive people have assumed are implemented about as fast as they could be for general-purpose linear searches. Also, if it turned out that "assoc" (or "assq") took a significant adverse performance hit, that might create a big barrier to a particular production system upgrading its Racket version. I imagine you might even make these procedures faster by moving from C to pure Racket implementations, where there is more info from which to optimize calls to the procedures. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Eli Barzilay wrote at 04/22/2011 05:09 PM: One way to make it fast is to have it bound to a macro so (member f l eq?) expands to a `memq', and when used as a function have it dispatch to `memq' if given `eq?'. If someone really wanted to do that optimization in a macro (at first glance, seems a little unSchemely to me, and I think a compiler or JIT should be able do that optimization, anyway), I'd hope they'd pick a new name for the macro. "member", "assoc", and friends of course have been procedures forever. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Universe and Redex
David Van Horn wrote at 04/23/2011 09:12 PM: was to define the language of client to server messages as a Redex language and then use Redex's random term generation to stress test our server. Would be interesting to see how this work with Redex would be framed within related work. There is a popular broad term, "fuzz testing". -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Thanks for the performance numbers and JIT enhancements, Matthew. Do I read this correctly that (for whatever distributions of inputs you used) we can expect the new "assq" to be about twice as fast on 64-bit x86, and about half-again as slow on 32-bit? Matthew Flatt wrote at 04/24/2011 10:44 AM: 32-bit run: 'kern:assq cpu time: 23 real time: 23 gc time: 0 cpu time: 38 real time: 39 gc time: 0 cpu time: 39 real time: 38 gc time: 0 'assq cpu time: 38 real time: 39 gc time: 0 cpu time: 60 real time: 61 gc time: 0 cpu time: 61 real time: 61 gc time: 0 64-bit run: 'kern:assq cpu time: 36 real time: 36 gc time: 0 cpu time: 117 real time: 117 gc time: 0 cpu time: 118 real time: 118 gc time: 0 'assq cpu time: 39 real time: 39 gc time: 0 cpu time: 66 real time: 65 gc time: 0 cpu time: 65 real time: 65 gc time: 0 -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Matthew Flatt wrote at 04/24/2011 06:53 PM: At Sun, 24 Apr 2011 12:48:53 -0400, Neil Van Dyke wrote: Do I read this correctly that (for whatever distributions of inputs you used) we can expect the new "assq" to be about twice as fast on 64-bit x86, and about half-again as slow on 32-bit? Well, here are some new numbers (32-bit): Cool, Matthew. The modest performance hit for "assq" on 32-bit (my workstation) right now is a small price to pay for doubling the speed on 64-bit (lots of servers). That should be a significant help to one of the production apps that uses Racket. This is a nice spring holiday gift. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Matthew Flatt wrote at 04/24/2011 07:58 PM:
At Sun, 24 Apr 2011 19:24:18 -0400, Neil Van Dyke wrote:
The modest performance hit for "assq" on 32-bit (my workstation) right now is a
small price to pay for doubling the speed on 64-bit (lots of servers).
I forgot to reply to that point before. Unfortunately, I don't think you're
going to see the same effect on other machines.
Oh, you did say something about influence of a particular 64-bit
compiler earlier, but in all my excitement, I didn't make the connection.
If, at the time this new "assq" makes it into a Racket release, the new
"assq" turns out to be significantly slower than the old C one, can the
old one ("kernel:assq"?) be exposed for programs to call directly?
A performance regression in "assq" would adversely impact some
performance-sensitive legacy code that saw a lot of micro-optimizing
last year. Having the old "assq" available as a fallback option would
be reassuring.
BTW, I do like the idea of "assq" being pure Racket code, where it's
more amenable to ongoing work on optimizers, and I don't mean to sound
critical of this process.
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Optional equality predicate for assoc and member
Eli Barzilay wrote at 04/24/2011 09:01 PM: Related to the other thing I said: if you have code that depends on fast assoc-ing, and you don't have cycles, then rolling your own version is probably going to be faster anyway. Good point. I believe this was not case when I was profiling several different implementations of certain list procedures under PLT 4.2.x (e.g., calling C "assq" was faster on our large-ish alists than what should have been optimal Scheme code for doing the same on acyclic alists), but the JIT has improved since then. I think this is not a showstopper situation, and I have a few app-specific optimizations ready in my back pocket if necessary, so that this app can upgrade to new Racket versions without giving up its pervasive use of alists. (The original architect had good reasons to use alists that way, I have to mention.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] An occasional newline in the PLaneT install Log?
John Clements wrote at 04/28/2011 02:09 AM: On Apr 27, 2011, at 12:10 PM, Robby Findler wrote: There actually are newlines there in some ways the log is viewed. So something looks buggy somewhere to me. I'm not quite sure what you're suggesting. I had a look with emacs, and I'm pretty sure there are no special characters in there. Perhaps I'm misunderstanding you. My "~/.racket/planet/300/5.1/INSTALL-LOG" on GNU/Linux contains *zero* LF or CR characters, despite reflecting a few PLaneT packages having been installed. First guess: someone is getting the log text line-by-line without newlines, and forgetting to add the newlines when sending the lines to the log file. If Robby means that his log contains LF and/or CR characters, maybe he's using a different Racket version, or is on a different host platform. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket vs. scheme vs. clojure (as it appears to others)
The Web is full of outdated and/or ill-informed references to PLT and Racket. People see these, and the bad information propagates memetically -- perpetuating and increasing. One thing Racket people could do is a one-time blitz of existing bad info all over the Web, to correct as many of these as possible, and promote the message of how Racket is positioned. This can include updating various wikis, posting corrections or updates in otherwise stale Web forum threads, emailing maintainers of non-wiki sites suggested updates to their pages, emailing blog authors who do not have comments, etc. This is a one-time thing, to update the static parts of the Web, distinct from the ongoing activities of participating in dialogs as they happen. Before doing the blitz, an internal refresher course on the message wouldn't hurt, so that the blitzing by multiple people is fairly consistent. Example of something to decide: Under what circumstances should Scheme ever be mentioned, and how should Racket's relationship to Scheme be characterized when it is mentioned? I can tell you that the word "Scheme" is often useful when a prospective Racketeer starts out wanting "Scheme", and then they get pointed to Racket. And I think "Scheme" might *sometimes* be useful when someone academically-inclined is asking about interesting programming languages and we can tout Scheme as part of our heritage (or, alternatively, just point to the PL research). "Scheme" is usually a liability when someone used it in school years ago (other than with HtDP). "Scheme" is also a liability when someone is almost in the Racket fold, but then goes Googling around for information on "Scheme" and gets all confused, time-wasted, and turned off. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket vs. scheme vs. clojure (as it appears to others)
Matthias Felleisen wrote at 05/06/2011 10:41 AM: For what time period should we leave the description constant to test this conjecture? Someone mathematically-inclined did something similar-sounding a decade(?) ago, for US national political campaign fund-raising. From what I could gather, the campaign Web sites would automatically experiment with varying the approach, *on a per-visitor basis*, to find optimal ways of presenting itself. I think they were searching the combinatorics of different text, positioning, dollar amount alternatives, etc., and also correlating with messages in the news. In one respect, they had it easy: dollars donated immediately through the site is an exceptionally good success metric. I suspect that the party didn't publish on their setup (just guessing; I don't follow such things), and the person I'm thinking of has moved on to doing different kinds of work. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] breaking news nearly invisible
John Clements wrote at 05/24/2011 01:47 PM: I saw a commit go by that seemed to suggest that the racket-lang web page now included some kind of "breaking news" item regarding RacketCon. So I went to the web site but... nothing. If you want an 10-second solution to make it more prominent for most everyone, you could change the background of the box to a yellow (Post-It Note metaphor), maybe with a thin red border. It's OK if it doesn't quite fit in to the style, because it is new, temporary, and made to stand out. You could make it complementary in style to the very noticeable "Download Racket" icon. (I actually noticed the "RacketCon" graphic yesterday before the email went out, when I went to the home page yesterday to click on the "Community" link. Probably because of visual memory that something had changed in the page, and/or because the italics were different than everything else, and/or because, textually, the word "RacketCon" was unfamiliar. But, for people of all visual inclinations, and people not already familiar with the busy home page, the current graphic is a bit reserved.) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] problem running configure script
I don't know why you're getting those errors (are you using "zsh"?), but does "./configure" instead of "bash configure" work for you? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] net/url and https
I appreciate the conscientiousness about backward-compatibility here, but, as a data point of one developer, I would be happy to incur the backward-incompatibility of option #1 in exchange for getting rid of the Cookbook HTTPS hack sooner rather than later. I also think that Eli's option #1 could be done without breaking backward-compatibility, but I'm not sure it's worth the effort in code and documentation, and I don't want to discourage him moving forward with #1 by making the task harder than it has to be. (Full disclosure: Breaking backward-compatibility in the option #1 way would generate approx. one billable hour of consulting work for me. Just to edit some "require" forms, quickly inspect the call sites with Emacs grep, test, and remove a Cookbook hack file from the CM branch.) Thanks for tackling this, Eli. Robby Findler wrote at 06/19/2011 06:26 PM: I think we should not remove anything from the net/url library (including the unitized interface) as I believe that will break old code. On Mon, Jun 20, 2011 at 5:57 AM, Eli Barzilay wrote: 1. Looking at the code, there are only two tcp functions used (`tcp-connect' and `tcp-abandon-port'), so eliminating the unit interface and just hooking things up so that an "https" scheme uses the ssl functions is relatively easy. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] bug reporting system is not spam-protecting email addresses
The bug reporting system is not spam-protecting email addresses provided by bug report submitters. It is putting submitters' email addresses unprotected on public Web pages, including with "mailto:"; links. This is a great way to make users not only flee your platform, but track you down personally and set your house on fire. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] bug reporting system is not spam-protecting email addresses
Robby Findler wrote at 06/26/2011 08:06 AM: I suspect we should fix this at least for appearances Yes, I think it's first and foremost an etiquette issue. but do you think that that really helps avoid spam? Keeping email addresses off of Web pages does still help, IME. I believe that the email list I use to subscribe to most email lists still gets no spam. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Testing mode
I like the "testing" part, but am uneasy with the "deploying" part. Unit testing is so commonplace, and sometimes you want to have unit tests of private stuff within a module, without having to break up the module to expose the private stuff for testing. So, in that very common, almost universal situation, being able to embed unit tests in a module and have a way of switching them on and off at run time, seems good. Beyond that, I think that talking about modes of running gets trickier and more application-specific. Just a knee-jerk reaction without looking at it, but hearing that there's a construct "with-deploying" sounds seems like a dumbed-down, toy thing to do. I'd rather see an extensible mechanism for run modes instead. Just one example: just like some people might have mode called "deploying" or "production", I might have particular modules that have a run mode in which there are multiple implementations of the same function, and at run time both the simple and the fast-and-fancy algorithms are run and their results compared (and run modes in which only one of the two algorithms are run). What modes I use for ``production'' might change during the development lifecycle, on a per-module basis. I also have modes for profiling information, including reports within the system. We also have modes in which logging is done or not, and (ideally, though Racket's logging features don't directly support this), this is on a per-module or per-something-else basis. Some of these modes were originally intended for ``development mode'' but were put into production at times. Whether logging, profiling, algorithm-checking, etc. are done is not limited to non-"production". Also, even though I just said that embedded test cases are so universal, and there is a convenience factor to being able to test unexported stuff from a module, even this mode wants to be more complicated sometimes. For example, sometimes tests are expensive, and you want to run a smaller subset of the tests. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket startup
Eli Barzilay wrote at 06/28/2011 09:52 AM: This makes `MAIN' the Racket equivalent of Python's `__main__' thing. As for the name, if you could promise me that this name isn't a slippery slope to a proliferation of all-uppercase variable names... (By convention, I use all-uppercase for pattern variables in macro transformers, and that is the best use of them I've found so far.) As for adding Python/Ruby/Perl-esque automagical behavior and hacks, I trust that people will do so with judicious hesitation. Sometimes a hack is the most sensible way, but Racket is mostly not Hacket. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Testing mode
Jay McCarthy wrote at 06/28/2011 10:52 AM: My patch was supposed to address this by setting up a protocol for code to be test only or "not" test (that's what I intended by with-deploying.) It was "deploying" in the name that I thought was problematic. "when-testing-mode" and "unless-testing-mode", or something like that? -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] rename "Help Desk" menu item
Now that there is no longer a "Help Desk", can that menu item in DrRacket be renamed to something like "Documentation" or "Racket Documentation"? I think lots of users are reluctant enough to go to "Help" menus, since they (Help menus, not users) are usually full of useless filler crap. If a user *does* open the menu, hopefully "Documentation" will catch their eye. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] ohloh page
John Clements wrote at 07/06/2011 08:53 PM: 2) I see that we're "in the top 2% of all open-source projects" according to ohloh. Perhaps we should advertise this? Below is very opinion-heavy seat-of-pants reaction. I'm not familiar with Ohloh, and I could be off the mark... The Ohloh site seems oriented towards PHBs who use 'analysis' like "decreasing year-over-year development activity" without wondering whether it's at all accurate and meaningful. (Yes, that's what they say about Racket, with a yellow warning graphic. And only 2 people on that site claim to use Racket, which just looks funny.) A quick poll of open source developers I bumped into, including one loosely connected to Ohloh, said nothing positive about it. Personally, I would invest a little effort in making Racket look good on Ohloh now that we're there, since that might serendipitously come in handy for a PHB someday. But I don't know that I would link to Ohloh or mention them outside of their own site right now. Too much like those tacky bogus "Top x% Web Site" awards in the late '90s. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
4DOS. Eli Barzilay wrote at 07/10/2011 01:51 PM: Ok, `4racket' and a beer for anyone who knows why. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
Yes! Name your favorite brand and I'll bring it... I don't know a good beer to name, but I'm sure that the Bukowski Tavern near us has some sufficiently pricey imported craft ones. :) -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
Eli Barzilay wrote at 07/14/2011 10:38 AM:
9 hours ago, John Clements wrote:
First thing: you can use ESC-(. That is: press and release ESC, type
(. That works, but it's a big pain.
Use Alt-( -- much less pain. (And that works in Emacs regardless of
paredit, BTW.)
On a tangent, but an important one:
1. Text editors that involve Alt- combinations a lot should also support
ESC.
2. People should be warned that the "ESC (" (two keypresses) might be *a
lot* easier on their hands than "Alt-(" (multi-key combinations).
3. Other things you can do to make typing easier on the hands might be
good, though there are tradeoffs.
The reason has to do with the stress of stretching/twisting people do
with their hands for multi-key combination, is my layperson's
understanding. Around the time, when CTS and other RSIs were getting a
lot of attention, I heard this from multiple credible sources, and the
knowledge seemed to work for me.
Now, you can avoid the stretching by using alternate hands for this
two-key combination, if you have two Alt keys. But the alternate-hands
approach doesn't avoid stretching when you get a Ctrl-Alt combination,
which happens a lot in, say, Emacs. So, if you forsee frequent Ctrl-Alt
combinations
I had hand pain from typing, circa 1990, but I made a few changes, like
switching to use ESC in Emacs. Something in those changes solved the
problem, and years later I can still type heavily without difficulty.
Back then, I was on a project team that had two people injure their
hands from typing, to the point that they were advised not to type *at
all* or they would lose all use of their hands. We hired typists for
them, and eventually they had to change careers. Most of the rest of
the team had wrist braces by the end. It happens; we weren't really
designed to sit down and press little squares a hundred times per
minute, all day.
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
Unfinished sentence: if you foresee frequent "Ctrl-Alt-" combinations,
it might be easier to learn or teach just always doing "ESC" instead of
"Alt-", rather than doing "Alt-" for 2-key and but doing "ESC Ctrl-" to
avoid the 3-key.
Neil Van Dyke wrote at 07/15/2011 12:36 AM:
Eli Barzilay wrote at 07/14/2011 10:38 AM:
9 hours ago, John Clements wrote:
First thing: you can use ESC-(. That is: press and release ESC, type
(. That works, but it's a big pain.
Use Alt-( -- much less pain. (And that works in Emacs regardless of
paredit, BTW.)
On a tangent, but an important one:
1. Text editors that involve Alt- combinations a lot should also
support ESC.
2. People should be warned that the "ESC (" (two keypresses) might be
*a lot* easier on their hands than "Alt-(" (multi-key combinations).
3. Other things you can do to make typing easier on the hands might be
good, though there are tradeoffs.
The reason has to do with the stress of stretching/twisting people do
with their hands for multi-key combination, is my layperson's
understanding. Around the time, when CTS and other RSIs were getting
a lot of attention, I heard this from multiple credible sources, and
the knowledge seemed to work for me.
Now, you can avoid the stretching by using alternate hands for this
two-key combination, if you have two Alt keys. But the
alternate-hands approach doesn't avoid stretching when you get a
Ctrl-Alt combination, which happens a lot in, say, Emacs. So, if you
forsee frequent Ctrl-Alt combinations
I had hand pain from typing, circa 1990, but I made a few changes,
like switching to use ESC in Emacs. Something in those changes solved
the problem, and years later I can still type heavily without difficulty.
Back then, I was on a project team that had two people injure their
hands from typing, to the point that they were advised not to type *at
all* or they would lose all use of their hands. We hired typists for
them, and eventually they had to change careers. Most of the rest of
the team had wrist braces by the end. It happens; we weren't really
designed to sit down and press little squares a hundred times per
minute, all day.
--
http://www.neilvandyke.org/
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
Guillaume Marceau wrote at 07/15/2011 01:02 AM: One of the best such study is A Prospective Study of Computer Users, by Gerr, Marcus, Ensor, Cohen, Edwards, Gentry, Ortiz, Monteilh, AJIM 41:221-235 (2002) http://www3.interscience.wiley.com/journal/91016561/abstract Over a period of 38 months, they followed 632 computer professionals Interesting that their concluding list of recommendations you quoted, was almost entirely the common folk wisdom a decade earlier. :) The one factor in the folk wisdom that I recall at the moment, that wasn't mentioned in the quoted list, is stress. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Was: intro videos
Guillaume Marceau wrote at 07/15/2011 01:02 AM: Yes, but paredit still gets its priorities backward. You want to have the most commonly used edit operations on the easiest chords (or without any chord at all, if you are trying to avoid RSI.) BTW, I just started a tangent, on the "users" list. "Subject: what kind of Racket editor operations would you like to see?" -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket DMG improvements
Jakub Piotr Cłapa wrote at 07/17/2011 08:25 AM: Uncompressed HFS+ images may be mounted on Linux but I am not sure if there is a way to do it without being root. If you want to access a filesystem image file *as a Linux filesystem*, I think you probably have to mount it with a "loop" device, which requires either root/sudo privs, or perhaps a fixed path that can be put into "/etc/fstab" with privs granted for normal users to mount it. (There is another option, using FUSE, but I think "loop" will be easier.) I would guess that any building of HFS+ images would be done on OS X, though. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Roogle?
Shriram Krishnamurthi wrote at 08/05/2011 12:17 AM: This idea is proposed roughly every 2-3 years for at least 30 years. I am not aware of anyone having made this idea "fly". If you have a info retrieval method with useful precision&recall, but the barrier to adoption is the user's overhead in invoking the feature... you might help it fly by not requiring user to invoke it. For general example, something done automatically, context-sensitive, that user can perceive in subtle visual annotations, or by glancing into another part of the window, or something. For more specific, and potentially quite simple example: your editor/viewer/browser knows what bits of text you're editing or looking at (cursor, what's visible in window, document, movement, maybe even gaze-tracking), and in some little window provides a ranked list of info (perhaps document links/excerpts) it thinks might be relevant at the moment. People including myself have used this approach successfully for IR problems. -- http://www.neilvandyke.org/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
