[racket-dev] DrRacket flickers?
Hi, Using Racket 6.1.1.1--2014-10-13(47b7a28/a) [3m] on Ubuntu 14.04, I see DrRacket flickering during selections, tab switching and other occasions, but it's not consistent. Does anyone else see the same thing? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket hash tables vs. Python dicts - Performance
Even more idiomatic:
(time (for ([w words])
(hash-update! d w add1 0)))
But it seems to be slightly slower that Robby's version.
Laurent
On Thu, Jul 24, 2014 at 11:26 AM, Robby Findler ro...@eecs.northwestern.edu
wrote:
Not an answer to your direction question, but this is the more
idiomatic way to write that and it seems to be a bit faster:
(time (for ([w (in-list words)])
(hash-set! d w (add1 (hash-ref d w 0)
On Wed, Jul 23, 2014 at 10:54 AM, Pedro Ramos
pedropra...@tecnico.ulisboa.pt wrote:
Hi,
I've been developing an implementation of Python in Racket, where I'm
implementing Python's dictionaries over Racket custom hash tables.
While my occasional benchmarks typically show better performance on
Racket
programs than their Python equivalents, Racket's hash tables generally
seem
to be slower than Python's dicts.
I've set up this benchmark in Racket:
#lang racket
(define alphabet abcdefghijklmnopqrstuvwxyz)
(define (random-word n)
(build-string n (lambda (x) (string-ref alphabet (random 23)
(define words (for/list ([k 100])
(random-word 3)))
(define d (make-hash))
(time (for ([w words])
(if (hash-has-key? d w)
(hash-set! d w (add1 (hash-ref d w)))
(hash-set! d w 1
And its equivalent in Python:
import random
import time
alphabet = abcdefghijklmnopqrstuvwxyz
def random_word(n):
return ''.join([random.choice(alphabet) for i in range(n)])
words = [random_word(3) for k in xrange(100)]
d = {}
a = time.time()
for w in words:
if w in d:
d[w] = d[w] + 1
else:
d[w] = 1
b = time.time()
print b-a, 'seconds'
The Racket example yields running times of around 500 ms (running on
Racket
v6.0.1) while the Python example yields running times of around 330 ms
(running on Python 2.7.3).
I find this unusual because Python is somewhat more dynamic than Racket,
since
(a) Python's equality and hashing functions have to dispatched at runtime
for each key;
(b) referencing and setting values in a Python dict is done using a very
general operator, [], whose behaviour also has to be dispatched at
runtime,
unlike the more specific hash-ref and hash-set! Racket functions.
Is there something I'm missing about Racket's hash tables which explains
this slower speed?
Thanks,
Pedro Ramos
_
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] actionable items, was: comments on comments on learning Racket
On Mon, Apr 28, 2014 at 3:47 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: o Are you a student learning to program? o Are you an experienced programmer learning to use Racket? (why /learning/ to use Racket? I could well be that s/he's on a new machine) Why not simply Choose a language and give a list of the usual ones with explanations? define (gather-return-values f . s) (call-with-values (lambda () (apply f s)) list)) Why not something like `apply-list` or `apply/list`? (personally I usually call it `cvl` for call/values-list, but that's because I often use it on the command line, which makes going from `(foo 'a 'b 'c)` to `(cvl foo 'a 'b 'c)` effortless) (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i Forgot to mention that I've had less need for this one as once you have `gather-return-values` it's easy enough to write `(second (gather-return-values foo 'a 'b 'c))`. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] comments on comments on learning Racket
On Sun, Apr 27, 2014 at 1:09 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: ** tab completion must be faster and re-indentation of large parts of files too, if possible. Currently, re-indenting a 500 lines file can take a few seconds. ?? I don't get the Uniform syntax is harder to read comment. More highlighting, hmph? Maybe it's just that he's not used to prefix bracketed syntax. That certainly demands a bit of training. Also, because Racket makes extensive use of long-and-clear words, maybe it is comparable to reading a math formula (non-racket) and reading the same formula using words (racket): If you know how to read a formula (know what all the symbols mean, etc.), it can be much faster than reading the verbose form. ** I do get jealous when I see [(i, j, k) | i - [1..10], j - [i..10], k - [j..10], i^2 + j^2 == k^2] vs (for*/list ([i (range 1 20)] [j (range i 20)] [k (range j 20)] #:when (= (+ (sqr i) (sqr j)) (sqr k))) (list i j k)) Would you be less jealous reading the following? (for*/list ([i (.. 1 20)] [j (.. i 20)] [k (.. j 20)] #:when (= (: i ^ 2 + j ^ 2) (: k ^ 2)) (list i j k)) or is it really the #:when part that you'd have preferred to be treated on par with the rest, as in Haskell? (or the one-liner?) ** Do we need to add these to our library? ;; (X ... - Y ...) X *- [List-of Y] (define (gather-return-values f . s) (call-with-values (lambda () (apply f s)) list)) ;; Nat (X ... - Y ...) X *- Y (define (nth-return-value i f . s) (call-with-values (lambda () (apply f s)) (lambda l (list-ref l i I've been having a need of these functions on several occasions myself too. (Although the names are too long, but maybe just omitting `return` would be acceptable to my taste.) ** Printing is brutally expensive in DrRacket. Is there a way to make it cheaper? (maybe use some buffering, like wait at least 0.2 seconds before printing, instead of printing everything right away?) ;; - [1] What do we call the thing that shows up at the top right? I think Robby calls them the blue-boxes? ;; = PART II ** Why, why must everything be Inferior By Default? We obviously need a 'syntax story' that takes readers directly from define-syntax-rule to syntax-parse, bringing in hygiene only late, when it truly matters to raise expressiveness Why not use `define-simple-macro` and completely ditch `define-syntax-rule` from the guide? He could then have gone from (define-simple-macro (swap x y) ) to (define-simple-macro (swap x:id y:id) ) in no time. ** For some reason I was thinking that indentation information is somehow stored with functions/macros themselves. I was wrong. We discussed this years ago. Hmph, he thought so too. I'd also have preferred that (but it's easier to say than to do, obviously). This would allow users to define their own indentation rules for their own forms, and possible re-define it for old forms, but that is more debatable. Thanks to submodules, it could be loaded only when used, e.g. by DrRacket. ** I'm afraid that with the level of flexibility Racket allows, I'll never get to writing an actual program – most likely I'll be spending my time improving Racket itself (well, or at least changing it to suit my tastes). Well, I went there when I was young and saw macros. Who hasn't? I remember the time when I first thought Oh my, Racket is the most powerful language in the world!. Quite a enlightenment moment. On Sun, Apr 27, 2014 at 2:38 AM, Sam Tobin-Hochstadt sa...@cs.indiana.eduwrote: Ok, I think we agree then. What I'm proposing is that new DrRacket installations should start in a mode where `#lang racket (+ 3 4)` works, which is not currently the case. Completely agree on that. Also, maybe the Language preferences should be accessible from the Edit/Preferences panel, or at least be listed right under, in Edit/Language preferences. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Implementation question
One simpler possibility is to use `tcp-connect/enable-break` and run a timer in parallel to break it after a shorter delay. For example: (define-values (in out) (values #f #f)) (define connect-thread (thread (λ()(set!-values (in out) (tcp-connect www.google.com 80) (sleep 3) (unless in (displayln Connection not established. Breaking thread.) (break-thread connect-thread)) The timer can also be place into its own thread if you need to set up several connections in parallel. Hope this helps, Laurent On Thu, Apr 17, 2014 at 6:48 PM, nicolas carraggi nicocarra...@hotmail.comwrote: Hello, I am actually using Racket/tcp for a project in Racket. I'm creating a peer-to-peer network but now I encountered a small problem. For a multicast I want to connect with each server on the same network. For this I use tcp-connect, but when i try to connect to an ip address which is not hosting a server, throwing the error only happens after more than 1 minute. So I would like to use a modified tcp-connect with a smaller time-out. Where can I find the implementation of tcp-connect? I already found tcp.rkt but there it gets the tcp-connect method from '#%network but I can't find this one... Greetings! Nicolas _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] gui responsiveness
As a side note, I remember having stumbled on the same issue some while back, and the way I dealt with it was to refresh based on a random outcome. Not clean, but it works pretty well as long as the refresh calls are still close enough. Laurent On Thu, Apr 17, 2014 at 12:11 AM, David Vanderson david.vander...@gmail.com wrote: Thanks for the great (and quick!) response. It's good to know that the ordering is intentional, and to have some nice ways to work around it if needed. The reason I thought that refreshes were lower priority was because of the scrollbar behavior in the program below. On Unix/X, dragging the scrollbar back and forth does lots of paints, but I only actually see a few of them. Does that sound like a bug to you? #lang racket/gui (define num-on-paint 0) (define frame (new frame% (label Refresh) (width 500) (height 500))) (define (draw-screen canvas dc) (set! num-on-paint (add1 num-on-paint)) (sleep 0.1) ; simulate a longer painting effort (send dc draw-text (~a num-on-paint paints) 400 70)) (define canvas (new canvas% (parent frame) (paint-callback draw-screen) (style '(no-autoclear hscroll (send frame show #t) (send canvas init-auto-scrollbars 700 #f 0.0 0.0) On 04/16/2014 01:56 PM, Matthew Flatt wrote: You're right that it's about event ordering and not refresh coalescing. Since mouse events are handled after refreshes, you won't get the next refresh request until an earlier one is handled, after which the next mouse event can trigger another refresh request. I think the difference between Unix/X and Windows may be that Windows sends fewer mouse events. There are trade-offs here, but my experience is that ordering input events before refresh does not work well in general. To trigger refreshes at a lower priority in this case, you could use Neil's suggestion or change (send this refresh) to (set! needed? #t) (queue-callback (lambda () (when needed? (set! needed? #f) (send this refresh))) #f) ; = low priority where `needed?` is a field that's initially #f. At Wed, 16 Apr 2014 13:33:02 -0400, David Vanderson wrote: (moved to dev) On Linux, the attached program shows terrible responsiveness when dragging points around on the graph. Can anyone else on Linux reproduce this behavior? The patch below dramatically improves the responsiveness by forcing the eventspace to process medium-level events (mouse movement) before refresh events. Without the patch, each mouse drag causes a paint. With it, multiple mouse drags are processed before a paint. I'm unsure about this fix. Windows doesn't show the problem (I don't have a mac to test), so I think it's just a GTK issue. My guess is that the gui layer is relying on the native libraries to coalesce multiple refresh requests (but this is not working with GTK). Can anyone confirm this? Thanks, Dave diff -ru racket-6.0_clean/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt racket-6.0/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt --- racket-6.0_clean/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt 2014-02-18 12:27:43.0 -0500 +++ racket-6.0/share/pkgs/gui-lib/mred/private/wx/common/queue.rkt 2014-04-16 09:41:16.810993955 -0400 @@ -300,8 +300,8 @@ (lambda (_) #f)) (or (first hi peek?) (timer-first-ready timer peek?) - (first refresh peek?) (first med peek?) + (first refresh peek?) (and (not peek?) sync? ;; before going with low-priority events, -- [text/plain graph_ui.rkt] [~/Desktop open] [~/Temp open] _ 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] Test errors on scribble/reader.rkt
Thank you both for the info, I see that now. Laurent On Thu, Dec 19, 2013 at 3:32 PM, Sam Tobin-Hochstadt sa...@cs.indiana.eduwrote: On Thu, Dec 19, 2013 at 8:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Is there an easy way to know if some tests are enabled in DrDr? Currently, the configuration is in pkgs/plt-services/meta/props but we need to move that information into individual collections (via info.rkt files, maybe). Perhaps easier than trying to read that file is just looking at DrDr itself. For example, here's the reader.rkt file, from a few days ago: http://drdr.racket-lang.org/27930/pkgs/scribble-pkgs/scribble-test/tests/scribble/reader.rkt You can see that it was run with `raco test`, which doesn't actually test anything on that file. And here's the main.rkt file, which is what Matthew enabled. Then: http://drdr.racket-lang.org/27930/pkgs/scribble-pkgs/scribble-test/tests/scribble/main.rkt Now: http://drdr.racket-lang.org/27959/pkgs/scribble-pkgs/scribble-test/tests/scribble/main.rkt It turns out that the `reader.rkt` file is still not being tested on its own, but the whole set of tests is now run via `main.rkt`. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Test errors on scribble/reader.rkt
Thanks! I was worried I was doing something wrong, but IIUC these tests
were just not enabled in DrDr.
Is there an easy way to know if some tests are enabled in DrDr?
Laurent
On Thu, Dec 19, 2013 at 3:02 AM, Matthew Flatt mfl...@cs.utah.edu wrote:
Thanks --- I've tracked down the problem and pushed repairs.
At Tue, 17 Dec 2013 17:08:34 -0500, Greg Hendershott wrote:
I see the same.
Using HEAD (97ee349) today, built just now.
On Sat, Dec 14, 2013 at 9:47 AM, Laurent laurent.ors...@gmail.com
wrote:
Hi,
After a fresh `git pull --ff-only` followed by `make`, I have 9 errors
when
running `raco test .` in scribble-test/tests/scribble/ like:
reader.rkt:935:22: test failure
bad result in
@foo{ -@error- #rx:1:0: missing closing `}'$
results:
(missing closing `}') != (#rx:1:0: missing closing `}'$)
[...]
Looks like the location information is not included (anymore?) in the
error
message.
Did I forget to rebuild something or do something, or is it not just
me?
(Note: some external packages did not build correctly, like an old
cce-scheme, but that's not related, is it?)
Laurent
_
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-dev] Test errors on scribble/reader.rkt
Hi,
After a fresh `git pull --ff-only` followed by `make`, I have 9 errors when
running `raco test .` in scribble-test/tests/scribble/ like:
reader.rkt:935:22: test failure
bad result in
@foo{ -@error- #rx:1:0: missing closing `}'$
results:
(missing closing `}') != (#rx:1:0: missing closing `}'$)
[...]
Looks like the location information is not included (anymore?) in the error
message.
Did I forget to rebuild something or do something, or is it not just me?
(Note: some external packages did not build correctly, like an old
cce-scheme, but that's not related, is it?)
Laurent
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] separate plot library into gui-requiring and non-gui-requiring
Le 10 oct. 2013 00:09, Neil Toronto neil.toro...@gmail.com a écrit : Also, what's a good name for the module that exports `plot-file', `plot-pict', `plot-bitmap', `plot/dc', and the 3d versions of those functions? Something like plot/no-gui? plot/draw maybe? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] info.rkt `deps` and new #:version keyword: Backward compatibility?
On Thu, Oct 3, 2013 at 4:07 PM, Greg Hendershott greghendersh...@gmail.comwrote: On Thu, Oct 3, 2013 at 9:50 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Oct 3, 2013 at 7:40 AM, Greg Hendershott The concept of backwards compatibility does not apply to beta software in my opinion. The next release will be the first release where the package system is not beta. I understand. OTOH this is a public beta where people are invited to use it for real, and pkg.racket-lang.org already has many packages. If we had somehow painted ourselves into a corner where a required change had no (reasonable) backward compatibility tactic, people would (have to) understand and accept that. And in that case maybe we'd want to re-launch the package system as Works only with 5.3.90 or higher, for sanity. But so far, in cases like multi vs. single collection default, or #:version, it's very much appreciated the intent has been to preserve it -- thanks! If having a beta period with a number of backward incompatibilities means having the best package system ever, I'm all for it. Twice. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Installing subsets of Racket
Thanks for the info. Binaries may still be good when one wants to install a package only for a single purpose. On Tue, Sep 24, 2013 at 12:50 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Although packages are not currently distributed in binary form, you can install built packages (as available from a snapshot site) in binary mode by supplying the `--binary' flag to `raco pkg install'. For example, if you start with a Minimal Racket build from http://www.cs.utah.edu/plt/snapshots/ then install it on Mac OS X (64-bit), it starts with a footprint of about 30 MB. Using bin/raco pkg install -i --binary images installs about 40 packages to bring the total footprint to about 70 MB. In contrast, using bin/raco pkg install -i images installs about 95 packages to bring the total footprint to about 260 MB. Fewer packages are installed in binary mode because build dependencies are pruned from each package as it is converted (on download) from built to binary. The binary versus built distinction doesn't automatically exclude documentation. The 40-ish packages installed for images includes images-doc, because the images package is meant to imply both images-lib and images-doc. Little other documentation is installed, however, because other documentation is mostly needed only to build the images documentation. The smallest installation with the images libraries is bin/raco pkg install -i --binary images-lib which installs about 30 packages to bring the total footprint to about 55 MB. Then again, sticking with built mode as bin/raco pkg install -i images-lib installs the same 30-ish packages with a footprint of 65 MB, which illustrates that the savings from `--binary' are almost all from reducing dependencies (and not about omitting source). So, `--binary` is available and can help, but it's an indirect way of reducing dependencies. Improved support for generating, installing, and depending on -lib variants might be better in the long run --- but I think we don't know how to do that, yet. At Mon, 16 Sep 2013 09:04:49 -0600, Jay McCarthy wrote: Hi Laurent, I think that the solution to this are binary builds versions of a package that only have the bytecode and documentation. We're a bit behind on binary builds, because when they were discussed for the main repository [1] they were rejected. I hope to be able to still provide them for ring-0 packages through the results of DrDr running tests (and thus compiling) on those packages, but it's in the future. The result would be that when you installed a package in binary form, you would only get the deps and not the build-deps. (And you'd probably get those in binary form too.) Jay 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote: Hi, (this is not a complain, just an inquiry) While installing Racket on a small server, I wanted to avoid installing gui and doc related libraries. The minimal install was great! Then I wanted to install a package of my own (the aptly named bazaar), which requires images and other gui libs (which I actually would not use on the server), among other things, but no doc But the images package draws racket-doc and gui-doc dependencies, which in turn draws practically all of Racket. And it then takes a much longer time for `raco setup` to do its job that I had hoped for. Certainly, this can be resolved by splitting images and bazaar into lib, gui and docs packages, but I foresee another problem: It's difficult to enforce such a split for third-party libraries, as it puts the burden on the user. And the first package like that to be installed will again draw all of Racket dependencies. This is probably not a trivial matter, but what can be done about this? My dream would be that gui and doc dependencies are never triggered, without preventing the packages I actually use to be downloaded, but I don't know how this could actually be ensured without a good amount of magic. Merely preventing downloads does not sound like a good option though. I bet you've already discussed this far and wide, so are there any plans? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Installing subsets of Racket
Hi, (this is not a complain, just an inquiry) While installing Racket on a small server, I wanted to avoid installing gui and doc related libraries. The minimal install was great! Then I wanted to install a package of my own (the aptly named bazaar), which requires images and other gui libs (which I actually would not use on the server), among other things, but no doc But the images package draws racket-doc and gui-doc dependencies, which in turn draws practically all of Racket. And it then takes a much longer time for `raco setup` to do its job that I had hoped for. Certainly, this can be resolved by splitting images and bazaar into lib, gui and docs packages, but I foresee another problem: It's difficult to enforce such a split for third-party libraries, as it puts the burden on the user. And the first package like that to be installed will again draw all of Racket dependencies. This is probably not a trivial matter, but what can be done about this? My dream would be that gui and doc dependencies are never triggered, without preventing the packages I actually use to be downloaded, but I don't know how this could actually be ensured without a good amount of magic. Merely preventing downloads does not sound like a good option though. I bet you've already discussed this far and wide, so are there any plans? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Installing subsets of Racket
great, thanks, that was quick! On Mon, Sep 16, 2013 at 6:34 PM, Robby Findler ro...@eecs.northwestern.eduwrote: In the meantime, the images pkg is now broken up and images-lib depends only on draw-lib (and some unstable stuff), no longer on the full gui library or the docs. Robby On Mon, Sep 16, 2013 at 11:24 AM, Laurent laurent.ors...@gmail.comwrote: Sounds good! I think as long as it's possible to somehow choose between byte-code and source-code packages/distributions, there should not be too much to worry about. My server would be very happy with byte-code packages, and my desktop with a full source-code Racket. Laurent On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy jay.mccar...@gmail.comwrote: Hi Laurent, I think that the solution to this are binary builds versions of a package that only have the bytecode and documentation. We're a bit behind on binary builds, because when they were discussed for the main repository [1] they were rejected. I hope to be able to still provide them for ring-0 packages through the results of DrDr running tests (and thus compiling) on those packages, but it's in the future. The result would be that when you installed a package in binary form, you would only get the deps and not the build-deps. (And you'd probably get those in binary form too.) Jay 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote: Hi, (this is not a complain, just an inquiry) While installing Racket on a small server, I wanted to avoid installing gui and doc related libraries. The minimal install was great! Then I wanted to install a package of my own (the aptly named bazaar), which requires images and other gui libs (which I actually would not use on the server), among other things, but no doc But the images package draws racket-doc and gui-doc dependencies, which in turn draws practically all of Racket. And it then takes a much longer time for `raco setup` to do its job that I had hoped for. Certainly, this can be resolved by splitting images and bazaar into lib, gui and docs packages, but I foresee another problem: It's difficult to enforce such a split for third-party libraries, as it puts the burden on the user. And the first package like that to be installed will again draw all of Racket dependencies. This is probably not a trivial matter, but what can be done about this? My dream would be that gui and doc dependencies are never triggered, without preventing the packages I actually use to be downloaded, but I don't know how this could actually be ensured without a good amount of magic. Merely preventing downloads does not sound like a good option though. I bet you've already discussed this far and wide, so are there any plans? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Installing subsets of Racket
Sounds good! I think as long as it's possible to somehow choose between byte-code and source-code packages/distributions, there should not be too much to worry about. My server would be very happy with byte-code packages, and my desktop with a full source-code Racket. Laurent On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy jay.mccar...@gmail.comwrote: Hi Laurent, I think that the solution to this are binary builds versions of a package that only have the bytecode and documentation. We're a bit behind on binary builds, because when they were discussed for the main repository [1] they were rejected. I hope to be able to still provide them for ring-0 packages through the results of DrDr running tests (and thus compiling) on those packages, but it's in the future. The result would be that when you installed a package in binary form, you would only get the deps and not the build-deps. (And you'd probably get those in binary form too.) Jay 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote: Hi, (this is not a complain, just an inquiry) While installing Racket on a small server, I wanted to avoid installing gui and doc related libraries. The minimal install was great! Then I wanted to install a package of my own (the aptly named bazaar), which requires images and other gui libs (which I actually would not use on the server), among other things, but no doc But the images package draws racket-doc and gui-doc dependencies, which in turn draws practically all of Racket. And it then takes a much longer time for `raco setup` to do its job that I had hoped for. Certainly, this can be resolved by splitting images and bazaar into lib, gui and docs packages, but I foresee another problem: It's difficult to enforce such a split for third-party libraries, as it puts the burden on the user. And the first package like that to be installed will again draw all of Racket dependencies. This is probably not a trivial matter, but what can be done about this? My dream would be that gui and doc dependencies are never triggered, without preventing the packages I actually use to be downloaded, but I don't know how this could actually be ensured without a good amount of magic. Merely preventing downloads does not sound like a good option though. I bet you've already discussed this far and wide, so are there any plans? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Bug report not confirmed
On Sat, Sep 14, 2013 at 12:40 AM, Eli Barzilay e...@barzilay.org wrote: Just now, Greg Hendershott wrote: On Thu, Sep 12, 2013 at 4:41 PM, Laurent laurent.ors...@gmail.com wrote: FYI, I have filed a bug report more than 3 hours ago but did not receive any confirmation. Is it possible the bug tracker is broken? There was a permission problem with it, which is fixed now. I just sent another (different) report, and did received the notification this time. Thanks. Unfortunately, it looks like the contents of those messages are lost. Ok, meanwhile I found a workaround, so it's not that important now. I'm not sure what's the correct thing to do here: Should I submit another bug report for something that had annoyed me but doesn't anymore? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] List-box% infinite loop (was: Bug report not confirmed)
On Sun, Sep 15, 2013 at 4:34 PM, Robby Findler ro...@eecs.northwestern.eduwrote: What was the issue? It was an infinite loop triggered by a particular callback in list-box%: #lang racket/gui (define my-frame (new frame% [label my-frame] [min-width 200] [min-height 200])) (define lb (new list-box% [parent my-frame] [label values] [choices '(a b)] [callback (λ(lb ev) (displayln (send ev get-event-type)) (send lb clear) (send lb set '(b)) )])) (send my-frame show #t) Click on b, this will trigger infinite events It's actually the combination of the callback calling `clear' and `set' that triggers this infinite loop. The problem is easily solved by removing `(clear)', which is redundant with `set' anyway (which I hadn't understood at first). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Revising Racket's home page
Apologies if this has been mentioned already (too much to read), but IMHO the sections are too close to one another. I'd personally add more padding-top to the h2, even up to 1.5em. Some h2 section headers (Documentation, Learning, Community) are also too close from their section body IMO too. At first glance it was difficult to identify the sections. Otherwise I like it a lot. Laurent On Mon, Aug 19, 2013 at 11:39 PM, Sam Tobin-Hochstadt sa...@cs.indiana.eduwrote: 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
Re: [racket-dev] .desktop files (for GUI apps on Unix)
Thank you very much!
On Sat, Aug 10, 2013 at 8:54 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
I've added support for .desktop files for GUI launchers on Unix. When
an info.rkt file specifies a launcher for name.rkt, then if
name.desktop exists, name.desktop is used as the initial
content of the executable's .desktop file; Exec and Icon entries
are added automatically to the end. A name.png or name.ico file
provides the .desktop file's icon.
For an in-place installation, installation-scoped .desktop files go
into share/applications, and they use relative paths for Exec and
Icon. Relative paths are not actually supported in .desktop files,
so the .desktop files are essentially templates for creating useful
.desktop files. (Relative paths are used, even though they are not
supported in .desktop files, because an in-place installation is
meant to have no absolute paths.)
For a Unix-style installation, then installation-scoped .desktop
files have full paths. The destination for .desktop files can be
adjusted with the `--appsdir' flag to `configure' (or by an end user
when installing a distribution). The default destination is
${prefix}/share/applications, which means that .desktop files to
the usual system-wide place when ${prefix} is /usr.
Finally, if a package that provides an application is installed in user
scope, then the generated .desktop file in
~/.racket/version/share/applications uses full paths, so it should
work as expected.
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg install should default to linking for filesystem packages
So `--link' could be the default, while `--copy' (?) could disable special handling of directory sources? That sounds fine. I mean, I am unlikely to ever use --copy, but whatever makes sense to expose in terms of the underlying model. It could be useful if the directory is on a remote computer, but this will probably be a less frequent case. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] single-collection packages
Much better indeed, but maybe there is still some redundancy left with the `setup-collects' option? http://docs.racket-lang.org/pkg/metadata.html Laurent On Tue, Jun 25, 2013 at 11:08 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: +1 On Jun 25, 2013, at 4:27 PM, Sam Tobin-Hochstadt wrote: On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. 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
Re: [racket-dev] single-collection packages
(looks like I'm misunderstanding this option. Forget about it.) On Wed, Jun 26, 2013 at 10:30 AM, Laurent laurent.ors...@gmail.com wrote: Much better indeed, but maybe there is still some redundancy left with the `setup-collects' option? http://docs.racket-lang.org/pkg/metadata.html Laurent On Tue, Jun 25, 2013 at 11:08 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: +1 On Jun 25, 2013, at 4:27 PM, Sam Tobin-Hochstadt wrote: On Tue, Jun 25, 2013 at 4:24 PM, Matthew Flatt mfl...@cs.utah.edu wrote: So, I think it's better to define `collection': [snip] I think this is a definite improvement. 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
Re: [racket-dev] Keywords
On Mon, Jun 17, 2013 at 5:09 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments My intent was that you could use both positional and keyword arguments at the same time, for each argument. This way, you may even avoid the new for `new', and use the procedure itself, i.e., with the same procedure or struct or class, you can simply write: (define (fish name weight) (list name weight)) and call it with: (fish #:name Nemo #:weight 700) or (fish Nemo 700) or (fish Nemo #:weight 700) and same for make-fish (for structs) and fish%. There would be no difference in the calling style between proc, struct and class. (Or maybe I misunderstood your point.) On Mon, Jun 17, 2013 at 5:28 PM, Neil Van Dyke n...@neilvandyke.orgwrote: I have used this in Python, and it is kinda neat and has its uses, but overall, I prefer the current way in Racket. One reason I prefer the current way in Racket is that, if every argument can be positional, then you have to keep this in mind when adding keyword arguments to a procedure that is used by other code: new arguments can only be added at the end of the list, even if that does not make the most sense for documentation purposes. Good point. Then one possibility is to allow to force an argument to be by-name only (I don't see a strong reason to allow to force an argument to be by-position only, except maybe to avoid bad proc-call habits, but not even sure). Another reason is that the keyword arguments restrict the syntax somewhat, so, when a mistaken extraneous sexp is where we'd expect a keyword, it is flagged as an error, rather than be considered a positional argument. Related to the previous reason, if the programmer is *intentionally* intermixing keyword arguments with positionals, such as (foo 37 #:x 41 74 #:a 34), that seems error-like that I wish they would get an error and change their ways. I agree, although less strongly than for the above point. I wouldn't mind to force calls to take positional arguments first, and have no more positional arguments after the first keyword. (it actually seems to be easier to implement this way too.) Though note that currently Racket does allow things like that: (define (foo y #:x x ) (list x y)) (foo #:x 3 1) ; - '(3 1) Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Here's a simple demo for procedures if you want to try it out: https://gist.github.com/Metaxal/5851215 Laurent On Mon, Jun 24, 2013 at 4:54 PM, Laurent laurent.ors...@gmail.com wrote: On Mon, Jun 17, 2013 at 5:09 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: p.s. On second thought, for structs you want two constructors: -- one that takes positional arguments -- one that takes keyword arguments My intent was that you could use both positional and keyword arguments at the same time, for each argument. This way, you may even avoid the new for `new', and use the procedure itself, i.e., with the same procedure or struct or class, you can simply write: (define (fish name weight) (list name weight)) and call it with: (fish #:name Nemo #:weight 700) or (fish Nemo 700) or (fish Nemo #:weight 700) and same for make-fish (for structs) and fish%. There would be no difference in the calling style between proc, struct and class. (Or maybe I misunderstood your point.) On Mon, Jun 17, 2013 at 5:28 PM, Neil Van Dyke n...@neilvandyke.orgwrote: I have used this in Python, and it is kinda neat and has its uses, but overall, I prefer the current way in Racket. One reason I prefer the current way in Racket is that, if every argument can be positional, then you have to keep this in mind when adding keyword arguments to a procedure that is used by other code: new arguments can only be added at the end of the list, even if that does not make the most sense for documentation purposes. Good point. Then one possibility is to allow to force an argument to be by-name only (I don't see a strong reason to allow to force an argument to be by-position only, except maybe to avoid bad proc-call habits, but not even sure). Another reason is that the keyword arguments restrict the syntax somewhat, so, when a mistaken extraneous sexp is where we'd expect a keyword, it is flagged as an error, rather than be considered a positional argument. Related to the previous reason, if the programmer is *intentionally* intermixing keyword arguments with positionals, such as (foo 37 #:x 41 74 #:a 34), that seems error-like that I wish they would get an error and change their ways. I agree, although less strongly than for the above point. I wouldn't mind to force calls to take positional arguments first, and have no more positional arguments after the first keyword. (it actually seems to be easier to implement this way too.) Though note that currently Racket does allow things like that: (define (foo y #:x x ) (list x y)) (foo #:x 3 1) ; - '(3 1) Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] version 5.3.5 release, ready for testing
Here is some feedback. I did not read the book, so please ignore whatever is meaningless. Tested on (uname -a): Linux UX31A 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Ubuntu 13.04 Drracket starts, no problem. Games could run without major problem. Just some typos and minor comments: chapter2/source.rkt and chapter5/source.rkt : you uessed it. - guessed Chapter 5: guess game: quit with q does not close the frame (maybe normal?) and has the same behavior as =. ufo: The ufo crashes in the bottom of the frame. May be better if it lands properly? Check-syntax is activated, but does not handle non-pure text files, and thus displays an error message. Might be confusing for a beginner? Chapter 6: source.rkt: qiuckly - quickly BUG? -- to be removed? Chapter 8: n does not start a new game Otherwise, looks like a lot of fun! I wish my teachers had used RoR for teaching us PLT Scheme ;) If anyone likes to play Dice of Doom, it has an improved version to which many hours of my PhD studentship got lost: http://www.gamedesign.jp/flash/dice/dice.html Laurent On Mon, Jun 17, 2013 at 2:41 AM, Matthias Felleisen matth...@ccs.neu.eduwrote: A candidate release v5.3.5 is ready for testing at http://pre.racket-lang.org/5.3.5/ I have downloaded, installed, and played with the bundle on Mac OS X 10.8 w/o a hitch. Could I ask for volunteers to check the bundle on Windows, older Macs, and *nix boxes? Timeline: We'd like to release tomorrow or Tuesday. Thanks -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
Actually I realize I'd like something exactly like `instantiate'. If instantiate used keywords instead of bindings, and removing the `instantiate' word, we would then even have the exact same syntax for class instantiation and procedure call: (define nemo (fish% Nemo #:age 3)) ; instantiates `fish%' Of course this could be extended to structs. This would harmonize different calling mechanisms, as well as being more flexible. Wouldn't that be nice? Laurent On Fri, Jun 7, 2013 at 8:12 AM, Laurent laurent.ors...@gmail.com wrote: On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: I've always wondered why the syntax of keywords implied two elements: the #:keyword and the identifier. I find that quite heavy for procedure headers, and most of the time I use the same symbol for the identifier and the keyword (and when I don't it's because I'm simply lazy and use a shorter identifier). Is there a rationale somewhere for that? The rationale is to make function definitions have the same shape as function calls. I see what you mean, though I wouldn't make a strong case of it (maybe I'm missing something). From time to time, I really feel frustrated by the current function header style. What I'd really like, for the sake of flexibility / ease of use, is to have no explicit keyword argument, but all arguments are implicit ones, so that you can call a function by mixing by position and by name as you like, without having specified so in the function's header. (Visual Basic[1] and Python[2] do something along these lines.) For example: (define (foo x y [z 3] [t 4]) ) (foo 1 2 5) (foo #:z 5 #:y 1 #:x 2) (foo 1 #:t 6 #:y 3) (foo #:x 3) Error: missing mandatory argument `y' (apply/kw f 2 #:y 3 '(5) '((t . 3))) In particular, one would then not have to worry about the order of the optional arguments in the function definition. Headers would be also smaller, easier to read, and easier to write. Pushing a bit further: (define (foo x y . rest) ) would not accept keywords different from #:x and #:y, but (define (foo x y . rest-by-pos . rest-by-name) ) would receive a list of positional argument values, and a dictionary of names and values, even if these names are not x or y. Laurent [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx [2] http://www.diveintopython.net/power_of_introspection/optional_arguments.html _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.
FWIW, I like the Alt-Arrows keybindings of DrRacket for moving around s-exp, but they can probably be improved. For example, Alt-Up goes up one level, and Alt-Shift-Up selects from the cursor's position to the left paren. It would probably be better if it selected the whole surrounding s-exp. If you haven't seen it yet, you can also activate Edit/Racket/Automatically adjust closing parentheses. The new behavior of the double-quotes with this is great too (and goes slightly beyond paredit, IIUC). Laurent On Sat, Jun 8, 2013 at 8:36 PM, Mayank Jain firesof...@gmail.com wrote: Hi, I am participating in Lisp in Summer Project[0]. Recently I stated doing this course on coursera[1], and I realized that there is no equivalent of paredit[2] mode in DrRacket (atleast I couldn't find anything of that sort). And I was wondering if I could work on porting it. Can anyone guide me into what is possible? What I should be looking at etc? I am a noob in Clojure and have basic familiarity with Emacs. I love paredit[3], and I find that very crucial to using lisp dialects and I found it very hard to work without it in DrRacket. So was wondering about this idea. Any feedback, suggestions, criticism etc would be great. Thanks, Mayank. [0] : http://lispinsummerprojects.org/ [1] : https://class.coursera.org/programdesign-001/ [2] : https://github.com/emacsmirror/paredit [3] : *http://emacsrocks.com/e14.html* _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Keywords
On Fri, Jun 7, 2013 at 1:42 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 9 May 2013 16:22:54 +0200, Laurent wrote: I've always wondered why the syntax of keywords implied two elements: the #:keyword and the identifier. I find that quite heavy for procedure headers, and most of the time I use the same symbol for the identifier and the keyword (and when I don't it's because I'm simply lazy and use a shorter identifier). Is there a rationale somewhere for that? The rationale is to make function definitions have the same shape as function calls. I see what you mean, though I wouldn't make a strong case of it (maybe I'm missing something). From time to time, I really feel frustrated by the current function header style. What I'd really like, for the sake of flexibility / ease of use, is to have no explicit keyword argument, but all arguments are implicit ones, so that you can call a function by mixing by position and by name as you like, without having specified so in the function's header. (Visual Basic[1] and Python[2] do something along these lines.) For example: (define (foo x y [z 3] [t 4]) ) (foo 1 2 5) (foo #:z 5 #:y 1 #:x 2) (foo 1 #:t 6 #:y 3) (foo #:x 3) Error: missing mandatory argument `y' (apply/kw f 2 #:y 3 '(5) '((t . 3))) In particular, one would then not have to worry about the order of the optional arguments in the function definition. Headers would be also smaller, easier to read, and easier to write. Pushing a bit further: (define (foo x y . rest) ) would not accept keywords different from #:x and #:y, but (define (foo x y . rest-by-pos . rest-by-name) ) would receive a list of positional argument values, and a dictionary of names and values, even if these names are not x or y. Laurent [1] http://msdn.microsoft.com/en-us/library/51wfzyw0.aspx [2] http://www.diveintopython.net/power_of_introspection/optional_arguments.html _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Great! Thank you very much. On Wed, Jun 5, 2013 at 11:04 PM, Matthew Flatt mfl...@cs.utah.edu wrote: More generally, I hope I haven't come across as being firmly opposed to the idea of single-collection packages. I intended to come across as being opposed to implementing the idea myself. :) I wanted to give it a stab, but didn't have much time. Plus you did it way better than I could have done anyway. Some other the details: * A package's mode is recorded in the installed-package table. Otherwise, a linked package could switch modes just because the package directory's content changes, which would be difficult to keep in sync with the low-level table of links. Does it handle the case where user A installs B's single-collection package, and at some point B changes its package to a multi-collection package, triggering the updating of A's installation? As Jay pointed out to me, putting the collection name in the info.rkt file --- instead of using the package name as the collection name --- makes the package content work the same even when the package is renamed. Otherwise, you have to know whether the package is single-collection or multi-collection to know whether changing the package's name changes its content. It's debatable whether single-collection or multi-collection would be a better default, but I favor multi-collection mode. What I'd like is to have single-collection being the default so that the average Joe can even not care about including a info.rkt file, and expect the collection's name to be just the directory's name. Less burden on the user - more packages. I believe most users will not even (try to) understand the concept of multi- collection packages. To them a package is just a bunch of source files and that's all. Then to create a simple package, Joe only has to create a directory, put his my-file.rkt in it, and he's done! If at some point Joe thinks about having a different name for his package and for his collection, it should be intuitive to him that he should say so somewhere (i.e. in the info.rkt file). So here is a demo patch attached to precise what I mean (without test, would have taken me way too much time). Because it considers that single-collections are the default, it is backward incompatible. If info.rkt exists, it looks for 'multi-collection, and otherwise looks for the 'collection-name string. If info.rkt does not exist, it creates it and gives the 'collection-name the name of the package by default. (This of course fails if the directory is read-only, but since it's just a useful default it should not be a problem. This should at least work for all downloaded archives.) Laurent lib.rkt.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
If info.rkt does not exist, it creates it and gives the 'collection-name the name of the package by default. That doesn't seem like a good idea to me. As you've noted, there can be problems with writing extra files. The collection name could be instead computed in `pkg-single-collection', which would treat the absence of an info.rkt to mean single-collection mode, right? Some calls to `pkg-single-collection' would need to change to pass in a package name to use instead of the `dir' name, since the `dir' argument is sometimes a temporary directory that is used to stage a package. That's an easy change. If the original package/directory name can be retrieved at any time, then yes, it's a much better idea (actually I had started this way, but didn't know how to retrieve the name at any time). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt mfl...@cs.utah.edu wrote: What I'd like is to have single-collection being the default [...] So here is a demo patch attached to precise what I mean (without test, would have taken me way too much time). Because it considers that single-collections are the default, it is backward incompatible. If info.rkt exists, it looks for 'multi-collection, and otherwise looks for the 'collection-name string. I could go along with this, as long as (most?) everyone agrees, and as long as package authors are willing to update existing packages. I am *very* strongly in favor of this -- I'd rather have single-collection packages than multi-collection packages, if forced to choose. I'm very glad that you and Laurent have done the work here. The main problem with this is that it brings in internal linking where code directly refers to other packages (implementations) and not modules (interfaces) as the default. This means we will see code like (require jays-awesome-data-structure) rather than (require data/awesome). I think this is bad because it makes it harder to deal with forking, maintainers abandoning their code, splitting packages into packages that just depend on 'jays-awesome-data-structure, rather than implementing it internally, etc. Obviously you can still deal with those things, but if the path of evolution we imagine starts off with single-package-with-package/collection-name-shared, then most packaged collections will have a package as their name. Ok, I see your point. Let me try to make a use case here: User A writes package P on Github at A/P. A creates a PLaneT package also named P. User B forks P to B/P. Since the package name P is already taken, you expect B to name his package B-P. (But I think you make this point sufficiently clear in the docs that this should be very seldom.) So on installation, you have a collection name B-P, which is bad, because you cannot replace A's P directly by B's P, simply by uninstalling A's and installing B's. Now, the thing is you'd like B's collection to be name P also, right? (which means only one could be installed at the same time, otherwise we get back to the same problem, whatever the option we choose.) Now if we really want to have P as the default collection name for B's P, we could also probably use B's Github repo name. Is it retrievable from the downloaded package? We would then use this if available, or the package/directory name otherwise (I guess non-repo installations will be rare anyway). But then people would still write $ raco pkg install jay-awesome-package but would then need to write (require awesome) which is, in most cases, quite counter-intuitive: you'd need to state it clearly in the docs of the package, but you would still have dyslexic users asking why it doesn't work (like I have with you, btw, with slideshow-latex). And this will probably occur much more often than the case above, because you have many more users of packages than developers, and the default should be intuitive for the largest part. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Fwd: PLaneT(2): Single vs multi-collection packages
(post back to the mailing list...) On Thu, Jun 6, 2013 at 9:02 PM, Jay McCarthy jay.mccar...@gmail.comwrote: My goal is to have a large xrefed documentation site of all ring-0 packages (we are close to this) so you can look up awesome or slideshow-latex and then require it and have racket/DrRacket give you a pop up that says, Do you want to install package blah to get this? (I believe DrRacket does this now and we have xrepl that does it too). Since ring-0 guarantees no conflicts, there is always a unique answer to the require-package question. (Btw, that sounds like a nice feature! I'd just worry a little about the size of the docs though, but then maybe you plan to have the docs can stay online?) In other words, my goal is to have only package authors ever concerned with (a) their package names and (b) which package they are even getting their modules from. UNLESS, you want to use ring-1 (untested) or ring-2 (conflicting) packages---since using those rings is inconvenient, it is incentivizes authors to remove conflicts and test their code to get to ring-0. (In other words, I don't want any ring-1 or 2 packages.) I'm not sure how that poses problems with the use case above, but then in ring-0, you could easily ask for packages to be correctly named? I believe if you want to write a package of this quality, you should take time to name it correctly, and adding one line in the info.rkt file is no big deal (if ever really needed, which I expect to be rare). I don't really expect programmers of ring-0 to have bad habits, my main concern is with all the others, who certainly don't want to spend a lot of time understanding what to do to make a package. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Mon, Jun 3, 2013 at 7:36 PM, Matthew Flatt mfl...@cs.utah.edu wrote: The simplification of not handling links also seems like a big weakness to me. I think one of the best things about Jay's design is that I don't have to change the way I think about a package when moving between link and non-link modes (which makes it much easier to work with a GitHub repository, for example). I particularly encourage you to think about what should happen when a user needs to transition a GitHub repo from a representing a single-collection package to a multiple-collection package --- and how that interacts with links as well as non-link, GitHub-based installations of the package. Actually I use collection links instead of package links for my single-collection packages, which are Github clones. It kind of makes sense. (One more homogeneous possibility would be to add a `raco pkg install --link-single my-collect/package` command that is just a synonym for `raco link my-collect/package`. Actually I would much prefer to have `raco pkg install --link` work like `raco link` and have an additional `raco pkg install --link-multi` command instead.) As Greg suggested, the single-collection package would have only one info.rkt file (which is simpler for the user[*]), and would contain both the info for the package and for the collection. As they seem to have mutually-exclusive information, it should be ok. (But one would have to be sure that this will remain the case in the future but I think it should hold. I think it should be ok too, see at the bottom of the email.) E.g., dependencies of a single collection fit well in the collection's info.rkt I think (meaning these are the dependencies of the collection). When installing the package with 'dir, the collection gets its own subdir, and the info.rkt file just needs to be copied in the package directory. When changing from a single-collection to a multi-collection package, you'd have to do (I think): - collect-unlink the current package, - move the collection to a subdirectory (along with the info.rkt file), - create a info.rkt file in the package root, and move the parts of the collection's info.rkt that are package-specific to this new file, - package-link the new package. Since I don't expect people (other than the Racket dev) to do that often (or even at all for most of them), I don't see that's a problem (it's not even a big deal). When someone wants to do that, it means he already has some good knowledge about collections and packages (since he wants to build a multi-collection package), and thus it should not be a problem either. You could generalize the principle: - When all you need is a file, just use a file. It should have all the necessary information (i.e., why not have a 'info' submodule? E.g. to deal with dependencies) - If you need several files, create a folder, put your files in there, and add a collection-specific file (info.rkt) - if you need several collections (a package), create a new folder, put your collections in there, add a file that is specific to the collection of collections (the package) - if you need several packages (a repository?), create a new folder, put your packages in there, etc. - etc. The info.rkt files that are closer to the root are more general, and more specific info.rkt files should have precedence in case there is a conflict (like in CSS for example). I expect the first two cases to be overwhelmingly dominant, and thus they should be easier to achieve. Laurent [*] I think a good tool is one that asks for Minimum User Effort, and if the user wants to do something simple, it should be simple to achieve. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@barzilay.org wrote: To clarify, because of reasons that I won't go into on the list, the actual chances of me getting this implemented (and of such a change being accepted) are pretty much in the area of slim to none. That's a bummer. At first sight I'd have thought that it would have just been a matter of creating a directory with the same name as the package, and then decompressing the package into that directory. At the lower level, packages use links, and raco link's default mode of work is at the collection level. There is obviously a need for packages that correspond to collection roots, but I wanted to see the default being the same as the raco-link default (which fits most uses that don't come out of the current main tree). Not sure I was clear, or I don't exactly understand what you mean. And maybe I'm missing some important point here. But the more I think about it, the less I see why this double-directory thing should be the default behavior of the new package system (I can understand why it's useful for plt packages though). Even Carl's mischief package doesn't make use of collections like that. Jen's this-and-that does, though, but then every collection of his package must have a name that is different from any existing collection. (And actually I think that's a bad idea, and that he should split his package into several single-collection packages −unless they are tightly related− because I don't want to install all his collections if I want to only try one of them, unless there is a way to install only one collection of an existing package?) For example, my personal racket project tree is arranged somewhat like that: racket ├── project-B │ └── main.rkt ├── project-A │ └── main.rkt ├── not-yet(?)a-project-C ├── my-collects │ ├── slideshow │ ├── scribble │ ├── racket │ └── data └── misc ├── try-this.rkt └── try-that.rkt project-A and project-B are git clones. my-collects contains all my extensions to racket's collections, plus some more generally useful collections. For my personal use, I just do: raco link project-A project-B my-collects and all is fine. I tend to believe it's a quite common tree for racket users. In my-collects, I have names that would collide with racket's collections, so instead of having: (require orseau/racket/slideshow) as in the former package system, I would now have (require some-funny-name/slideshow) after renaming my-collects to some-funny-name to make sure it does not collide with anything else. ... and since I don't want to invent a funny name for each extension of a racket collection I do, I prefer to put them all in a single package and collection. Now if I were to follow the new package system, I'd need to change my tree to: racket ├── misc │ ├── try-that.rkt │ └── try-this.rkt ├── some-funny-name │ └── some-funny-name │ ├── data │ ├── racket │ ├── scribble │ └── slideshow ├── not-yet(?)a-project-D ├── project-A │ └── project-A │ └── main.rkt └── project-B └── project-B └── main.rkt which is a mess. And I would also need to change my git repos to match that structure, which looks awkward. /But/ I don't care if the tree of the packages I *install* look like that. So what I would like is to keep my tree like the first one, but the package system can still install like the second one. My proposal was that for single-collection packages, I could keep my tree like the first one, my git clones like project-A/main.rkt, and tell the package manager (probably in the info.rkt file) that it is a single-collection package so that when it installs it in the installed-package-directory-that-I-will-not-look-into it generates a tree like the second one. Well, the reason I think that plain collection packages are important is it will simplify dealing with packages, and lower the investment threshold that you need to publish a package. Along the same line, there should also be a way to put out just a single file (or very few) as a first step where I make some code public but with absolutely minimum effort on the publisher's side. See for example the Processing thread, where Sean said that people who do these kind of thing don't even know what source control is, let alone packages -- so the existence of such a crowd is a perfect reason for a single-file thing being another important point on the code distribution spectrum. I entirely agree with that, and I think it is of utmost importance for a programming language (and system) to make sure that its users can easily share code. Probably all of you agree with that, but I want to emphasize that it's really important to put as much effort as required into that. Don't get me wrong, I really like the steps forward taken with the new direction
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Here is a patch for a proof of concept (file /collects/pkg/lib.rkt). The modifications are minimal as I had expected, but obviously I only have a very narrow view of the package system, so probably something does not work properly. In particular, I changed only for the 'dir type, and did not touch the 'link type. Since the 'github type and others use the 'dir type once the archive is downloaded, I think it should work as expected for those too. I've tested on an old 5.3.4.10--2013-05-13(96acfb0/a) [3m], but made the patch with the latest in git, and it still works with the old version. (I was about to test it with the latest nightly, but its installation failed, see the mailing list) To try it, in the collects/pkg directory: $ patch lib.rkt lib.rkt.patch $ sudo raco setup -D pkg Then create a dummy package: $ cd /tmp $ mkdir dummy $ echo '#lang racket\n(displayln It works!)' dummy/main.rkt $ touch dummy/single-collect The file single-collect is here to signal that this package is a single-collection package (it's not the right way to do it, but it's a proof of concept). Install the package: $ raco pkg install -t dir dummy (You should see This is a single-collection package as the first line of the log) Then try it: $ racket (require dummy) It works! Or is this patch way too naive for some reason? Laurent On Mon, Jun 3, 2013 at 4:37 PM, Eli Barzilay e...@barzilay.org wrote: (I completely agree with you, so I'll take it off-line.) 30 minutes ago, Laurent wrote: On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@barzilay.org wrote: To clarify, because of reasons that I won't go into on the list, the actual chances of me getting this implemented (and of such a change being accepted) are pretty much in the area of slim to none. That's a bummer. At first sight I'd have thought that it would have just been a matter of creating a directory with the same name as the package, and then decompressing the package into that directory. At the lower level, packages use links, and raco link's default mode of work is at the collection level. There is obviously a need for packages that correspond to collection roots, but I wanted to see the default being the same as the raco-link default (which fits most uses that don't come out of the current main tree). Not sure I was clear, or I don't exactly understand what you mean. And maybe I'm missing some important point here. But the more I think about it, the less I see why this double-directory thing should be the default behavior of the new package system (I can understand why it's useful for plt packages though). Even Carl's mischief package doesn't make use of collections like that. Jen's this-and-that does, though, but then every collection of his package must have a name that is different from any existing collection. (And actually I think that's a bad idea, and that he should split his package into several single-collection packages −unless they are tightly related− because I don't want to install all his collections if I want to only try one of them, unless there is a way to install only one collection of an existing package?) For example, my personal racket project tree is arranged somewhat like that: racket ├── project-B │ └── main.rkt ├── project-A │ └── main.rkt ├── not-yet(?)a-project-C ├── my-collects │ ├── slideshow │ ├── scribble │ ├── racket │ └── data └── misc ├── try-this.rkt └── try-that.rkt project-A and project-B are git clones. my-collects contains all my extensions to racket's collections, plus some more generally useful collections. For my personal use, I just do: raco link project-A project-B my-collects and all is fine. I tend to believe it's a quite common tree for racket users. In my-collects, I have names that would collide with racket's collections, so instead of having: (require orseau/racket/slideshow) as in the former package system, I would now have (require some-funny-name/slideshow) after renaming my-collects to some-funny-name to make sure it does not collide with anything else. ... and since I don't want to invent a funny name for each extension of a racket collection I do, I prefer to put them all in a single package and collection. Now if I were to follow the new package system, I'd need to change my tree to: racket ├── misc │ ├── try-that.rkt │ └── try-this.rkt ├── some-funny-name │ └── some-funny-name │ ├── data │ ├── racket │ ├── scribble │ └── slideshow ├── not-yet(?)a-project-D ├── project-A │ └── project-A │ └── main.rkt └── project-B └── project-B └── main.rkt which
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Ah, that's cool. Looking forward to it! And the in-url thing would be useful indeed for gists for example. Laurent On Thu, May 30, 2013 at 8:32 PM, Eli Barzilay e...@barzilay.org wrote: Yes, I really want to try and get to look into doing this. The thing is that multi-collection libraries are going to be a common case for plt packages (which will get pulled out from the main repository), but the single-collection ones are going to be the much more popular case elsewhere. (And I also still dream on doing some `url-in' to require a single file, since that's also an important mode of quick sharing. But that's another story.) 10 minutes ago, Jay McCarthy wrote: The Racket package system doesn't support packages that aren't collection roots. Eli has said that he wants to implement such a feature, but it is not available today. Jay On Thu, May 30, 2013 at 8:29 AM, Laurent laurent.ors...@gmail.com wrote: I'm willing to upgrade my packages for the new PLaneT system, but one thing that pushes me back is the fact that I need to create a directory for my package and a subdirectory for the collection(s). But most of my packages are (and will probably be) single-collection packages, and it hurts my logic to have to modify my directory tree for that purpose. I know there have been several discussions already about this, but perhaps there is a simple fix: Maybe there could be a `single-collection?' entry in the info.rkt file which, when true, would tell `raco pkg install' to create itself a directory for the package that has the same name as the collection it contains? -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@barzilay.org wrote: To clarify, because of reasons that I won't go into on the list, the actual chances of me getting this implemented (and of such a change being accepted) are pretty much in the area of slim to none. That's a bummer. At first sight I'd have thought that it would have just been a matter of creating a directory with the same name as the package, and then decompressing the package into that directory. But I guess things are always way more complicated than at first sight... TBH, the chances of implementing an `in-url' are low too, but they're probably higher than going into the package system. That would be nice, but I'd much much prefer to see the single-collection package thing implemented. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] PLaneT(2): Single vs multi-collection packages
I'm willing to upgrade my packages for the new PLaneT system, but one thing that pushes me back is the fact that I need to create a directory for my package and a subdirectory for the collection(s). But most of my packages are (and will probably be) single-collection packages, and it hurts my logic to have to modify my directory tree for that purpose. I know there have been several discussions already about this, but perhaps there is a simple fix: Maybe there could be a `single-collection?' entry in the info.rkt file which, when true, would tell `raco pkg install' to create itself a directory for the package that has the same name as the collection it contains? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [racket] Parens/string quotes automatic behavior
+1 indeed, that way you can follow easily with typing a paren, thus enclosing it again. Laurent Le 23 mai 2013 17:17, John Clements cleme...@brinckerhoff.org a écrit : On May 23, 2013, at 8:13 AM, Robby Findler wrote: On Thursday, May 23, 2013, Nadeem Abdul Hamid wrote: Hello Racket devs, I'm working on tweaking how typing a double quote is handled in strings when DrRacket's auto parens mode is on, per recent post on the users list. If any of you use the mode and can offer feedback on the following, it'd be appreciated: In addition to handling Laurent's initial feature request (see message at bottom), I'm setting it up so that if the following string is in the DrRacket window: abcdefghi and you select the _def_ and press (double quote), then it places double-quotes around the def with additional quotes to ensure that the other two portions of the string are still validly delimited, i.e. abcdefghi One question is where to put the cursor following this operation? Should it be right inside the beginning of the lifted string, or in front of its double quotes, i.e.: abc|defghi or abc|defghi ? Oh: another possibility: keep the selection where it is (or, perhaps better, select the open quote, the def, and the close quote). +1 John _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
As a generalization, maybe Racket2 could keep the invariant `#:else' is
the absorbing (default) case of any multi-arm form ?
On Sun, May 5, 2013 at 4:30 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
More generally, the role of `else' in `cond' is to select a particular
production in the grammar of `cond' clauses, and keywords are normally
the right way to do that in Racket. Keywords are normally right because
they are syntactically distinct from expressions --- and so using a
keyword avoids various potential ambiguities and sources of confusion.
At Sat, 4 May 2013 10:36:14 -0500, Robby Findler wrote:
I think the bad property is the shadowing of the else identifier and
Matthew's point is that one way to avoid that is to not use an identifier
at all.
The racket2 wiki currently says try this out so I guess it isn't
something people believe will definitely be better, but something to
explore.
Robby
On Sat, May 4, 2013 at 10:33 AM, Laurent laurent.ors...@gmail.com
wrote:
(that was assuming Ryan's assertion that [...]Matthew say that he
would
have used a keyword for `else` in `cond` if he had it to do over
again,
which seem to mean that even in Racket2 Matthew would prefer `#:else'
over
`[else ...]' ?)
On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com
wrote:
Matthew,
Out of curiosity, could you explain why you'd prefer #:else everywhere
instead of [else ...] ?
Would such an #:else allow for multi-line bodies?
On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu
wrote:
At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote:
On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu
wrote:
At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote:
A few minutes ago, Robby Findler wrote:
FWIW, this was the bug in redex that prompted me to send this
message (it was there for some time since it wasn't a syntax
error
it was similar in spirit to the code I posted; things
broke
when #f was an argument)
[I think that it's good to have a much more relaxed policy
about
breaking compatibility in cases like this: so far there was no
real
code found that uses the feature, but there is one instance of
code
that would get fixed by the change...]
Well, Ian provided an example from real code, right? Ian is
willing
to
change his code, but the code sounds real.
There's also the use in `unparse-pattern' in Redex. Maybe that's
the
troublesome one that Robby has in mind changing (or he would be
happy
to change it, obviously), but it's another real example.
No, that was not the example. The code I sent at the beginning of
the
thread was an adjusted version of the bug that hid in Redex for,
roughly,
months. It was a real bug and caused real problems and we knew
something
was wrong but didn't find it for some time.
In other words, this isn't some made-up, code cleanliness-based
request.
Yes, I understand that you faced a real bug. I hedged above on
`unparse-pattern' not to suggest that your actual bug was
uninteresting, but to suggest that I might misunderstand the
relationship between the bug and the current state of our repository.
All else being equal, I'm definitely in favor of a change to a
sensible
`else' for `match'. The else that isn't equal, however, is backward
compatibility, and I think we're at the right point in our
development
cycle to defer backward incompatibilities to the next language ---
hence my vote to defer.
_
Racket Developers list:
http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Racket2 suggestion: Attaching properties to operators
Speaking of invariants, from time to time I would like Racket to know some properties about its usual operators, so that some usual treatments get simplified and can be easily generalized. For example, considering group theory, properties like 'identity-element', 'absorbing-elements', 'inverse-operator', 'commutative?', 'associative?' and such could be attached to operators like `+', `*', `max', `string-append', `hc-append', etc. Forms like `for/op' could use this information to know how to loop and accumulate, and even possibly to optimize the code, even for newly created operators. In the simple case of + and such, one also only needs to define the binary operator, and the multi-argument procedure can be generated automatically. Of course it needs not be tied to group/category/mathematical theory. It can be about whatever is useful. It's only an idea, in case this resonates for someone. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
Each existing properties can come with a batch of generic test to test some usual corner cases, to check that property holds. It would indeed be easier if some elements of the domain/range could be given (or an automatic generator). Random testing would be good, but I don't think it's necessary to impose this constraint to have good assurance that the operator is well defined. Do you know why C++ has stopped pursuing this idea by any chance? On Sun, May 5, 2013 at 6:58 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 5, 2013, at 12:51 PM, Laurent wrote: On Sun, May 5, 2013 at 6:44 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: C++ has tried this tack for some time. Sounds like it has failed then. I can see doing for built-ins but how would you go about programmer-created operations? Trust the programmer? -- Matthias Well, I guess some checks can be added, but I don't see the difference between attaching bad properties to a newly created operator and defining a buggy procedure. I think it is one thing to say (define (fahrenheit-celsius f) 32) and another to attach associative to the floating-point + operator. Since we all write examples first and translate then into test suites before we code, finding a bug in fahrenheit-celsius is straightforward and supported by our support mechanisms. If you don't trust your tests, attach contracts to your procedures because they generalize tests in a natural way. Finding bugs in false claims about functions is much less supported at the moment. Perhaps random testing or model checking or something like that may help along here. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket2 suggestion: Attaching properties to operators
Would you happen to have a reference on that? On Sun, May 5, 2013 at 7:15 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 5, 2013, at 1:12 PM, Laurent wrote: Do you know why C++ has stopped pursuing this idea by any chance? No, and they may have more work going on besides standard work. It's worth reading up on it if you're interested. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
(that was assuming Ryan's assertion that [...]Matthew say that he would have used a keyword for `else` in `cond` if he had it to do over again, which seem to mean that even in Racket2 Matthew would prefer `#:else' over `[else ...]' ?) On Sat, May 4, 2013 at 5:14 PM, Laurent laurent.ors...@gmail.com wrote: Matthew, Out of curiosity, could you explain why you'd prefer #:else everywhere instead of [else ...] ? Would such an #:else allow for multi-line bodies? On Sat, May 4, 2013 at 5:06 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sat, 4 May 2013 09:15:22 -0500, Robby Findler wrote: On Sat, May 4, 2013 at 9:07 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Fri, 3 May 2013 17:29:52 -0400, Eli Barzilay wrote: A few minutes ago, Robby Findler wrote: FWIW, this was the bug in redex that prompted me to send this message (it was there for some time since it wasn't a syntax error it was similar in spirit to the code I posted; things broke when #f was an argument) [I think that it's good to have a much more relaxed policy about breaking compatibility in cases like this: so far there was no real code found that uses the feature, but there is one instance of code that would get fixed by the change...] Well, Ian provided an example from real code, right? Ian is willing to change his code, but the code sounds real. There's also the use in `unparse-pattern' in Redex. Maybe that's the troublesome one that Robby has in mind changing (or he would be happy to change it, obviously), but it's another real example. No, that was not the example. The code I sent at the beginning of the thread was an adjusted version of the bug that hid in Redex for, roughly, months. It was a real bug and caused real problems and we knew something was wrong but didn't find it for some time. In other words, this isn't some made-up, code cleanliness-based request. Yes, I understand that you faced a real bug. I hedged above on `unparse-pattern' not to suggest that your actual bug was uninteresting, but to suggest that I might misunderstand the relationship between the bug and the current state of our repository. All else being equal, I'm definitely in favor of a change to a sensible `else' for `match'. The else that isn't equal, however, is backward compatibility, and I think we're at the right point in our development cycle to defer backward incompatibilities to the next language --- hence my vote to defer. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
That one is twisted indeed, if you forget about how `else' must be written in `match' (which I had, not using match too much). I was thinking about issuing a warning when a syntax-parameter gets shadowed (if that is even catchable). Then suddenly I realized Racket doesn't do warnings. (Is there a reason for that?) Laurent On Fri, May 3, 2013 at 3:39 PM, Robby Findler ro...@eecs.northwestern.eduwrote: [ for those that just want to see what I'm getting at, scroll to the end ] While the docs are clear (enough) on this point, I think it can be quite confusing. See if you spot the bug in this program: #lang racket (define (find-literals e) (define literals '()) (let loop ([e e]) (match e [`(λ (,x) ,e) (loop e)] [`(,e1 ,e2) (loop e1) (loop e2)] [(? symbol?) (void)] [else (cond [(member e literals) (void)] [else (set! literals (cons e literals))])])) literals) (module+ test (require rackunit) (check-equal? (find-literals '(λ (x) x)) '()) (check-equal? (find-literals '((λ (x) x) 1)) '(1)) (check-equal? (find-literals '((λ (x) x) #f)) '(#f))) Hint: the last test case fails. Second hint: if you switch it to use sets, it starts working. Third hint: this isn't about lists. :) The bug is that 'else' is treated as a variable in match, so it gets bound to #f, which shadows the else in the cond which is confusing. So, how about making match treat else specially? I don't ask this completely from outer space; there was a bug in Redex's random generation that was caused exactly by this shadowing of else. Robby _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] else clauses: possible change to match?
On Fri, May 3, 2013 at 4:22 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I don't like warnings that are basically admitting weaknesses in the language design Ah, that's the answer my subconscious was seeking when I wondered about Racket warnings. Good point! FWIW, I'd vote (with my voting weight being around the epsilons) for a change in else/match too, as I hardly see someone binding else in match intentionally, and hoping to get away with it. At best, some old buggy programs will magically start working ;) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] take, drop, split-at, etc -- and argument order, again
Just a side question: Would it be a bad idea to make a separate library that uses the normal names without f, so that people can write #lang racket (require racket/flist) ? or even use `prefix-in' if they prefer? Laurent On Sat, Mar 9, 2013 at 4:28 PM, Eli Barzilay e...@barzilay.org wrote: Two days ago, Asumu Takikawa wrote: We were considering the following set of names: takef, dropf, takef-right, dropf-right, splitf, splitf-right I did most of this, and there are three important comments: 1. Name: `splitf' is not right, since it's missing the -at. I eventually went with `splitf-at' (since adding the `f' at the end makes it unreadable). 2. Argument order: I think that it is important to be able to switch from (for example) `take' to `takef' and the index by a predicate. For this analogy to work, the order of arguments needs to be the same for both. Given that `take' etc already exist, it's the new functions that need to change. This is unfortunate: 0. It goes against `take' in Haskell and in lazy (not new). 1. Clojure joins that other party. 2. It also goes against `member' and `find' where the list is the second argument, so the f similarity between `findf' and `takef' can be confusing. Personally, I think that this has been a PITA for such a long time and I'd prefer seeing `take' etc change to join the winning party. I think that srfi-1 made a mistake, not just that it chose the path that ended up being unpopular, because it made an inconsistent choice with other functionality that it provides. Regardless of this, if it's uniform interface vs good order, I prefer going with the uniform interface and the existing bad order. So I think that I should switch the order, protest myself silently, and continue. 3. `takef-right' etc. I started implementing these, but maybe they shouldn't. The following explanation is probably only for people who are interested in what gets added (ie, Asumu), or maybe if you like a dead-end puzzle. For the others, it's probably enough to note that there are no such things in drfi-1/clojure/etc that I see. Here's why I think it might be useless: For just `takef-right', it's possible to do something smart that scans the list in order, keeping a pointer to the beginning of the current good block. This avoids a double scan *but* the payment is in applying the predicate on all emlements. There might be a point in that in some cases, but probably in most cases it's best to apply it in reverse order, get the index, then do the usual thing. That's mildly useful in a completely unexciting way, but when it gets to the other *f-right functions, it gets worse in that the first approach won't work. So for all of these, the best that I see is: reverse the list[*], look for the place where the predicate flips to #f, then use one of the non-f from-right functions to do the work. So they're all just a little bit better than a reverese + non-f + reverse combination. ([*] Not a strict reverse, to make these functions work with improper lists -- which is in-line with other questionable srfi-1 inheritance.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Floating-Point Compliance Testing
On Fri, Feb 8, 2013 at 7:53 PM, Tobias Hammer tobias.ham...@dlr.de wrote: Tested it too and got an interesting result. On a 32bit linux its: +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 +nan.0 That's what I get too. And indeed my other machine was a 64bits Ubuntu and Racket. Laurent so, completely wrong. But on a 64bit Linux its correct if i use the 64bit racket version. When i try the 32bit build i get the wrong results again. I think you can blame it on 32 implementation of racket/libc/compiler or whatever. Not on the actual cpu in use because the hardware was always the same (2 identical computers, identical OS + version, only 32bit in one, 64 in the other). Tobias On Fri, 08 Feb 2013 19:07:53 +0100, Neil Toronto neil.toro...@gmail.com wrote: Back on list. A lot of things point to general sloppiness in either the FPU or C libraries, but I'd like more information just in case. Can you reply with the values of the following expressions on the Athlon? (flexpt -1001.0 -1.3407807929942596e+154) (flexpt -1001.0 1.3407807929942596e+154) (flexpt -0.1 -1.3407807929942596e+154) (flexpt -0.1 1.3407807929942596e+154) (flexpt -744.4400719213812 -1.3407807929942596e+154) (flexpt -744.4400719213812 1.3407807929942596e+154) (flexpt -1.0 -1.3407807929942596e+154) (flexpt -1.0 1.3407807929942596e+154) You should get these values: 0.0 +inf.0 +inf.0 0.0 0.0 +inf.0 1.0 1.0 I think these are cases Racket handles specially instead of handing off to C's `pow' on platforms where we know `pow' handles them wrongly. We might need to ask Matthew to expand that set of platforms. Small rounding errors like this: ((fl*/error -6.87181640380727e-156 2.3341566035927725e-153) 0.7079979032237692) which are only 1 bit off, are probably the cause of these errors: ((fl2log 1.5124390004859715e-308 0.0) 4294967296.220986) ((fl2log1p 3.799205740343036e+246 1.4492752004468653e+230) 549755813887.9473)) `fl2log' and `fl2log1p' are 103-ish-bit logarithm implementations used in certain tricky subdomains of a few special functions. They assume arithmetic is always correct and are very sensitive to rounding errors. You're getting about 65-bit output precision for certain inputs. We can almost certainly blame the FPU because IEEE 754 requires arithmetic to be implemented and correctly rounded. IEEE 754 only *recommends* typical irrational functions. When they're not implemented in hardware, C libraries compute them in software. So I don't know whether these and others are the FPU's or C library's fault: ((flsin 2.5489254492488616e+52) 22637349860729424.0) ((flcos 3.91520018229574e+49) 6369061509154398.0) ((fltan 1.6614020610450763e+21) 9158003261155244.0) ((flexp 16.938769136983012) 7.0) ((flexp 282.52374429474406) 102.0) ((flexp -10.0) 4.0) ((flexp -708.3964185322641) 124.0) These errors come from not doing argument reductions carefully enough. The trigonometric functions probably don't compute x % 2*pi using a high-precision 2*pi when x is large. They seem to be correct enough when x is small, though. The exponential function wasn't tested well at the boundaries of its domain: ((flexp 709.782712893384) +inf.0) 709.782712893384 is (fllog +max.0), and (flexp (fllog +max.0)) should be near +max.0, not (as I suspect) +inf.0. I don't know whether Racket should do anything about these errors. I don't think it would be too hard to do something like Java's StrictMath, but it would take time. In the meantime, don't use the Athlon for serious numerical computation. Neil ⊥ On 02/08/2013 12:13 AM, Laurent wrote: Hi Neil, Interaction in a terminal is attached, using Racket 5.3.2.3. Some details about my machine: Linux 3.2.0-37-generic-pae #58-Ubuntu SMP Thu Jan 24 15:51:02 UTC 2013 i686 athlon i386 GNU/Linux In particular, I use a 32bits Ubuntu 12.04.2 on a 686 processor, if that's of any interest. Cheers, Laurent On Fri, Feb 8, 2013 at 1:15 AM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com** wrote: On 02/07/2013 12:09 PM, Laurent wrote: On Thu, Feb 7, 2013 at 5:50 PM, Neil Toronto neil.toro...@gmail.com mailto:neil.toro...@gmail.com** mailto:neil.toro...@gmail.com mailto:neil.toro...@gmail.com**__ wrote: Today is not that day, but thanks for asking about this anyway. :) On one machine with Ubuntu 12.10, I get no error, but on another machine with Ubuntu 12.04, I get more than 14000 errors, many of them being +inf.0 and other numbers with big exponents (is my machine really that bad?). Is this exactly the kind of reply you want to avoid for now or are you interested in a report? Alrighty, you've piqued my interest. Better send it off-list, though. :) Neil
Re: [racket-dev] Racket learning page videos
Cool! As I hesitate to edit myself, and since I don't see any Discussion page like on Wikipedia, I'll say it here: I think it would be better to reorganize the videos from friendlier to more technical, e.g.: Tutorials and Demos Talks Interviews Research talks More I can of course edit it myself if any PLT member agrees with this. Laurent On Wed, Jan 30, 2013 at 7:12 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Ok, I've started this page: https://github.com/plt/racket/wiki/Videos Please fill in whatever I've missed! (The page already has more on it than I expected to find, so I'm sure I've missed things.) I also updated the web page (needs upload) to point to the videos page. but I didn't yet try to link to key videos. At Tue, 29 Jan 2013 19:09:18 -0600, Robby Findler wrote: I agree. Listing important videos on unlikely-to-go-away sites seems important. Robby On Tue, Jan 29, 2013 at 4:44 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: 1. Pointing to the wiki from racket-lang.org is a good idea. 2. But I agree with the original proposal that we really may wish to list key videos at the main site directly. It is a service to our community. -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] small GTK problem in 5.3..1.900
After re-reading the docs about `on-demand-callback' in `menu%', I now see that Unity handles things in a weird way, so Unity is quite probably the source of the problem here. I've modified the script menu so that it does not use `on-demand-callback' anymore (which forces the user to click on Reload once in a while, oh my ;) ). Now at least it does not flicker anymore, but just FYI, the warning message still appears each time the menu is re-created. The problem apparently comes from the `(send a-menu-item delete)' call (called prior to re-creating the whole menu). This problem now has low priority for me. Laurent On Fri, Jan 18, 2013 at 7:53 AM, Laurent laurent.ors...@gmail.com wrote: Ubuntu 12.04.1, 32 bits $ uname -a Linux Eurisko 3.2.0-35-generic-pae #55-Ubuntu SMP Wed Dec 5 18:04:39 UTC 2012 i686 athlon i386 GNU/Linux (i386-linux/3m) (get-display-depth) = 32 On Thu, Jan 17, 2013 at 10:25 PM, Matthew Flatt mfl...@cs.utah.eduwrote: I haven't been able to provoke this warning. Can you tell me more about your OS distribution? (I tried Ubuntu 12.04, 32-bit mode, not necessarily up-to-date.) At Thu, 17 Jan 2013 20:22:49 +0100, Laurent wrote: Hi, I see many messages like this one when I run 5.3.1.900 from a terminal: LIBDBUSMENU-GTK: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed It is not really blocking, but it makes my Scripts menu flicker a little or sometimes it even fails to show up. This problem was not present in 5.3.1.10 Laurent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Racket sources getting mysteriously out of sync
I have indeed seen some similar behavior: On a Unix-like install, without changing any of Racket-bundled sources, from time to time, when I recompile one of my collections with `raco setup my-collection` it tries to rebuild all of Racket source tree (but fails, because it does not have write permissions). However, running the same command again does not trigger the full recompilation anyway (which is fortunate). It's quite rare though and I could find a way to reproduce it consistently. Laurent On Thu, Jan 17, 2013 at 7:20 PM, Carl Eastlund c...@ccs.neu.edu wrote: Recently I've run into some odd cases where I run raco setup and it rebuilds a whole bunch of stuff that should have been up-to-date. For instance, I have seen it rebuild all of the collections in a downloaded, pre-built installation of Racket that I had been using for a while. After the rebuild, many uses of raco make sped way up -- somehow, having out of sync collections slowed it down, yet it was not amortizing this cost by bringing them up to date as it went. Just now, I built an up-to-date git checkout from scratch, up through make install, then ran raco setup again and watched it re-run and re-render all of the Scribble documentation. Has anyone else seen behavior like this? Is there some way I might be misconfiguring things that would cause this? I'm mystified, and I'd like to stop wasting time rebuilding things over and over. For reference, I always have the following environment variables set: PLTHOME = root of whichever PLT tree I am using PLTADDONDIR = $PLTHOME/add-on PLTPLANETDIR=$PLTHOME/add-on/planet PLTCOMPILEDROOTS=$PLTHOME/zos/v@(version): Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] small GTK problem in 5.3..1.900
Hi, I see many messages like this one when I run 5.3.1.900 from a terminal: LIBDBUSMENU-GTK: watch_submenu: assertion `GTK_IS_MENU_SHELL(menu)' failed It is not really blocking, but it makes my Scripts menu flicker a little or sometimes it even fails to show up. This problem was not present in 5.3.1.10 Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] ctype-scheme-c
Hem, I don't know if it was me being blind or if they have been added in the docs since, but anyway, thanks! And I'll add a general Thank You for all the small things that I've been asking for or complaining about and that you guys have been adding to Racket and I didn't notice right away. Laurent On Thu, Nov 8, 2012 at 9:12 AM, Laurent laurent.ors...@gmail.com wrote: Hi, Is there a reason that ffi/unsafe does not export ctype-scheme-c and ctype-c-scheme? Because I find them very useful in practice. Or should I avoid using them for some reason? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Given that context, maybe the right thing here is (a) installation-specific packages by default and (b) a way to *upgrade* an existing installation when installing. That might be as simple as automatically running 'raco pkg migrate', but I think making it part of the installation step would make life easier for people, and perhaps an upgrade could avoid duplicating files. I second that. Being a more normal user that most of you, my installation only usually has one version of Racket (in general one of the last nightlies). If you go for the upgrade option, it would be really appreciated if, during installation or on the first run of DrRacket (preferably the former, because of DrRacket Tools), I'm asked whether I want to keep/migrate my packages for the new version. It's currently quite annoying to have to do all this reinstalling by hand. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket automatic parentheses mode update
Nice, thank you very much. I think I'll gonna use it now. Too bad for the delete key, it would be really useful to me :) Is it normal that it does not work in the interaction window? Laurent On Tue, Dec 4, 2012 at 4:42 AM, Robby Findler ro...@eecs.northwestern.eduwrote: Thanks, Nadeem! Robby On Mon, Dec 3, 2012 at 9:30 PM, Nadeem Abdul Hamid nad...@acm.org wrote: Some improvements to DrRacket's automatic parentheses mode are now available in the nightly build version and git repository. If you have previous tried auto-parens and abandoned it, or if you have never tried it, please do try it now! In auto-parens mode, typing a closing parenthesis will skip over an existing one if the cursor is right in front of it. You can also type M+) (meta key + close parens), whether in auto-parens mode or not, to skip right past the closing parentheses of the enclosing expression, or, if the expression is not well-balanced, just forward to the next closing parentheses. This behavior should also work as expected with other closing parenthesis-like symbols, double quotes, and | ... | pairs. There are also some tweaks to the auto-parens mode so that block comments #| ... |# are inserted correctly. Also auto-parens mode has no effect when inside a string literal or comment (you can always use M+( to force a parens pair if you really want one) or when typing a character literal. While 'undo' works properly now for just-inserted () pairs in auto-parens mode, I did not mess at all with delete key behavior. I've left the Paredit-like functionality for another time/person! :-) Have fun, nadeem _ 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] change to `raco setup' doc builds and SQLite
Sounds cool. On yesterday's nightly (debian squeeze 64), I had to do a `sudo raco setup` to have the help webpage, otherwise I would get a http 404. Laurent On Sat, Nov 24, 2012 at 4:09 AM, Matthew Flatt mfl...@cs.utah.edu wrote: When `raco setup' builds documentation, it now puts cross-reference keys and dependency information into an SQLite database. So, building documentation now requires that SQLite is installed (on Unixes; SQLite is installed by default on Mac OS X, and Racket includes SQLite on Windows). The changes are all under the hood, but you may notice the difference: * DrRacket's initial footprint is about 50 MB smaller for a 64-bit build. The savings come from not loading all cross-reference information into memory. When you ask for documentation on `cons', DrRacket now consults the database to determine which document might have information on `cons', and so on. Ultimately, cross-reference information must be deserialized from the same kind of out.sxref file as before. A large document like the Reference can have multiple out.sxref files, however, so DrRacket doesn't have to deserialize all of the Reference's cross-references to show information `cons'. * When you have a simple Scribble document like #lang scribble/base Hello and click Scribble HTML, the result is closer to instantaneous. Scribble doesn't have to load (another copy of) all cross-reference information into memory before rendering the document. You get the same improvement when using `raco scribble ++xref-in setup/xref load-collections-xref'. * The document-rendering part of `raco setup' uses a little less memory and runs a little faster. Besides reducing the need to load and re-load cross-reference information, dependency and global duplicate-definition checking is now handled by a database query, so it should scale better. There will almost certainly be some problems, so keep an eye out for broken or suspicious `raco setup' or documentation behavior. _ 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
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' ?).
Laurent
On Fri, Nov 23, 2012 at 1:20 AM, Nadeem Abdul Hamid nad...@acm.org wrote:
Hello all,
I've been discussing with Robby a possible improvement of DrRacket's
automatic parentheses behavior and would like to get a sense of others'
general opinion about this. What follows is a description of my proposal
and then some concrete questions.
;;
The idea is to have DrRacket automatically skip over
automatically-inserted closing parens if the user types one while the
cursor is right in front of one. (The Eclipse Java IDE does this with
various types of braces and parens, and in the past I've found this very
nice and have observed others (my students) interact well with such a
feature.)
A concrete example: suppose you are in the process of typing the
expression (+ 4 (- 1 2) 3). After you type the first opening
parentheses and the characters following it up to the 2, the expression
in the editor looks like:
(+ 4 (- 1 2|))
where the | represents the cursor's position. Note the two
automatically-inserted closing parens that are after the cursor right now.
With
the current implementation, you have to then use the right arrow key to
make the cursor skip past the first auto-inserted ) and then you can
type 3. However, that really disrupts the typing process because even
if you don't type a ) as a habit and then realize you have to delete the
extra one, you still have to lift and move your finger to the arrow keys
area of the keyboard or type some other key combination to skip the
cursor forward.
My proposal would be to have it so that if you type ) in the editor
state above, it becomes:
(+ 4 (- 1 2)|)
and now you continue typing a space and the 3. Of course, the same thing
should apply for other types of parens - ( [ { etc.
I don't know about others, but I actually get annoyed with the curent
automatic parens feature to the point of disabling it. That is, I like
the auto-parens feature not because it relieves me from having to type
closing parentheses - I don't mind that, and I actually tend to do that
automatically as I'm typing expressions; but the benefit is that it always
keeps parens balanced while I'm still in the middle of typing an
expression. However, with the current behavior, it tends to make me type
extra closing parentheses and have to go back and delete parens to balance
things up again.
;;
So, the questions:
1. Do you use the automatic parentheses feature of DrRacket?
2a. If yes, does the proposal above resonate well with you?
2b. And, do you think this smart skipping of auto-inserted closing
parentheses should become the intrinsic behavior of the automatic
parentheses mode, or should it be a separate preference? (i.e. have two
preference options - the current automatic parentheses one and then a
subordinate option that enables/disables this skipping over of
auto-inserted closing parentheses as the user types them)
3. If your answer to #1 is No, why not? (Is it because you find its
current behavior awkward in some way?)
Thanks,
nadeem
_
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
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. Another idea could be to remove the closing paren of the enclosed s-expr automatically; but there may be some cases where this could lead to undesired behaviors. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `regexp-replaces'
On Fri, Jun 22, 2012 at 5:36 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Laurent wrote: add1 I also use such a function from time to time, and I'd be happy to have it in the string or regexp libs. I'll assume that without other replies, there are no objections to adding it? Also, at least as a start, I'm thinking of a function that looks just like the one from the ffi: (regexp-replaces str (list (list regexp replacement) ...)) Anything else that this should do? Maybe we could consider dictionaries for the replacement lists? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `regexp-replaces'
add1 I also use such a function from time to time, and I'd be happy to have it in the string or regexp libs. Laurent On Thu, Jun 21, 2012 at 1:56 PM, Eli Barzilay e...@barzilay.org wrote: While scanning code for a minor incompatible in a commit, I ran into this function which is the ffi collection of all places. (See the docs for what it does.) Given that this comes up often, maybe it's time to add this to `racket/string'? (Or maybe `racket/private/string' next to the other regexp functions?) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Comments and DrRacket
Hi Harry, This would be a nice feature indeed. Note that you can use code folding for that purpose, but I personally don't like it because it makes the saved source code non-textual. One related proposal that I made earlier is to have a multi-view document, where you could select Source, Source + Tests, Tests only, and then maybe same for comments, etc. though maybe you'd like partial hiding of the comments. It's unlikely that PLT is going to implement that any time soon, so it's more in our hands I guess (though it's unlikely that I'll do that anytime soon either). Laurent On Wed, Jun 20, 2012 at 12:16 AM, Harry Spier vasishtha.sp...@gmail.comwrote: I tend to put a lot of comments not just at the beginning of procedures but also in the body of the procedures, usually above lines of code instead of to the right because the comments can be fairly long and multi-line. This makes it easier to understand the procedure on the one hand but because it spreads the procedure out over several screens makes it harder to follow also. For that reason I thought a nice feature in DrRacket might be a menu button to either display or hide comments, so you could see the comments and then click the button and disappear them and see the entire or most of the procedure to see the program flow. Thanks, Harry Spier _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Code micro-level organization
How about a define* that is exactly like let* without the additional indentation level? E.g.: (define* [↑ foo bar baz] [↑ (substring ↑ 3 8)] [str (string-trim ↑)] [↑ (regexp-match? #rx^[a-z].*[a-z]$ str)]) (and ↑ (string-append * str *)) Laurent Le 31 mai 2012 19:04, Neil Toronto neil.toro...@gmail.com a écrit : On 05/30/2012 03:40 PM, Eli Barzilay wrote: Now, lets imagine that instead of a simple `' hole, there are two kinds of holes with an up or a down direction -- this leads to this kind of a syntax: (○ foo bar baz (substring ↑ 3 8) (string-trim ↑) (let ([str ↑]) ↓) (and (regexp-match? #rx^[a-z].*[a-z]$ str) ↓) (string-append * str *)) where you can read `↑' as the above and `↓' as the below. It seems like `↑' is another way to not name expressions (i.e. a pointless style :D), and `↓' is handled just fine by internal definitions. This is equivalent, currently defined, has less nesting, and avoids a rename: (define orig-str foo bar baz) (define sub (substring orig-str 3 8)) (define str (string-trim sub)) (define m (regexp-match? #rx^[a-z].*[a-z]$ str)) (and m (string-append * str *)) A `define*' form like Jay (and I) want would make these kinds of things less error-prone and allow names to be reused: (define* ↑ foo bar baz) (define* ↑ (substring ↑ 3 8)) (define* str (string-trim ↑)) (define* ↑ (regexp-match? #rx^[a-z].*[a-z]$ str)) (and ↑ (string-append * str *)) It's still pretty wordy, though. Even if I had `define*' I'd be tempted to go with my current favorite idiom, which trades wordiness for a nesting level: (let* ([↑foo bar baz] [↑(substring ↑ 3 8)] [str (string-trim ↑)] [↑(regexp-match? #rx^[a-z].*[a-z]$ str)]) (and ↑ (string-append * str *))) I occasionally get annoyed by how deeply these can get nested. I feel your pain, man. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Code micro-level organization
(sorry for the bad indentation, writing s-exps on a phone predictive keyboard is painful...) Le 31 mai 2012 19:21, Laurent laurent.ors...@gmail.com a écrit : How about a define* that is exactly like let* without the additional indentation level? E.g.: (define* [↑ foo bar baz] [↑ (substring ↑ 3 8)] [str (string-trim ↑)] [↑ (regexp-match? #rx^[a-z].*[a-z]$ str)]) (and ↑ (string-append * str *)) Laurent Le 31 mai 2012 19:04, Neil Toronto neil.toro...@gmail.com a écrit : On 05/30/2012 03:40 PM, Eli Barzilay wrote: Now, lets imagine that instead of a simple `' hole, there are two kinds of holes with an up or a down direction -- this leads to this kind of a syntax: (○ foo bar baz (substring ↑ 3 8) (string-trim ↑) (let ([str ↑]) ↓) (and (regexp-match? #rx^[a-z].*[a-z]$ str) ↓) (string-append * str *)) where you can read `↑' as the above and `↓' as the below. It seems like `↑' is another way to not name expressions (i.e. a pointless style :D), and `↓' is handled just fine by internal definitions. This is equivalent, currently defined, has less nesting, and avoids a rename: (define orig-str foo bar baz) (define sub (substring orig-str 3 8)) (define str (string-trim sub)) (define m (regexp-match? #rx^[a-z].*[a-z]$ str)) (and m (string-append * str *)) A `define*' form like Jay (and I) want would make these kinds of things less error-prone and allow names to be reused: (define* ↑ foo bar baz) (define* ↑ (substring ↑ 3 8)) (define* str (string-trim ↑)) (define* ↑ (regexp-match? #rx^[a-z].*[a-z]$ str)) (and ↑ (string-append * str *)) It's still pretty wordy, though. Even if I had `define*' I'd be tempted to go with my current favorite idiom, which trades wordiness for a nesting level: (let* ([↑foo bar baz] [↑(substring ↑ 3 8)] [str (string-trim ↑)] [↑(regexp-match? #rx^[a-z].*[a-z]$ str)]) (and ↑ (string-append * str *))) I occasionally get annoyed by how deeply these can get nested. I feel your pain, man. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `racket/string' extensions
On Thu, May 24, 2012 at 10:45 PM, Eli Barzilay e...@barzilay.org wrote: (string-index str sub [start 0] [end (string-length str)]) Looks for occurrences of `sub' in `str', returns the index if found, #f otherwise. [*2*] I'm not sure about the name, maybe `string-index-of' is better? Maybe `string-find'? (list-index list elt) Looks for `elt' in `list'. This is a possible extension for `racket/list' that would be kind of obvious with adding the above. [*3*] I'm not sure if it should be added, but IIRC it was requested a few times. If it does get added, then there's another question for how far the analogy goes: [*3a*] Should it take a start/end index too? [*3b*] Should it take a list of elements and look for a matching sublist instead (which is not a function that is common to ask for, AFAICT)? 3b: I think that's over-complicating things, personally. 2. Another subtle point is what should these return: (string-trim aaa aa) (string-trim ababa aba) After deliberating on that, I eventually made it return because it seems like that would be more expected. That this could return surprised me. The intuitive behavior to me is the following: If you remove aa from aaa, you get a, and if you repeat it (from either side), you don't match and return a. This relies on an occidental left-right preference though. But as you say, these are rare cases, so it could well be left as unspecified or specified in the simplest way to implement, as long as it is well documented? (But that's really a subtle point, since multi-character string separators are very rare anyway.) I also looked into several of these functions, but there's no precedent that I've seen either way. (In many cases it uses a regexp or uses the `sep' string as a bag of characters.) As a corollary of this, I thought that it might also mean that this should happen: (string-split x---y---z --) = '(x y z) but in this case it looks like this wouldn't be expected. Indeed. Perhaps a hand-wavy proof of this is that coding this behavior would take a little effort (need to look for all occurrences of the pattern) whereas in the `string-trim' case the above is very easy (find the start and end, return if start = end). * (string-split str [sep #px\\s+] #:trim? [trim? #t] #:repeat? [+? #f]) As discussed. * (string-normalize-spaces str [sep #px\\s+] [space ] #:trim? [trim? #t] #:repeat? [+? #f]) Side comment: If it's possible, formatting the signature like this in the docs could be a good idea: put all the keyword arguments on another line, so that the most important and often used options are put forward. I think that might help newbies to understand the question (keywords can be a bit frightening maybe? (not sure)). I ended up keeping the name of this. Also, it's easy to implement directly as (string-join (string-split str sep ...) space) That's a good sign that the functions have the correct (default) behavior. Looking forward to use all these! Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax
On Sat, May 12, 2012 at 12:49 AM, Eli Barzilay e...@barzilay.org wrote: 5 hours ago, Neil Toronto wrote: On 05/09/2012 02:18 AM, Laurent wrote: From the guide: Caveat 1: Until language specifications come with fixed indentation rules, we need to use the default settings of DrRacket’s indentation for this rule to make sense. Maybe a special submodule like drracket-indentation with declarations like: (module+ drracket-indentation (like-lambda my-lambda my-function ) (like-begin my-begin ) ) could be useful for user-specific indentation. As a submodule, Racket can readload it only at appropriate moments. When indenting the file, DrRacket could first load the drracket-indentation module of the file to know how to indent it. One could then create a whole language with its own indentation rules. It would also be easier to add good indentations for for/fold and others. That would be awesome for Typed Racket macros in particular. Its `for' macros are great examples of forms that should have fairly complex indentation rules. Optional type declarations make it difficult to classify them as begin-like, define-like or lambda-like. That kind of indentation specification is more fitting in the language info, together with coloring etc. Probably. But how can the user specify its own rules then? (genuine question, I don't know where the language info lies, and how it can be extended) For specific macros in some random file something that I suggested in the past could work better: have an ability to use sub-namespaces where an identifier can have a number of related bindings -- so you could define `foo' and some `foo@indent' (or whatever) which specifies indentation. The reason that this would work better is that any context that receives the `foo' binding would also get its indentation. Interesting idea. Could sub-namespaces be loaded independently from the main identifier, in case you don't need it? Anyway, submodules already exists, hence my suggestion. Eg, think about providing it as `bar' -- if the rules are in a sub-module, then it won't work unless you construct your own sub-module. Unless `bar' knows its real name is `foo'? (which it does, maybe?) Currently, DrRacket does not seem to be able to do this anyway (which may be why you proposed sub-namespaces?): #lang racket (require (rename-in racket [define gabuzomeu])) (gabuzomeu (foo bar) (list bar)) So probably sub-moduled indentation rules would be a less important change than adding sub-namespaces, and thus requires less work which makes it more probable to appear in a near future? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] A few suggestions on indentation and DrRacket graphical syntax
Hi, Reading the style guide for Racket, I came up with a few debatable suggestions. ( http://www.ccs.neu.edu/home/matthias/Style/style/Textual_Matters.html ) Apologies if this has already been longly debated. * Indentation: adding new indentations constructs to DrRacket From the guide: Caveat 1: Until language specifications come with fixed indentation rules, we need to use the default settings of DrRacket’s indentation for this rule to make sense. Maybe a special submodule like drracket-indentation with declarations like: (module+ drracket-indentation (like-lambda my-lambda my-function ) (like-begin my-begin ) ) could be useful for user-specific indentation. As a submodule, Racket can readload it only at appropriate moments. When indenting the file, DrRacket could first load the drracket-indentation module of the file to know how to indent it. One could then create a whole language with its own indentation rules. It would also be easier to add good indentations for for/fold and others. * Graphical syntax When we figure out how to save such files in an editor-compatible way, we may relax this constraint. Maybe the graphical job should be done by DrRacket only, and the file itself should remain textual. For example, special forms can be turned into graphics by DrRacket when reading the file: You write: (image balloon.jpg) and DrRacket turns this into the image (if the option is turned on somewhere in the preferences). Of course, the s-exp should still be editable, for example with a contextual menu that proposes Back to s-exp or Turn me into graphical form. Or even surround it with a form like (drracket-show-image (image balloon.jpg) 48 48) for better rendering (that form obviously expands into (image balloon.jpg) for Racket). Same for code folding, 2 options: - either surround s-exps with a (drracket-fold ) form to inform DrRacket to fold the s-exp, and Racket to just do what's inside the form, (but that pollutes the file for external editors, though an `unfold-file' function should not be too difficult to do) - or do not save folding into the file (loading a file displays it unfolded, then it can be folded as desired). This might be problematic with DrSync though, unless the file is not reverted if it has not changed. But I agree all this would require some work, certainly. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax
* Line-width In GEdit, there's an option to show a thin vertical line at 80 chars (modifiable number). I find it of great help to avoid writing long lines, which I tend to not do otherwise or often (inconveniently) look at the column number to see where I am. Such a vertical line might be a good idea for DrRacket. Laurent On Wed, May 9, 2012 at 10:18 AM, Laurent laurent.ors...@gmail.com wrote: Hi, Reading the style guide for Racket, I came up with a few debatable suggestions. ( http://www.ccs.neu.edu/home/matthias/Style/style/Textual_Matters.html ) Apologies if this has already been longly debated. * Indentation: adding new indentations constructs to DrRacket From the guide: Caveat 1: Until language specifications come with fixed indentation rules, we need to use the default settings of DrRacket’s indentation for this rule to make sense. Maybe a special submodule like drracket-indentation with declarations like: (module+ drracket-indentation (like-lambda my-lambda my-function ) (like-begin my-begin ) ) could be useful for user-specific indentation. As a submodule, Racket can readload it only at appropriate moments. When indenting the file, DrRacket could first load the drracket-indentation module of the file to know how to indent it. One could then create a whole language with its own indentation rules. It would also be easier to add good indentations for for/fold and others. * Graphical syntax When we figure out how to save such files in an editor-compatible way, we may relax this constraint. Maybe the graphical job should be done by DrRacket only, and the file itself should remain textual. For example, special forms can be turned into graphics by DrRacket when reading the file: You write: (image balloon.jpg) and DrRacket turns this into the image (if the option is turned on somewhere in the preferences). Of course, the s-exp should still be editable, for example with a contextual menu that proposes Back to s-exp or Turn me into graphical form. Or even surround it with a form like (drracket-show-image (image balloon.jpg) 48 48) for better rendering (that form obviously expands into (image balloon.jpg) for Racket). Same for code folding, 2 options: - either surround s-exps with a (drracket-fold ) form to inform DrRacket to fold the s-exp, and Racket to just do what's inside the form, (but that pollutes the file for external editors, though an `unfold-file' function should not be too difficult to do) - or do not save folding into the file (loading a file displays it unfolded, then it can be folded as desired). This might be problematic with DrSync though, unless the file is not reverted if it has not changed. But I agree all this would require some work, certainly. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 4:04 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 3, 2012, at 11:03 PM, Neil Van Dyke wrote: Matthias Felleisen wrote at 05/03/2012 10:57 PM: I don't think Eli is proposing an elimination of the old names but supplementing the code base with new ones. I am in favor -- Matthias Would be good to have a shorter naming convention for all parameters. The current- prefix is not short, but it's what I've been using when coding new parameters, because that's the convention. Of course, a naming convention is much less important when we have static checking of argument types, but we usually don't. General, off specific topic: Even in the presence of [on-line] type checking, naming conventions make programs readable, as do other conventions. If I may add my opinion: They also make programs easier to write. And you've probably already been there several times, but: However, long names make programs both easier and harder to read: many symbols on the screen gives a lot of information to the eye, which then takes more time to see relevant info. As sad as I am to say this, arr[x] = 3 is read quicker by the eye than (vector-set! my-integer-array the-current-iterator the-number-three) (obviously exaggerating): for the reader to understand what the instruction/expression means the former only requires syntactic reading, i.e. quick pattern matching for the mind, whereas the latter requires semantic expansion of the words, although the ! here is helpful. I'm certainly not advocating very short names though (and I also like Racket's real words, although sometimes it is indeed too long), just stating some debatable thoughts. An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 4:41 PM, Matthias Felleisen matth...@ccs.neu.eduwrote: On May 4, 2012, at 10:34 AM, Laurent wrote: As sad as I am to say this, arr[x] = 3 is read quicker by the eye than (vector-set! my-integer-array the-current-iterator the-number-three) I started saying this in 1988, when I requested from a Scheme implementor that arrays should be treated as (finite) functions: (arr x) ~ (vector-ref arr x) I would very much like that (for all kinds of containers, and this would even help programs be container-independent). What was the reason for not including this in Racket? An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Go for it. I would certainly if I had time right now... (though using `read' and a hash might be easier). That will need to wait if no one else feels like doing it. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current-*-port
On Fri, May 4, 2012 at 5:04 PM, Neil Van Dyke n...@neilvandyke.org wrote: Matthias Felleisen wrote at 05/04/2012 10:41 AM: On May 4, 2012, at 10:34 AM, Laurent wrote An interesting idea would be to count the number of times each identifier is used in the sources, and see how many characters would be saved by using different conventions. That sounds like a fantastic exercise for someone who is truly skilled at scripting the shell with all kinds of find/wc/add knowledge. Heresy. Racket is actually well-suited for this task. (At the risk of stating the obvious... Well, you have to do some of the mechanics of directory tree traversal manually, unless someone's already written a directory-fold or similar. in-directory does what you want. http://docs.racket-lang.org/reference/sequences.html?q=in-directory#%28def._%28%28lib._racket/private/base..rkt%29._in-directory%29%29 The main problem I recently had `read'ing scribble files was the #reader directives, which I had to remove by a regexp-replace before parsing the file (hoping that what follows the #reader is still in s-exp form). Not sure if there is a better solution(?). Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Most used identifiers and their length
Here is a quick test on the collects dir (program attached if you want to improve it). A number of files are not parsed because of various glitches (#reader lines in particular). Below is the dict of the first 500 identifiers with the number of occurrences, sorted by this number times the string-length of the identifier. Actually, it doesn't look that bad IMO. Laurent, who should have worked instead... '((define . 47453) (quote . 48703) (lambda . 22377) (send . 21027) (syntax . 13956) (let . 21909) (... . 18877) (list . 13315) (unquote . 6398) (x . 43546) (define/public . 3189) (quasiquote . 3689) (loop . 8958) (if . 17508) (set! . 8569) (make-object . 3104) (unless . 5432) (require . 4582) (stx . 10494) (else . 7808) (name . 7663) (and . 10187) (cons . 7529) (raise-syntax-error . 1631) (values . 4865) (cond . 7077) (define-syntax . 2149) (when . 6942) (car . 8956) (provide . 3745) (syntax-list . 2124) (syntax-case . 2257) (let-values . 2462) (define/override . 1517) (unsyntax . 2757) (o . 20379) (format . 3377) (define-values . 1553) (define-struct . 1548) (null? . 3961) (cdr . 6557) (quasisyntax . 1752) (string-append . 1456) (raise-type-error . 1176) (begin . 3621) (- . 8915) (define/private . 1261) (with-syntax . 1603) (parameterize . 1416) (check-equal? . 1408) (identifier? . 1527) (string-constant . 1115) (syntax-e . 2082) (error . 3274) (not . 5409) (parent . 2662) (map . 5280) (vector-ref . 1575) (let* . 3791) (start . 2987) (string? . 2120) (unquote-splicing . 906) (eq? . 4740) (null . 3550) (void . 3513) (apply . 2727) (exact-nonnegative-integer? . 516) (append . 2182) (length . 2104) (test-case . 1401) (define-syntax-rule . 688) (for-each . 1463) (equal? . 1857) (test . 2775) (define-enum . 1003) (make-parameter . 787) (quote-syntax . 918) (in-list . 1562) (with-handlers . 811) (v . 10374) (expr . 2584) (vector . 1707) (pair? . 2024) (label . 1997) (body . 2485) (args . 2481) (id . 4899) (list-ref . 1218) (build-path . 972) (or . 4801) (p . 9589) (string-symbol . 675) (+ . 9441) (i . 9390) (generate-temporaries . 465) (datum-syntax . 715) (printf . 1527) (s . 9138) (dc . 4555) (a . 8852) (string-length . 675) (syntax/loc . 873) (symbol-string . 621) (symbol? . 1228) (expression . 859) (c . 8442) (unsyntax-splicing . 496) (color . 1665) (define-for-syntax . 478) (provide/contract . 499) (listof . 1326) (reverse . 1136) (style . 1571) (new . 2618) (port . 1953) (hash-ref . 974) (module . 1292) (syntax-rules . 644) (number? . 1104) (match . 1543) (real? . 1539) (zero? . 1538) (rest . 1922) (cadr . 1919) (for-syntax . 764) (pos . 2534) (regexp-match . 633) (height . 1255) (snip . 1880) (super-new . 834) (val . 2493) (case-lambda . 679) (result . 1240) (y . 7388) (struct . 1230) (racket/base . 657) (path . 1778) (term . 1776) (current-error-port . 393) (l . 7049) (e . 7021) (n . 6991) (quasisyntax/loc . 464) (solid . 1391) (boolean? . 868) (hash-set! . 768) (pattern . 977) (for/list . 847) (inexact-exact . 480) (procedure? . 672) (f . 6699) (stretchable-height . 370) (free-identifier=? . 388) (λ . 6592) (b . 6524) (str . 2172) (width . 1293) (line . 1613) (filename . 805) (def/public . 643) (add1 . 1607) (syntax-datum . 486) (or/c . 1568) (display . 875) (vector-length . 471) (tex-def-prim . 509) (all-from-out . 493) (_ . 5915) (unbox . 1180) (text . 1472) (current-output-port . 307) (number . 968) (test-expression . 387) (vector-set! . 526) (type . 1432) (number-string . 409) (t . 5713) (value . 1141) (current-continuation-marks . 219) (procedure-arity-includes? . 227) (empty . 1122) (last-position . 427) (racket/class . 462) (- . 5534) (string-number . 395) (case . 1364) (_pointer . 670) (len . 1782) (path-string . 442) (syntax-property . 353) (inherit . 753) (eof-object? . 478) (begin-edit-sequence . 274) (class . 1038) (Integer . 737) (prefix . 857) (end . 1703) (stretchable-width . 298) (proc . 1266) (callback . 630) (side-condition . 354) (default-color . 380) (expected . 615) (in-range . 615) (any/c . 980) (match-define . 407) (memq . 1220) (current-directory . 287) (arithmetic-shift . 304) (string=? . 602) (obj . 1603) (rectangle . 533) (end-edit-sequence . 282) (= . 2393) (out . 1588) (file-exists? . 394) (in-hole . 672) (mzscheme . 587) (this . 1172) (: . 4680) (set-box! . 582) (current-namespace . 272) (base . 1153) (sub1 . 1149) (andmap . 765) (syntax? . 654) (bytes-length . 381) (* . 4561) (test-suite . 454) (key . 1513) (char-integer . 349) (file . 1122) (preferences:get . 297) (var . 1484) (check . 890) (r . 4447
[racket-dev] version number for functions/forms in docs
Hi, If that's not too difficult to do (maybe automatically), it would be nice if the docs could tell if a function/form has changed or has been added recently. Maybe a note in the margin like Added in 5.2.1 or Changed in 5.3.0. It would be helpful for backward compatibility. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] skip release
Agreed. It may also give you/us more time to play with submodule and not be too afraid of backward compatibility in case you'd like to change something. Laurent On Tue, Apr 24, 2012 at 22:43, Karn Kallio tierplusplusli...@gmail.comwrote: I think it is good to wait until the release is ready. There is no rush ... I prefer slower but better. Saludos, Karn _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Fwd: [racket] Are There More String Functions?
(sorry, I couldn't figure out how to reply properly from the list archive, as I don't receive the dev-list emails.) One string function that I often find useful in various scripting languages is a `string-split' (explode in php). It can be done with `regexp-split', but having something more along the lines of a `string-split' should belong to a racket/string lib I think. Plus it would be symmetric with `string-join', which already is in racket/string (or at least a doc line pointing to regexp-split should be added there). Maybe also a `string-replace' could be useful, especially when one does not want regexps and has special characters that need to be quoted. Regexps are very powerful, but they are complicated for beginners. Laurent I think `racket/string' should provide the useful string functions, rather than refer users to srfis. The only srfi/13 function I ever use is `string-trim-both' -- any objection to adding that to `racket/string'? On Tue, Apr 17, 2012 at 5:29 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: I saw no response to this question and no commit that includes the cross-link. Anything? Begin forwarded message: From: Asumu Takikawa as...@ccs.neu.edu Subject: Re: [racket] Are There More String Functions? Date: April 12, 2012 5:47:26 PM EDT To: Cristian Esquivias cristian.esquiv...@gmail.com Cc: us...@racket-lang.org On 2012-04-12 10:43:15 -0700, Cristian Esquivias wrote: As a slight aside, is this module mentioned anywhere in the Racket Guide or Racket Reference? I tried to RTFM as much as possible but didn't see this module mentioned anywhere in the string pages. Should this module be mentioned for others like me? I think that's an interesting point and has been brought up before on this list: what's the official stance on SRFIs? On the documentation page they are near the bottom in Miscellaneous libraries. If their use is encouraged, maybe doc pages should have a pointer in the margin similar to how reference entries point to guide entries. For example, the string section in the reference could point to SRFI-13. Cheers, Asumu Racket Users list: http://lists.racket-lang.org/users _ Racket Developers list: http://lists.racket-lang.org/dev -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-split'
(define (string-split str [sep #px\\s+]) (remove* '() (regexp-split sep str))) Nearly, I meant something more like this: (define (string-split str [splitter ]) (regexp-split (regexp-quote splitter) str)) No regexp from the user POV, and much easier to use with little knowledge. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-replace'
On Thu, Apr 19, 2012 at 14:26, Eli Barzilay e...@barzilay.org wrote: Two hours ago, Laurent wrote: Maybe also a `string-replace' could be useful, especially when one does not want regexps and has special characters that need to be quoted. Again, it's not clear how this shold look -- my guess: (define (string-replace from str to) (regexp-replace* (regexp-quote from) str to)) I meant this: (define (string-replace from str to) (regexp-replace* (regexp-quote from) str (regexp-replace-quote to))) (string-replace ( (a list) \\1) ; - \\1a list) Newbie-friendly (I meant regexp-quoted without the user seeing it) and easy to use. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-split'
On Thu, Apr 19, 2012 at 14:33, Matthew Flatt mfl...@cs.utah.edu wrote: I agree with this: we should add `string-split', the one-argument case should be as Eli wrote, About this I'm not sure, as one cannot reproduce this behavior by providing an argument (or it could make the difference between string-as-not-regexps and regexps? Wouldn't this be different from other places?). It would then appear somewhat magical. To me the default splitter seems more intuitive. Laurent and the two-argument case should be as Laurent wrote. (Probably the optional second argument should be string-or-#f, where #f means to use #px\\s+.) At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote: (define (string-split str [sep #px\\s+]) (remove* '() (regexp-split sep str))) Nearly, I meant something more like this: (define (string-split str [splitter ]) (regexp-split (regexp-quote splitter) str)) No regexp from the user POV, and much easier to use with little knowledge. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-split'
On Thu, Apr 19, 2012 at 14:53, Matthew Flatt mfl...@cs.utah.edu wrote: At Thu, 19 Apr 2012 14:43:44 +0200, Laurent wrote: On Thu, Apr 19, 2012 at 14:33, Matthew Flatt mfl...@cs.utah.edu wrote: I agree with this: we should add `string-split', the one-argument case should be as Eli wrote, About this I'm not sure, as one cannot reproduce this behavior by providing an argument (or it could make the difference between string-as-not-regexps and regexps? Wouldn't this be different from other places?). I'm suggesting that supplying `#f' as the argument would be the same as not supplying the argument. It is a special case, though. I don't mind the specialness here, because I see the job of `string-split' as making a couple of useful special cases easy (as opposed to the generality of `regexp-split'). Then instead of #f one idea is to go one step further and consider different useful cases based on input symbols like 'whitespaces, 'non-alpha, etc. ? Or even a list of string/symbols that can be used as a splitter. That would make a more powerful function for sure. (It's just that I'm troubled by the uniqueness of this magical default argument) Laurent It would then appear somewhat magical. To me the default splitter seems more intuitive. Laurent and the two-argument case should be as Laurent wrote. (Probably the optional second argument should be string-or-#f, where #f means to use #px\\s+.) At Thu, 19 Apr 2012 14:30:31 +0200, Laurent wrote: (define (string-split str [sep #px\\s+]) (remove* '() (regexp-split sep str))) Nearly, I meant something more like this: (define (string-split str [splitter ]) (regexp-split (regexp-quote splitter) str)) No regexp from the user POV, and much easier to use with little knowledge. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-split'
Continuing with this line, it seems that a better definition is as follows: (define (string-split str [sep ]) (remove* '() (regexp-split (regexp-quote (or sep )) str))) Except that the full definition could be a bit more efficient. Three questions: 1. Laurent: Does this make more sense? Yes, this definitely makes more sense to me. It would then treat (string-split aXXby X) just like the case. Although if you want to find the columns of a latex line like x y z you will have the wrong result. Maybe use an optional argument to remove the empty strings? (not sure) 2. Matthew: Is there any reason to make the #f-as-default part of the interface? (Even with the new reply I don't see a necessity for this -- if the target is newbies, then I think that keeping it as a string is simpler...) There is probably no need for #f with the new spec. 4. Related to Q3: what does xy as that argument mean exactly? a. #rx[xy] b. #rx[xy]+ c. #rxxy d. #rx(?:xy)+ Good question. d. would be the simplest case for newbies, but b. might be more useful. I think several other languages avoid this issue by using only one character as the separator. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Argument positions of string-... like functions
(define (string-index-of sub str [start 0] [end (string-length str)]) I always need to go check the documentation for that kind of argument position (like for (string-replace from str to) ). To me, what makes more sense is to have the str argument on the first position, just like for a method call with a self argument, which makes sense for strings on functions like string- Does it bother other people too? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `string-split'
4. Related to Q3: what does xy as that argument mean exactly? a. #rx[xy] b. #rx[xy]+ c. #rxxy d. #rx(?:xy)+ Good question. d. would be the simplest case for newbies, but b. might be more useful. It would make more sense that a string really is a string, not a set of characters. Without going as far as srfi-14, a set could be a list of strings or characters, but maybe this is not needed. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] `racket/string' extensions
I like it a lot. [...] (string-split str [sep #px\\s+]) Splits `str' on occurrences of `sep'. Unclear whether it should do that with or without trimming, which affects keeping a first/last empty part. [*1*] Possible solution: make it take a `#:trim?' keyword, in analogy to `string-normalize-spaces'. This would make `#t' the obvious choice for a default, which means that (string-split ,,foo, bar, ,) - '(foo bar) A keyword might be a good idea indeed. (list-index list elt) Looks for `elt' in `list'. This is a possible extension for `racket/list' that would be kind of obvious with adding the above. [*3*] I'm not sure if it should be added, but IIRC it was requested a few times. If it does get added, then there's another question for how far the analogy goes: [*3a*] Should it take a start/end index too? [*3b*] Should it take a list of elements and look for a matching sublist instead (which is not a function that is common to ask for, AFAICT)? Or should it take a comparison operator (e.g., defaulting to equal?) ? Maybe list-index could be simple (considering the list flat), and list-index* could return a list of positions in the sublists? E.g., (list-index* '(a (b (c d) e) f) 'c) - '(1 1 0) (list-index* '(a (b (c d) e) f) '(c d)) - '(1 1) Btw, from time to time I wish that `remove*' accepted a single element that is not a list. I find it a bit cumbersome and not good looking to wrap a single value in a (list ...). Since modifying remove* would probably break a few things, maybe a remove+ ? Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact-exact: no exact representation for +nan.0)]
you're certainly on the right track. I tried starting drracket in this way: LC_ALL=en_US.UTF-8 drracket Same here: LC_ALL=en_US.UTF-8 gracket Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. .3 0.3 Great! *However*, this did not work with: LC_ALL=fr_FR.UTF-8 gracket Weird. Thank you, Laurent and almost all symptoms were gone. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk78JkIACgkQp/VmCx0OL2wedgCfSApHFEmJ6GojTYbTGg/fY4fz LjoAnREzYAr9VYv/BZyAJEWYNunWNK9s =1ZSi -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact-exact: no exact representation for +nan.0)]
On Wed, Dec 28, 2011 at 13:18, Matthew Flatt mfl...@cs.utah.edu wrote:
Thanks for all the new info! I don't think that it's a bytcode problem.
I start to wonder if it's in number parsing...
On line 1102 of src/racket/src/numstr.c, there's a call to STRTOD().
Does it change anything if you wrap that call with calls to
scheme_push_c_numeric_locale() and scheme_pop_c_numeric_locale(loc)?:
{
GC_CAN_IGNORE char *loc;
loc = scheme_push_c_numeric_locale();
d = STRTOD(ffl_buf, ptr);
scheme_pop_c_numeric_locale(loc);
}
It works!
Though: I downloaded the nightly Unix sources, and did:
mkdir build
cd build
../configure
make
But no drracket executable appears (did I do something wrong?).
So I did:
gracket/gracket3m
and it took a full minute with 100% CPU to start (same for simply racket3m).
Then
Welcome to Racket v5.2.0.7.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
.3
0.3
In case this does not completely solve the issue, here is another
minimalistic interesting interaction in the buggy gracket:
Welcome to Racket v5.2.0.6.
This is a simple window for evaluating Racket expressions.
Quit now and run DrRacket to get a better window.
The current input port always returns eof.
.3
0.0
3.3
3.0
.3
0.3
So it seems that it's the fact that using a = 1 floating point number make
the bug go away.
Anyway, I hope this does solves the issue!
Thank you very much,
Laurent
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] .1 evaluates to 0.0 [was Re: plot doesn't plot (inexact-exact: no exact representation for +nan.0)]
I'm not alone! FWIW, I still have that problem in 5.2.0.6. And I confirm the .1 minimalist test case. When running 'racket' from the command line, this does not occur however: laurent:~$ racket Welcome to Racket v5.2.0.6. Edit ~/.racketrc to modify inits. .1 0.1 But this still happens with gracket: Welcome to Racket v5.2.0.6. This is a simple window for evaluating Racket expressions. Quit now and run DrRacket to get a better window. The current input port always returns eof. .1 0.0 Probably irrelevant: Could the GPU be in the loop somehow? Good luck, Laurent On Tue, Dec 27, 2011 at 14:26, Marijn hk...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24-12-11 16:23, Matthew Flatt wrote: At Wed, 14 Dec 2011 16:49:23 +0100, Marijn wrote: #lang racket (* .1 pi) produces 0.0 reliably in a freshly started drracket even when rerunning it, but: $ racket -e '(* .1 pi)' 0.3141592653589793 and the program: #lang racket pi (* .1 pi) on the first run (drracket again) produces: 3.141592653589793 0.0 while on subsequent runs it produces: 3.141592653589793 0.3141592653589793 Thanks --- this is very helpful! I'm still stumped, unfortunately. It looks the same as PR 12070, which we never figured out: http://bugs.racket-lang.org/query/?debug=database=defaultcmd=view+audit-trailcmd=viewpr=12070 Interesting!, though it is a bit hard to read the Audit Trail because everything is jumbled together. I reproduce that bug and step 7) and 8) can be replaced with a single re-evaluate for me. It seems to indicate very clearly that the problem is in the floating point start-up somehow and has nothing to do with `pi' or variable references. Another possibility would be that multiplication (*) was at fault, but my new smallest test-case rules that out: #lang racket .1 = 0.0 And actually it works also directly in the REPL without running any program: Welcome to DrRacket, version 5.2.0.7--2011-12-15(-/f) [3m]. Language: racket; memory limit: 128 MB. .1 0.0 1 1 .1 0.0 .2 0.0 .3 0.0 .4 0.0 .5 0.0 .6 0.0 .7 0.0 .8 0.0 .9 0.0 1.0 1.0 .1 0.1 So should we look at the byte-code produced for this (how does one do that and what is the expected code)? Is there some way to invoke racket from the command line in such a way that it behaves like the drracket initial repl? How does one run the byte-code? What external suspects are there? I suppose gcc, but are there any other? My CFLAGS are set to a very conservative AFAIK CFLAGS=-march=native -ggdb -O2 -pipe, currently on version 4.5.3. Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk75x5IACgkQp/VmCx0OL2xZRACcC8dubYCSNXScyOG8wdJQxxN1 xAgAnRVKv8YpTWODEKn2qEMMhcXHZLSk =n+xT -END PGP SIGNATURE- _ Racket Developers list: http://lists.racket-lang.org/dev
