Re: [racket-dev] Class contracts: opaque or transparent?
On Fri, Apr 27, 2012 at 5:55 PM, Asumu Takikawa wrote: > (and/c (class/c #:opaque [m (->m number? number?)]) > (class/c #:opaque [n (->m number? number?)])) Would it be possible to do (opaque/c (and/c (class/c [m (->m number? number?)]) (class/c [n (->m number? number?)]))) and would it help? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] "bookmarks" in drracket?
Note that the "Bookmark" features are almost always separate from the "Long Jump" features, both in key binding and in nomenclature. In Visual Studio: Jump to definition: F12 Jump back on the stack: C-* Jump forward on the stack: C-& Toggle a bookmark: C-k C-k Jump to next bookmark: C-k C-n Jump to previous bookmark: C-k C-n In Eclipse: Jump to definition: F3 Jump back on the stack: A-left Jump forward on the stack: A-right By default, Eclipse doesn't have keyboard shortcut for its bookmarking feature, but some people use Toggle a bookmark: C-b Jump to next bookmark: C-n Jump to previous bookmark: C-p In Emacs (using the built-in tagging functionality): Jump to definition: M-. Jump back on the stack: M-* Jump forward on the stack: not available Toggle a bookmark: C-x r m Jump to next bookmark: C-x r j Jump to a different bookmark (from a list): C-x r l I don't remember any having a visual display of the stack. I don't remember any saving the stack across sessions. Some save bookmarks, or save them them, but only if you ask. To make the stack feature work, it is essential that it jump across windows. You want M-. followed by M-* to cancel each other. Since jumping to a definition will sometime open a new window, then jumping back has to switch back to the original window. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Code compiled for version ~a, not ~a
On Sun, Sep 18, 2011 at 10:43 AM, Matthew Flatt wrote: > I've pushed a fix for the problem with forward slashes in PLTCOLLECTS. Thanks! > >cd c:\matthew\collects > >c:\matthew\plt\raco link uu-cs1410 > >c:\matthew\plt\raco setup -D > >c:\matthew\plt\drracket > [ok --- tool works] I went through the sequence you indicated and saw the same behavior as you did. When I was doing it earlier, I was skipping the 'raco setup -D' step. I was under the impression that the 'raco link' operation updated the necessary info-domain/compiled/cache.rktd files automatically. When I add or remove a directory from PLTCOLLECTS, I don't need to re-run 'raco setup'. So long as the tool's collect has been compiled once before, it loads correctly. I was expecting the same behavior from 'raco link' We can either fix 'raco link's behavior to match my brain, or fix my brain to match raco's. Either-or. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] [racket] Code compiled for version ~a, not ~a
On Sat, Sep 17, 2011 at 11:11 PM, Robby Findler wrote: > Whoops, I see we lost the mailing list at some point in this thread. We're back now. > If the former, then those are the directories that DrRacket > intentionally doens't compile (and those are the ones that I'd expect > you to have multiple copies of). That's pretty subtle. I don't remember seeing a notice of this in the documentation. Is it somewhere and I didn't stumble on it? It might be worth changing the behavior or the error message to make the behavior more discoverable. > Does this mean that you added it to the directory that's listed first > in the PLTCOLLECTS variable or that you added a second path to that > variable? It breaks both ways, with export PLTCOLLECTS=';c:\documents\collects' and with export PLTCOLLECTS='c:\documents\collects;' > If the latter, what does > > #lang racket/base > (require setup/dirs) > (find-collects-dir) > > produce on your machine? (And what is PLTCOLLECTS)? It produced # , which is where my git repository is. In case it is useful, (current-library-collection-paths) produces: '(# # #) >> When logging-tool is linked with raco, the error doesn't occur at >> lunch because DrRacket doesn't attempt loads tools the linked >> collects. > > It is supposed to. So maybe something is wrong there too. ah, ok. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Downloading DrRacket for Mac is hard?
On Fri, Aug 12, 2011 at 7:26 PM, Shriram Krishnamurthi wrote: > And I suspect this is precisely why FF makes Windows the default (as > Guillaume has shown us). Everyone who's not on Windows is acutely > conscious of the fact that they are not, and knows what to do about > it. FF and all the other sites I gave as examples all attempt to autodetect the platform you are accessing the site from, and gives that download as the default. They don't blindly suggest Windows. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Downloading DrRacket for Mac is hard?
On Thu, Aug 11, 2011 at 3:03 PM, Guillaume Marceau wrote: > Or we can trust that the Mozilla Foundation's user interface designers has > already done the experiment. They have some of the best people of the > industry working for them, including Aza Raskin, son of Jef Raskin, one of > the original designer of the Macintosh. I see no reason to deviate from > their design choice. >[big:] DrRacket >[almost as large:] Free Download >[small and grey:] 5.1.2 for Windows, English (US) >[outside of the button, small and light-grey:] All Systems & Languages > Shriram, if you want I can email Aza and ask him what experiments they did > to arrive at the current design. > This particular design is getting more common around the web. Apple's iTune download page <http://www.apple.com/itunes/download/> have a big button that reads "Download Now," then at the bottom of the page they have two small links: 64-bit editions of Windows Vista or Windows 7 require the iTunes 64-bit installer and G3 Mac Users Google Chrome <http://www.google.com/chrome/> has a big button that read "Download Google Chrome", right below they have "It's free and installs in seconds For Windows XP, Vista, and 7," then at the bottom of the page, in small: Chrome for Mac or Linux · Chrome Beta Sourceforge <http://sourceforge.net/projects/inkscape/> have a big button "Download Inkscape-0.48.1…exe", and then below "Other Versions, Browse all files" etc. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Downloading DrRacket for Mac is hard?
Or we can trust that the Mozilla Foundation's user interface designers has already done the experiment. They have some of the best people of the industry working for them, including Aza Raskin, son of Jef Raskin, one of the original designer of the Macintosh. I see no reason to deviate from their design choice. [big:] DrRacket [almost as large:] Free Download [small and grey:] 5.1.2 for Windows, English (US) [outside of the button, small and light-grey:] All Systems & Languages Shriram, if you want I can email Aza and ask him what experiments they did to arrive at the current design. On Thu, Aug 11, 2011 at 2:53 PM, Shriram Krishnamurthi wrote: > We also have an extensive audience on the users list and in our > individual departments. So it would be easy to circulate a draft Web > page (no fancy download or even formatting) that simply says, "I'm > guessing you are using a ... -- is this correct?" and get lots of > people to test (and get more details from those who say no). We > should crowdsource this for maximum benefit. > > Shriram > > On Thu, Aug 11, 2011 at 2:22 PM, Robby Findler > wrote: > > I'd be happy to comment on drafts too, if that's useful. > > > > Robby > > > > On Thu, Aug 11, 2011 at 1:20 PM, Matthias Felleisen > > wrote: > >> > >> Guillaum, why don't you work out a concrete plan, especially the wording > of the messages to the downloader, and submit it to ELi for review. He will > implement a version of it. Thanks -- Matthias > >> > >> > >> _ > >> 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 > _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Downloading DrRacket for Mac is hard?
On Thu, Aug 11, 2011 at 1:21 PM, Robby Findler wrote: > > On Thu, Aug 11, 2011 at 12:16 PM, Guillaume Marceau > wrote: > > In the ambiguous cases, you can get additional information by checking for > > flash. Because Adobe doesn't support flash player on x64 browsers, if > > detection is successful then it is definitely a 32 bit browser, if not, then > > the request came from either a 32 bit browser without flash plugin or from a > > 64 bit browser. > > That seems like an unfortunate thing to rely on. Such is life in the stormy world of web development. Just ask Danny about the ridiculous things he has to do to make WeScheme work on the different browsers. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Downloading DrRacket for Mac is hard?
On Thu, Aug 11, 2011 at 3:25 AM, Eli Barzilay wrote:
> On Aug 10, 2011, at 11:33 PM, Guillaume Marceau
wrote:
>> Does the combo box auto detect the
>> downloader's platform for the User-Agent header.
>
> Yes, in some cases when it's possible to make a guess.
>
I found this Stackoverflow article:
http://stackoverflow.com/questions/1741933/detect-64-bit-or-32-bit-windows-from-user-agent-or-javascript
which says that the following code
deployJava.isWin64OS = function() {
return navigator.userAgent.indexOf('WOW64')>-1 ||
window.navigator.platform=='Win64';
};
will return one of these:
64 bit MacOS + 64 bit Safari or 32 bit Chrome:
window.navigator.platform=MacIntel
32 bit windows + safari:
window.navigator.platform=Win32
64 bit Windows + 64 bit IE:
window.navigator.platform=Win64
window.navigator.cpuClass=x64
64 bit Windows + 32 bit IE:
window.navigator.platform=Win32
window.navigator.cpuClass=x86
64 bit Windows + 32 Firefox (or Chrome):
window.navigator.platform=Win32
32 bit linux mint (i686) + firefox:
window.navigator.platform=Linux i686
64 bit Ubuntu (x86_64) + 32 bit Chrome:
window.navigator.platform=Linux i686
64 bit Ubuntu + 64 bit Epiphany:
window.navigator.platform=Linux x86_64
In the ambiguous cases, you can get additional information by checking for
flash. Because Adobe doesn't support flash player on x64 browsers, if
detection is successful then it is definitely a 32 bit browser, if not, then
the request came from either a 32 bit browser without flash plugin or from a
64 bit browser.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
[racket-dev] Downloading DrRacket for Mac is hard?
I received a plea for help from a person who is attempting to learn how to program for the first time. They found the DrRacket download page and were presented 5 different options for downloading DrRacket for Mac: Macintosh OS X (Intel i386) Macintosh OS X (PPC) Macintosh OS X (Intel x86_64) Macintosh Darwin (PPC) Macintosh source This particular novice had no way to choose, aside from a vague impression that they probably wanted one of 'Intel' ones, and so they abandoned their attempt to download DrRacket. Can we make this better? Does the combo box auto detect the downloader's platform for the User-Agent header. If so, then the next step is to change the layout to: Download: __Macintosh OS X (Intel i386)__ (this is the version of DrRacket for your system. In rare cases, you might need a version for a __different system__) where the link "different system" leads to the whole combo box. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New plot library [Was: (to Jay) Re: What I'm working on]
> Doug and other heavy `plot' users: What can I add to plot2d and plot3d to > make your life easier? Do you know about ggplot? It's a plotting library based on a grammar of graphic elements, rather than a bucket of pre-set charts, which is what most plotting libraries offer. The design principles behind ggplot are very Scheme-like: a small base of powerful orthogonal features with as few restriction on composition as possible. http://had.co.nz/ggplot2/resources/2007-past-present-future.pdf It would be great to have something like it in ggplot. I do a lot of charting, but I hardly ever use the plot module since the charts I do are more 'information design'-style charts that can't be made with pre-set charts. If DrRacket had a plotting library like ggplot, I would be able to stop building everything by hand from pict's. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Release Announcement for v5.1.2
On Mon, Aug 1, 2011 at 11:48 AM, Eli Barzilay wrote: > * Simplified error messages in student languages, and use colors to > add visual information (see the teachpack manual for guidelines on > writing teachpacks). (Is this the right place? IIRC it moved.) > " * The error messages in the student languages now use a smaller vocabulary base, and use a more consistent phrasing across messages. Please update the error messages of your teachpacks and curriculum material to match. See the 'Error Message Composition Guidelines' in the help desk. " > use colors to add visual information This is not implemented yet. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] language-specific documentation failed on 5.1.1
On Tue, Jul 19, 2011 at 2:08 PM, Robby Findler wrote: > On Tue, Jul 19, 2011 at 1:06 PM, Eli Barzilay wrote: > > Yesterday, Robby Findler wrote: > >> Also, when I disable cookies, I see that the context sensitive > >> search just silently doesn't work. > >> > >> Would it be possible to always have the search set a (separate) > >> cookie and give a warning if it doesn't find the (constant) cookie? > > > > I think that it's far more likely that JS fails, so you won't see any > > warning anyway. > > JS could also hide a warning that JS wasn't available, right? > > > As for a warning when chrome prevents storing a cookie, I remember > > trying that and IIRC it can't even tell when you're not allowed to > > store a cookie. > > Yeah, I can see how they'd set things up like that. I have JS and Cookies enabled on both browsers, so that's not the problem. >> I don't understand the last bit about refreshing and reseting the >> cookie. What problem is this second trampoline trying to fix? > >page it will re-set the cookie. The trampoline page is therefore >If you keep the "hq=blah" in the URL, then whenever you visit that >setting the cookie and then takes you further to the usual search page >without the parameter being part of the URL. and why are we using cookies? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] teaching language error messages
On Tue, Jul 19, 2011 at 12:03 PM, Robby Findler wrote: > I see that the teaching language error messages now have things like > this in them (where the . is an image literal): > > Welcome to DrRacket, version 5.1.2.3--2011-07-19(4b77a0fc/d) [3m]. > Language: Beginning Student; memory limit: 128 MB. > > (+ 1 (list .)) > +: expects a number as 2nd argument, given (cons an image empty) > I see that this is being done via regexps on the error message > strings. This seems bad. > > Can we at least get some delimiters on there so it doesn't look like a > malformed use of 'cons'? My goal is to have the actual image displayed there instead. "an image" was just a quick replacement for #(struct:object:cache-image-snip% ...), which is incomprehensible to students, and intimidating. I've push a fix that makes it read (cons (image) empty) instead. That should hold us up until we get a proper image there. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] language-specific documentation failed on 5.1.1
Danny and I looked at this last night. Both Chrome and IE are failing, but in different ways. On Chrome, in my cookie file: c:/Documents and Settings/gmarceau/Local Settings/Application Data/Google/Chrome/User Data/Default/Cookies I have two entries for docs.racket-lang.org: docs.racket-lang.orgPLT_ContextQueryLabel docs.racket-lang.orgPLT_ContextQuery/ But there is no other entries for PLT_ContextQuery. I would expect to see some cookie set for local files. On IE, we get a permission error. Danny and I tried to get the "mark of the web" trick working last night, without success. search-content.html has the following note at the top: I don't understand the last bit about refreshing and reseting the cookie. What problem is this second trampoline trying to fix? Because at the moment it seems to be causing more problem than it solves. On Mon, Jul 18, 2011 at 8:15 PM, Robby Findler wrote: > Also, when I disable cookies, I see that the context sensitive search > just silently doesn't work. > > Would it be possible to always have the search set a (separate) cookie > and give a warning if it doesn't find the (constant) cookie? > > Robby > > On Mon, Jul 18, 2011 at 7:03 PM, Danny Yoo wrote: > >>> > I tried this too and it seems to work for me, even under windows with > >>> > firefox. > > > > > > Sorry: I should have mentioned. I observed the behavior in IE on the > > Windows 7 machines in the lab. I believe what's happening is related > > to the way IE is prohibiting JavaScript from running on for local > > files. When the user then clicks IE and allows JavaScript to > > evaluate, perhaps it's already too late for the JavaScript trampoline? > > _ > > 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] language-specific documentation failed on 5.1.1
On Mon, Jul 18, 2011 at 7:21 PM, Robby Findler wrote: > I tried this too and it seems to work for me, even under windows with > firefox. > > So, I suspect that there is something subtle about the UI that Eli and > I are doing one way but others are doing another way that is > interacting badly with the way some internal state somewhere works. > Except that I can't think of anything peculiar I might be doing. I'll have to keep rummaging in code. Is there any javascript involved? Where is that in the codebase? I'll start putting printf in that and see where that leads. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] language-specific documentation failed on 5.1.1
The temporary file send-url creates contains: Please go here. but if I paste that url into my browser, it immediately rewrite itself to: file:///C:/Documents%20and%20Settings/gmarceau/Application%20Data/Racket/5.1.2.3/doc/search/index.html?q=w This is on Windows using Chrome, but our student were seeing this same behavior on Windows using Firefox. On Mon, Jul 18, 2011 at 3:12 PM, Eli Barzilay wrote: > 50 minutes ago, Guillaume Marceau wrote: > > On Mon, Jul 18, 2011 at 1:24 PM, Eli Barzilay wrote: > > > > > Something seems wrong. Specifically, I'm getting the right > > > results (two matches from `2htdp/image' and one from > > > `htdp/image'). What I did was: > > > > Where should I look to start debugging this? > > There is a drracket capability that controls the context -- it's > called `drscheme:help-context-term'. The problem should be somewhere > around that. If you grep the `lang' collection for that you'll see > where it's set -- so it's best to start looking there. First see that > it's the right value, you can do that by adding printouts to where > its value is retrieved (look for it in "dracket/private/rep.rkt" and > in "dracket/private/unit.rkt"). If it's there, then the problem is in > the code that starts the browser. If it isn't, then it's some problem > in drracket or in the tool or similar places. > > -- > ((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] language-specific documentation failed on 5.1.1
On Mon, Jul 18, 2011 at 1:24 PM, Eli Barzilay wrote: > Something seems wrong. Specifically, I'm getting the right results > (two matches from `2htdp/image' and one from `htdp/image'). What I > did was: > Where should I look to start debugging this? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] language-specific documentation failed on 5.1.1
In Beginner with the latest DrRacket from git. Write 'width' in the definition window, right click on it, choose "search help desk for 'width'". The result is: width (method of mx-element%) provided from mysterx :maxwidth in handin-server argb-width provided from mrlib/cache-image-snip block-width provided from scribble/core border-bottom-width (method of mx-element%) provided from mysterx border-bottom-width-native (method of mx-element%) provided from mysterx border-left-width (method of mx-element%) provided from mysterx border-left-width-native (method of mx-element%) provided from mysterx border-right-width (method of mx-element%) provided from mysterx border-right-width-native (method of mx-element%) provided from mysterx border-top-width (method of mx-element%) provided from mysterx border-top-width-native (method of mx-element%) provided from mysterx border-width (method of mx-element%) provided from mysterx border-width-native (method of mx-element%) provided from mysterx card-width (method of card<%>) provided from games/cards content-width provided from scribble/core current-para-width provided from slideshow/base , slideshow determine-width (method of frame:info<%>) provided from framework error-print-width provided from racket/base , racket fixed-width-label-snip provided from embedded-gui On Mon, Jul 18, 2011 at 12:48 PM, Robby Findler wrote: > What dd they do to get to the docs? > > On Monday, July 18, 2011, Danny Yoo wrote: > > Currently doing Program-by-Design workshop. > > > > One issue so far: Help Desk is not giving language-specific help. One > > of the users searched for "width", and hit basically every width > > function except the one he was looking for. I can't check at the > > moment to see if the upcoming DrRacket release fixes this issue. > > _ > > 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] [plt] Push #23038: master branch updated
> Guillaume, I finally realize that you replace 'produce' with 'return'. WHY? > The use of 'produce' for functions in HtDP is pervasive. Do you really want > to use distinct vocabularies in teachpacks+langs and the book? I am not concerned with keeping consistency we HtDP v1. When I updated DrRacket's to the new vocabulary, HtDP v1 and DrRacket parted ways and they will not meet again. The goal now is to align DrRacket and 2HtDP. Before my patch of last night, DrRacket was quite inconsistent. It used the verb "produces", but also "creates", "determines", and "returrns". This causes students to struggle as they wonder whether these words are truly synonyms, or whether they have shades of meaning they are meant to understand. Shriram, Kathi, Emmanuel, Stephen and I have been debating which word should be the standard. We also contacted Jon Star for his insight on how to help bridge with algebra. Turns out algebra does not have a commonly agreed word for this concept. In algebra, everything is equal to something else, as in the sentence "f(x) is 5" or "f(x) is equal to 5". We agreed that this is a weakness of high school algebra that we should not import into HtDP. The candidates verbs were "produces", "gives back", "creates", "determines", and "returrns". I chose 'returns' because it is the shortest word, which I expect will help the students' ability to subvocalize code. Imagine a student reading their draw function: "this place-image returns the image with the rocket added, the second place-image returns the image with the clouds added, and the third place-image returns the image with a score added". If you change 'returns' in this sentence with 'produces', 'gives back', or 'determines', you slow the sentence down and break its rhythm. 'returns' is also a standard nomenclature in programming languages, and since 'returns' it is not inherently imperative, I'm happy to be consistent with the rest of the discipline. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Sat, Jul 9, 2011 at 10:17 AM, Matthew Flatt wrote: > I see that `case' is the only one in a blue box that doesn't fit, but I > meant the grammar at the start of each language section. It doesn't fit > for any of the languages on my machines (i.e., some line extends > further than the beige bar at the top of the page). > > IE handles the overflow particularly badly on my Win7 machine: > Sometimes it erases or doesn't draw text that extends beyond the > column, which sometimes has the particularly unfortunate effect of > omitting a closing parenthesis. That's probably an IE bug, but > overflowing the column creates all sorts of problems. > > Maybe the solution is to add newlines. I see that the `case' production > already has newlines (though the indentation is off). I don't have enough time to debug this before the release, so I rolled back the "expr -> expression" change. Hopefully that fixes the layout problem you see. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
On Thu, Jul 14, 2011 at 1:42 PM, Eli Barzilay wrote: > Yes -- paredit is exactly an attempt to get the always-balanced > benefits of structured editing, without an actual structure editor. Yes, but paredit still gets its priorities backward. You want to have the most commonly used edit operations on the easiest chords (or without any chord at all, if you are trying to avoid RSI.) In paredit, keystrokes to edit sexp are heavily chorded, and keystrokes to edit single-characters are simple, even though single-char only occur when fixing typos in identifiers, which is quite rare when using auto-completion. Case-in-point, Moving forward by one sexp in paredit is CTRL-ALT-F (ouch). In DivaScheme it's just L. Moving forward by two chars in paredit is RIGHT, RIGHT. In DivaScheme it's W, RIGHT, RIGHT On Fri, Jul 15, 2011 at 12:36 AM, Neil Van Dyke wrote: > > The reason has to do with the stress of stretching/twisting people do with > their hands for multi-key combination, is my layperson's understanding. > Around the time, when CTS and other RSIs were getting a lot of attention, I > heard this from multiple credible sources, and the knowledge seemed to work > for me. Yes. Any deviation of the wrist away from neutral by more than 5° correlates with higher incidence of RSI, and there are biological phenomenon that have been observed that give credence to a causal relationship. One of the best such study is A Prospective Study of Computer Users, by Gerr, Marcus, Ensor, Cohen, Edwards, Gentry, Ortiz, Monteilh, AJIM 41:221-235 (2002) http://www3.interscience.wiley.com/journal/91016561/abstract Over a period of 38 months, they followed 632 computer professionals who were pain-free at the beginning of the study. By observing who developed pain, and comparing their work habits to those of the pain-free workers, the study was able to measure the risk factors associated with many different postures or practices. Their recommendations were (starting with the most effective): Keep your elbows slightly open, at around 121° (reduced the risk by 84%) Leaves more than 12 cm between the edge of the table and the "J" key (... by 62%) Don't use your neck to hold the phone (... by 60%) Avoid keyboard wrist rests (... by 48%) Don't bend your wrists when holding the mouse. Keep it within 5° (... by 45%) Strike the keys with a light touch, with less than 48 g of pressure (... by 40%) Raise the screen so that your neck tilt by less than 3° (... by 36%) Rest your elbows or forearms on the chair armrests, or on the desk itself (... by 35%) Use a keyboard that is less than 3.5 cm thick (... by 35%) Keep the keyboard slightly lower than your elbows (... by 23%) Avoid resting your hands on the leading edge of your desk, or pad the edge (... by 22%) The highest incidences were for females, for people over 30, and for people who type more than 20 hours per week. The risk factor of these groups was about twice that of the general population. I have an entire article on RSI on my website, for people who are interested: http://gmarceau.qc.ca/articles/your-wrists-hurt-you-must-be-a-programmer.html _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
On Thu, Jul 14, 2011 at 10:38 AM, Eli Barzilay wrote: > > A proper thing would need to do much more, something like paredit. Or DivaScheme, but without its edit-mode/insert-mode. Though the modalness was a life saver for people with RSI, and wasn't very popular with the healthy-wristed. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Thu, Jul 14, 2011 at 12:00 AM, Robby Findler wrote: > In racket/pretty, pretty-print is like print and pretty-write is like > write. In scheme/pretty, pretty-print is like write. > > So probably the better change is to stick with racket/pretty and use > pretty-write instead of pretty-print. Done. It is commit 793d7894, which should be pulled into the release. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote: > * All contracts for primitives print as lists. I traced this down to the change from (require scheme/pretty) to (require racket/pretty). I don't understand how that's causing the bug, but reverting to (require scheme/pretty) fixes things. Ryan, can you pull this fix into the release branch? It's commit 452f3a14fb7b25e6c54d08abdb8770fb20e68752 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] intro videos
There are 11'000 subscribers in the http://www.reddit.com/r/learnprogramming forums. Its very active and well loved. It was created shortly after guy called Carl Herold started http://www.reddit.com/r/carlhprogramming, where he gives free programming lessons (in C, its horrific a bit). He has another 10'000 subscribers. If you play your cards right, it should be possible to tailor these videos to draw some of that crowd to your lessons. On Wed, Jul 13, 2011 at 1:17 PM, Jens Axel Søgaard wrote: > Great initiative. Already subscribed. > * the sound is good > * the resolution (except the first one) is great > * perhaps mention that option and command is called alt and mumble on > Windows > (or add an annotation (using the YouTube editor) to the video, so you > don't have to reshoot) > * If you are using ScreenFlow to record the videos, you could let > it show the keyboard shortcuts. > * the short length is good > Do you happen to have a tablet? If so you could use together with OmniDazzle > to write on top of the DrRacket screen. > See for example > http://www.youtube.com/watch?v=TVc2tmsZfFg > where Paul Anderson uses it to write on top of a Keynote presentation. > Keep 'em coming. > -- > Jens Axel Søgaard > > 2011/7/13 John Clements >> >> Frustrated by what I'm seeing on khanacademy.org, I've now recorded 8 >> *short* videos on getting started programming in DrRacket. >> >> http://www.youtube.com/playlist?list=PLD0EB7BC8D7CF739A >> >> It gets through about half of the first page of HtDP 2e. I'm trying to >> stress those things--interface details, understanding error messages--that >> are a better fit for video. >> >> Comments welcome. >> >> John >> >> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev > > > > -- > -- > Jens Axel Søgaard > > > > _ > 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] New error messages for *SL
On Mon, Jul 11, 2011 at 6:32 PM, Matthias Felleisen wrote: > I'd much prefer eliminating such function calls. Do you want them out in this release? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Thu, Jul 7, 2011 at 12:44 PM, Matthew Flatt wrote: > * ASL incorrectly specifies >= 1 arguments required for functions and > function calls (i.e., functions and call are not common syntax at > that point). > Stephen pointed out that function calls in BSL can invoke functions of zero arguments. You can't define such a function, but if you get it from a library, it works fine. Should I document the grammar for function calls as (name expression ...) thorough? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] interactive hack
4scsh ? On Sun, Jul 10, 2011 at 3:15 PM, Jos Koot wrote: > For racket? > jOS > > -Original Message- > From: dev-boun...@racket-lang.org [mailto:dev-boun...@racket-lang.org] On > Behalf Of Eli Barzilay > Sent: domingo, 10 de julio de 2011 19:52 > To: Sam Tobin-Hochstadt; rafk...@cs.utah.edu; dev@racket-lang.org > Subject: Re: [racket-dev] interactive hack > > Ok, `4racket' and a beer for anyone who knows why. > > On 2011-07-10, Sam Tobin-Hochstadt wrote: >> I agree -- this is not going to be something people write often; it >> goes into your .racketrc. There's no reason to have a short and >> confusing name. >> >> On Sun, Jul 10, 2011 at 12:40 PM, Jon Rafkind wrote: >>> command-repl +1 >>> crepl -1 >>> >>> On 07/10/2011 09:54 AM, Eli Barzilay wrote: It's no longer mine, and it's really been years since it was really a hack. I think that I'll go with a shortened command-repl: `crepl'. On 2011-07-10, Matthias Felleisen wrote: > how about ElisInteractiveHack > > > On Jul 10, 2011, at 8:39 AM, Eli Barzilay wrote: > >> 10 minutes ago, Sam Tobin-Hochstadt wrote: >>> Why not `interactive'? >> Interactive what? -- It's way too generic. >> >> >>> And this is for the name of the module, right? >> A new toplevel collection. Used similarly to readline. (And >> supersedes it, hopefully, for casual users.) >> >> -- >> ((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 >>> >> >> >> >> -- >> sam th >> sa...@ccs.neu.edu >> >> _ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/dev >> > > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.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] New error messages for *SL
> Fix pushed. Thanks. > Some remaining issues: > > * ISL's "Syntax" section lists syntax that was already in B+SL. > > * ASL incorrectly specifies >= 1 arguments required for functions and > function calls (i.e., functions and call are not common syntax at > that point). > > * The order of some things is strange, such as `quote' instead of > `define' to lead off the BSL syntax section. Those are fixed in the commit I just pushed. > * All contracts for primitives print as lists. This is pending. I'll look into it next. > * Expanding `expr' to `expression' means that the grammar tables don't > fit in the available width. (Is `expr' as an abbreviation confusing > to students?) In general, yes, abbreviations are a big speed bump for students, enough that we put a 'no abbreviation' rule in the error message composition guidelines. It's somewhat important that the HTdP documentation be consistent with what we say in the guidelines. The grammar chart doesn't look too wide on my machine, except for the two lines for "case" in Advanced. Are you seeing something else? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Thu, Jul 7, 2011 at 11:49 AM, Guillaume Marceau wrote:
>>>> I'm talking about the references to identifiers, and sections.
>>>> Guillaume and I want pure, verbatim duplication of a piece of
>>>> documentation.
>>>
>>> Is the issue is that you want the links in one copy of the docs to go
>>> to one place and the links in another copy to go in another place and
>>> Scribble's use of lexical scope to do linking is getting in your way?
>>
>> Yes.
>
> Yes
>
>
> Right now I am using macros that accept some identifiers as an
> argument, instead of breaking hygiene.
>
>
> (define-syntax-rule (define-form/explicit-lambda define lambda)
>
> (make-splice
> (list
>
> @defform/none[#:literals (define lambda)
> (... (define name (lambda (variable variable ...) expression)))]{
>
> An alternate way on defining functions. The @racket[name] is the name of
> the function, which cannot be the same as that of another function or
> variable.
>
> @defidform/inline[lambda] cannot be used outside of this alternate syntax.
> }
> )))
>
... that macro works well enough.
If I could ask for something better, it would be something like
@duplicate-documentation[define-struct #:from htdp-beginner].
The big problem at the moment is that the layout engine doesn't know
what to do with the source information generated from the macro, so
the HTML comes out all wrong.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
>>> I'm talking about the references to identifiers, and sections.
>>> Guillaume and I want pure, verbatim duplication of a piece of
>>> documentation.
>>
>> Is the issue is that you want the links in one copy of the docs to go
>> to one place and the links in another copy to go in another place and
>> Scribble's use of lexical scope to do linking is getting in your way?
>
> Yes.
Yes
Right now I am using macros that accept some identifiers as an
argument, instead of breaking hygiene.
(define-syntax-rule (define-form/explicit-lambda define lambda)
(make-splice
(list
@defform/none[#:literals (define lambda)
(... (define name (lambda (variable variable ...) expression)))]{
An alternate way on defining functions. The @racket[name] is the name of
the function, which cannot be the same as that of another function or
variable.
@defidform/inline[lambda] cannot be used outside of this alternate syntax.
}
)))
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] typo in message for 'begin0'? Or not?
On Thu, Jul 7, 2011 at 2:21 AM, John Clements wrote: > While patching up the stepper tests results for the Advanced language level, > I noticed this strange error message: > > (begin0) > > => > > "begin: expected at least one expression after begin0, but nothing's there" > > Shouldn't that error message have begun with "begin0", rather than "begin"? > Or was that deliberate? That looks like a bug. Can it be that it is generated by stepper annotations in teach.rkt's ensure-expression? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Wed, Jul 6, 2011 at 7:11 PM, Carl Eastlund wrote: > A click away can be one too many. Students have enough difficulty > finding documentation as it is. Yes... On Wed, Jul 6, 2011 at 5:51 PM, Jay McCarthy wrote: > But, if you read the documentation as a reference > when you have a problem it is frustrating to chase through a few links > to get the "real" documentation. ...and yes. That's the idea. > If it is a click away and if the idea is that students got to B because they > went thru A? This change is targeted at people who use the language tower as intended (in order, from BSL to ISL). By the time students get to BSL+abbr, they are still very shaky on BSL. You can't say "these forms are just like BSL" and expect them to be able to recall the details of BSL. They will have to click through the link, but most likely they won't click, and they will remain confused. It is better to have all the information right there in the first place. > How about we have a > note saying that ISL cond is the same as ASL cond, then write it all > out anyway. Right now all the forms that are borrowed from the previous level are gathered together under the "Common Syntax" subsection header. But it looks like people find this too subtle, so I'll add something more visible. > And presumably we don't need to do it by duplicating > code, we can define it one place in Scribble and just use that text > twice. That's how it's coded at the moment. Though because of the how the layout engine interacts with the macros I'm using to avoid the dictation, I'm getting all these extra new lines, but hopefully we fix that before the release. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] New error messages for *SL
On Wed, Jul 6, 2011 at 9:14 AM, Matthew Flatt wrote: > In the case of the HtDP languages, was the choice to duplicate all the > text deliberate, or was it a side-effect of some other change? Yes, this was a deliberate move away from the no-duplication style used in the professional documentation, for pedagogical reasons. At each language level, I gathered in a separate section called "Common Syntax" the forms that that level has in common with the previous level. The idea is to make it possible to get a quick sense of of the commonality between the levels, while giving the students confidence that documentation page they are looking at is comprehensive. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] New error messages for *SL
I just pushed a commit that updates the error messages of the teaching languages. With this update, *SL now agrees with the rules of the error message composition guidelines we sent last month. If you try the *SL languages from the git repository, you will now see that the error messages restrain themselves to a smaller vocabulary base. The sentences are now simpler, and more consistent between error messages. The error messages of check-expect, world and universe are now consistent with those of the language itself. I also updated the documentation to the new vocabulary, and cleaned their layout a bit. Here are a few examples of the changes you will see. old error messagenew error message - image: name is not defined, not a image: this variable is not defined parameter, and not a primitive name planes-direction: this selectorplanes-direction: expects 1 argument, expects 1 argument, here it is but found none provided 0 arguments define: expected a name for thedefine: expected a variable, but function's 1st argument, but found found something else something else function call: expected a defined function call: expected a function function name or a primitive after the open parenthesis, but found operation name after an open a number parenthesis, but found a number cons: second argument must be of cons: second argument must be a type , given 1list, but received 1 and 2 and 2 --- This is a somewhat large patch, and it does not limit itself to changing strings, as one might expect. I had to change a fair amount of code to get the new error messages working, notably in places where *SL leaked error messages from the professional language. So, to everyone reading this, [1]Please make sure all the code you use to teach it still works correctly. If something breaks, e-mail me and I will try to address the problem right away. [2]If you are the author of a teachpack, please update your error messages to match this new style. You can follow the error message completion guidelines, which are now in the main documentation under the "How to Design Programs Teachpacks" header. Send me e-mail if you need help. [3]There is a layout problem in my new documentation I need help with. I tried to abstract the common text between the documentation of the different levels. Possibly because I didn't do it correctly, the macro I am using confuses the layout engine, and it is now inserting lots of spurious new lines whenever there is a @defform. Look at the documentation for beginner's COND, you'll see what the problem is. As always, let us know what you think, feedback is welcome, etc. Guillaume _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] documentation reorganization
On Fri, Jul 1, 2011 at 8:45 PM, Ryan Culpepper wrote: > I just pushed a commit intended to improve the usability of the main > documentation page, especially for newcomers to Racket. You can also > see the new version here: This is great. Heres a few comments that come to mind: Underneath the "Teaching" header, the first item is "How to Design Programs", it should probably read "How to Design Programs, the Book". RackLog should be under "Languages" or under "Experimental Languages", not under "Tools". I am nominating RackUnit for promotion to the "Racket Language and Core Libraries" section. I would demote "drawing toolkit" if you don't want the section to get any larger. As it is, there are two items that make the sales pitch "we can draw things in windows", but none that say "we take testing seriously". The racket/gui manual should have a duplicate entry under "GUI and graphics libraries". _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Fancy application/automatic anonymous functions
On Tue, May 17, 2011 at 3:14 PM, Sam Tobin-Hochstadt
wrote:
> Lots of people have written similar things (`cut' in SRFI 26, Jay's
> `super-cut', etc), but I'd like to move towards using it implicitly.
I use (require (rename-in srfi/26 [cut //])) and that's simple enough for
me. I find the implicit version harder to read. You have to read further to
the right before realizing you are inside a function, and it is easy to
miss.
Here are two example from my code of how it looks.
(define common-confusions
(count-instances
(filter-not all-the-same?
(map (// sort <> <)
(map (// take <> 2) summary)
(define (non-whitespace-diff? . strings)
(define collapsed (map (// regexp-replace* #px"[[:space:]]{2,}" <> " ")
strings))
(not (andmap (// equal? (first collapsed) <>) (rest collapsed
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] cgywin build working? Which line endings?
On Tue, Jan 18, 2011 at 5:03 PM, Stephen Chang wrote: > I tried once and got some problems. I dont remember exactly what went > wrong, but I think the problem might have been with my cygwin install. > > I think it's expected to work. Here is a paragraph from the README file: It's expected to work, but it's been buggy for a while. Last time I tried was around four months ago or so. One thing to be careful about that's not mentioned in the documentation: the absolute path containing your source tree must not have any spaces. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Racket documentation
On Tue, Sep 21, 2010 at 5:47 PM, Matthias Felleisen wrote: > > I often program in an 'off line' manner, and I'd find on-line docs to be way > too slow. I don't mind building the docs once a day. Google Gears was a framework to build these sort of things, namely provide locally cached version of a dynamic online service. Google Gears was deprecated but I hear HTML 5 is supposed to have similar functionality, or will have. Alternatively, DrRacket could be programmed to download updates to the docs once a day. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] stepper UI question
Right now, the stepper takes the code from the definition windows and displays it in a different window, with a different color, with a different layout, with some brackets turned into parenthesis, and with the comments are removed. I just opened a simple solution from last semester and launched the stepper on it. It took me no less than 20 seconds to trace the first redex presented by the stepper to the expression in the definition window it came from. It's really hard to do! When using the stepper, students struggle to see the correspondence between what's on the left and what's on the right, despite the colored highlights and all that. In my experience, the correspondence has to be carefully pointed out to them by the instructor. Their understanding of the correspondence between the content of the stepper window and the code they wrote in the definition window must be fainter still. There has to be an easy way to establish these two correspondences: from pre-step to post-step, and from the stepper window to the definition window. None of the proposals posted to in this thread so far address this. I can think of many different ways to make the stepper<->definition correspondence manifest. As John said, I once suggested that the code should be reduced in-place, in the definition window. Shriram doesn't like that idea (but he has never bothered to say why.) Another possibility is to use a two column layout. The left column would show the normal definition window, and the right column would show a single stepper state, aligning each reduced (or partially reduced) expression with the expression it came from on the left-hand side. To establish the pre<->post correspondence, the redex should disappear and its reduction be put in its place (with the rest of the code sliding downward smoothly to make space if necessary.) > It's not clear how you want to handle test cases; they don't > currently generate anything in the interactions window, and yet this > sounds like the thing that you're *most* likely to want to be able to > step. Yes. > the result of "generate-report" (the hidden summary-generation call > that check-expect inserts) should be a snip that shows up in the > interactions window, called (e.g.) "Test Report". Clicking on this > (right-clicking on this?) should open a window showing the test cases > in some tabular format, indicating which ones succeeded and which > ones failed. Selecting one of these, the user could choose to see > its steps. That's too many clicks. Every click the student has to do is a click they may fail to do successfully. In my observations, most students fail to click on the blue links that appear in the test result window. Those who do click the link then fail to click back to the definition window. Clicks are expensive; our interfaces should strive to minimize them as much as possible. See also: Aza Raskin's presentation "Don't Make Me Click" http://www.cheaprevolution.com/the_cheap_revolution/2008/10/dont-make-me-click.html and Aza's blog post on how to critique an interface. http://www.azarask.in/blog/post/how-to-critique-an-interface/ _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] source distribution problems
On Thu, Aug 5, 2010 at 8:36 AM, Matthew Flatt wrote: > > We need to add "build on Linux from source distribution" to our > release-time checklist. Kevin, can we put that under your name? > On that note, do we care about maintaining the ability to compile under cygwin? I've been having trouble compiling under cygwin for a while now, but I haven't able to decide whether it was me reading the documentation wrong, if there was a bug in the docs, or if there is a bug in the code. I would be happy to test the compilation under cygwin during release cycles, if that could help. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] P4P: A Syntax Proposal
On Fri, Jul 30, 2010 at 10:52 AM, Matthias Felleisen
wrote:
>
> Programmers who complain about parens mean something larger:
> -- the entire syntax (it doesn't look traditional)
> -- the entire semantics (function calls dictate nearly everything)
> -- the way we program (inductive structures have more weight than indexed
> ones)
> and more and certainly all the 'syntactic' symptoms that come with this:
> -- nested expressions show up a lot; how to read them
> -- array/for-loop "patterns" of programming aren't working, how to start?
> -- why this focus on data representations, can't we just use arras?
> And I am sure the list of such make-me-feel-bad unfamiliarities goes on.
I'll give a different theory.
My theory starts with the observation that students who program in BSL
spend an inordinate amount of time fiddling with parentheses. It's
exhausting, non-fun work. I think students are blaming the
parentheses simply because that is what is under their nose most of
the time.
One thing we have learned from the interviews is, they might hate the
parentheses, but they love the gray highlight tool of DrRacket. By
mid-semester, they use it accurately, and skillfully. Their technique
looks like this: the student clicks on a closing parenthesis, sees
which constructs it is closing, and then tries to remember the
original intention for that closing parenthesis. They are checking
whether that parenthesis is closing what they meant it to close. This
takes a lot of time, as they are constantly re-inferring the
intentionality of their closing parentheses.
Professional programmers don't do this. Why not?
First, we rely on indentation, visually, and also procedurally. We
press "tab" on a line that should be correctly indented, and if the
line moves, we know there is a problem. Second, we don't adjust
parentheses one at the time. After editing a section of code, we
delete the entire block of closing parentheses, "))])]))", then we
press close until the next line tabs to the right place.
I've never seen student in a beginner course work this way. As an
experiment, I invite you to try programming without using tab, and
without deleting blocks of parenthesis at once. I suspect you will
develop sympathy for these students who "hate parentheses".
Why would this be less of a problem in curly brace languages?
First, there are just many more parentheses in a Racket program. As
Matthias was saying, we use a lot of nested expressions, and function
call dictate nearly everything. So, in a curly brace language, when a
student is trying to re-infer their parenthesis structure, there are fewer
of them, so it isn't as hard.
Second, the grammar markers in a curly brace language have names on
them. They use "then" to separate the predicate from the answer, we
use ")(". It is much easier to re-infer intentionality of the former.
The latter is just another a bunch of parenthesis floating amongst
other anonymous parentheses.
If this theory holds, then P4P should help a great deal. P4P enforces
indentation, so students will have to start paying attention to it
(they really don't at the moment). P4P also reduces the number of
parentheses overall, and it puts names on the grammar markers.
I concur with Shriram. I don't think prefix notation for arithmetic is
a problem. Early in the course they will sometime write an infix
expression by mistake, but the error message they receive quickly
prompts them to the right fix. I don't see them struggling with this.
I also don't think "I hate parentheses" comes from familiarity with
some other syntax, or from familiarity with arrays. The feeling seem
just as common amongst non-majors who have never seen any programming
before.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] P4P: A Syntax Proposal
How does P4P interact with existing macros? How much work does it take to make a macro such as require/contract available to P4P programs? Is there an equivalent of the dotted-infix syntax in P4P? What would the following line look like in P4P? : (provide/contract [process (path-string? path-string? (listof symbol?) . -> . any)]) Right now, if I run #lang s-exp "p4p.rkt" require(srfi/1) I get the error require: not at module level or top level in: require Is this a bug? _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] self-documenting feature
During There is good support from the interviews for having dynamic documentation in DrRacket would help quite a bit. Two out of the four students I interview requested the feature. Here are some relevant inteview excepts. Student #1: " Maybe a tiny example, or something, that follows the contract and purpose of AND, might help. Because a lot of the time when I was doing these I found myself not remembering the contract and purpose for little things like this, like AND. It can take in multiple things. But the real thing I forgot is if they want things to the end. The problem is that they all have to be inside the parentheses. G, you're forgetting the contract and purpose of different functions? S, of course that happens a lot. CONS, LIST, APPEND, STRING-APPEND, all things we use, I forget what it takes in. Sometime I think of using SYMBOL? instead of SYMBOL=? and I have to take that extra second just to think after I've noticed I have an error. Which one do I use, SYMBOL?, or SYMBOL=? because they are relatively the same thing. They both produce Boolean, but one says this equals to the other. Having at least a little example, or the contract, or the purpose, the contract probably would help a lot. But that would be a lot of work to, but it would definitely help. I remember the contracts, the documentation of the contracts, and having to look it up. What does AND take in? Or what is APPEND. Or what about MIN vs MAX? Which takes in which? The x/y, I forget? overlay. " Student #2: " Random idea, but perhaps something that could be helpful... maybe under the error if you could somehow put an example of a define struc t... just something to show define-struct is define-struct open parenthesis something something G, some kind of syntax reminder S, yeah. Because there was probably my hardest thing, trying to learn the language? like when you add five and seven, its (+ 5 7) not (5+7)? example would probably be really useful. and later during the interview: " For example define-struct, ever since we started using it a lot, it was just something that I knew how to use because we used it almost everyday in class. But for something like format, or filter, I would just touched on in one lecture, then we would have to use it in special circumstances, an example in the error message would be awesome. It would be a very good reminder. " _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] How to run the BSL test suite?
> If I execute "Racket.exe -f racket/htdp.rktl" I get the error: > "racket/beg-adv.rktl:2:1: htdp-syntax-test: this function is not > defined in: htdp-syntax-test" For the record, I later discovered that this is indeed the right way to run the test suite. The error message I was receiving was describing something that needed to get fixed. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] How to run the BSL test suite?
What is the right way to run the BSL test suite? I'm not sure what is meant to be the main entry point. If I execute "Racket.exe - t run-automated-tests.rkt", the file tests/racket/htdp.rktl is not run. If I execute "Racket.exe -f racket/htdp.rktl" I get the error: "racket/beg-adv.rktl:2:1: htdp-syntax-test: this function is not defined in: htdp-syntax-test" _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] comment boxes
gzip compression (from file/gzip) followed by mime encoding (from net/base64) results in an average size reduction of 74%, on average, across 600 assignment submissions that were saved in Racket's "binary" format. On Tue, Jun 29, 2010 at 1:27 PM, Shriram Krishnamurthi wrote: > Part of the need for this is the bug report system doesn't allow > attachments, which I have sometimes sorely missed. Of course, it isnt the > only usecase. > > On Jun 29, 2010 1:05 PM, "Robby Findler" > wrote: > > Some kind of compression could help, but at the moment the format is > designed so that if someone were to copy and paste the contents of a > file into an email window and send it to us, we could still use it > (wierd linebreaks and all) and even if it gets truncated there is some > hope of recovering some of the content of the file. There probably is > a way to do better, but these properties have proven useful in the > past. > > Robby > > On Tue, Jun 29, 2010 at 11:57 AM, Guillaume Marceau > wrote: >> On Sat, Jun 26, 2... _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] comment boxes
On Sat, Jun 26, 2010 at 2:30 PM, Robby Findler wrote: > > Saving comment boxes requires the file to be saved in our fancy file > format and it adds a fair amount of overhead to do that. My impression is that all overhead would pretty much disappear if the binary format was gzipped. I would like to see a variant of the .rkt format with implicit compression, like .jar's, or .pdf's. These are compressed, but without the file name extension exposing that fact to users. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
