Re: [racket-dev] new release policy
On Thu, Aug 12, 2010 at 7:55 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 12 Aug 2010 07:28:34 -0400, Eli Barzilay wrote: One thing about stability that bugs me is pushing changes and extensions that are likely to change. For example, I'm worried about Jay's push for a number of new features as a response to a blog post, it looks like coding in haste that is likely to change. I strongly support Jay's current push. We don't need to wait for a new package system to get our data-structure libraries in better shape. FWIW, I too agree that Jay's push was a good one. Robby _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] How to build Places
At Wed, 11 Aug 2010 18:56:49 -0400, Gene Diveglia wrote: Building as outlined below on OS X 10.6.4 Intel is failing. I'm anxious to experiment with places, any suggestions on how to fix this build? I've pushed a repair to the header files, but GRacket crashes if you try to run it; I think that GRacket doesn't yet cooperate properly with Racket when places are enabled. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] continuation weirdness
Understood, too. So, do you want WeScheme/Racket compatibility or WeScheme/DrRacket compatibility? In some sense, neither. We'd like to understand what is actually happening, so we can make an intelligent decision accordingly. Shriram _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] experiment of the unified require syntax == Re: haskell's 'hell of a lot of libraries', planet
Hi YC, At the meeting we had in Chicago this past weekend, we discussed the packaging system and where it needs to be. One of the high-level points was that there should be no distinction between core and user packages in a program; the only distinction between these will be in the installation environment. I think that's one of your main desires, so I hope that will make you happy. In the next few months, I plan on sending out the design document and specification of the packaging system for comments and I hope that you will read it closely. Jay On Mon, Aug 9, 2010 at 4:12 PM, YC yinso.c...@gmail.com wrote: Hi all - I have uploaded bzlib/UNIFY.plt to planet, hoping to demonstrate what an unified require syntax between collects and planet can look like when we keep it simple. Please feel free to play with the code. The example below represents how the syntax can look like (bolded are translated to the planet form): #lang planet bzlib/unify ;; hoping to see #lang racket here soon instead... (require net/url ;; in collects soegaard/infix ;; from planet == (planet soegaard/infix) (only-in bzlib/file mtime) ;; == (only-in (planet bzlib/file) mtime) ) (provide (all-from-out net/url ;; in collects soegaard/infix ;; in planet ) ) Note the main difference is simply the removal of (planet). bzlib/unify follows a very simple lookup rule (even simpler than I have thought needed originally) - it checks to see if the module-path exists (i.e. net/url or soegaard/infix) via the default (current-module-name-resolver). If it exists it's in collects, otherwise wrap the path in `(planet ,module-path). No additional database lookup is required. And it does not incur anymore network overhead for planet packages than would have been needed in the first place (just the first-time install). The package is meant to showcase the viability of the approach and hope to spark further conversations/actions. Although the concept is doable as a planet module, it should really be incorporated into the core module resolver, since that can make it faster and do error handlings (hiding the planet origin in an error message) better. A few considerations: 1 - there might be name clashes between the packages in collects vs in planet. This can be fixed via some or all of the following approach: reserve account names (such as racket or scheme) in planet so others cannot register them that maps to the collects packages so there are no future conflicts if there are already conflicts - determine what to do there on case by case basis, including possibly taking over the account or rename the collect package in question 2 - planet packages are always in the form of account/package.plt, whereas collects do not follow this rule. This can either be fixed by changing the planet system to enable top level packages, or change the collects package to follow the same convention. 3 - you (racket core devs) might want a new way to specify module paths instead. I am only focused on removing planet from the require/provide syntax, and trying to show that it can be done without a hefty re-architecture so you might decide to incorporate it. If you do feel new module path formats are warranted, that's great too. Thoughts/comments/questions? Love to discuss further on this topic. Cheers, yc On Wed, Jul 28, 2010 at 12:33 PM, YC yinso.c...@gmail.com wrote: 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
[racket-dev] GUI Refresh
Observation of DrRacket and PLT Redex leads me to believe that when updating something displayed in the GUI each change is immediately reflected (in a nice functional manner), even if a batch of changes is being performed, thus wasting time drawing the GUI on intermediate results. The effect is a less usable GUI. Example 1: Have two tabs open in DrRacket. Click the other one. You can see the scroll bar adjust first, showing the corresponding location in the current file, then the contents adjust second showing the right file. Example 2: In PLT Redex traces graph, move the font-size slider. The whole GUI freezes up until it has redrawn, even though I wasn't done moving the slider. The result is that I have to move the slider one font size (or few font sizes) at a time. Possible solutions: - For the slider: a timeout after user input stops before actually changing the value. - For the tabs: The ability to give a list of changes before updating the GUI - Functions to turn on/off updating and use them around a group of changes or when dragging a slider. - Some other kind of double-buffering feature at least, so it isn't as slow and as visible. Or am I wrong about the cause (and thus solutions) of these GUI problems? Thanks, -Everett _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] new release policy
On Aug 12, Sam Tobin-Hochstadt wrote: On Thu, Aug 12, 2010 at 7:28 AM, Eli Barzilay e...@barzilay.org wrote: One thing about stability that bugs me is pushing changes and extensions that are likely to change. For example, I'm worried about Jay's push for a number of new features as a response to a blog post, it looks like coding in haste that is likely to change. This is something that the `unstable' collection can be useful for. +1, in general. It allows us to get some experience with a new API without foreclosing the possibility of changes. Of course, that means it won't be as immediately useful for users outside of the collects, but I think a little patience can pay off here. (And here too.) On Aug 12, Matthew Flatt wrote: At Thu, 12 Aug 2010 07:28:34 -0400, Eli Barzilay wrote: One thing about stability that bugs me is pushing changes and extensions that are likely to change. For example, I'm worried about Jay's push for a number of new features as a response to a blog post, it looks like coding in haste that is likely to change. I strongly support Jay's current push. We don't need to wait for a new package system to get our data-structure libraries in better shape. My point was completely unrelated to packaging. (Jay added it to the core racket language anyway.) On Aug 12, Jay McCarthy wrote: As a final note, I don't intend this to be a mere pandering to this blog post. When I was reading the blog post I found myself saying, Ya but you could implement that so easily or Ya, it is annoying to use that pattern, etc. Hearing myself say that told me that I've always wanted many of these functions but I always implemented them in a one-off fashion or used a boilerplate pattern. I should explain why I said the above. (Yes, this will be verbose. Why? Because my short one-sentence version was taken as a baseless whine, so I'll go through the details that I'd think through before doing this. Perhaps this is too much, but I'd like to think it isn't, especially for code in racket/private.) First, I completely agree with this specific mode of operation (and have added several things in a similar way) -- but the thing that I'm careful with is adding things that might be regretted later on. One place that I'm not too happy about is `fold-files', which I'll use as an example. IMO, such regretting can lead to one of these: * Coming up with a better interface, but keeping the old one for compatibility (keeping `fold-files' as is, and keeping it working), * Same, but removing the old one (either a new `fold-files' with a different interface, or a new name instead), * Improving the interface in a desired way, while keeping things backward compatible. The last one is almost always the best way to go, and I view keyword arguments as an essential feature because it makes this option practical. In the `fold-files' case it is likely that problems could be fixed by adding more keywords, and possible changing the default behavior (which is more work but even that is reduced with keywords, since existing call sites only need to be updated with a new keyword). Without keywords, this would not be possible. But dealwing with sequences is not something that can be deferred for later with some keyword -- at least not as easily as with a function. And in light of this I'd be much more careful about adding things that might turn out to be more regrets. As for the actual thing that I'm talking about -- sequences and making them more list like -- I should have explained why I think this addition is not something that is clearly desired in my view. Yes, there is definitely a problem with sequences and lists -- the first is way more complicated to deal with than the second, and Mark's post did highlight this issue. One solution is what Jay did -- do the extra work of building the list-like sequence functions, and given enough primitives, the rest would be easy to add if/when needed. But what about these issues: ** The addition is *slow*. Very slow. I wrote a test program to sum up the integers from 0 to 200 -- and I get these numbers (test code attached below): - Plain `for' loop: cpu time: 9 real time: 10 gc time: 0 - Using a sequence value:cpu time: 222 real time: 222 gc time: 0 - Using `seqn-cdr' on range: cpu time: 1142 real time: 1142 gc time: 211 - `seqn-cdr' + value:cpu time: 1141 real time: 1141 gc time: 210 I view this as a real problem -- performance issues at the 100x slowdown are bugs at the library level, but at the core level they're *bad* bugs. ** At the conceptual level, there is a major problem with for sequences -- if you care about performance, they're second-class values. As seen above, using a sequence value instead of the form directly in the for loop makes it 20x slower. This is kind of ok as things currently stand (pre Jay's afdditions), since most people who deal with
