[racket-dev] testing
One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] testing
I think a convention is good. I also think that this kind of organizational principle (where do tests go? How do you name the main file in some package? etc) is completely appropriate for a style guide somewhere, so maybe I'm missing something, tho. Robby On Thu, Aug 4, 2011 at 11:11 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? _ 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] testing
On Thu, Aug 4, 2011 at 12:11 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. Why not? But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? We need to standardize on something. It is necessary to run other people's tests too often to rely on this search-and-hope method. Even a README convention so that each collection spells out how to test it would be a start in the right direction. --Carl _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] testing
I feel challenged to write this up. So I will put it on my wish list and assign your name to it. On Aug 4, 2011, at 12:17 PM, Robby Findler wrote: I think a convention is good. I also think that this kind of organizational principle (where do tests go? How do you name the main file in some package? etc) is completely appropriate for a style guide somewhere, so maybe I'm missing something, tho. Robby On Thu, Aug 4, 2011 at 11:11 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? _ 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] testing
OK. On Thu, Aug 4, 2011 at 11:18 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I feel challenged to write this up. So I will put it on my wish list and assign your name to it. On Aug 4, 2011, at 12:17 PM, Robby Findler wrote: I think a convention is good. I also think that this kind of organizational principle (where do tests go? How do you name the main file in some package? etc) is completely appropriate for a style guide somewhere, so maybe I'm missing something, tho. Robby On Thu, Aug 4, 2011 at 11:11 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? _ 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] testing
At Thu, 4 Aug 2011 12:11:27 -0400, Matthias Felleisen wrote: One of the responses to the draft of the Racket style guide contains the following paragraph: There should be unified way to test collections. Let's say I fix something in collect `foo', there should be an obvious way to run `foo''s tests. Currently, the closest we have would be to look in `tests/foo', and see if anything looks like an entry point. Standardizing on test suite entry points would make it easier for people to run tests after fixing bugs in collects that are not their own. Such an entry point could be that each collect `X' is required to have a `tests/X/run.rkt' file that, when run, runs the test suite for `X'. I don't consider this topic appropriate for the style guide. But I consider it important enough to bring up for discussion. QQQ: Is there a policy that spells out testing collections? QQQ: Should we try to formulate one or leave individual testing styles alone? The above suggestion does not rule out individual testing styles. It only mentions a standardized entry point. What the test suite does afterwards can still be left to the programmer. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] testing
On Aug 4, 2011, at 12:19 PM, Vincent St-Amour wrote: The above suggestion does not rule out individual testing styles. It only mentions a standardized entry point. What the test suite does afterwards can still be left to the programmer. I really really prefer placing my tests in a directory within the collection. Perhaps it is the proximity perhaps the not-thinking-about-where. Indeed, for plain unit tests, I prefer to place them inside the module. That's what I mean personal testing style. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Racket and Text Editors
As I mentioned at RacketCon, I've been working (with help from Asumu Takikawa and Jon Rafkind) on a document that provides pointers to tools for using Racket with popular text editors. I now have a draft of it on my webpage: http://www.ccs.neu.edu/home/stamourv/using-racket-with-your-editor-of-choice.html I think this would be a nice resource to have somewhere in the Racket documentation. Does anyone have an idea where it should go? I'd also like feedback on the document itself. It's not especially detailed, and I'm sure I forgot a lot of useful things. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Different refresh behavior between 4.2.5 and 5.0+
I would like to migrate my production machines from the current PLT Scheme 4.2.5 to the latest release of Racket.However, there is one annoying graphics inconsistency with graphics refresh that is giving me problems. For some of my graphics programs, I update many canvases - some visible and some not, depending on what tabs are selected - and afterwards I just issue one (send the-frame refresh). This works fine in 4.2.5. However, in 5.0+ (at least the last couple versions), some of the canvases update and some don't. One can switch to a different tab and back to force the repaint and that works, but obviously annoys the users. I haven't experimented enough to track down exactly which do and which don't. [I rolled my production machines back to 4.2.5 and haven't moved that code to a development machine to play with it.] There seem to be a couple of open bugs reports that may or may not be related - 11759 and 12065. On my development code that has a similar problem I moved the refreshes down to the individual canvases (as they are updated) and that works. But it seems that one refresh of the frame at the end should work just a well. Is this a new feature that I missed somewhere or a bug? Doug _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket and Text Editors
Three minutes ago, Rodolfo Carvalho wrote: Hello, About Bash completion, is seems to me that it is not part of the normal distribution. Maybe available through the Racket full nightly installer or the git repo. Through a URL, it's accessible at our git server or github as: http://git.racket-lang.org/plt/blob_plain/HEAD:/collects/meta/contrib/completion/racket-completion.bash https://raw.github.com/plt/racket/master/collects/meta/contrib/completion/racket-completion.bash -- ((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 and Text Editors
I agree with most of your points, and will fix the document accordingly. At Thu, 4 Aug 2011 17:02:26 -0400, Eli Barzilay wrote: I'd also like feedback on the document itself. It's not especially detailed, and I'm sure I forgot a lot of useful things. * xrepl should be mentioned at the top, since its main goal is to make it easy to live with *any* random editor, even notepad. The specific highlights to mention is that it gives you an ,enter command to go into a module and an ,edit command that can be used to invoke your $EDITOR on a file (and it defaults to the file you entered into). Also, there's a ,drracket command that can start drracket, which makes it easy to use random editor to write code, and drracket to test things. I didn't want to repeat information that was already in the xrepl documentation, but you're right that highlighting some of the features is probably a good idea. * Also might good to mention that Neil is in the process of writing something new? I'm planning to add it once he releases it. * Did you verify that paredit treats []s properly? (At least at some point in the past I think that it didn't.) I've been using paredit daily for years, and I don't recall having any issues. * `check-requires' is even less important than that... Including it means including a whole bunch of other things (for example, the macro stepper's textual interface). If anything, add it as an xrepl command. Adding it to xrepl is a good idea. Vincent _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Roogle?
6 minutes ago, Asumu Takikawa wrote: A few of us in the lab today were discussing how the Haskell community has this nice tool called Hoogle (http://www.haskell.org/hoogle) that lets you search Haskell docs by type. Are there any *practical* uses for that thing? (Not a flame, I tried it a few times, and it looked like i might be useful in a language where you use point-free style to compose functions -- so you might know the type that you need `(a - b - c) - (b - c - a)' but not the `flip' name. But such serches don't see, to work. So from this shallow scan, it looks like one of these things that sound cool on paper, but are useless in practice.) Is it at all feasible to supplement Racket's doc search to display contracts That won't be hard in itself, but the real problem is huge blocks of text in the results which would make it much less useful. and/or search by contract? (or type for TR) That would be more difficult, since the search will need to do a lot more work. I'm also guessing that given that we have much more *text* in contracts (as in integer and resolved-module-path?), it will make searching show way more false positives. -- ((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] Roogle?
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. Shriram On Fri, Aug 5, 2011 at 12:13 AM, Robby Findler ro...@eecs.northwestern.edu wrote: I too tried it (ages ago) and ended up roughly where Eli is, but I didn't want to judge since I wasn't actually trying to use it for something useful (and, as we all know, that can change how you use things and how well they work for you). So I wonder if anyone has a positive experience with this kind of searching in an in anger kind of setting? Robby On Thu, Aug 4, 2011 at 9:08 PM, Eli Barzilay e...@barzilay.org wrote: 6 minutes ago, Asumu Takikawa wrote: A few of us in the lab today were discussing how the Haskell community has this nice tool called Hoogle (http://www.haskell.org/hoogle) that lets you search Haskell docs by type. Are there any *practical* uses for that thing? (Not a flame, I tried it a few times, and it looked like i might be useful in a language where you use point-free style to compose functions -- so you might know the type that you need `(a - b - c) - (b - c - a)' but not the `flip' name. But such serches don't see, to work. So from this shallow scan, it looks like one of these things that sound cool on paper, but are useless in practice.) Is it at all feasible to supplement Racket's doc search to display contracts That won't be hard in itself, but the real problem is huge blocks of text in the results which would make it much less useful. and/or search by contract? (or type for TR) That would be more difficult, since the search will need to do a lot more work. I'm also guessing that given that we have much more *text* in contracts (as in integer and resolved-module-path?), it will make searching show way more false positives. -- ((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 _ 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] Roogle?
On 2011-08-05 00:08:03 -0400, Eli Barzilay wrote: Are there any *practical* uses for that thing? It could be useful if you have an idea of the name of the thing you're looking for and then want to narrow it down by type. Or you know you want a higher order function that works on a list but don't know where it is (so you look up (a - b) - [a]). The first example on Hoogle for that search is in GHC.Exts so if that's what you wanted it would be harder to find by browsing. That said, I'm not a heavy Hoogle user so I don't know. That won't be hard in itself, but the real problem is huge blocks of text in the results which would make it much less useful. I think this would be a more useful feature than the searching. Maybe it could display optionally or truncated if it's too long. Another nice thing Hoogle does is search Hackage, but I think that's been discussed here before (and probably depends on how packages end up?). Cheers, Asumu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Roogle?
10 minutes ago, Asumu Takikawa wrote: On 2011-08-05 00:08:03 -0400, Eli Barzilay wrote: Are there any *practical* uses for that thing? It could be useful if you have an idea of the name of the thing you're looking for and then want to narrow it down by type. An important difference is that we often use the same names in the contracts. Or you know you want a higher order function that works on a list but don't know where it is (so you look up (a - b) - [a]). (Yes, that's the use case that I thought would be common, but I doubt that it's used for that in practice.) That won't be hard in itself, but the real problem is huge blocks of text in the results which would make it much less useful. I think this would be a more useful feature than the searching. Maybe it could display optionally or truncated if it's too long. Even tiny contracts tend to be big, so a good UI will be challenging. Another nice thing Hoogle does is search Hackage, but I think that's been discussed here before (and probably depends on how packages end up?). Yes. -- ((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] 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 precisionrecall, 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
Re: [racket-dev] Roogle?
8 minutes ago, Anthony Cowley wrote: On Fri, Aug 5, 2011 at 1:22 AM, Eli Barzilay e...@barzilay.org wrote: That's not surprising -- the question is how much the search-by-type feature is used vs the plain by-name searches. Search-by-type is the main useful feature. Another search engine, hayoo, often does better on name-based searches covering hackage. Some people run local instances of hoogle as it is relatively straightforward to hook into emacs and will index all the types and names from all the packages you have installed locally. OK, that sounds closer to what I asked... (And on the positive side.) We already have that kind of exploratory searching, since types in the contract system are real functions. I guess that this is another way to make the point: in Haskell and other statically typed languages types are second-class, but in Racket they're first class so looking for a type name will get you information because it's also a binding. (And the same goes for TR, only those are not runtime values.) Searching by type names and aliases works fine: http://www.haskell.org/hoogle/?hoogle=String Yes, what I'm saying is that in Haskell, if you have a tool that searches for bound values, you won't get types, therefore you need to have a specific tool (or extension of one) that can search types. In Racket, then contract type is `string?', which is something that you can look for even without a special by-contract search. Hoogle really is quite good, don't sell it short! I'm not -- the above point is in no way saying anything bad about it, it's just an observation about the differences between the two language worlds. -- ((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
