Re: [racket-dev] Announcing Soft Contract Verification tool

2015-01-15 Thread Asumu Takikawa
On 2015-01-15 14:13:02 -0500, Asumu Takikawa wrote:
   Contract violation: 'fact' violates '='.
   Value
 0.105
   violates predicate
 real?
   An example module that breaks it:
 (module user racket (require (submod .. fact)) (factorial 0.105))
   (Verification takes 0.05s)

Hmm, actually I should've looked at this more carefully. Is this a case
where the tool is telling me that the function is non-terminating on
this input?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Announcing Soft Contract Verification tool

2015-01-15 Thread Asumu Takikawa
On 2015-01-14 19:11:59 -0500, David Van Horn wrote:
 If you have questions, comments, bugs, or any other feedback, let us
 know, or just file bug reports on the GitHub source code.

Nice tool! I like the web interface too.

I was confused by this interaction though. Clicking verify on this:

  (module fact racket
(define (factorial x)
  (if (zero? x)
  1
  (* x (factorial (sub1 x)
(provide (contract-out [factorial (- (=/c 0) (=/c 0))])))

gives me:

  Contract violation: 'fact' violates '='.
  Value
0.105
  violates predicate
real?
  An example module that breaks it:
(module user racket (require (submod .. fact)) (factorial 0.105))
  (Verification takes 0.05s)

but the value 0.105 shouldn't violate the predicate real? I think.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Expansion size vs. zo file size

2014-11-14 Thread Asumu Takikawa
On 2014-11-11 17:25:37 -0500, Asumu Takikawa wrote:
 I found this unintuitive. Is there anything I can do to get the bytecode
 compiler to help me out here?

FWIW, I also tried looking at the optimizer logs in both cases to see if
there was much difference. Grepping for inlining shows counts of 75
vs. 47 for compiling matrix.rkt (post/pre change and ignoring the
inlining that goes on for modules like '#%util).

So maybe this is just a time/space tradeoff that I can't do much about.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Expansion size vs. zo file size

2014-11-11 Thread Asumu Takikawa
Hi all,

I'm currently trying to improve Typed Racket's contract generation. I
have a change which improves time/memory usage and also the size of the
expanded code.

The trouble is that despite the decrease in the size of the expanded
code, the resulting zo files are actually *larger*.

I found this unintuitive. Is there anything I can do to get the bytecode
compiler to help me out here?

Here are the numbers:

 with change  without change
  matrix.rkt expansion |   264K |  524K
  --
  matrix.rkt zo file   |  1036K |  820K

If you'd like to try to reproduce this, the branch I'm operating on is
here:
  https://github.com/takikawa/racket/tree/tr-experimentation-2

I got the expansion size with:
   raco expand matrix.rkt  matrix-expansion
   du matrix-expansion

and just `du compiled/matrix_rkt.zo` for zo file size. This is for
matrix.rkt in the math library.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #29450: master branch updated

2014-10-28 Thread Asumu Takikawa
On 2014-10-28 12:05:12 -0400, sa...@racket-lang.org wrote:
 | Avoid requires of contracts when they're not used.
 |
 | This changes when various libraries that provide contract
 | support to possible contracted bindings to declare when
 | those bindings are needed.

Is there some unit test we can write that will check to make sure these
requires are not included when they're not used?

(I ask because there are some refactorings of contract generation I'd
 like to merge eventually and I don't want to break the improvement
 you've made here)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #29452: master branch updated

2014-10-28 Thread Asumu Takikawa
On 2014-10-28 17:58:49 -0400, as...@racket-lang.org wrote:
 64bc7d4 Asumu Takikawa as...@racket-lang.org 2014-10-28 17:41
 :
 | Send thunks to check-syntax for type tooltips
 |
 | This avoids the cost of computing the printed types
 | to some degree. It still does have overhead (~5%) over
 | not computing anything related to tooltips because of
 | the cost of traversing the type table and computing
 | tooltip locations.

Actually I may have mismeasured this and I think the overhead may be
lower or non-significant. I'll just wait for DrDr to run on a few pushes
and see how the test graphs look.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Proposed addition of #:where clause to the match library

2014-10-24 Thread Asumu Takikawa
Hi Michael,

On 2014-10-24 17:55:24 +, Michael Bernstein wrote:
Proposed Racket version (based on the Erlang example)
uses #:where keyword:
(define/match (insert X lst)
  [{ X '() }                          (list X)]
  [{ X (cons H T) } #:where (= X H)  (list* X H T)]
  [{ X (cons H T) }                   (cons H (insert X T))])
(define (insertion-sort lst)
  (foldl insert '() lst))

You can write this as:

  (define/match (insert X lst)
    [{ X '() }                          (list X)]
    [{ X (cons H T) } #:when (= X H)   (list* X H T)]
    [{ X (cons H T) }                   (cons H (insert X T))])
  (define (insertion-sort lst)
    (foldl insert '() lst))

Note that #:where is replaced by #:when. I believe this works in Racket
v6.0 and later.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Racket build crashes on CGC mode

2014-09-08 Thread Asumu Takikawa
Hi all,

I've found a reproducible crash while building Racket using the CGC mode
on my Linux machine:

  $ ../configure --enable-cgcdefault --enable-sgc
  $ make  make install

  [... output ...]

  raco setup: 2 making: collects/file
  While receiving message from parallel-do worker 0 UNKNOWN::98: read:
  bad syntax `#'
  Makefile:178: recipe for target 'install-cgc' failed
  make[1]: *** [install-cgc] Error 1
  make[1]: Leaving directory
  '/home/asumu/plt/racket-sgc/racket/src/build'
  Makefile:86: recipe for target 'install' failed
  make: *** [install] Error 2
  $ WORKER SEND MESSAGE ERROR: error writing to stream port
system error: Broken pipe; errno=32
  WORKER SEND MESSAGE ERROR: error writing to stream port
system error: Broken pipe; errno=32
  WORKER SEND MESSAGE ERROR: error writing to stream port
system error: Broken pipe; errno=32
  WORKER SEND MESSAGE ERROR: error writing to stream port
system error: Broken pipe; errno=32

(I don't actually need to use CGC, but I was just curious to see what
 would happen)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] SGC as default

2014-08-11 Thread Asumu Takikawa
On 2014-08-12 05:16:21 +0100, Matthew Flatt wrote:
 If you have an existing build in a repo checkout, then `make` is likely
 to fail, because the makefile dependencies are not precise enough to
 deal with the switch. You can discard your old build directory, or it
 might work to simply delete

   builddir/racket/libmzgc.a

The build didn't work for me in an existing checkout, so I tried making a fresh
one and still got this failure:

  make xsrc/precomp.h
  make[7]: Entering directory 
'/home/asumu/plt/racket-fresh/racket/src/build/racket/gc2'
  env XFORM_PRECOMP=yes ../racketcgc -G 
/home/asumu/plt/racket-fresh/build/config -cqu ../../../racket/gc2/xform.rkt 
--setup . --cpp gcc -E -I./.. -I../../../racket/gc2/../include -pthread   
-DUSE_SENORA_GC --keep-lines -o xsrc/precomp.h 
../../../racket/gc2/precomp.c
  Segmentation fault
  Makefile:202: recipe for target 'xsrc/precomp.h' failed
  make[7]: *** [xsrc/precomp.h] Error 139

Anything I should try to debug this?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v6.1

2014-08-01 Thread Asumu Takikawa
On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote:
 asumu:
 - removed mzlib/class100 (5711e900)
 - classes and TR (various)

I don't have anything in particular for classes.

For TR, we should add Stephen's contribution of async-channel support:

  * Typed Racket now supports asynchronous channels using the
`typed/racket/async-channel' library.

I also added a new syntax for asymmetric filters. Is that worth
including? (and the filter syntax is now documented)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v6.1

2014-08-01 Thread Asumu Takikawa
On 2014-08-01 13:54:15 -0400, Asumu Takikawa wrote:
 On 2014-07-28 14:33:07 -0400, Ryan Culpepper wrote:
  asumu:
  - removed mzlib/class100 (5711e900)

Whoops, sorry, we should actually put in a blurb about class100 though.

  * As noted in the v5.3.2 release, the `mzlib/class100` library is
deprecated. The library has now been removed from the distribution.
Use `racket/class` instead.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Problem with Values type constructor

2014-07-28 Thread Asumu Takikawa
On 2014-07-23 20:20:56 +0100, Antonio Menezes Leitao wrote:
Although the typed racket documentation mentions Values as a type
constructor, it does not work:

[...]

Am I missing something?

Nope, this is just a bug. Thanks for the report. I've pushed a fix to
git.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] flatten-begin

2014-07-21 Thread Asumu Takikawa
On 2014-07-19 23:12:51 -0400, Asumu Takikawa wrote:
 This sounds like a nice solution and it would be fine for my use-case
 too. Anyone have any reasons against? (otherwise I can make the change)

I just realized that `flatten-begin` actually doesn't care if the form
starts with a `begin`. In other words, the following evalutes like this:

  (flatten-begin #'(a 1 2)) = (list #'2 #'3)

In which case the behavior of #:all? becomes a bit weird since it would
care about the head being a `begin` (otherwise it would collapse too
manay things).

Maybe the recursive flattener should be a different function after all?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Pre-Release Checklist for v6.1

2014-07-21 Thread Asumu Takikawa
On 2014-07-21 16:14:27 -0400, Vincent St-Amour wrote:
 Sam, Asumu, Eric: what's new for this release?

This came up on IRC the other day. I think Eric was saying the main
changes were inference speedups, support for contracted functions, and
better keyword support.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] flatten-begin

2014-07-19 Thread Asumu Takikawa
On 2014-07-18 09:52:26 -0500, Robby Findler wrote:
 Unless someone knows why it is a bad idea, how about adding a #:all?
 argument that flattens all the way down?

 I don't see many uses of flatten-begin in our tree, but the one in
 compatibility/package sure looks like it could use the #:all?
 argument. Ditto the one in TR (in class-prims.rkt). And I'm pretty
 sure that replacing the hand-rolled loops in drracket for doing this
 (they predate that library) would use the #:all? argument if they were
 rewritten.

This sounds like a nice solution and it would be fine for my use-case
too. Anyone have any reasons against? (otherwise I can make the change)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] flatten-begin

2014-07-18 Thread Asumu Takikawa
On 2014-07-17 22:17:18 -0500, Robby Findler wrote:
Why doesn't flatten-begin already do this?

I'm not sure. I was hoping someone else could tell me. :)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] flatten-begin

2014-07-17 Thread Asumu Takikawa
Hi all,

I was wondering what people think about a potential API addition to the
`syntax/flatten-begin` library.

Something like `flatten-begin*` (or a less terrible name) that would
recursively flatten `begin` expressions like the `flatten` function does
for plain lists.

i.e.,
  (flatten-begin* #'(begin (begin 1 2) 3 4)) = (list #'1 #'2 #'3 #'4)

as opposed to
  (flatten-begin #'(begin (begin 1 2) 3 4))  = (list #'(begin 1 2) #'3 #'4)

Would that be useful? I keep finding myself writing functions like this.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] FOOL 2014 Call for Papers

2014-07-14 Thread Asumu Takikawa
Call For Papers

  21th International Workshop on
  Foundations of Object-Oriented Languages
   (FOOL 2014)
A Workshop of SPLASH (OOPSLA) 2014
   Portland, Oregon, United States.

http://homepages.ecs.vuw.ac.nz/~servetto/Fool2014/

Important dates:
- August 15, 2014 Abstract submission
- August 23, 2014 Full paper submission
- September 26, 2014 Notification
- October 10, 2014 Paper due for informal proceedings
- October 20-24, 2014 Workshop
  (the day is still to be decided)

The search for sound principles for object-oriented languages has
given rise to much work during the past two decades, leading to a
better understanding of the key concepts of object-oriented languages
and to important developments in type theory, semantics, program
verification, and program development.

Submissions for this event are invited in the general area of
foundations of object-oriented languages. Topics of interest include
language semantics, type systems, type modifiers, memory models,
program verification, object capabilities, formal calculi, concurrent
and distributed languages, database languages, and language-based
security issues.

Papers are welcome to include formal descriptions and proofs, but
these are not required; the key consideration is that papers should
present novel and valuable ideas or experiences. The main focus in
selecting workshop contributions will be the intrinsic interest and
timeliness of the work, so authors are encouraged to submit polished
descriptions of work in progress as well as papers describing
completed projects.

We solicit submissions on original research not previously published
or currently submitted for publication elsewhere. The program chair
should be informed of any related submissions; see the ACM SIGPLAN
Republication Policy. Submissions should be PDF in standard SIGPLAN
10pt conference format for a US-letter size page. While submissions
can be up to 12 pages, shorter papers describing promising preliminary
work are also encouraged. Papers must be submitted electronically via
EasyChair.


***NEW: Future of Object-Oriented Foundations session at FOOL 2014***

Over the past 20 years, research presented at FOOL has lead to a more
solid understanding of the foundations of today's object-oriented
programming languages.  At the same time, new object-oriented
languages and concepts are constantly being proposed, and there remain
core topics that have not yet been fully explored.  This year at FOOL
2014, we will hold a special session on the Future of Object-Oriented
Foundations (FOOF).  For this session, we solicit short papers as well
as brief position statements regarding future research in
object-oriented foundations:
- A short paper will have the same format as regular submissions to
FOOL, and will be reviewed in a similar way, but will be limited to 4
pages.
 - A position statement includes a title, authors, and 2-3 paragraphs
of text summarizing the position.  These will be lightly evaluated to
ensure the position is of interest to the community.

Authors of short papers will be given short presentation slots to
present them in the FOOF session.  One author of each position
statement will be invited to participate in an panel related to the
position statement's topic.  Possible topics include, but are not
limited to: brands, tags, and pattern matching; module systems and
modularity; protocols, typestate, and sessions; ownership,
permissions, and immutability; concurrent and distributed object
models; OO logics and reasoning; and gradual/hybrid types and
verification.

An informal proceedings will be made publicly available on the web
page. However, presentation at FOOL does not count as prior
publication, and many of the results presented at FOOL have later been
published at ECOOP, OOPSLA, POPL, and other main conferences.

Program Committee

Ferruccio Damiani
  (University of Turin)
Sophia Drossopoulou
  (Imperial College London)
Truong Anh Hoang
  (Vietnam National University Hanoi)
Hidehiko Masuhara
  (Tokyo Institute of Technology)
Rosemary Monahan
  (National University of Ireland, Maynooth)
Alex Potanin
  (Victoria University of Wellington)
Sukyoung Ryu
  (Korea Advanced Institute of Science and Technology)
Marco Servetto
  (Victoria University of Wellington)
Asumu Takikawa
  (Northeastern University)
Thomas Wies
  (New York Univeristy)
Tobias Wrigstad
  (Uppsala University)
 Elena Zucca
  (University of Genova)

--
Organizers
Marco Servetto (PC Chair)
(Victoria University of Wellington)
James Noble
  (Victoria University of Wellington)
Jonathan Aldrich
  (Carnegie Mellon University )

-
Steering Committee
Jeremy Siek
  (Indiana University Bloomington)
John Boyland
  (University of Wisconsin-Milwaukee)
Atsushi Igarashi
  (Kyoto University)
Shriram Krishnamurthi
  (Brown University)
James Noble
  (Victoria University

Re: [racket-dev] [plt] Push #28936: master branch updated

2014-06-26 Thread Asumu Takikawa
On 2014-06-26 07:30:40 -0400, Sam Tobin-Hochstadt wrote:
Can we make this error message a little more informative? People find this
confusing.

Sure, did you have something in mind?

Something like this?

  Type Checker: cannot apply a function with no known arities;
Function `f` had type Procedure which cannot be applied

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] 2htdp/image Feature Suggestion

2014-06-22 Thread Asumu Takikawa
On 2014-06-22 20:27:21 -0700, Kevin Forchione wrote:
Thanks! Is there any documentation or guide on which *styles* to prefer in
writing Racket code? I find myself scratching my head at times in these
matters!

In recent Racket distributions and online docs there's now a style
manual:

  http://docs.racket-lang.org/style/index.html

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Machinery for eliding contracts

2014-06-09 Thread Asumu Takikawa
On 2014-06-09 00:19:40 -0700, Eric Dobson wrote:
 One issue I see is that we need an unforgeable property that the value
 actually came from the typed world so we know that eliding the new
 contract is safe.

 Does this seem like a reasonable thing to support/do people see issues with 
 it?

A potentially useful generalization of this that's not just for TR is to
avoid duplicate complex check ons values (no types involved), making
complicated contracts more feasible.

Imagine a contract that parses a string to see if it is a valid IP
address, for example.

Would this only work for higher-order/behavioral values/types though?
(i.e., not my IP example)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28689: master branch updated

2014-05-06 Thread Asumu Takikawa
On 2014-05-07 00:27:34 -0400, as...@racket-lang.org wrote:
 f638247 Asumu Takikawa as...@racket-lang.org 2014-04-28 17:17
 :
 | Add docs for TR's filter syntax
 :
   M .../scribblings/reference/types.scrbl | 69 
 +++-

Since there's now documentation for the TR filter syntax, we should make
sure before (add1 v6.0.1) that we're ok with what's there. Then we can
also add support for printing the full filters when an option is
enabled.

In particular, some of the documented syntax is currently broken (and
thus nobody could have used it), so it's a good opportunity to change it
if we want.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Preserving trailing zeros in formatting numbers as strings

2014-05-02 Thread Asumu Takikawa
On 2014-04-24 05:25:07 -0400, Kathi Fisler wrote:
I'm generating class notes in HTML via scribble.  I'm trying to include
the number 10.50 (as a price in an test case, so the trailing 0 matters).
 I'm using format to produce the strings that go into the rendered html.
 When I do this (whether with ~a or ~s), the trailing 0 is dropped,
producing 10.5 in my output instead of 10.50.  

Maybe this is too late to be useful (I think the mailing list ate your
post?), but here's one way to do it:

   (~r 10.5 #:precision '(= 2))
  10.50

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v6.0.1

2014-05-01 Thread Asumu Takikawa
On 2014-05-01 13:49:55 -0400, Ryan Culpepper wrote:
 asumu:

  * Types in Typed Racket are now pretty-printed.

  * Function types can now be written in prefix style, which is
now preferred and is used for printing. Infix function types
are still accepted for backwards compatibility.

  * A new `-*' type constructor is used for writing types for
functions with optional and keyword arguments. The notation
is similar to the matching contract combinator.

 - TR :-less syntax (e6e3ab4e, 45d36579, 37b09521, etc)

  * Typed Racket forms do not have a `:' suffix by default now.
For example, the `struct' form replaces `struct:'. The suffixed
versions are all provided for backwards compatibility.

 - explain/warn about Class types?

  * Typed Racket now has preliminary support for classes and
objects. However, it is still experimental and the APIs are subject
to change.

 - TR recursive type aliases (a8cc430d)

  * Type aliases in Typed Racket now support recursion and mutual
recursion. For example, `(define-type (MyList X) (U Null (Pair X (MyList 
X'
is now a valid type alias.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Regular expression types [was Re: [racket-bug] all/14455: wrong type for hash]

2014-04-20 Thread Asumu Takikawa
On 2014-04-20 14:38:50 -0400, Matthias Felleisen wrote:
 This might be one of those areas where we could 'generalize' gradual
 typing.

I think we could do it without fundamentally changing anything about
gradual typing.

The issue is that uniform rest args assume that the type is always a
`(Listof Foo)`. We could instead allow users to write down any type for
the whole rest args list (classes take this approach for `init-rest`).

While it's not a fundamental change, it's also not easy. It would also
complicate the system and add more type syntax for a pretty modest
benefit. (more important for classes which have weird initialization
patterns)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Catching the undefined value

2014-04-16 Thread Asumu Takikawa
On 2014-04-15 21:19:16 -0600, Neil Toronto wrote:
 Does TR not having to worry about #undefined mean that the following
 program will typecheck?

   #lang typed/racket

   (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A

   (let ()
 (define: lazy-zeros : (Lazy-Listof Zero)
   (delay (cons 0 lazy-zeros)))
 lazy-zeros)

Yes, that should be the case. Here's an interaction from my pull request branch
for removing undefined handling in TR:

  Welcome to Racket v6.0.1.3.
  - (define-type (Lazy-Listof A) (Promise (Pair A (Lazy-Listof A
  - (let ()
   (define: lazy-zeros : (Lazy-Listof Zero)
 (delay (cons 0 lazy-zeros)))
   lazy-zeros)
  - : (Lazy-Listof Zero)
  #promise:lazy-zeros

That's assuming there aren't any design problems with that PR that come
up in code review.

 BTW, I was happy to see that the type `Lazy-Listof' could be defined like
 that when coming up with the example.

:D

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Catching the undefined value

2014-04-15 Thread Asumu Takikawa
On 2014-04-15 18:13:31 -0400, claire alvis wrote:
 The push below includes changes to letrec expressions, internal
 definitions, units, classes, and certain ill-formed shared expressions so
 that they no longer leak the `undefined' value.

This is great! (especially happy that TR, even with classes, doesn't
have to worry about #undefined anymore)

BTW, I found this weird behavior:

  Welcome to Racket v6.0.1.3.
  - (require racket/unsafe/ops)
  - (let () (+ x 3) (define x 3) 5)
  ; x: variable used before its definition [,bt for context]
  - (let () (unsafe-fx+ x 3) (define x 3) 5)
  5

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] class100 removal

2014-04-14 Thread Asumu Takikawa
Hi all,

A few releases ago we announced our intention to remove the
mzlib/class100 library from Racket. I think this was scheduled to happen
around either last release or this upcoming release.

Should I go ahead and remove mzlib/class100 and its docs? Its uses in
the codebase should be long gone (I removed the last remaining uses a
while back).

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] class100 removal

2014-04-14 Thread Asumu Takikawa
On 2014-04-14 15:42:18 -0500, Robby Findler wrote:
 Lets have a full cycles without it in the git tree before the release,
 but otherwise, I think so yes.

Okay, then I'll remove it after v6.0.1 is released.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28450: master branch updated

2014-03-31 Thread Asumu Takikawa
On 2014-03-31 20:01:07 -0700, Eric Dobson wrote:
 Do we have a performance test case which shows improvment with this change?

No, it turns out I misdiagnosed the issue and there was no performance
bug. See commit 8a93eeb52bd7c98c5a060ca019bdc8f4c5a0b09c for the actual
fix.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28213: master branch updated

2014-02-20 Thread Asumu Takikawa
On 2014-02-20 20:31:56 -0700, Neil Toronto wrote:
 How close is this to being able to support, say, the plot library
 converted to TR? The OO stuff in it is a few custom classes without
 anything complicated, a couple of snip% descendants, and drawing
 onto device contexts.

Should be very close. Not quite there currently because there are two
more chunks that I've written and haven't pushed yet:

  * Implicit (mutual) recursive type aliases, so that a `define-type`
can define mutually recursive type alises like the types for
`bitmap%` and `bitmap-dc%`.

  * Types for everything in racket/gui and a few other libraries.
Types for the framework are still work-in-progress.

  * Full contract support.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28213: master branch updated

2014-02-20 Thread Asumu Takikawa
On 2014-02-20 23:03:22 -0500, Asumu Takikawa wrote:
 Should be very close. Not quite there currently because there are two
 more chunks that I've written and haven't pushed yet:

   * Implicit (mutual) recursive type aliases, so that a `define-type`
 can define mutually recursive type alises like the types for
 `bitmap%` and `bitmap-dc%`.

   * Types for everything in racket/gui and a few other libraries.
 Types for the framework are still work-in-progress.

   * Full contract support.

Apparently I should learn how to count though. :p

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28213: master branch updated

2014-02-20 Thread Asumu Takikawa
On 2014-02-20 21:25:59 -0700, Neil Toronto wrote:
 You mean something like this would work?

   (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X)))
   (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X

Yes, that should work. Here's an example interaction from my development
branch:

  Welcome to Racket v5.90.0.10.
  - (let () (define-type (Leaf1 X) (Pair (Leaf2 X) (Leaf2 X)))
 (define-type (Leaf2 X) (U X (Pair (Leaf1 X) (Leaf1 X
 (define: x : (Leaf1 Integer) (cons 3 (cons (cons 5 5) (cons 6 5
 x)
  - : (Leaf1 Integer)
  '(3 (5 . 5) 6 . 5)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Testing for Racket v6.0

2014-02-14 Thread Asumu Takikawa
On 2014-02-14 15:55:59 -0500, Ryan Culpepper wrote:
 If you are interested in helping, please reply to this message to
 the mailing list and include the configuration(s) you are willing
 to test.

I can test the following configurations:

 - Unix build from source, in-place install
 - Unix build from source, minimal, in-place install
 - Windows 64-bit

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Racket v5.92

2014-01-27 Thread Asumu Takikawa
On 2014-01-25 12:55:43 -0500, Ryan Culpepper wrote:
  * Racket's HTML documentation has a new and improved look, thanks to
Matthew Butterick.

BTW, the 5.92 docs are missing some of the recent CSS changes from HEAD.
Could we cherry-pick some of those for 6.0? For example, the blue boxes
don't work here:
  http://docs.racket-lang.org/inside/Evaluation.html

compare to:
  http://www.cs.utah.edu/plt/snapshots/current/doc/inside/Evaluation.html

Also, could we cherry-pick a few documentation commits made recently?
For example, this one:
  https://github.com/plt/racket/commit/d202f415d95ff04e295be101db59402489dc9bfa

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Bug report lost? Here it is again: Issue with help

2014-01-26 Thread Asumu Takikawa
On 2014-01-26 11:45:43 -0500, Greg Hendershott wrote:
 But I didn't get a confirmation email.  And I don't see it using
 advanced query arrival-date  2014-01-24 00:00 GMT.

Is that this bug report by any chance?

  http://bugs.racket-lang.org/query/?cmd=viewpr=14313

Odd that you didn't get a notification though.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Racket v5.92

2014-01-25 Thread Asumu Takikawa
On 2014-01-25 12:55:43 -0500, Ryan Culpepper wrote:
 Racket 5.92 has a new package system, including a catalog of
 hundreds of already-available packages. Please visit

I noticed that the src tarball of v5.92 has a different directory
structure compared to previous releases. Namely, everything is under a
`racket` directory rather than `racket-5.92`.

Is that intentional?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Strange definition of dict-count in docs and tests

2014-01-18 Thread Asumu Takikawa
Hi Gustavo,

On 2014-01-17 19:25:21 -0200, Gustavo Massaccesi wrote:
 The documentation about gen:dict
 http://docs.racket-lang.org/reference/dicts.html#%28def._%28%28lib._racket%2Fdict..rkt%29._gen~3adict%29%29
 says that dict-count accepts one argument. But then it is defined with
 a #:default argument:

Thanks for the report! I agree, it looks like a mistake. I'll push a fix
later.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #28054: master branch updated

2014-01-13 Thread Asumu Takikawa
On 2014-01-13 16:40:17 -0500, Eli Barzilay wrote:
 Why not (string-trim s #:left? #f) ?

Only because I didn't know it existed. Thanks!

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Should `dynamic-require`d libraries be in package dependencies?

2013-11-25 Thread Asumu Takikawa
Hi all,

Should dynamically required libraries induce a package dependency?

Take for example the xrepl-lib package. It currently depends on five
other packages, but I think two of them can be dropped and `raco setup`
won't complain.

On the other hand, XREPL may `dynamic-require` the macro stepper (one of
the dependencies that can be dropped). The same is true for DrRacket
(not listed as a dependency), but it doesn't make much sense to make the
XREPL package depend on DrRacket.

Is there a best practice for these kinds of cases yet?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Check syntax + phase levels

2013-11-21 Thread Asumu Takikawa
Hi all,

Would it be easy to supplement the current background syntax checking to
display the phase level of an identifier use or definition? I was
imagining it could draw the phase number next to the arrow.

I'd be willing to try to implement it myself if it's feasible and
someone points me in the right direction.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] new package system status

2013-11-20 Thread Asumu Takikawa
On 2013-11-20 14:10:05 -0500, Neil Van Dyke wrote:
 * The documentation for the package system in 5.3.6 does not seem to
 reflect previous discussion, and the chapter title still says
 (Beta).

The 5.3.6 docs are by now fairly out of date. Your best bet is to look
at the pre-release docs here:
  http://www.cs.utah.edu/plt/snapshots/current/doc/pkg/index.html

The new first section gives a more helpful overview too.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27802: master branch updated

2013-11-19 Thread Asumu Takikawa
On 2013-11-19 15:22:52 -0500, j...@racket-lang.org wrote:
 80ba30e Jay McCarthy j...@racket-lang.org 2013-11-19 13:22
 :
 | Fix PR14175
 :
   M .../compiler-lib/compiler/commands/test.rkt   | 21 
 +++-

Thanks! I'm not sure it totally fixed the issue though.

This looks better:
  - (require (submod compiler/commands/test paths))
  - (collection-paths racket/gui)
  '(#path:/home/asumu/plt/racket-git/racket/collects/racket/gui)

But shouldn't these return results?
  - (collection-paths typed)
  '()
  - (collection-paths plot)
  '()
  - (collection-paths math)
  '()

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] `collection-path' Considered Brittle

2013-11-04 Thread Asumu Takikawa
On 2013-11-04 11:49:44 -0600, Robby Findler wrote:
collection-path is legacy and should generally be removed when you find it
(I think I fixed two uses of it Saturday in fact).
But hopefully you could use collection-file-path in most cases instead of
a collections-path function.

There are still some cases where you may want a `collection-paths`
function instead though. For example, it would be useful for
`raco-find-collection` so that when a user asks for `typed-racket`, it
can pick a better default than the alphabetic ordering.

(right now you have to ask for `typed-racket/core` to disambiguate,
 which corresponds to using `collection-file-path`)

For my purposes, I could just copy+paste the code in the compiler-lib,
but maybe it should be moved into the core?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] PLT Package Catalog changes

2013-10-12 Thread Asumu Takikawa
On 2013-10-11 16:42:35 -0600, Jay McCarthy wrote:
 I've tested the JS code with most major browsers on Linux and I
 believe I use all standard things (jquery, etc) that are
 cross-browser, but please inform me of any problems you find.

I can't seem to login on the new site. I don't get an error, but there
is no response after clicking Log In. This is using Firefox 24.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg dependency checks and exit code

2013-10-03 Thread Asumu Takikawa
On 2013-10-03 06:45:12 -0600, Jay McCarthy wrote:
 In the first case, you are forgetting to do it and we warn to tell you
 what you should put. In the second case, you put them in but are wrong
 and should be CAUGHT and PUNISHED. I think that's the logic behind it.

That seems fair, but then in the first case, should `raco setup` tell
you which dependencies are missing? It currently just says there are
none (but not which are missing).

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] raco pkg dependency checks and exit code

2013-10-02 Thread Asumu Takikawa
Hi all,

I noticed that if you don't specify any dependencies for a package, then
`raco` will warn you about that.  However, the exit code is 0 and it's
not an error.

Comparatively, if you supply a dependencies field of `empty`, then you
will get a bunch of errors about undeclared dependencies and the exit
code is 1.

Is there a reason why these two cases are treated differently?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27511: master branch updated

2013-09-17 Thread Asumu Takikawa
On 2013-09-17 06:15:42 -0600, Matthew Flatt wrote:
 Yes, please treat missing package dependencies the same as any other
 build error. Mistakes will happen, but they should be corrected as soon
 as possible, even if it requires a stop-gap solution.

Whoops, sorry for breaking the snapshots. I thought undeclared
dependencies were warnings and not errors.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27511: master branch updated

2013-09-16 Thread Asumu Takikawa
On 2013-09-16 16:17:33 -0400, as...@racket-lang.org wrote:
 +@defmodule[math #:no-declare #:link-target? #f]
 +@defmodule[plot/typed #:no-declare #:link-target? #f]

These two lines cause `raco setup` to complain with a warning about
undeclared dependencies. It seems silly, though, to have the TR doc
package force a dependency on `math`. Can I quelch the warning somehow?
(like a I don't really care if the dependency is missing flag)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27395: master branch updated

2013-08-30 Thread Asumu Takikawa
On 2013-08-30 16:15:23 -0400, Sam Tobin-Hochstadt wrote:
 I worry about mutable sets here, but I can't think of any bugs it can
 cause ATM.

I don't have any segfault-causing bugs, but here's a violation of the blame
theorem:

  #lang racket

  (module a0 racket
(define s (mutable-set 1 2 3))
(provide s))

  (module a typed/racket
(require/typed (submod .. a0) [s Any])
(: x (Setof Any))
(define x (assert s generic-set?))
(provide x))

  (require 'a)
  x

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Updating dependency packages from other sources

2013-08-16 Thread Asumu Takikawa
On 2013-08-16 14:27:41 -0600, Matthew Flatt wrote:
 How about allowing a package source as an argument to `raco pkg update`?

 After all, removing an old package implementation and installing a new
 one is already the job of `raco pkg update`, not `raco pkg install`.

I like this idea better than what I suggested earlier.

 I have in mind that `raco pkg update` would treat as package name as it
 does now, instead of like other package sources. That is, it would
 update based on how the package was previously installed.

Right now updates from the local filesystem (say in --copy mode) aren't
tracked. Is the idea to change that so that `raco pkg update foo` will
copy a new version of the package from the filesystem? (assuming it was
installed that way to begin with) Similarly with URL installs, etc. If
so, that sounds great too.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Updating dependency packages from other sources

2013-08-15 Thread Asumu Takikawa
On 2013-08-15 08:19:06 -0600, Jay McCarthy wrote:
 As for what we could do going forward, I think either of these
 approaches could be 'automated'.

Yes, that'd be great.

 For instance, we could add a command like

 $ raco pkg replace x11 new-x11-source

 This would behave like either of those (which would be invisible to the user).

 Do you have any opinions about how you'd want to do this replacement?

Maybe `raco pkg install` can have an additional flag that lets you
replace existing packages? Or maybe it should allow conflicts if the
package has the same name as an already installed package (possibly
prompting/warning the user)?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Updating dependency packages from other sources

2013-08-13 Thread Asumu Takikawa
Hi all,

I have a question about updating packages. I'll use an example
development scenario to frame the question.

Suppose I have package `aosd` installed that depends on `x11`:

  Installation-wide:
   Package  ChecksumSource
   x11  0fc7555f6bc8f09601a75f9d88f44bfa3c4ff632(catalog 
x11)
   aosd 7ab51262a256a324b062d7b407cb5341d1f41f69(catalog 
aosd)

Now suppose I want to work on the `x11` package since I need to upgrade
it for some aspect of the `aosd` package. Right now it's installed from
the package server, but I want to switch it to a linked package from the
filesystem for development.

If I try to remove just the `x11` package so I can replace it, I get
this error:

  $ raco pkg remove x11
  raco pkg remove: cannot remove packages that are dependencies of other
  packages
dependencies:
   x11 (required by: (aosd))

which is reasonable. But I have to remove the package before I can
install it from a different source. The `raco pkg update` command looks
like it might help, but it doesn't let you update from a different
source AFAICT. The `raco pkg install` command won't work because it'd be
a conflicting package.

What are the right steps to install over dependency packages? I don't
think manually uninstalling and re-installing is a good solution.  If n
other packages depended on `x11` too, it seems like I'd have to
re-install all n of them.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27263: master branch updated

2013-08-08 Thread Asumu Takikawa
On 2013-08-08 10:01:41 -0700, Eric Dobson wrote:
 Was this addition intentional?

No, thanks for catching it.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] struct:name exports from 2htdp/image, mrlib/image-core, etc.

2013-08-06 Thread Asumu Takikawa
Hi all,

A few teaching libraries like `2htdp/image` provide struct constructors
and accessors, but don't export the struct type descriptor values. Does
anyone mind if I add the exports to libraries like `2htdp/image`,
`mrlib/image-core`, etc.?

(it's needed for Typed Racket with require/typed)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] chaperone-evt restrictions?

2013-08-02 Thread Asumu Takikawa
Hi all,

I'm currently trying to implement contracts for synchronizable events.
During that, I've discovered that there seems to be an undocumented
restriction that `chaperone-evt` can only chaperone an event that is not
a handle event. Here's an example:

  - (sync (chaperone-evt (handle-evt always-evt identity)
  (lambda (e) (values e identity
  ; wrap-evt: contract violation
  ;   expected: (and/c evt? (not/c handle-evt?))
  ;   given: #evt
  ; [,bt for context]

This is problematic for Typed Racket. If the type system does not
distinguish handle events vs. not (as is the case now), there's no way
to refuse to generate a contract for the `handle-evt` case (which is
necessary if the contract can't work).

Also, is there supposed to be an `impersonate-evt` as well? I've noticed
that the C code has a few code paths that hint at such a primitive, but
it doesn't exist.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] chaperone-evt restrictions?

2013-08-02 Thread Asumu Takikawa
On 2013-08-02 18:32:38 -0400, Asumu Takikawa wrote:
 I'm currently trying to implement contracts for synchronizable events.
 During that, I've discovered that there seems to be an undocumented
 restriction that `chaperone-evt` can only chaperone an event that is not
 a handle event. Here's an example:

I just realized this was supposed to be worded as a question, but I
forgot to include the question: is this a fundamental limitation that I
should work around in the type/contract system or can it be changed?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] git submodule for native-library packages

2013-07-30 Thread Asumu Takikawa
On 2013-07-27 07:10:54 -0600, Matthew Flatt wrote:
 I'm still unsure that submodules are going to be useful for managing a
 kind of main-distribution repository with references to package
 repositories.

Perhaps it would be worth considering using the git subtree feature
instead of submodules for the rest of the repository (just to clarify,
I'm not saying we should reconsider submodules for native-pkgs).

Description here:

  https://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

In particular, this aspect seems useful for us:
  you can also extract the entire history of a subdirectory from
   your project and make it into a standalone project

From what I understand (not having used them yet), subtrees also enable
end users of our main repo to just do a clone without any special
consideration for the subtrees. Only package maintainers would have to
occasionally update the subtrees in the main repo to pull in changes
from their own package repos.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] git submodule for native-library packages

2013-07-30 Thread Asumu Takikawa
On 2013-07-30 17:44:37 -0400, Carl Eastlund wrote:
  I looked into git-subtree, and as I recall it, nothing in the setup
  recalls what subtree is used for what.  Every git-subtree command you
  enter has to be fully explicit, which is a big hassle. 

AFAIK, you are correct. OTOH, I imagine that using subtree commands is
actually going to be relatively rare. Here is my reasoning:

  * You are a developer on a Racket main distribution package:
- Most of your commits will be local to that package while you
  work on it. Let's assume this is in a separate repo (otherwise
  the subtree thing is moot)
- You'll work on a working copy of that package installed instead
  of the core package that ships with release Racket
  (using `raco pkg` to set up the links)
- Assuming the last two points, you are unlikely to use any
  subtree commands until the changes need to be merged for a
  release or for wider use/testing.

  * You are a power user of Racket:
- You'll just clone the whole Racket git repo and automatically
  get all of the subtrees. No additional effort necessary unless
  you want to make changes.

  * You are a developer responsible for the release:
- You will probably end up pulling all subtrees (which is pretty
  manual work) and then cherry-pick all relevant commits.

In comparison, I think submodules are supposed to make it less
convenient for the power user who is just cloning the repo. That said,
this isn't informed by a lot of experience with either feature, so
please take with a salt mine.

Maybe I will try this with Typed Racket somewhere and see what happens.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] git submodule for native-library packages

2013-07-30 Thread Asumu Takikawa
On 2013-07-31 00:04:20 -0400, Asumu Takikawa wrote:
 Maybe I will try this with Typed Racket somewhere and see what happens.

One downside I discovered immediately after trying to set this up:
the subtree command is only available in git 1.7.11 and newer and it's
only available if the contrib tools are packaged in your git install
(it's not in Debian).

I tried using the subtree command to split out the main Typed Racket
package into a separate repo. The result is here:
  https://github.com/takikawa/typed-racket-lib

One issue is that the new repo only has history going back until the
package split. This makes sense, given that the old paths are nonsense
in the new repo. Maybe this is ok if the main Racket repo still has the
history though.

Unfortunately, this experiment didn't work very well. Doing a `git
subtree pull` with just one simple new commit caused a spurious merge
conflict, due to the fact that the new repo's SHA1s are different.
Splitting out the package will require more clever git hackery.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] alarm-evt contract

2013-07-29 Thread Asumu Takikawa
Hi all,

Is there any reason for the documented contract on `alarm-evt` to
specify a non-negative real? The function will happily accept negative
inputs and it seems like that's desirable (if for some reason your
computer clock is set to before 1970 for a good reason).

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Motivation for handle-evt/wrap-evt contracts

2013-07-25 Thread Asumu Takikawa
Hi all,

I had a question about `handle-evt` and synchronizable events in
general. I was trying to understand the documentation and only have a
partial idea of the motivation behind `handle-evt` and the contracts of
`handle-evt` and `wrap-evt`.

In particular, what is the motivation for disallowing objects that
satisfy `handle-evt?` as an argument for `handle-evt` and `wrap-evt`?

As far as I understand, `handle-evt` allows more efficient
post-processing of a synchronization result because the handler is
called in tail position. However, it doesn't seem necessary to disallow
the addition of more handlers (with the caveat that the tail call
guarantee will disappear if this happens).

Am I missing something?

Note: I'm asking because these restrictions in the contracts complicate
the types that we need to assign in Typed Racket:
  https://github.com/plt/racket/pull/379

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Motivation for handle-evt/wrap-evt contracts

2013-07-25 Thread Asumu Takikawa
On 2013-07-25 12:55:25 -0500, Robby Findler wrote:
I think the issue is that the tail guarantee can't be met if there are two
handles (one won't be in tail position wrt to the sync).

I understand. I guess what I'm asking is that there seem to be two
reasonable choices for the semantics here:

  (1) Do not allow an event that is created as a handle event to
  ever have two handlers.

  (2) If an event ever ends up having two handlers, that's okay, but
  it will not respond #t to `handle-evt?`.

My question boils down to why semantics (1) and not (2)?

(though it doesn't matter much if we just choose not to reflect
 this in the type system, but that means you will sometimes
 get a contract error saying expected (not/c handle-evt?) but ...)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Motivation for handle-evt/wrap-evt contracts

2013-07-25 Thread Asumu Takikawa
On 2013-07-25 12:36:32 -0600, Matthew Flatt wrote:
 My thought was that you should only use `handle-evt' if you need tail
 behavior for something like a loop. If you use `handle-evt' and you're
 not getting tail behavior (but `sync' continues on, anyway), then
 something has gone wrong --- and maybe it's better to get an error than
 have a slow leak that will be tricky to detect.

I could see how that might be a better choice for debugging. Especially
since it seems that people don't check `handle-evt?` on events (which
you would need to do to ensure tail-behavior in semantics 2).

In particular, there are zero uses of `handle-evt?` in the codebase
outside of tests.

Since it's primarily a performance debugging feature, it seems OK to
ignore the distinction in Typed Racket and keep the current semantics.

Thanks,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] RacketCon Signup

2013-07-24 Thread Asumu Takikawa

  *** Action Item: sign up for RacketCon http://bit.ly/racketconsignup2013 ***

RacketCon 2013 will be taking place at Northeastern University on
September 29. Please sign up at the link above if you plan on attending.

If you are interested in giving a 10 minute talk on something you've
built in or for Racket, please contact the organizers at
racket...@racket-lang.org

Cheers,
Asumu Takikawa
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] expand, local-expand, and syntax-procedure-converted-arguments-property

2013-07-10 Thread Asumu Takikawa
Hi all,

I'm currently trying to fix the Typed Racket unit tests. I think I've
narrowed down the issue to a certain syntax property for keyword
functions.

The issue is illustrated by the following example:

  #lang racket

  (require racket/file
   (for-syntax racket/file
   racket/keyword-transform))

  ;; the property is #f
  (begin-for-syntax
   (displayln
 (syntax-case (expand-syntax #'(copy-directory/files 1 2)) ()
   [(let-values (((temp1) _)
 ((temp2) _))
  (if _
  (#%plain-app1 copy-directory/files15 e1 ...)
  (#%plain-app2 copy-directory/files17 e2 ...)))
(syntax-procedure-converted-arguments-property 
#'copy-directory/files15)])))

  ;; property is syntax
  (begin-for-syntax
   (displayln
 (syntax-case (local-expand #'(copy-directory/files 1 2) 'expression null) 
()
   [(let-values (((temp1) _)
 ((temp2) _))
  (if _
  (#%plain-app1 copy-directory/files15 e1 ...)
  (#%plain-app2 copy-directory/files17 e2 ...)))
(syntax-procedure-converted-arguments-property 
#'copy-directory/files15)])))

There are two syntax-time computations here. Both are expanding an
application of a keyword function (one with local-expand, one with
expand) and looking at the resulting syntax.

The key point here is that I want to find the property looked up by
`syntax-procedure-converted-arguments-property` on an output identifier
because Typed Racket needs it to type-check the expansion.

Unfortunately, as the comments indicate, only the second piece of code
can find the property. The reason appears to be that the property key is
actually a private `gensym`ed symbol and the two pieces of code appear
to get separate instantiations of the kw.rkt module (perhaps at different
phases).

To check that, if I modify kw.rkt to use a plain symbol, both of the
snippets above return the same property value.

Anyone have any idea how I can keep using `expand` but still be able to
look up the property?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Tool warnings from raco

2013-07-09 Thread Asumu Takikawa
Hi all,

I've suddenly started getting odd warnings from `raco` on git HEAD. Any
idea what's going on?

warning: tool make registered twice: make and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool exe registered twice: exe and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool pack registered twice: pack and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool unpack registered twice: unpack and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool decompile registered twice: decompile and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool test registered twice: test and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool expand registered twice: expand and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool distribute registered twice: distribute and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool ctool registered twice: ctool and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool demodularize registered twice: demodularize and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/compiler-lib/compiler/commands
warning: tool docs registered twice: docs and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/racket-pkgs/racket-doc/help
warning: tool check-requires registered twice: check-requires and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/macro-debugger-pkgs/macro-debugger-text-lib/macro-debugger
warning: tool show-dependencies registered twice: show-dependencies and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/macro-debugger-pkgs/macro-debugger-text-lib/macro-debugger
warning: tool scribble registered twice: scribble and 
#path:/home/asumu/plt/racket-pkg/racket/lib/../../pkgs/scribble-pkgs/scribble-lib/scribble

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] snapshot builds

2013-07-03 Thread Asumu Takikawa
On 2013-07-02 13:40:18 -0600, Matthew Flatt wrote:
 The snapshot page has

  * Racket installers with the usual stuff: DrRacket, HtDP support,
etc.

I tried the Racket Windows installer, but AFAICT it's missing DrRacket
and other libraries.

  $ sha1sum.exe /home/asumu/racket-5.3.900.3-i386-win32.exe
  5ba5331efbc0d8d0443dce795f1da045a24a4c21i/

  $ ls
  doc  etc  include  lib  man  Racket.exe  raco.exe  Uninstall.exe

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] snapshot builds

2013-07-03 Thread Asumu Takikawa
On 2013-07-03 22:56:16 -0600, Matthew Flatt wrote:
 The 32-bit Windows Racket installer works for me, this time --- but the
 Mac OX X builds seem completely broken.

Thanks, this time I was able to get DrRacket from the installer.

BTW, one thing that seems broken is if I go to the package manager and click
on Installl from List, I get the following internal error:

  get-all-pkg-details-from-catalogs: bad response from server
url: 
http://www.cs.utah.edu/plt/snapshots/20130703-d2ddfc0/catalog/pkgs-all?version=5.3.900.3
response: #f
context...:
 C:\Program Files\Racket-5.3.900.3\lib\collects\pkg\lib.rkt:2008:2: for-loop
 C:\Program 
Files\Racket-5.3.900.3\lib\pkgs\drracket\pkg\gui\by-list.rkt:321:9: for-loop

I can't seem to reproduce it the same way anymore, but it also happens if I
click Update Package List.

Also, thanks for setting this up!

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #27030: master branch updated

2013-06-27 Thread Asumu Takikawa
On 2013-06-27 22:21:23 -0400, as...@racket-lang.org wrote:
 42b5cfe Asumu Takikawa as...@racket-lang.org 2013-06-27 22:17
 :
 | Use racket/cmdline instead of mzlib/cmdline
 |
 | This should fix the build
 :

This fixes the build on my machine, but there are several more files
left over that have dependencies on `mzlib`. I don't know which are
essential:

  * racket/src/worksp/gc2/make.rkt
  * racket/src/worksp/mzcom/xform.rkt
  * racket/src/racket/gc/upgrade.rkt
  * racket/src/mac/osx_appl.rkt

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Triggered a macro system internal error

2013-06-25 Thread Asumu Takikawa
Hi all,

I accidentally triggered what appears to be an internal error message
from the macro expander (to do with syntax taints).

Unfortunately, I have no idea how to come up with a narrow test case
since it happens due to changing Typed Racket's `struct:` expansion.
I've attached a short patch below that shows what's needed to trigger it
though.

Here's the interaction I get with the patch applied:
  $ racket -I typed/racket
  Welcome to Racket v5.3.900.1.
  - (struct: Foo ([x : Integer]))
  ; internal error: cannot copy taint armings from tainted source [,bt for
  ;   context]

Any ideas on how I can get a better test case?

Cheers,
Asumu
From 4abd6636420c0425b77015ca5a00ecb73230f3c7 Mon Sep 17 00:00:00 2001
From: Asumu Takikawa as...@ccs.neu.edu
Date: Tue, 25 Jun 2013 10:03:02 -0400
Subject: [PATCH] Patch that triggers internal taint error

---
 .../typed-racket-lib/typed-racket/base-env/prims.rkt  |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt
index 548bfe4..d3a8b53 100644
--- a/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt
+++ b/pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/base-env/prims.rkt
@@ -593,7 +593,10 @@ This file defines two sorts of primitives. All of them are provided into any mod
nm.old-spec (fs ...)
#:maker #,cname
#,@mutable?))])
-#'(begin d-s dtsi)))]
+(if (eq? (syntax-local-context) 'top-level)
+#'(begin (module a typed/racket d-s dtsi)
+ (eval '(require 'a)))
+#'(begin d-s dtsi]
 
 
 ;Copied from racket/private/define-struct
-- 
1.7.10.4

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] local-transformer-expand behavior

2013-06-25 Thread Asumu Takikawa
On 2013-06-25 11:02:37 +0200, Matthew Flatt wrote:
 That error is due to a bug in handling the 'top-level context, and I've
 pushed a repair.

Thanks for the repair and nice explanation!

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Things we could move out of the core

2013-06-25 Thread Asumu Takikawa
On 2013-06-25 16:32:28 -0400, Sam Tobin-Hochstadt wrote:
 - mzlib/{pconvert, class100, serialize, thread, transcr}

According to the 5.3 release announcement, class100 is set to be removed
by the August release, so maybe we can just remove it entirely now.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] local-transformer-expand behavior

2013-06-24 Thread Asumu Takikawa
Hi all,

Does anyone know what the behavior of

  (local-transformer-expand #'(define x 3) 'top-level null)

should be? I'm not sure, but I expected something like what
`local-expand` would do. Instead, I get an error like this:

   (define-syntax (m stx)
  (local-transformer-expand
   #'(define x 3) 'top-level null))
   (m)
  ; readline-input:14:51: define: not allowed in an expression context
  ;   in: (define x 3)
  ; [,bt for context]

Am I just misuing the function? I also tried to wrap the quoted
definition with a `let`, but then got errors saying `let-values` is
unbound (which seems odd since it's a core form).

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] engine-kill from racket/engine

2013-06-24 Thread Asumu Takikawa
Hi all,

I was trying to write an example for the racket/engine docs and stumbled
on a case that seems to cause a deadlock. I'm curious if this is
intentional or just accidental behavior.

Here's the example:

  #lang racket
  (require racket/engine)
  (define e (engine (lambda (s) (sleep 5
  (thread (lambda () (sleep 2) (engine-kill e)))
  (engine-run never-evt e)

This will never terminate. If you comment out the fourth line, it will
terminate. If you change `never-evt` to 4000 (or any other event that
will become ready), it's also fine.

What seems to be going on is that `engine-kill` does actually kill the
thread underlying the engine. However, `engine-run` is `sync`ed on (1)
the given event (2) the engine being done or (3) an exception being
raised.  Since `engine-kill` does not trigger any of those, the `sync`
is blocked.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] path-relative-string/setup

2013-06-21 Thread Asumu Takikawa
Hi all,

It looks like in the recent pkg reorganization, the function
`path-relative-string/setup` has disappeared from the
`setup/path-to-relative` module.

As a result, XREPL's ,enter doesn't work anymore and possibly other
things. Is this an intentional omission or was it just lost by accident?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR internal error

2013-06-21 Thread Asumu Takikawa
On 2013-01-21 10:48:48 +0100, Pierpaolo Bernardi wrote:
the file attached causes the following internal error:
Internal Typechecker Error: bad expected: #(struct:tc-results
(#(struct:tc-result Char - -) #(struct:tc-result (Vector Integer Integer
Integer Integer) - -)) #f)
while typechecking:
(#%app vector ah am as af)
originally:
(vector ah am as af)

Thanks for the report! Sorry for not getting around to this earlier, but
I've pushed a fix now.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] ready for the package switch?

2013-06-18 Thread Asumu Takikawa
On 2013-06-18 10:47:01 -0600, Matthew Flatt wrote:
 Because this change will break all sorts of things in the short run,
 I'd like to feel more confident that enough of us are ready before
 merging it to the main Racket repository.

The pkg2 branch builds for me fine (modulo `plot`) and I can run
DrRacket. The `plt-games` executable does not work, however, and just
produces a blank window for me.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.

2013-06-09 Thread Asumu Takikawa
On 2013-06-09 23:25:43 +0530, Mayank Jain wrote:
 While it does autocomplete the closing paren, it does not prevent you from
 breaking the form if I accidentally delete the opening/closing paren.

This is a feature that I like a lot from paredit, because it provides
some level of confidence that I won't have silly mismatched parens.

One improvement over paredit that I'd like to see in a DrRacket port is
to handle #; comments correctly.

For the features of paredit that are already in DrRacket, it'd be nice
if the paredit plugin could just change the keybindings around so that
those of us who are used to emacs+paredit can use it without
re-training (unless this is already the case).

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] member like assoc

2013-06-09 Thread Asumu Takikawa
On 2013-05-31 19:40:52 -0400, Asumu Takikawa wrote:
 Is it feasible to get `member` to have the same optional argument
 behavior as `assoc`? That is, to have an equality predicate as the third
 argument.

I went ahead and implemented this behavior and submitted a pull request:
  https://github.com/plt/racket/pull/366

To see if the change is pay as you go, I ran some microbenchmarks to
see if old-style `member` calls would slow down (see below). There
doesn't seem to be any significant slow-down AFAICT.

I was surprised that the non-JIT version was faster in the first case
but much slower in the second microbenchmark though. (note: I had to
change the C implementation of `member` for the non-JIT path)

I'd appreciate any suggestions on the code.

Cheers,
Asumu

  ;;; NEW BRANCH
  $ racket member-benchmark.rkt
  cpu time: 1748 real time: 1752 gc time: 0
  $ racket --no-jit member-benchmark.rkt
  cpu time: 1524 real time: 1526 gc time: 0

  ;;; MASTER
  $ racket member-benchmark.rkt
  cpu time: 1712 real time: 1716 gc time: 0
  $ racket --no-jit member-benchmark.rkt
  cpu time: 1524 real time: 1528 gc time: 0

The microbenchmark is just this:
  #lang racket/base
  (require (only-in racket/list range))
  (define lst (range 1 5000))
  (time
(for ([i 3])
(member 2500 lst)))

On a slightly different microbenchmark:

  ;;; NEW BRANCH
  $ racket member-benchmark-2.rkt
  cpu time: 2396 real time: 2402 gc time: 0
  $ racket --no-jit member-benchmark-2.rkt
  cpu time: 7156 real time: 7174 gc time: 0

  ;;; MASTER
  $ racket member-benchmark-2.rkt
  cpu time: 2412 real time: 2416 gc time: 0
  $ racket --no-jit member-benchmark-2.rkt
  cpu time: 6892 real time: 6911 gc time: 0

  #lang racket/base
  (define lst '(a b c))
  (time
(for ([i 3000])
(member 'b lst)))

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] member like assoc

2013-06-09 Thread Asumu Takikawa
On 2013-06-09 20:51:21 -0500, Robby Findler wrote:
Do the times change if you put an 'in-range' in the for loops?

Is this the code change you meant?

  #lang racket/base
  (require (only-in racket/list range))
  (define lst (range 1 5000))
  (time
(for ([i (in-range 3)])
  (member 2500 lst)))

  ;;; NEW BRANCH
  $ racket member-benchmark-3.rkt
  cpu time: 1756 real time: 1760 gc time: 0
  $ racket --no-jit member-benchmark-3.rkt
  cpu time: 1524 real time: 1530 gc time: 0

  ;;; MASTER
  $ racket member-benchmark-3.rkt
  cpu time: 1756 real time: 1761 gc time: 0
  $ racket --no-jit member-benchmark-3.rkt
  cpu time: 1532 real time: 1535 gc time: 0

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] member like assoc

2013-06-09 Thread Asumu Takikawa
On 2013-06-09 21:15:31 -0500, Robby Findler wrote:
Sorry: I should have been clearer: I would only expect a difference when
the list is short (so your benchmark 2).

Here're the numbers for that:

  #lang racket/base
  (define lst '(a b c))
  (time
(for ([i (in-range 3000)])
  (member 'b lst)))

  ;;; NEW BRANCH
  $ racket member-benchmark-4.rkt
  cpu time: 1408 real time: 1414 gc time: 0
  $ racket --no-jit member-benchmark-4.rkt
  cpu time: 3724 real time: 3731 gc time: 0

  ;;; MASTER
  $ racket member-benchmark-4.rkt
  cpu time: 1380 real time: 1384 gc time: 0
  $ racket --no-jit member-benchmark-4.rkt
  cpu time: 3616 real time: 3622 gc time: 0

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Project Idea to port Paredit mode to DrRacket.

2013-06-08 Thread Asumu Takikawa
On 2013-06-09 00:06:21 +0530, Mayank Jain wrote:
 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).

That sounds like a great project idea! I just wanted to comment that if
you get this working, I would definitely use it.

 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?

You will probably want to look into the main text editing interfaces in
Racket's GUI library such as editor%, text%, and racket:text%.

  http://docs.racket-lang.org/gui/editor___.html
  http://docs.racket-lang.org/gui/text_.html
  
http://docs.racket-lang.org/framework/Racket.html#%28def._%28%28lib._framework%2Fmain..rkt%29._racket~3atext~3c~25~3e%29%29

(maybe you can port paredit by replacing the emacs text buffer
 manipulation function calls with method calls into these interfaces)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] member like assoc

2013-05-31 Thread Asumu Takikawa
Hi all,

Is it feasible to get `member` to have the same optional argument
behavior as `assoc`? That is, to have an equality predicate as the third
argument.

I find myself writing the (imaginary) equivalent of things like:
  (member id some-list free-identifier=?)

and it seems like it would be nicer with an extra `member` argument than
with `memf`.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] proposal for moving to packages

2013-05-20 Thread Asumu Takikawa
On 2013-05-20 14:42:15 -0600, Matthew Flatt wrote:
 Eventually, when the dust settles, I think we'll want to convert every
 directory to its own git repo, and then we can incorporate the
 individual repos as git submodules.

One nice thing about the current repo organization is that push
notifications for every part of the PLT codebase go to all of the
developers.

Will that still be available in this organization scheme? (I don't care
if it's opt-in too much, but opt-out will hopefully mean more eyes see
the code)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #26861: master branch updated

2013-05-19 Thread Asumu Takikawa
On 2013-05-19 17:55:26 -0700, Eric Dobson wrote:
 This doesn't pass with contract checking enabled. make-StructTop
 requires a Struct? not any old Type?. Is there a reason that the type
 is not just bottom?

In the error case? I'm not sure. TBH, I cargo culted that line. Sam, do
you have an opinion on this? (you had the last commit to touch that line
before me)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] set!-transformers and syntax-local-value/immediate

2013-05-17 Thread Asumu Takikawa
Hi all,

I'm confused about an aspect of set! and rename transformers. I'll
explain with this example:

  #lang racket

  ;; a macro that uses `syntax-local-value/immediate`
  (define-syntax (lookup stx)
(syntax-case stx ()
  [(_ id)
   (let-values ([(f _) (syntax-local-value/immediate #'id)])
 (displayln (rename-transformer? f))
 (displayln (set!-transformer? f))
 #'0)]))

  ;; f is a set!-transformer
  (let-syntax ([f (make-set!-transformer values)])
(lookup f))

  ;; sanity check
  (rename-transformer? (make-set!-transformer values))

In this example, `f` is bound to a set!-transformer. The macro `lookup`
will look up the value bound to `f` at compile-time, and I expected that
the result would be the set! transformer.

However, it seems like the set! transformer is somehow being turned into
a rename transformer (note the two print statements produce #t and #f
respectively). The last line suggests that set! transformers are not
actually a subtype of rename transformers though.

Am I confused about set! transformers or is there a bug here?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] set!-transformers and syntax-local-value/immediate

2013-05-17 Thread Asumu Takikawa
On 2013-05-17 19:51:00 -0400, Carl Eastlund wrote:
 That's where the rename comes from.

Ah, thanks! I should've looked closer at the expansion.

(also thankfully it turns out I didn't need any complicated
 set!-transformer manipulation to do what I was trying to do)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] Package system quickstart section?

2013-05-08 Thread Asumu Takikawa
Hi all,

Would anyone be opposed to adding a Quickstart section to the Package
System documentation page? The current first section[1] is useful, but
it's a pretty dense read for someone who just wants to know how to
install a package.

I'm imagining that the Quickstart would describe where to find packages
(pkg.racket-lang.org, github, etc.) and the commands you need to type to
install a package from typical sources. Maybe screenshots showing how to
use the package GUI.

[1]: http://docs.racket-lang.org/planet2/Package_Concepts.html

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


[racket-dev] [ANN] RacketCon 2013: 29 September

2013-05-08 Thread Asumu Takikawa
RacketCon 2013
--

We are pleased to announce that (third RacketCon) will take place on
September 29, 2013 at Northeastern University in Boston.  This year, we
plan to bring in several speakers from industry, as well as host talks
from Racket developers and users.

Lunch will be provided.

On the Saturday (28th) before RacketCon, we plan to hold a hackathon to work on
various Racket projects.

Registration will open during the summer, and we will post a detailed
schedule of events around the same time. The conference website is at

  http://con.racket-lang.org/

Asumu Takikawa and PLT

_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] else clauses: possible change to match?

2013-05-04 Thread Asumu Takikawa
On 2013-05-04 10:36:14 -0500, Robby Findler wrote:
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.

FWIW, Clojure uses keywords for `else` so there is some experience
there:
  http://clojuredocs.org/clojure_core/clojure.core/cond

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-02 Thread Asumu Takikawa
On 2013-04-04 10:33:25 -0700, Eric Dobson wrote:
 Sometimes TR tests fail with the error

 [...]

 How can this happen? Is the thread getting killed? Also since this
 error doesn't have blame information I don't know if this is an
 internal promise error or if TR is misusing the promise library.

I still don't know the cause of this problem, but the following smaller
example seems to exhibit the issue:

  #lang racket

  ;; Run this in collects/tests/typed-racket/optimizer

  (require unstable/open-place)

  (define (start-worker get-ch name)
(open-place ch (let loop () (loop

  (define-values (enq-ch deq-ch) (place-channel))

  (define (start-workers)
(for ([i 8])
  (start-worker deq-ch i)))

  (define (mk-suite dir)
(define prms (for/list ([name (directory-list dir)]
;; this line appears to be critical for some
;; strange reason
#:when (regexp-match .*rkt$ name))
   (delay/thread 0)))
 (for/list ([p prms])
   (force p)))

  (define (optimization-tests) (mk-suite tests))

  ;;;

  (start-workers)

  (optimization-tests)

;;;

This produces a promise error on every third or fifth run or so for me.
Commenting out the #:when line makes it work, very oddly.

Since this error appears to be raised when the thread is killed
prematurely (e.g., (thread-kill (current-thread)) or via a continuation
abort), I would guess that the promise thread is somehow killed by a
strange interaction with places or something else.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] TR tests sometimes fail with a promise error

2013-05-02 Thread Asumu Takikawa
On 2013-05-02 22:14:44 -0400, Asumu Takikawa wrote:
 This produces a promise error on every third or fifth run or so for me.
 Commenting out the #:when line makes it work, very oddly.

Tried it on another machine, the #:when line didn't matter there. Also,
I can reproduce this more reliably on a machine with fewer cores.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #26710: master branch updated

2013-04-25 Thread Asumu Takikawa
On 2013-04-25 14:55:45 -0400, as...@racket-lang.org wrote:
 a15fa5b Asumu Takikawa as...@racket-lang.org 2013-04-20 23:18
 :
 | Start on a notation section for the Reference
 :

This is in response to the How to read procedure documentation? thread
from the users list. It documents how to read some of the blue boxes
with contracts from the Reference.

I'm not sure this is the best place to put it, so feedback appreciated
on where it should go (or anything else).

Ryan was also suggesting that there should be explanations of blue boxes
interspersed in the Guide as well (in 2.2.4 for example) with more
Guide-like language, which I agree would be a good thing to add.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] take/drop argument order

2013-04-11 Thread Asumu Takikawa
On 2013-04-11 12:05:59 -0400, Eli Barzilay wrote:
   Remove the `*f' functions from the interface, and change the
   non-`*f' functions to accept keywords as follows:

   (take #:num N L)
   (take #:while P L)
   (take #:until P L)

I like this suggestion since keywords seem like a nice Rackety solution.

On the other hand, does this solve the original problem? As I
understand, the original objection was that the `take` arguments should
look familiar to someone from Clojure, Haskell, etc.

Also, what happens if I wrote the following?

  (take #:while P L 5)

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #26558: master branch updated

2013-04-04 Thread Asumu Takikawa
On 2013-04-04 10:29:30 -0700, Eric Dobson wrote:
 Can we make it so that IP addresses are immutable? This would require
 changing make-ip-address to have a call to make-immutable-bytes in
 each case.

That's a good suggestion, thanks.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #26528: master branch updated

2013-04-02 Thread Asumu Takikawa
On 2013-03-30 10:10:20 -0400, ry...@racket-lang.org wrote:
 293b208 Ryan Culpepper ry...@racket-lang.org 2013-03-20 10:52
 :
 | added optional #:grammar clause to defform, etc
 :
   M collects/scribble/private/manual-form.rkt  |  68 -
   M collects/scribblings/scribble/manual.scrbl | 132 
 ++

Is this the preferred way of documenting forms now? It does look more
convenient, and I noticed that `defform/subs` and friends are now
relegated to a smaller corner of the docs.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] take/drop argument order

2013-03-30 Thread Asumu Takikawa
Late reply, but better than never.

On 2013-03-10 16:20:14 -0400, Eli Barzilay wrote:
 Assuming this, here's a suggestion that I made in the past for
 resolving this:

 * Make the existing `take', `drop', `split-at' accept their arguments
   in *either* order.

I'm fine with this.

 * Change the required types for lists to be a null-or-pair, or even
   require a `list?', or require a `list?' but throw an error only if
   scanning gets to a non-null-terminator.  Any of these would make
   sure that the arguments are distinguishable.  (You can currently
   write something like (take 0 1) -- it's not an error.)

I would much prefer a `list?` if backwards compatibility for this isn't
a concern. Has anyone *ever* used the feature that `take` can operate
on non-lists?

 * And another thing that can be done to reduce the name clutter is to
   have only the plain names, but make them accept either an index or a
   predicate.

I'm less sure about this change, since the `f` suffix isn't particularly
verbose and the integer case is likely more common, but I'm not opposed
to it either.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] [plt] Push #26439: master branch updated

2013-03-09 Thread Asumu Takikawa
On 2013-03-09 10:57:28 -0500, sstri...@racket-lang.org wrote:
 7d1ad25 Stevie Strickland sstri...@racket-lang.org 2013-03-09 10:32
 :
 | Revert hack for top-level, institute real fix.
 |
 | As a side-effect of this fix, we don't need the thunking behavior for
 | external identifiers anymore.  Even better!

Very nice!

One problem though. I think this has broken some uses of
`define/contract` in third-party code I have installed. Here's a
boiled-down snippet that shows the issue:

  #lang racket

  ;; breaks
  (define/contract (f x #:y [y 3])
(-* (integer?) (#:y integer?) integer?)
x)

  ;; contract-out ok with same contract
  #;
  (define (f x #:y [y 3]) x)

  #;
  (provide
(contract-out
  [f (-* (integer?) (#:y integer?) integer?)]))

The error I see is:
  dc-bug.rkt:5:19: #%datum: keyword used as an expression
in: #:y
context...:
 standard-module-name-resolver

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Tweaked doc pages

2013-02-26 Thread Asumu Takikawa
On 2013-02-26 09:53:11 -0500, Eli Barzilay wrote:
 I have finally implemented a script that hacks the on-line doc pages.
 Currently, it does the following (and you can see the changes on the
 web now):

Maybe I'm missing something, but the changes have been rolled back from
the main page right? Can you upload the new version somewhere so we can
see what it would look like?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


  1   2   3   >