Re: [racket-dev] Email encoding in net/sendmail
On Tue, Dec 20, 2011 at 1:22 PM, Eli Barzilay e...@barzilay.org wrote: 2. There is still an issue with non-ascii content in the body. Digging around, it seems to me that the easiest way to make it work is to always add a Content-Transfer-Encoding: 8bit header. Does anyone know if this is a correct way to do this? (I'm not clear about the differences between the different content headers.) 8bit is not considered safe for SMTP - a SMTP server is 8bit safe if it supports 8bitmime (see http://www.ietf.org/rfc/rfc1652.txt), but it's no guarantee that 8bit-safe server will route only with 8bit-safe servers. By default content are encrypted either via quote-printable or base64, with the content-transfer-encoding set accordingly. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Email encoding in net/sendmail
On Tue, Dec 20, 2011 at 1:37 PM, YC yinso.c...@gmail.com wrote: By default content are encrypted either via quote-printable or base64, with the content-transfer-encoding set accordingly. I meant encoded instead of encrypted. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Packaging
Jay - 1. Thanks for having this out - this is a great start and a very important problem to solve 2. Is it correct that *heap* maps to the account name in planet? Such as jaymccarthy, schematics, or bzlib? There is always tension between the naming by capability or author in package systems. Do we have a preference one way or another? 3. For all the modules that are currently in core, it might make sense to simply lump them under a *core* heap to simplify the reorganization, but it's clear that not all packages are strictly required, so it would eventually be great to separate them out: 1. absolute core (scheme racket language, no GUI) 2. GUI 3. other languages 4. etc 4. Agreed that the installation/compilation takes way too long. Would like the ability to turn off doc installation - I believe docs needs to be online, and easily updated, i.e. wiki format 5. Another thing to improve the time of installation is to have pre-compiled binaries. If this is a possibility, then perhaps binary-only package should also be considered. That might not be the open source ideal, but can increase more adoption 6. Planet packages also have problems with dependency breakage when the dependency is a development link. So that will need to be addressed 7. It's hard to understand the Glue section - are you suggesting having the URL embedded into the require spec? I hope I am reading it incorrectly, as such hardcoding should be avoided. 8. The Linux repo (such as apt or yum) should be the preferred approach here - having a repo definition that defines where to search for packages. Such approach allows for having planet mirrors and private repos The above are what I can think of for now. Cheers. yc On Fri, Feb 18, 2011 at 1:21 PM, Jay McCarthy jay.mccar...@gmail.comwrote: You may recall from the meeting over the summer that I promised a packaging Christmas present to Racket. I'm over a month late, but here it is: http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html I lay out some goals for the new packaging system and make a concrete proposal. Please share your feedback so I can direct my efforts better. Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] racket-lang down?
Looks like planet is down. On Wed, Jan 19, 2011 at 10:56 PM, Jon Rafkind rafk...@cs.utah.edu wrote: its working for me. i just submitted a bug, too. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Tue, Dec 7, 2010 at 1:17 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I've removed the coercive contracts and replaced them with a global imperative any-response hook that defaults to off but can easily be turned on to support X-exprs or the old behavior of the Web Server. Great! Thanks. yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Mon, Dec 6, 2010 at 9:35 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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.) Coercion can go wrong when it tries to create good value over zealously, but if applied judiciously it should be the same as input validation, which performs the following: 1. accept inputs in particular formats 2. validate the input's soundness - if fails, reject the input 3. if successful - pass the input through Step # 2 is often done as a conversion step, since if the conversion is successful the value is valid. And if you have converted the values to an internal representation already, it makes sense to simply pass on the internal representation, instead of asking the inner function to do the conversion again explicitly. The key is that there isn't a general coercion mechanism, as you do not want to convert all values into the same representation by tracing all coercible routes. But in limited environment it can save quite a bit of typing and denotes intention clearly like a contract system. The nice thing about the contract system is that it has the support of the runtime to assign blame to the correct party, whereas an input validation's error doesn't tell you who the caller is, so it's harder to track down the offending input. So having the ability to assign error to the correct location provided by the runtime can aid people to develop their own limited scope coercion mechanism. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Dec 4, 2010 at 10:29 PM, Jay McCarthy jay.mccar...@gmail.comwrote: The Web Server will define response/c as (dynamic/c any/c current-response/c response?) and provide the current-response/c parameter for customization. The default will be no coercion, but Xexpr conversion will be easily accessible. A compatibility library will automatically set current-response/c appropriately. This looks great! And again thanks for taking the time to go through a vetting process - appreciated. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
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. The compatibility issues simply appear to be much more than an explicit make-xexpr-response call and will most likely cause breakage. This is the type of change that two parallel versions should be kept until it's clear everyone has a chance to migrate (and that can take a long while). I like the migration path from mzscheme to scheme to racket that all are still available and maintained. Except for the mutable pair issue that broke a few libraries, it was quite well managed. Cheers, yc On Fri, Dec 3, 2010 at 10:54 PM, Jay McCarthy jay.mccar...@gmail.comwrote: Here is my current plan: Add web-server/compat/0 directory with, e.g., web-server/compat/0/http/response-structs to hold compatibility bindings to bridge the old http/response-structs and the new http/response-structs In that directory is the attached README. What do you think? Jay _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Dec 4, 2010 at 5:25 AM, Jay McCarthy jay.mccar...@gmail.com wrote: I think you misunderstand. Every place where there is incompatibility listed in the README is solved by putting a call to response/xexpr rather than returning an Xexpr. The file just lays out all the places where you may need to put those calls. Almost all of those places are internal plumbing places that I don't observe people using in practice [especially the ones which I haven't provided compatible bindings for [except for web-server/insta]] Reading it again I realize that my concern is that I cannot discern what I need to do to keep compatibility from the doc alone and that had me concerned. I probably should have waited to read it again in the morning before sending out an email. Question: what does all the removed binding mean? For example, response/basic, response/incremental, etc are all removed. Are these kept in the compatibility layer and the removed mean that they are removed from the old version? I'm not convinced that a parallel version will be any different than a user staying with an old version or taking the directory from the old version and putting it in the new version. If users stay with an old version because of this wouldn't that defeat the purpose of making a new release? Also I would not expect users to manually copy the old web-server and put it into the new version, because such change means they are shackled to their own customization of the platform, which will break when the platform is yet upgraded again. I think the difference is that those are languages where you want interoperability between ported programs and yet-to-be ported. In contrast, even though you can split a Web app into many servlets and many modules per servlet, I don't observe people using multiple servlets [which would be able to be ported separately]; and if you tried to just port some modules of a many-module servlet, it simply wouldn't work with parallel version because there would be, for example, two incompatible request data structures because they are generative. Having the old language available means users do not have to port the code at all. That's the path to least resistance toward an upgrade. My C code written 10 years ago still compiles on new compilers today without me having to fix anything, and that gives me the confidence as an user that I can upgrade to the latest and greatest version, and I can sell those code to whoever wanting to buy them without any fuss on my part. With regards to web-app, people might not write multiple servlets, but if their app is of any complexity (most web apps I know are complex) they will call many other modules to do the work, and that means they might want to write newer modules with newer version of racket because of a new features are being offered (or a critical bug fix being available). But they likely will want to focus their energy on taking advantage of that new feature, instead of having to fix their servlet because of compatibility. Having said that, I am not saying compatibility can never be broken - just that it always comes at a cost. So the users need to be enticed to an upgrade with promise of better functionality, supported with an upgrade path, and perhaps enforced with a grace period of obsolescence. In this specific case, I am not sure what users will gain with the refactoring. I know what it gains architecturally, but the benefits for users have not been articulated. Cuz again, xexpr is a good default format, and users should have a default format instead of having to always make a response explicitly. It feels like the users have lost a benefit. Thanks Jay for putting this up through a vetting process. Although my opinion appears to differ from yours, I want to ensure you know that I appreciate you doing this, as it shows that you value users' input and put the concern of compatibility high. My perspective comes from an industry user and lib writer, and I harbor the hope that racket can achieve that escape velocity perl/python/etc enjoyed, so I constantly apply industry expectations here, which might not be fair yet, since that might not be a goal of the racket team, but I can hope can't I ;) Anyhow - just my 2 cents as usual. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Removing Xexpr preference from Web Server
On Sat, Nov 27, 2010 at 2:39 AM, Jay McCarthy jay.mccar...@gmail.comwrote: 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? Having response/port is great. In the future it would also be great to expose the input output port to the servlet. I very much agree; I wonder if the single 'make-xexpr-response' will be too much overhead. It won't be just a single make-xexpr-response at the entry point, if the idea is to push the construction of the type of responses into the servlet, unless the servlet only deals with a single type of response. On Fri, Nov 26, 2010 at 4:55 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I would like to remove the implicit preference the Web Server gives to Xexprs and the old esoteric bytes response format. This is backwards incompatible change, but I think it will make the server better in the long run as it will promote other HTML encodings, like the xml and html modules, Eli's new system, SXML, etc. I am interested in your opinion. I agree with Neil that xexpr or sxml are very nice representations of html as well. Given their inherent advantage I think an extensible response mechanism might work better: 1. create hooks to handle different response types 2. let the different package to install the necessary hooks For example - the hook might be called make-response-hook, and in xml package (maybe xml/web-server.ss) can install the hook. Such a hook will allow others to make their own extension as well to manage their own custom response types. My 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Wed, Jul 28, 2010 at 1:09 AM, Stephen De Gabrielle stephen.degabrie...@acm.org wrote: It's not to early to think about an expanded set of categories One idea is to allow module writers to add to the categories or tags so it becomes a decentralized process, like how blogs do it these days. On Wed, Jul 28, 2010 at 6:41 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jul 28, 2010, at 12:26 AM, YC wrote: Other package systems separate the installation step from the import step Indeed, this is the key design decision separating us from the rest of the world, and it is not clear whether it was a good decision. I personally like the design except for the issues I've raised so far, but the disadvantage can be remedied by unifying the require spec syntax between collects and planet. On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell d.j.gurn...@gmail.com wrote: I'd also like to be able to set up a PLaneT proxy to add in-house libraries in on the top of publicly available libraries from planet.racket-lang.com . See my bzlib/planet package. This is an example where I would like to see the core team take advantage of what's available on planet directly instead of porting it into core. On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: Most important for me, I'd like to be able to define multiple (what I'll call for now) repositories (like Debian apt). FWIW - bzlib/planet is designed for you to facilitate having your own internal packages now. When multi-repo becomes available, you can still use bzlib/planet to host your own repo. On Wed, Jul 28, 2010 at 7:03 AM, Dave Gurnell d.j.gurn...@gmail.com wrote: I'd personally be in favour of a leaner core distribution with more code in external packages, so I can choose what I download when I'm only interested in a single web application. Once the collects and planet require syntax are unified - moving the currently-core packages to planet will become a snap. At that time it might even be possible to have build your own distribution by picking your own packages. On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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. Now I think about it, it might make sense to have local repo able to overwrite core repo in case you want to patch the core code. In that case the module resolve I proposed earlier would have to be changed to: 1. Try lookup the package in planet cache 2. If #1 fails, lookup in COLLECTS 3. If #2 fails, try lookup the package in planet repo On Wed, Jul 28, 2010 at 8:20 AM, Neil Van Dyke n...@neilvandyke.org wrote: 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. I like what ASDF has to offer here. The only thing I would add is that this auth mechanism should be optional (perhaps as a policy per repo). All my additional 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
IMHO planet works very well and shouldn't have issue to scale beyond a few thousand packages if it ever gets to that point. However, to get there I believe planet first needs one major upgrade - it needs to become location transparent - meaning that requiring modules in COLLECTS and PLANET look exactly the same from code perspective. With this change the invisible cultural divide between planet and core distribution will disappear, and core team can tap into the work of module developers, which in turn will help module developers feel more involved in the community - the virtuous cycle can then be built to gain momentum to increase the community. I have discussed the issues in detail back in January in the thread http://lists.racket-lang.org/users/archive/2010-January/037703.html - and love to discuss further if others are interested. Cheers, yc On Tue, Jul 27, 2010 at 2:45 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: If this hasn't come up yet here, please do take a look at http://donsbot.wordpress.com/2010/05/31/there-are-a-hell-of-a-lot-of-haskell-libraries-now-what-are-we-going-to-do-about-it/ I am sure we will face this kind of problem one day and we might be able to prepare ourselves a bit. _ 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] haskell's 'hell of a lot of libraries', planet
Thanks Matthias - please see inline. On Tue, Jul 27, 2010 at 7:03 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: 1. a 'remote url' require (which is what Planet boils down to) imposes a serious cost overhead (for compilation) and a connectivity overhead (suppose I send you code and you wish to compile it on your netbook while on the subway). People who get this kind of code should be aware of it. At a minimum, the path should start with /planet/ and that'll set it apart. (There's more, such as versioning.) Location non-transparency matters a lot in remote API calls since each calls incurs non-trivial network overhead. However, the 'remote url' require is only remote the *very first time*; once compiled it exists in cache and hence incur no additional overhead. Whereas the planet prefix incur the awareness overhead every single time. I.e., the cost is greater than the benefit. Other package systems separate the installation step from the import step, and in such systems the subsequent use of the package appears exactly the same as a local package. If we want `require` to continue to handle both first-time install and subsequent import, and we wish to unify the syntax, then what we can do is to make the first time interactive - i.e. when we require a package that has not been cached, we can prompt the user saying this package resides on planet - do you wish to download and continue the installation?. There are probably better UI approaches, but that's an idea. For versioning - any explicit version can be cached in planet style, and all version exists on planet systems. What this means is once planet and collects unify, you can have the different versions of collects packages living in planet. 2. it is easy to find and fix collects code. Planet's download mechanism would have to change a lot to enable that. This is the cultural issue that I am talking about. To use other people's code there needs to be trust that other people's code will be supported. The trust won't be built over night, but you also will not start using other people's code en masse. So there is time to build that trust. At first, most likely you will only try out a few packages, and probably from people that are already contributing to the collects packages, since you know them. But then eventually you will be able to include more people once the approach is understood and tested. Currently - the above is not possible at all since the platform prohibits it. So the platform needs to be fixed first before the culture will change. If direct source tree access is desired, then perhaps providing a planet source control system for module writers to opt-in for packages that become candidates to be included in the core system can be a requirement. This probably looks like a lot of chores at first, but the community can grow this way by giving module writers a chance to participate. My 2 cents. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Tue, Jul 27, 2010 at 7:06 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I guess the idea is that you'd eliminate the syntactic difference between a planet-located library and one in the distribution and then require on some external source to know where the package is located? Something like that? How would that work? Hi Robby - there are a lot of ways to go about doing this; Jay pointed to some ideas. Here's one KISS approach without major changes (assuming the syntax have been unified): Modify the module path resolver so that it does the following lookup for non-versioned require specs: 1. try lookup the package in COLLECTS 2. if #1 fails, lookup the package in planet cache 3. if #2 fails, lookup the package in planet repo For the versioned specs, you can skip the collects step above since it is currently not versioned. But of course you can also change collects to become versionable in the future if you wish to re-architect the system. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] haskell's 'hell of a lot of libraries', planet
On Tue, Jul 27, 2010 at 8:57 PM, Jay McCarthy jay.mccar...@gmail.comwrote: If PLaneT worked the same way, it would just be a way of distributing our .plt files. This is a great way to think about planet - a distribution mechanism that can be used to distribute any package. On Tue, Jul 27, 2010 at 8:59 PM, Jay McCarthy jay.mccar...@gmail.com wrote: I think we can and must improve the browsing, searching, rating, etc parts of PLaneT. There's no shame in copying Hackage, CPAN, etc on these areas because they are probably very wise in their decisions. +1. AFAICT CPAN is still the gold standard today that can be emulated. Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] multiple key-press
On Thu, Jul 22, 2010 at 6:43 AM, Jay McCarthy jay.mccar...@gmail.comwrote: On Thu, Jul 22, 2010 at 7:38 AM, Shriram Krishnamurthi s...@cs.brown.edu wrote: As far as I know, at the lowest level there is no multiple key press event even in the OS. Not that there is a multiple key press event in OS, but below are some potential solutions/examples in other languages: Here's a potential solution in C# describing looking up keyboard states via kernel32.dll - not sure whether it will easily be applicable/ported in your scenario. http://stackoverflow.com/questions/2686019/multiple-key-presses-doing-different-events-in-c Processing also appear to handle multiple keypress (code): http://wiki.processing.org/index.php?title=Keep_track_of_multiple_key_presses Here's one demo in flash with WASD - but did not show firing: http://www.freeactionscript.com/2009/02/multiple-key-press-detection/ Cheers, yc _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
