Re: [racket-dev] Latex files
On Fri, Feb 18, 2011 at 9:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Fri, Feb 18, 2011 at 9:42 PM, Robby Findler ro...@eecs.northwestern.edu wrote: It wouldn't hurt to include a little script that downloads the correct versions of the files from racket-lang.org somewhere and puts them where they are currently, tho, no? At least for the JFP file, it's pretty clearly a copyright violation for us to distribute the file at all -- on the web page or elsewhere. We'd have to download it from the CUP site. Is there more to the license than what Eli quoted? I don't see a violation of that part, at least. But I'm starting to think that Matthew's solution is easiest. Lets just punt. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
At Fri, 18 Feb 2011 22:44:54 -0500, Sam Tobin-Hochstadt wrote: At least for the JFP file, it's pretty clearly a copyright violation for us to distribute the file at all -- on the web page or elsewhere. We'd have to download it from the CUP site. For the ACM file, I emailed the contact email for the style file about the license. Did you e-mail anyone at JFP, yet? Looking again, I can imagine reading the jfp.cls file Robby's way. The intent of use may be produce a document, and the overall intent might permit redistribution of jfp.cls to others who are producing JFP documents. Or maybe not, but I now think it's worth asking, and I'll ask if you haven't already. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Sat, Feb 19, 2011 at 7:25 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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. For some of the things that scribble generates, new versions of the file will break scribble (this is why I originally thought it worth the work to try to have scribble download it from a known place). * If user needs a different version of the file, avoid accidentally getting the Racket-bundled version without knowing. This shouldn't happen. The user says #lang scribble/jfp which is its own, well-documented thing that does not adjust anyone's TEXINPUT paths or anything like that. It only uses jfp's style to help the final paper be something that jfp finds suitable for publishing. * 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. This means that they probably shoudln't be writing their papers in Scribble, then! (And, of course, if they don't do that, then I think that there are no issues.) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Sat, Feb 19, 2011 at 8:22 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 18 Feb 2011 22:44:54 -0500, Sam Tobin-Hochstadt wrote: At least for the JFP file, it's pretty clearly a copyright violation for us to distribute the file at all -- on the web page or elsewhere. We'd have to download it from the CUP site. For the ACM file, I emailed the contact email for the style file about the license. Did you e-mail anyone at JFP, yet? I have not, although one of the JFP editors is on this list :) Looking again, I can imagine reading the jfp.cls file Robby's way. The intent of use may be produce a document, and the overall intent might permit redistribution of jfp.cls to others who are producing JFP documents. That's certainly possible, but redistributing the file requires the permission of the copyright holder, and the tone of the notice suggests that they aren't very flexible about these things. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
Does it seem okay to provide a script that downloads the .cls file from the jfp website and tuck it into the (already installed) distribution (presumably in a user-specific place)? If so, then we can at least set up a drdr test that does that and checks to see if scribble produces exactly the same .pdf file for some well known scribble input file, so we get notified problems when they move the url or make a new version of the file or something. Robby On Sat, Feb 19, 2011 at 8:46 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, Feb 19, 2011 at 8:22 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 18 Feb 2011 22:44:54 -0500, Sam Tobin-Hochstadt wrote: At least for the JFP file, it's pretty clearly a copyright violation for us to distribute the file at all -- on the web page or elsewhere. We'd have to download it from the CUP site. For the ACM file, I emailed the contact email for the style file about the license. Did you e-mail anyone at JFP, yet? I have not, although one of the JFP editors is on this list :) Looking again, I can imagine reading the jfp.cls file Robby's way. The intent of use may be produce a document, and the overall intent might permit redistribution of jfp.cls to others who are producing JFP documents. That's certainly possible, but redistributing the file requires the permission of the copyright holder, and the tone of the notice suggests that they aren't very flexible about these things. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Sat, Feb 19, 2011 at 9:50 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Does it seem okay to provide a script that downloads the .cls file from the jfp website and tuck it into the (already installed) distribution (presumably in a user-specific place)? Yes, this is a well-known workaround in these sorts of situations. It's used for packages that install Flash on lots of Linux distributions, for example. I think it would probably be sufficient to provide a .cls file that errors with a message indicating where to go to get the file, although the script you describe would certainly be a helpful addition. If so, then we can at least set up a drdr test that does that and checks to see if scribble produces exactly the same .pdf file for some well known scribble input file, so we get notified problems when they move the url or make a new version of the file or something. Robby On Sat, Feb 19, 2011 at 8:46 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, Feb 19, 2011 at 8:22 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 18 Feb 2011 22:44:54 -0500, Sam Tobin-Hochstadt wrote: At least for the JFP file, it's pretty clearly a copyright violation for us to distribute the file at all -- on the web page or elsewhere. We'd have to download it from the CUP site. For the ACM file, I emailed the contact email for the style file about the license. Did you e-mail anyone at JFP, yet? I have not, although one of the JFP editors is on this list :) Looking again, I can imagine reading the jfp.cls file Robby's way. The intent of use may be produce a document, and the overall intent might permit redistribution of jfp.cls to others who are producing JFP documents. That's certainly possible, but redistributing the file requires the permission of the copyright holder, and the tone of the notice suggests that they aren't very flexible about these things. -- sam th sa...@ccs.neu.edu -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Sat, Feb 19, 2011 at 8:58 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, Feb 19, 2011 at 9:50 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Does it seem okay to provide a script that downloads the .cls file from the jfp website and tuck it into the (already installed) distribution (presumably in a user-specific place)? Yes, this is a well-known workaround in these sorts of situations. It's used for packages that install Flash on lots of Linux distributions, for example. I think it would probably be sufficient to provide a .cls file that errors with a message indicating where to go to get the file, although the script you describe would certainly be a helpful addition. I guess it depends how much we are worried they will produce backwards incompatible .cls files. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I've batch my responses to yesterday's questions together. As a general note, I'd like to have my document be an accurate reflection of what I should do when I start coding, so if you think I should update it to clarify the answers to these questions, please let me know. I'm blinded a bit by my intentions when I read it. 2011/2/18 Robby Findler ro...@eecs.northwestern.edu: Minor comment: why encourage names like libgtk and libgtk2 instead of a major and minor version number (ala PLaneT)? Don't we want those two libraries to be associated somehow (at least loosely)? I think having libgtk and libgtk2 alleviates a confusion with the most recent version policy. For example, I write my package when there is only libgtk and I don't specify which version I want, because any will do. Later libgtk gets upgraded and its second major version is not fully backwards compatible. I don't think it is plausible for the reader of my package metadata to know that I didn't know about the new version and SHOULD have written a major version 1 requirement, but didn't. By having a strict separation between major versions, I think it is kinder to less specific package metadata. (If you look around PLaneT, very few packages actually specify their dependencies with much detail.) As a slight social engineering, this policy also makes it easier to provide alternatives to dead packages, because upgrading to an alternative vendor is no harder than upgrading to the official version. Also, it may discourage new major versions and therefore encourage more compatibility. Also, it also isn't clear which of the complaints with PLaneT you're actually dealing with. I don't see anything about security for example or the discovery issue. By moving package dependencies outside of modules and allowing a system-wide installation, I attack the second-class-nes of PLaneT. By a different default policy, I attack the upgrade path. By having a more exposed directory structure and looser package hosting constraints, I attack the improvement problem. On the social site by having reputation, reviews, and tags, I hope to solve the discovery problem. By allowing any URL (without a custom server) as a package source, I hope to solve the centralization problem. By making the packaging system more capable, I hope to decrease the size of the core. Once that happens, those packages can be independently upgraded. On the security defaults, by using URLs, we can use HTTPS to get slightly better security. I mention having checksums on package files to ensure the right file was got. By allowing private repositories, you can ensure that you control your security destiny. I solve the unintended installation problem by making package installation separate from the runtime, where we could provide an apt-get style of these are the other packages that will be installed. I solve the module privacy with the linking directories. I have no solution for expensive installations (indeed in my final open problems I mention how we would store compiled code at the server.) The other part of installation---documentation---could be solved the same way we do now (explicit option to not build) and have better searching on the package site. My solution for untrustworth packages is a rather weak black balling. I think sandboxing compilation is outside the short-term scope of this project. And one fairly abstract worry: can I end up in a situation where I had a working system with dependencies between packages being obvious but install a new package and fall out of the obvious realm in some potentially confusing way? I think this is the most confusing situation: - Install package A that requires B - Develop a packageless program that uses B - Upgrade to a new provider of B's features... B2 Your packageless program uses B2, but A still uses B, even though you may think of them as the same package. I think the alternative behavior, that A starts using a different provider, is worse though. 2011/2/18 Jos Koot jos.k...@telefonica.net: I read your contribution with great interest. One problem that is not addressed, as far as I have seen, is that any idiot, like me, can install his/her contributions (modules/collections/packages or whatever) For a simple windows 7 user as I it is rather difficult to use command line instructions. I plead for an easy to use gui for making contributions. I think this is orthogonal to the project, but I do mention how important it is to have an easy way of getting packages post-installation. I was imagining that this would be a separate GUI tool that was auto-launched on Windows installation and suggested on first launch of DrRacket. I also plead for an option to delete contributions that have never been dowloaded by anyone else than the contributor (would that be possible?) I once contributed a module wrongly. I am sure it has never been dowloaded, but I have no option to correct my silly mistake. All I could do is to upload
Re: [racket-dev] Packaging
On Sat, Feb 19, 2011 at 9:39 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I've batch my responses to yesterday's questions together. As a general note, I'd like to have my document be an accurate reflection of what I should do when I start coding, so if you think I should update it to clarify the answers to these questions, please let me know. I'm blinded a bit by my intentions when I read it. 2011/2/18 Robby Findler ro...@eecs.northwestern.edu: Minor comment: why encourage names like libgtk and libgtk2 instead of a major and minor version number (ala PLaneT)? Don't we want those two libraries to be associated somehow (at least loosely)? I think having libgtk and libgtk2 alleviates a confusion with the most recent version policy. For example, I write my package when there is only libgtk and I don't specify which version I want, because any will do. Later libgtk gets upgraded and its second major version is not fully backwards compatible. I don't think it is plausible for the reader of my package metadata to know that I didn't know about the new version and SHOULD have written a major version 1 requirement, but didn't. By having a strict separation between major versions, I think it is kinder to less specific package metadata. (If you look around PLaneT, very few packages actually specify their dependencies with much detail.) As a slight social engineering, this policy also makes it easier to provide alternatives to dead packages, because upgrading to an alternative vendor is no harder than upgrading to the official version. It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo Also, it may discourage new major versions and therefore encourage more compatibility. This doesn't seem to follow. :) Also, it also isn't clear which of the complaints with PLaneT you're actually dealing with. I don't see anything about security for example or the discovery issue. By moving package dependencies outside of modules and allowing a system-wide installation, I attack the second-class-nes of PLaneT. By a different default policy, I attack the upgrade path. By having a more exposed directory structure and looser package hosting constraints, I attack the improvement problem. On the social site by having reputation, reviews, and tags, I hope to solve the discovery problem. By allowing any URL (without a custom server) as a package source, I hope to solve the centralization problem. By making the packaging system more capable, I hope to decrease the size of the core. Once that happens, those packages can be independently upgraded. On the security defaults, by using URLs, we can use HTTPS to get slightly better security. I mention having checksums on package files to ensure the right file was got. By allowing private repositories, you can ensure that you control your security destiny. I solve the unintended installation problem by making package installation separate from the runtime, where we could provide an apt-get style of these are the other packages that will be installed. I solve the module privacy with the linking directories. I have no solution for expensive installations (indeed in my final open problems I mention how we would store compiled code at the server.) The other part of installation---documentation---could be solved the same way we do now (explicit option to not build) and have better searching on the package site. My solution for untrustworth packages is a rather weak black balling. I think sandboxing compilation is outside the short-term scope of this project. These seem reasonable, but I did not get a clear connection when reading your essay. My comment is probably a presentation one, then. In general, the essay seems long on problem descriptions and short on solution descriptions, relying on the reader to be familiar with low-level details of Racket and having to be able to synthesize from them how things will interact. I suspect that a high-level description of the solution you're imagining (and possibly some more specific uses cases) will make your essay more readable (as you may have noticed, most of the replies don't actually say anything about your proposed solution in any detail; probably because we can't understand it). And one fairly abstract worry: can I end up in a situation where I had a working system with dependencies between packages being obvious but install a new package and fall out of the obvious realm in some potentially confusing way? I think this is the most confusing situation: - Install package A that requires B - Develop a packageless program that uses B - Upgrade to a new provider of B's features... B2 Your packageless program uses B2, but A still uses B,
Re: [racket-dev] Packaging
On Sat, Feb 19, 2011 at 10:18 AM, Robby Findler ro...@eecs.northwestern.edu wrote: It looks to me like you there is relevant, important metadata that you're making someone fold into an implicit place instead of an explicit one. Will you have a convention for these? What if I decide to call mine libgtk2.0 and someone else calls theirs somepackage-2? That doesn't seem good fo [ Sorry; got distracted here and forgot to come back. ] That doesn't seem good for users who are trying to find packages. Especially if I were to call mine 2-somepackage (you may think this far fetched, but if you look you should find an example of this in our current collection tree) Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
An hour and a half ago, Robby Findler wrote: On Sat, Feb 19, 2011 at 8:58 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Sat, Feb 19, 2011 at 9:50 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Does it seem okay to provide a script that downloads the .cls file from the jfp website and tuck it into the (already installed) distribution (presumably in a user-specific place)? Yes, this is a well-known workaround in these sorts of situations. It's used for packages that install Flash on lots of Linux distributions, for example. I think it would probably be sufficient to provide a .cls file that errors with a message indicating where to go to get the file, although the script you describe would certainly be a helpful addition. I completely agree with that -- what's the best links for the two files? I guess it depends how much we are worried they will produce backwards incompatible .cls files. I don't think that this is a problem. These files do two things -- they change the layout etc (so there's no additional commands to use), and much less frequently they add commands. I think that if there's a new version that *breaks* some existing command, then it's likely something different enough that you'd want to use it anyway. That's on top of the fact that the first kind of change is frequent enough that I think that people are likely to end up using the updated version anyway. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Feb 19, 2011, at 9:46 AM, Sam Tobin-Hochstadt wrote: I have not, although one of the JFP editors is on this list :) I have routinely provided the JFP style file from my own web page, and I am pretty sure JFP knows that I do so. Of course, I am the content EiC not the commercial editor. I'll ask. ;; --- For SIGPLAN I will say that I routinely have to change the 'latest' download that students use for their drafts so that I get one-column versions of the papers that I can extensively edit. I would really prefer scribble to provide the option of installing my own and not requiring a fixed file. -- Matthias _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Latex files
On Sat, Feb 19, 2011 at 11:19 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: For SIGPLAN I will say that I routinely have to change the 'latest' download that students use for their drafts so that I get one-column versions of the papers that I can extensively edit. I would really prefer scribble to provide the option of installing my own and not requiring a fixed file. This particular option seems incredibly useful and perhaps one that scribble should provide support for directly. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
I think that the versioning problem is an important and hard one, and the obvious first place to turn this infrastructure work into a research result. Racket gives you a significant opportunity that others would not have (for a certain class of solutions, at least). Even better, we have significant experience with one end of the spectrum and, of course, there are lots of other attempts out there that we should also be able to extract experience from if we dig into linux distros and their communities, etc. Robby On Sat, Feb 19, 2011 at 3:53 PM, Jay McCarthy jay.mccar...@gmail.com wrote: Eli, you have a lot of very good points that I will try to respond to individually later. I think the highest bit issue you bring up is conflicts. (Multiple versions are a special case of conflicts between packages.) I see three options 1. Totally disallow conflicts 2. Make conflicting installations irregular 3. Make conflicting installations normal I think (1) is epitomized by a single location that packages get copied into as they are installed. I think (2) is epitomized by something like (1) with a secret place on the side for conflicts to be stored. I think my proposal is (3). I think the way I proposed to deal with conflicts dovetails nicely into dealing with module privacy. I like the way that keeping things in separate directories always makes it easy to deal with version control. I also like the decoupling of package names and the modules they provide. I'd like to know where our community stands on this issue, because if most are happy with (1), then I think the packaging system could be much simpler. I personally think (2) is more complicated than (3). Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
