Re: [racket-dev] the preferences file under Windows
At Thu, 13 Jan 2011 17:29:15 -0500, Eli Barzilay wrote: 30 minutes ago, Matthew Flatt wrote: Unfortunately (again), the lock file has to exist alongside the data file, and our existing preferences files are not accompanied by lock files. It's no good assuming that you don't need the lock if there's no lock file present, because the lock file might get created in between the time that you try to use the lock file and the time that you try to open the preferences file. Why not always use such a lock file, creating it if it's not there -- and then you can open it once per process, and lock/unlock it for each read/write of the actual file. Done (Windows only). The `racket/file' library now provides `preferences-lock-file-mode', which reports the style of locking being used. DrRacket, for example, may need to use that function --- instead of testing whether the current platform is Windows --- to determine whether it can try to steal a lock by deleting the lock file. (As far as I know, there's no way to steal a Windows-implemented file lock. The lock will be released when the holding process is terminated.) The default handling of lock errors in `get-preference' is to wait a little while and try again. On the first failure, the handler waits 0.01 seconds, then it waits 0.02 seconds, then 0.04 seconds, then 0.08 seconds, then 0.16 seconds, and then it gives up with an exception. This default is implemented by a `make-handle-get-preference-locked' function provided by `racket/file'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] the preferences file under Windows
20 minutes ago, Matthew Flatt wrote: The `racket/file' library now provides `preferences-lock-file-mode', which reports the style of locking being used. DrRacket, for example, may need to use that function --- instead of testing whether the current platform is Windows --- to determine whether it can try to steal a lock by deleting the lock file. (As far as I know, there's no way to steal a Windows-implemented file lock. The lock will be released when the holding process is terminated.) The default handling of lock errors in `get-preference' is to wait a little while and try again. On the first failure, the handler waits 0.01 seconds, then it waits 0.02 seconds, then 0.04 seconds, then 0.08 seconds, then 0.16 seconds, and then it gives up with an exception. This default is implemented by a `make-handle-get-preference-locked' function provided by `racket/file'. Not too important now, but wouldn't it be easier to do the same thing on unix using flock()? -- ((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
[racket-dev] Gr2 on debian system: vastly better than 5.0.2!
It probably won't come as a surprise to hear that the newer gr2 flavor of DrRacket resolves all of the bizarre (and unfixed) font problems I had with older versions of DrRacket on bare-bones debian systems. Thanks! John smime.p7s Description: S/MIME cryptographic signature _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] atomic file update by write rename... not!
Yesterday, Matthew Flatt wrote: At Thu, 13 Jan 2011 16:30:08 -0500, Eli Barzilay wrote: 15 minutes ago, Matthew Flatt wrote: Is there anything else in the main distribution that is uses `rename-file-or-directory' for atomic update? Is the handin-server's use kosher? There are three uses of it, and the only one that looks suspicious is the last one, where ATTEMPT is renamed to SUCCESS-0. Those are directories, and you can't move to an existing directory name on any platform, right? I think the handin server probably depends on non-concurrent handins for a given account, though, since it shuffles many files and directories around. Probably it should use some sort of lock to enforce non-concurrency. I think that it does, but I don't remember... In any case, it sounds like if some locking is necessary it will be made obvious by an exception. Yesterday, Robby Findler wrote: In general, it seems like the handin server can safely make the assumption that there is only one sever running for a given directory and thus can do all of the syncronization at the Racket level (unlike the preferences file). Yeah, the issue is not multiple servers, but the single server trying to run two concurrent submissions. -- ((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] atomic file update by write rename... not!
So just use all of the wonderful syncronization stuff we have in Racket for that! The file system as syncronization operation is sooo low level (ahm, inconvenient ;) Robby On Fri, Jan 14, 2011 at 12:50 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Matthew Flatt wrote: At Thu, 13 Jan 2011 16:30:08 -0500, Eli Barzilay wrote: 15 minutes ago, Matthew Flatt wrote: Is there anything else in the main distribution that is uses `rename-file-or-directory' for atomic update? Is the handin-server's use kosher? There are three uses of it, and the only one that looks suspicious is the last one, where ATTEMPT is renamed to SUCCESS-0. Those are directories, and you can't move to an existing directory name on any platform, right? I think the handin server probably depends on non-concurrent handins for a given account, though, since it shuffles many files and directories around. Probably it should use some sort of lock to enforce non-concurrency. I think that it does, but I don't remember... In any case, it sounds like if some locking is necessary it will be made obvious by an exception. Yesterday, Robby Findler wrote: In general, it seems like the handin server can safely make the assumption that there is only one sever running for a given directory and thus can do all of the syncronization at the Racket level (unlike the preferences file). Yeah, the issue is not multiple servers, but the single server trying to run two concurrent submissions. -- ((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
[racket-dev] Blame and re-provided bindings
The new, nicely formatted blame messages helped me discover that every single Redex contract has the wrong negative party. (Admittedly, the commonly used Redex provides are macros.) There are two problems. I believe the first is a bug. The following program (module dependencies DAG: http://pastebin.com/u9KMTnuP) blames d.rkt, even though the abused function never passes through its hands. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt)) c.rkt: #lang racket (require e.rkt) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (require c.rkt) e.rkt: #lang racket (define (f x) x) (provide f) The second problem is that, AFAIK, there's no convenient way to define a module b that combines the provides of two modules c and d. If b requires c and d and provides values f and g using `all-from-out', then b, not the module that requires it, becomes the negative party on the f and g contracts. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt d.rkt)) c.rkt: #lang racket (define (f x) x) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (define (g x) x) (provide/contract [g (- string? string?)]) _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
FWIW, Casey and I talked about this in my office and I've long advocated that (require f.rkt) ;; provide/contract's f with some contract (provide f) or (require f.rkt) ;; provide/contract's f with some contract (provide (all-from-out f.rkt)) should be the equivalent of: (require f.rkt) (provide/contract [f any/c]) as far as the contract library is concerned, but now I'm starting to think that that is not convenient enough. Instead, we should really default to 'provide f with the same contract it had before, as if the programmer had copied and pasted the contract' (so change the blame labels) instead of the more high-falutin' interpretation I had before. So, this means it still will be the case that (provide f) is shorthand for (provide/contract [f any/c]) in some cases, but only when the variable is defined in the given module, not require'd in. Robby On Fri, Jan 14, 2011 at 1:40 PM, Casey Klein clkl...@eecs.northwestern.edu wrote: The new, nicely formatted blame messages helped me discover that every single Redex contract has the wrong negative party. (Admittedly, the commonly used Redex provides are macros.) There are two problems. I believe the first is a bug. The following program (module dependencies DAG: http://pastebin.com/u9KMTnuP) blames d.rkt, even though the abused function never passes through its hands. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt)) c.rkt: #lang racket (require e.rkt) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (require c.rkt) e.rkt: #lang racket (define (f x) x) (provide f) The second problem is that, AFAIK, there's no convenient way to define a module b that combines the provides of two modules c and d. If b requires c and d and provides values f and g using `all-from-out', then b, not the module that requires it, becomes the negative party on the f and g contracts. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt d.rkt)) c.rkt: #lang racket (define (f x) x) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (define (g x) x) (provide/contract [g (- string? string?)]) _ 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] Blame and re-provided bindings
The first problem is a variant of PR 11084, I think. Ryan On 01/14/2011 12:40 PM, Casey Klein wrote: The new, nicely formatted blame messages helped me discover that every single Redex contract has the wrong negative party. (Admittedly, the commonly used Redex provides are macros.) There are two problems. I believe the first is a bug. The following program (module dependencies DAG: http://pastebin.com/u9KMTnuP) blames d.rkt, even though the abused function never passes through its hands. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt)) c.rkt: #lang racket (require e.rkt) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (require c.rkt) e.rkt: #lang racket (define (f x) x) (provide f) The second problem is that, AFAIK, there's no convenient way to define a module b that combines the provides of two modules c and d. If b requires c and d and provides values f and g using `all-from-out', then b, not the module that requires it, becomes the negative party on the f and g contracts. a.rkt: #lang racket (require b.rkt) (f 3.5) b.rkt: #lang racket (require c.rkt d.rkt) (provide (all-from-out c.rkt d.rkt)) c.rkt: #lang racket (define (f x) x) (provide/contract [f (- integer? integer?)]) d.rkt: #lang racket (define (g x) x) (provide/contract [g (- string? string?)]) _ 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] Blame and re-provided bindings
On Jan 14, 2011, at 2:44 PM, Robby Findler wrote: as far as the contract library is concerned, but now I'm starting to think that that is not convenient enough. Instead, we should really default to 'provide f with the same contract it had before, as if the programmer had copied and pasted the contract' (so change the blame labels) instead of the more high-falutin' interpretation I had before. To some extent, this is what the user label was supposed to signify. That is, the negative blame stays correct (by our high-flautin' interpretation), but you also get additional blame that tells you if that value flowed to a different region of code that used it. This latter information is often more precise, and is exactly the old negative information. That is, the blame information you'd get when you don't consider simple reprovides as entering into the contract and reproviding with any/c. Just to check, we are still printing out the user blame information when it differs from the negative blame, right? (I know there's been work done on changing the contract messages, but I haven't tried it out yet.) Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] response/xexpr missing?
[Moving to dev] 15 minutes ago, Jay McCarthy wrote: It was added during the time between the last release and the current release (which will come out imminently.) And the moral is to wait with changes to the front page examples until after the release, I think. (If more such things add up, we could have a next branch that contains such commits, which I'll merge to the tree when doing a release. But for now it seems like there's no need for more bureaucracy.) -- ((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] Blame and re-provided bindings
No, actually in this case the user message is also wrong. If you trace thru the module dag, you'll see it. Robby On Fri, Jan 14, 2011 at 1:53 PM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 14, 2011, at 2:44 PM, Robby Findler wrote: as far as the contract library is concerned, but now I'm starting to think that that is not convenient enough. Instead, we should really default to 'provide f with the same contract it had before, as if the programmer had copied and pasted the contract' (so change the blame labels) instead of the more high-falutin' interpretation I had before. To some extent, this is what the user label was supposed to signify. That is, the negative blame stays correct (by our high-flautin' interpretation), but you also get additional blame that tells you if that value flowed to a different region of code that used it. This latter information is often more precise, and is exactly the old negative information. That is, the blame information you'd get when you don't consider simple reprovides as entering into the contract and reproviding with any/c. Just to check, we are still printing out the user blame information when it differs from the negative blame, right? (I know there's been work done on changing the contract messages, but I haven't tried it out yet.) Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
The first. I think you've got it. Robby On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 14, 2011, at 4:22 PM, Robby Findler wrote: No, actually in this case the user message is also wrong. If you trace thru the module dag, you'll see it. Just to check, are you talking about the second series of modules, or the first? The problem in the first is likely a variation of PR11084, as Ryan said. In the second, I get: contract violation: expected integer?, given: 3.5 contract on f from (file /Users/sstrickl/c.rkt) via (file /Users/sstrickl/a.rkt), blaming (file /Users/sstrickl/b.rkt) contract: (- integer? integer?) at: /Users/sstrickl/c.rkt:4.1 and if I'm breaking that text down correctly, that's: positive: c user: a negative: b Which seems right to me, according to what I said. That is, b entered into a contract with c about value f. b reprovided f (with no contract) to a, who actually used the value via the expression `(f 3.5)'. So a misused the value, but b was responsible for its misuse (since it gave it to a without any additional protection). This is, of course, going by the interpretation of uncontracted reprovides being equivalent to reproviding with the contract any/c. Have I missed anything here? Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] response/xexpr missing?
7 minutes ago, Robby Findler wrote: I've wanted to change the front page to change the 2htdp/image example to use 'freeze' (making the program go from exponential to linear in 'n') too, but I've held off until it was in an actually released release. It's still minor -- so feel free to send me a patch, and I'll remember to apply it when needed. (I'll make myself a reminder to apply it.) -- ((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] [racket] response/xexpr missing?
Thanks. #lang racket ; A picture (require 2htdp/image) (let sierpinski ([n 8]) (if (zero? n) (triangle 2 'solid 'red) (let ([t (sierpinski (- n 1))]) (freeze (above t (beside t t)) This is a revision. I don't nkow if it fits, tho. The call to freeze can be anywhere around the result if that helps at all. Robby On Fri, Jan 14, 2011 at 3:34 PM, Eli Barzilay e...@barzilay.org wrote: 7 minutes ago, Robby Findler wrote: I've wanted to change the front page to change the 2htdp/image example to use 'freeze' (making the program go from exponential to linear in 'n') too, but I've held off until it was in an actually released release. It's still minor -- so feel free to send me a patch, and I'll remember to apply it when needed. (I'll make myself a reminder to apply it.) -- ((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] [racket] response/xexpr missing?
Three minutes ago, Robby Findler wrote: Thanks. #lang racket ; A picture (require 2htdp/image) (let sierpinski ([n 8]) (if (zero? n) (triangle 2 'solid 'red) (let ([t (sierpinski (- n 1))]) (freeze (above t (beside t t)) This is a revision. I don't nkow if it fits, tho. The call to freeze can be anywhere around the result if that helps at all. It's the same width, so it should be fine. (You could also indent the `if' my way and get two more characters...) -- ((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] Blame and re-provided bindings
On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 14, 2011, at 4:22 PM, Robby Findler wrote: No, actually in this case the user message is also wrong. If you trace thru the module dag, you'll see it. Just to check, are you talking about the second series of modules, or the first? The problem in the first is likely a variation of PR11084, as Ryan said. In the second, I get: contract violation: expected integer?, given: 3.5 contract on f from (file /Users/sstrickl/c.rkt) via (file /Users/sstrickl/a.rkt), blaming (file /Users/sstrickl/b.rkt) contract: (- integer? integer?) at: /Users/sstrickl/c.rkt:4.1 and if I'm breaking that text down correctly, that's: positive: c user: a negative: b Which seems right to me, according to what I said. That is, b entered into a contract with c about value f. b reprovided f (with no contract) to a, who actually used the value via the expression `(f 3.5)'. So a misused the value, but b was responsible for its misuse (since it gave it to a without any additional protection). This is, of course, going by the interpretation of uncontracted reprovides being equivalent to reproviding with the contract any/c. FWIW, I had no idea what the message's via clause meant. I recognize that blaming x has a particular technical meaning, but the emphasis in the phrasing seems backwards -- the via module sounds like an innocent bystander to the blaming module's mistake, but it's precisely the other way around. Regardless, though, I still think we need some way to re-export a contracted value that makes the re-importer the negative party on the contract. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
Two complaints in one day about the wording of these clauses. Let's do something about the English. I have another one, unrelated: I don't like the 'self-blame'. I have encountered this now a couple of times, and I think we should use the Eiffel terminology of promised required ensured etc. This may just appeal to non-Racketeers when they see the contract violation reports. On Jan 14, 2011, at 5:24 PM, Casey Klein wrote: On Fri, Jan 14, 2011 at 3:28 PM, Stevie Strickland sstri...@ccs.neu.edu wrote: On Jan 14, 2011, at 4:22 PM, Robby Findler wrote: No, actually in this case the user message is also wrong. If you trace thru the module dag, you'll see it. Just to check, are you talking about the second series of modules, or the first? The problem in the first is likely a variation of PR11084, as Ryan said. In the second, I get: contract violation: expected integer?, given: 3.5 contract on f from (file /Users/sstrickl/c.rkt) via (file /Users/sstrickl/a.rkt), blaming (file /Users/sstrickl/b.rkt) contract: (- integer? integer?) at: /Users/sstrickl/c.rkt:4.1 and if I'm breaking that text down correctly, that's: positive: c user: a negative: b Which seems right to me, according to what I said. That is, b entered into a contract with c about value f. b reprovided f (with no contract) to a, who actually used the value via the expression `(f 3.5)'. So a misused the value, but b was responsible for its misuse (since it gave it to a without any additional protection). This is, of course, going by the interpretation of uncontracted reprovides being equivalent to reproviding with the contract any/c. FWIW, I had no idea what the message's via clause meant. I recognize that blaming x has a particular technical meaning, but the emphasis in the phrasing seems backwards -- the via module sounds like an innocent bystander to the blaming module's mistake, but it's precisely the other way around. Regardless, though, I still think we need some way to re-export a contracted value that makes the re-importer the negative party on the contract. _ 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] Blame and re-provided bindings
On Jan 14, 2011, at 5:24 PM, Casey Klein wrote: FWIW, I had no idea what the message's via clause meant. Truthfully, I was guessing that via = user blame. If I didn't know the internals, I wouldn't have known what that meant either. I think it needs to be rewritten, but I haven't thought about how I'd rewrite it yet, though. I recognize that blaming x has a particular technical meaning, but the emphasis in the phrasing seems backwards -- the via module sounds like an innocent bystander to the blaming module's mistake, but it's precisely the other way around. Well, it _is_ an innocent bystander if you take the no contract is equal to contract with any/c viewpoint. The blaming module never told the via module that there was a contract (and thus the effective contract was `any/c'), and thus there was no reason for the via module to think that using the value in the way it did was incorrect. Regardless, though, I still think we need some way to re-export a contracted value that makes the re-importer the negative party on the contract. I'm not necessarily in disagreement, but currently I think this should be an explicit action. In fact, there's another operation I'd like: re-export this with the same contract (without redescribing it) and treat _me_ as the positive party and whoever later enters into this as the negative party. This would be useful for collections, where some internal, private module defines and contracts the value initially, but you don't want the information about the internals to leak out when it's reprovided to the world at large through the public interface. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Blame and re-provided bindings
On Jan 14, 2011, at 5:33 PM, Matthias Felleisen wrote: Two complaints in one day about the wording of these clauses. Let's do something about the English. Agreed. I have another one, unrelated: I don't like the 'self-blame'. I have encountered this now a couple of times, and I think we should use the Eiffel terminology of promised required ensured etc. This may just appeal to non-Racketeers when they see the contract violation reports. Also agreed. I'll see about coming up with an alternative over the weekend and sending out examples over the list before I make the change in the repository. Stevie _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
