Re: [racket-dev] Revising Racket's home page
HtDP is how I learned to program correctly *after* I got my bachelor's in
CS. I still recommend it to coworkers and other experienced programmers so
they can start to learn good coding habits.
On Tuesday, August 20, 2013, Alexander McLin wrote:
The new design looks good on my iPhone and on desktop. It is a good
improvement over the old site.
To add to Neil's comment about dividing into two sections for experienced
programmers and educational outreach for aspiring programmers. One issue I
often see with others when talking about Racket is that they think it's
just an educational platform for middle school to high school. They don't
realize it's also a full service serious language for serious programming.
I think the web redesign should spend some effort on emphasizing that part.
However, although HTDP is intended for beginners, I still bought it anyway
as my introduction to Racket and to rework and improve my habits. It is
still good resource even for experienced people, so I'd hate to see it
hidden away behind a For Beginner button. I'm not sure whether
segregating completely the advanced and beginner materials is the right way
to do it.
Alex
On Mon, Aug 19, 2013 at 7:12 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edujavascript:_e({}, 'cvml', 'sa...@cs.indiana.edu');
wrote:
Ok, that makes sense. Can you file this as an issue on the GitHub
repository I just mentioned?
Sam
On Mon, Aug 19, 2013 at 7:09 PM, Stephen Chang
stch...@ccs.neu.edujavascript:_e({}, 'cvml', 'stch...@ccs.neu.edu');
wrote:
- web scraper example is cut off when clicking ? Maybe make the
overlay window variable width?
I'm not sure what you mean. Can you include a screenshot?
Screenshot attached.
Obviously not a huge issue but looking into it more, the example gets
cut off only because my browser window width is too small (monitor is
in portrait). If I increase the window width then the entire example
is visible. Still, it seemed weird because there was plenty of space
on either side.
on mobile (android 4.1.2, default browser):
- topright menu has very dark background when opened, so links are not
very visible
I'll check this out.
Thanks for the feedback!
Sam
On Mon, Aug 19, 2013 at 5:39 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu javascript:_e({}, 'cvml',
'sa...@cs.indiana.edu'); wrote:
Recently I (with assistance from Asumu) have spent some time drafting
a revised home page for Racket. A revised web page will nicely
complement the big upcoming release, I hope. You can see the draft
here, which is ready for people to try out:
http://homes.soic.indiana.edu/samth/new-web/
Some things to try out out: clicking the right and left arrows,
clicking the ? box, visiting the RacketCon page.
The new page addresses a few problems that I see with our current
page:
1. It works well on small devices, which our current page doesn't.
Try it out on a phone or a tablet.
2. It reduces the size of the top header, which will lighten the
burden on the documentation pages, for example, or the pkg index if
we
add the header there.
3. It puts more info on the first page. This means that people are
more likely to see information about how to contribute to Racket or
approaches to learning programming using our tools.
4. The font size is larger, which I think makes it much more
readable.
Perhaps more controversially, I adapted some prose about Racket from
Matthias' Racket is ... post, and added a tag line at the top.
Lots of work is still needed if we want to use this as the basis for
Racket's web page (it's written in raw HTML, other pages would need
work, etc), but I hope that people like it enough to continue
pursuing
this.
Sam
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] A story of a package split
Can you elaborate on your intermediate form? I don't understand how git submodules prohibit or restrict submodule evolution. The only difference I see with the submodule approach is that it requires an extra commit to update the submodule versions (and subsequently a pull followed by a submodule update in other clones), whereas the makefile approach only requires a 'make update' in the umbrella clones. Is there something else I'm missing? On Tue, Aug 13, 2013 at 2:22 PM, Tony Garnock-Jones to...@ccs.neu.eduwrote: Hi all, Matthias asked me to write a few words about an experience I had splitting a large repository of code up into smaller repositories and then building a mechanism to tie them together again. == A short story == Once upon a time, RabbitMQ (www.rabbitmq.com) was held in a single, monolithic Mercurial repository, including the server, the Java client library, the .NET client library, the Erlang client library, the protocol codec compiler, the documentation, adapters for other related messaging protocols, and so on. We decided for various reasons to split the monolithic repository into separate repositories. The approach we ended up taking was to have a single repository, the umbrella, which included a Makefile and a handful of scripts which checked out, updated, compiled etc. a number of other repositories from various places. You can still see the umbrella today here: http://hg.rabbitmq.com/**rabbitmq-public-umbrella/file/**defaulthttp://hg.rabbitmq.com/rabbitmq-public-umbrella/file/default The workflow for someone working on RabbitMQ is now: 1. Check out the umbrella, and `cd` into it. 2. Run `make checkout`. 3. Run `make`. 4. Edit, compile, debug, commit and push in the subdirectories resulting from step 2. 5. Occasionally run `make update` in the umbrella. (There's also some ugly makefile machinery to do cross-subrepository dependency tracking to let `make` in a subrepo recompile just the right things. Mostly.) Personally, I frequently use a script, `foreachrepo` (git variant attached) that lets me operate on all repositories found under the umbrella at once. For example, $ foreachrepo pwd would tell me where all the checkouts live, and $ foreachrepo git status would show me their status. When a configuration is found that works nicely and is to be released, a tag is made across all the currently-checked-out repositories: $ foreachrepo git tag my_release_2.3.4 $ foreachrepo git push --tags The split into completely separate repositories, linked informally by action of a script, worked out well for RabbitMQ, and the RabbitMQ project seems to be living happily ever after. == Comment == The problem addressed here is *configuration management*. RabbitMQ takes a very loose approach to configuration management, where individual modules evolve independently and are only connected to each other by happening to be in sibling directories within the umbrella. Tags are used to take a snapshot of a group of repositories at the same time. Another approach to configuration management uses an explicitly *versioned* manifest, where an umbrella repository names other repositories *and specific versions* of their contents to pull into scope. This is taken by systems like rebar, and is essentially how git submodules work. You could frame the contrast between the two by saying that the RabbitMQ approach is essentially *optimistic*, freezing configurations only when needed, and with occasional frankenconfigurations (when you `git pull` one subrepo but not one of its siblings) a risk during development, whereas the `git submodule` approach is *pessimistic*, keeping configurations frozen until explicitly moved forward into the next frozen configuration. An intermediate form could be imagined, where the Makefile checks out specific versions or branches but otherwise leaves them free to evolve in a way `git submodule` prohibits. Vincent has recently run into issues of configuration management: he wishes to assemble a specific collection of packages at specific versions to run a particular application (namely, some benchmarks). Others on this list do similar things, assembling specific versions of libraries into complete applications. I think it's interesting that both releasing applications and releasing the Racket system itself have this problem of describing a collection of related packages. Cheers, Tony _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A story of a package split
Although I like being right, I'm not sure what I'm right about. We use submodules at work both to include third-party tools and to share code among related internal projects. Submodules have worked fine for us so far, but they also have their downsides. For instance, we've made changes to shared submodules in one project and then not updated in other projects for a while, only to realize when we do update that those changes didn't work in the other project, so we had to make fixes to both (I just reread that sentence and realized it's pretty mumbly, but I'm too lazy to reword it). I was mainly asking about the intermediate form because it seems like it could be useful, but I didn't understand how it would work. On Tue, Aug 13, 2013 at 2:49 PM, Tony Garnock-Jones to...@ccs.neu.eduwrote: On 08/13/2013 04:42 PM, Nick Shelley wrote: Can you elaborate on your intermediate form? I don't understand how git submodules prohibit or restrict submodule evolution. The only difference I see with the submodule approach is that it requires an extra commit to update the submodule versions (and subsequently a pull followed by a submodule update in other clones), whereas the makefile approach only requires a 'make update' in the umbrella clones. Is there something else I'm missing? Perhaps you're right. Maybe my impression that git submodules are frozen is out-of-date. It has been a while since I used them. Perhaps they're first-class checkouts that can be manipulated independently of their... supermodule. If that's true, perhaps they're an OK way of specifying a versioned subrepo manifest. Cheers, Tony _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Racket learning page videos
I recently came across a presentation on the Racket way by Matthew Flatt ( http://www.infoq.com/presentations/Racket) and thought that it would be nice to be able to discover this and similar things more easily. I really like how all the publications are available on the Racket learning page. Would it be a good idea to also add links to videos such as this one? I also think Racket-con videos (or at least the link to the YouTube channel) would be good to have there. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket learning page videos
Maybe the main site could just point to the wiki for extra learning materials. On Tue, Jan 29, 2013 at 2:18 PM, Danny Yoo d...@hashcollision.org wrote: On Tue, Jan 29, 2013 at 9:35 AM, Nick Shelley nickmshel...@gmail.com wrote: I recently came across a presentation on the Racket way by Matthew Flatt (http://www.infoq.com/presentations/Racket) and thought that it would be nice to be able to discover this and similar things more easily. I really like how all the publications are available on the Racket learning page. Would it be a good idea to also add links to videos such as this one? I also think Racket-con videos (or at least the link to the YouTube channel) would be good to have there. I like this idea. It does seem like this kind of page would be more dynamic than the static pages on the main web site. Maybe it could fit into the wiki at https://github.com/plt/racket/wiki, and then if the content crystalizes, then reorganized into the main site? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
For what it's worth, Xcode differentiates these cases by inserting a temporary closing paren that is gray instead of black. You can make it permanent by arrowing over it, typing it yourself, tabbing over it, or just moving the cursor outside the matching parens. When it becomes permanent it is black like the other text and you have to delete it individually, but while it is still gray it will be deleted automatically if you delete the opening paren. I sort of like this behavior, and the visual difference gets rid of any potential confusion. On Saturday, November 24, 2012, Robby Findler wrote: On Sat, Nov 24, 2012 at 8:53 AM, Laurent laurent.ors...@gmail.comjavascript:; wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.orgjavascript:; wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@gmail.comjavascript:; wrote: If you can, I think it would be a good idea to remove the paren pair if the user deletes the opening paren he just typed by mistake. Undo should do the same (which apparently it does not currently; missing 'begin/end-edit-sequence' ?). Yeah, the undo behavior I've fixed. The first scenario you mention might be tricky - how do you distinguish between typing an open paren and then immediately deleting it vs. typing an open paren, making a bunch of other edits, and then coming back and deleting the open paren? I think it would already be good enough to only consider the case where the user types the paren and wants to remove them immediately (e.g., he placed them in the wrong place, or wanted square brackets instead, or just changed his mind). In the case of meanwhile edits, I don't think the user would bother deleting the closing paren himself. I think that hidden state like this can lead to confusing behavior. Probably you want to have deleting a paren do the same thing, regardless of what the character most recently typed was. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Survey for DrRacket users related to automatic parentheses behavior
Yes, I believe Eclipse does something like this too, maybe not with such a visual sort of indication. I agree that it's very cool functionality but it requires really thorough tracking of some hidden state as Robby says (history of the users' key and/or mouse interaction) and I don't think I'm going to go for this right now. I understand if it's not worth implementing for complexity reasons. I was just suggesting what I thought was a good visual solution to the potential confusion caused by such hidden state. And forgive me if this is an ignorant question since I have no idea what it takes to implement something like this, but couldn't you just have the state be tied to the specific closing paren character? If that were possible, the state could just include whether it is temporary and which opening paren it is linked to, and certain user actions change that state to permanent or deleted. I don't see a need to track history. But again, I have very little knowledge about this subject. On Sat, Nov 24, 2012 at 12:16 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 12:07 PM, Nick Shelley nickmshel...@gmail.comwrote: For what it's worth, Xcode differentiates these cases by inserting a temporary closing paren that is gray instead of black. You can make it permanent by arrowing over it, typing it yourself, tabbing over it, or just moving the cursor outside the matching parens. When it becomes permanent it is black like the other text and you have to delete it individually, but while it is still gray it will be deleted automatically if you delete the opening paren. I sort of like this behavior, and the visual difference gets rid of any potential confusion. Yes, I believe Eclipse does something like this too, maybe not with such a visual sort of indication. I agree that it's very cool functionality but it requires really thorough tracking of some hidden state as Robby says (history of the users' key and/or mouse interaction) and I don't think I'm going to go for this right now. On Saturday, November 24, 2012, Robby Findler wrote: On Sat, Nov 24, 2012 at 8:53 AM, Laurent laurent.ors...@gmail.com wrote: On Sat, Nov 24, 2012 at 3:11 PM, Nadeem Abdul Hamid nad...@acm.org wrote: On Sat, Nov 24, 2012 at 4:03 AM, Laurent laurent.ors...@gmail.com wrote: If you can, I think it would be a good idea to remove the paren pair if the user deletes the opening paren he just typed by mistake. Undo should do the same (which apparently it does not currently; missing 'begin/end-edit-sequence' ?). Yeah, the undo behavior I've fixed. The first scenario you mention might be tricky - how do you distinguish between typing an open paren and then immediately deleting it vs. typing an open paren, making a bunch of other edits, and then coming back and deleting the open paren? I think it would already be good enough to only consider the case where the user types the paren and wants to remove them immediately (e.g., he placed them in the wrong place, or wanted square brackets instead, or just changed his mind). In the case of meanwhile edits, I don't think the user would bother deleting the closing paren himself. I think that hidden state like this can lead to confusing behavior. Probably you want to have deleting a paren do the same thing, regardless of what the character most recently typed was. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Master-Worker with Places
Thanks, that is helpful. I think I had read about wrap-evt but didn't know how I would use it. Those examples help. I guess my email should have been a question to the users group about how I could do it better rather than a suggestion to the dev group about what to change. On Thu, Mar 29, 2012 at 12:14 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 29 Mar 2012 12:00:07 -0600, Nick Shelley wrote: I think it would make more sense for the result of syncing on a place-channel to return the channel itself as a result. This would make an explicit call to place-channel-get necessary, which may be a downside, but the upside is I could then put something on the same channel or do whatever else I may want with it. If syncing on a place channel doesn't return the available value, then it's possible for a different client to consume the value before a later `place-channel-get'. Besides the further complexity that adds, there are issues of fair scheduling. If you want the place channel back, you how about wrapping it so that the result combines the value with its place channel? (wrap-evt pc (lambda (v) (cons pc v))) Or, if the reason to have the place channel is to reply, then it might make sense to put the reply in the wrapping procedure: (wrap-evt pc (lambda (v) (channel-put pc (derive-some-answer v As a sort of side note, it would be nice to be able to treat this problem similar to a user thread problem where you can conceptually imagine having infinite workers and just giving one chunk of work to each of them. I tried to do this at first, but because of the way places are implemented, I ran out of file descriptors relatively quickly (and the overhead of starting a new VM for each chunk of work might have been too much anyway, I don't know). I don't know if an abstraction like that is possible or useful in general, but it may be something to consider. I agree that we need more abstractions built on top of places. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Fwd: [racket-bug] all/12642: #lang slideshow gets error message module: this function is not defined
I know I'm not a contributor (yet), but I think it would be nice if #lang always took priority, and a warning would appear if the #lang overrode the language drop-down (drop-up in DrRacket I guess). I don't think anyone using the teaching languages ever uses #lang, and when they do it's usually because they are moving on to other languages (at least temporarily). On Wed, Mar 21, 2012 at 9:04 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Wed, Mar 21, 2012 at 10:48 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Also, Roger (the bug reporter) tried basically all the languages in the dialog, but did not understand that Use the language declared in the source was even an option. Ugh. That's unfortunate. We spent a lot of time trying to make that dialog clear. Here are a few ideas for improving it: 1. Include some examples of #lang lines under the #lang option. 2. Change option 2 to be Use a teaching language, with *only* the teaching langauges listed. Then have a button to show the other languages. This would also cut down on the number of people who choose R5RS without knowing what they're doing. 3. Like option 2, but put even the teaching languages behind the button. This would make it hard to get confused as a newcomer to Racket, but students would need more explanation. I think both 1 and 2 are good ideas, and we could do them without inconveniencing people. 3 is more controversial. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Interactive Tutorial
My brother has been interested in learning to program, but not super motivated. I've tried to get him into HtDP 2e, but for him there's too much reading and not enough doing (and when he comes to the exercises he usually skips them anyway...). However, he recently started doing some codecademyhttp://www.codecademy.com/ exercises and really enjoys it. It seems like it wouldn't be too hard to turn the Quick guide into something similar by using something like WeScheme. I also know of several people who have expressed interest in learning to program but definitely don't have the motivation to go through HtDP. It seems like the codecademy approach is ideal for those types of people (the people who would like to dip their feet before diving in). I don't think I have the know-how to do something like that, but I'd be willing to help if anyone thinks it's worth tackling at some point. -Nick _ Racket Developers list: http://lists.racket-lang.org/dev
