That seems like a fair summary and since my preference is clearly the
minority one, I'm happy to stick with 'make as-is'. The new mode for
pulling updates will help, as well.
Sam
On Wed, Feb 18, 2015, 7:52 AM Matthew Flatt wrote:
> At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tob
On Tue, Feb 17, 2015 at 8:49 PM, Matthias Felleisen
wrote:
>
> On Feb 17, 2015, at 7:59 PM, Sam Tobin-Hochstadt wrote:
>
>> I expect that the packages that update for Matthias on `make` are
>> packages in "main-distribution",
>
>
> Personally, I have used
On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt wrote:
> At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote:
>> Regardless of that, though, I think we should switch to updating only
>> "main-distribution" (and perhaps "main-distribution-tests"). I d
failure". I guess I would label my preference
`--pull conservative` and that even if you miss the warning, it
wouldn't be so bad -- you almost certainly didn't want to change the
package in that case.
Relatedly, perhaps `raco setup` and `raco pkg update` have too much
output curr
On Tue, Feb 17, 2015 at 11:31 AM, Jens Axel Søgaard
wrote:
> 2015-02-17 14:26 GMT+01:00 Robby Findler :
>> I don't think the libraries are sufficient as is, but I would resist
>> adding aliases.
>
> A alternative: Added the word zip to the documentation index,
> link it to map and have an exampl
I think there are two seperable issues here:
1. Can we make `raco pkg update -a` better/more robust in this case?
2. Should `make` run `raco pkg update -a`?
In reverse order:
- I think `make`, by default, shouldn't update anything, and that we
should have a different Makefile target which updat
On Thu, Jan 22, 2015 at 3:57 PM, Alexis King wrote:
>
> I can work around this in a variety of ways—I can extract this into an
> untyped module and use require/typed, I can use vectors to “fake” structs
> and provide an appropriate interface, etc. Still, I wonder if there are any
> plans to resolv
On Thu, Jan 15, 2015 at 4:33 PM, Alexis King wrote:
> As an update, I’ve made a bit more progress on this. I’ve implemented an
> impersonate-async-channel function, and I’ve actually included this in the
> exports from racket/contract. I also realized the blame information is
> correct, it works f
How does this fit with backward compatibility?
Sam
On Wed, Jan 14, 2015 at 2:26 PM, Jay McCarthy wrote:
> Branch: refs/heads/master
> Home: https://github.com/racket/web-server
> Commit: 1c6411c670c1aa86df507a99c64dfc2701d36c0f
>
> https://github.com/racket/web-server/commit/1c641
tthias% git push
> error: The requested URL returned error: 403 while accessing
> https://github.com/racket/htdp.git/info/refs
>
> fatal: HTTP request failed
>
>
>
>
>
>
> On Jan 11, 2015, at 7:54 PM, Sam Tobin-Hochstadt wrote:
>
> You seem to be using hub
hias% git push
> error: The requested URL returned error: 403 while accessing
> https://github.com/racket/htdp.git/info/refs
>
> fatal: HTTP request failed
>
>
>
>
>
>
> On Jan 11, 2015, at 7:54 PM, Sam Tobin-Hochstadt wrote:
>
> You seem to be using hub fro
You seem to be using hub from the directory you checked out hub in, not the
htdp directory.
Sam
On Sun, Jan 11, 2015, 7:40 PM Matthias Felleisen
wrote:
>
> Sorry I am late to the party but how do I push to the new repos:
>
> I tried
>
> ** Asumu's method:
>
>
> > [:~/Hub/Hub] matthias% hub remo
I think this is the case for everyone.
I've used the `hub` [1] tool to address this. Once I have a checkout,
if I need to push, I do:
$ hub remote add -p racket/typed-racket
and then
$ git push racket
Having an option to `raco pkg update` and `raco pkg install` to use
the corresponding
Over the last couple days, I've set up a continuous integration system
for Racket that runs on Windows, using the service provided by
AppVeyor. You can see the current state here:
https://ci.appveyor.com/project/plt/racket
It's configured by the `appveyor.yml` file in the root of the
`plt/rac
On Fri, Dec 12, 2014 at 8:46 AM, Matthew Flatt wrote:
> At Thu, 11 Dec 2014 17:00:14 -0800, Dan Liebgold wrote:
>> If I use the -X and -S command line parameters to Racket to make my local
>> collects dir the first one searched, it makes it so I can't do (require
>> srfi/1).
>
> Yes, this is subtl
The bug in frtime has been fixed now.
Sam
On Fri, Dec 5, 2014 at 3:06 PM, Stephen Chang wrote:
> One more error, with frtime:
>
> raco setup: 3 making: /frtime
> raco setup: 3 making: /frtime/pkgs
> raco setup: 3 making: /frtime/pkgs/frtime (FrTime)
> racket/share/pkgs/frtime/pkgs/frtime/animati
The rate limit only applies to API calls, not to downloads, so I don't
think that could be it.
Sam
On Fri, Dec 5, 2014 at 1:07 PM, Stephen Chang wrote:
> Typed "make" and it timed out again.
>
> Could it be a github rate limit?
> https://developer.github.com/v3/rate_limit/
> https://developer.gi
er
>/Users/clements/plt2/racket/collects/racket/require-transform.rkt:266:2:
> expand-import...
>
> I think I may just try a fresh checkout, sigh.
>
> All of this is probably JFYI ... I know, you shouldn't abort a make. In the
> past, though, we've been pretty robust in t
On Thu Dec 04 2014 at 11:27:45 AM Matthias Felleisen
wrote:
>
> For those of you who have my level of experience with such things,
> here is what Sam's phrase "I *highly* recommend creating a new clone
> of the repository, and re-running `make`." means, for your value of
> the name 'plt2':
>
> $
I've just push a change to the plt repository that removes almost all
the packages.
The split repositories are all in the `racket` organization on GitHub.
You can see them here: https://github.com/racket/
I *highly* recommend creating a new clone of the repository, and
re-running `make`. This wil
On Wed, Dec 3, 2014 at 6:10 PM, Eli Barzilay wrote:
>
>>> If you're talking about implementing line editing yourself, then my
>>> personal reaction to that would be "wonderful", but doing it properly
>>> is something that is difficult and easy to underestimate
>>
>> I've already done this (adm
On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
wrote:
>
> # Changes for git users
>
> If you build Racket from source from Git, that build now contains
> fewer packages. There is not yet an single-step way to get all of the
> split pkgs as git repositories; we plan to
On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke wrote:
>
>>
>> Packages may find it convenient to build and provide reusable
>> functionality with many organizational names. This is particularly true of
>> "data", as many packages may have useful data structures.
>>
>> Of course, as such support c
On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay wrote:
> On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
> wrote:
>>
>> All the history for the code has been preserved, and for code that
>> dates back before 2005, the history is extended back to the original
>
On Sun, Nov 30, 2014 at 10:44 AM, Matthew Flatt wrote:
>
> There are plenty of real examples where it's sensible for different
> packages to introduce modules in overlapping collections, though.
> Sometimes, it's because different packages implement different facets
> of a conceptual whole, such a
On Sat, Nov 29, 2014 at 8:16 PM, Eli Barzilay wrote:
> On Sat, Nov 29, 2014 at 7:14 PM, Sam Tobin-Hochstadt
> wrote:
>>
>> All the history for the code has been preserved, and for code that
>> dates back before 2005, the history is extended back to the original
>
As Matthias mentioned in his email a few days ago, we're in the
process of splitting the repository so that it doesn't bundle together
so many packages. I've started this process already, and a number of
packages have already been split out. For most people, this won't have
a big impact, but I'll o
adding (require xrepl/readline) to .racketrc.
2. We ship a copy of "libeditline"with xrepl as a built binary, even on linux.
3. We statically link "libeditline" to Racket in the standard distribution.
I think 1 sounds most appealing if we're not ok with dynamically
fall
My understanding of the licensing issues is that if the code works with
both "libeditline" and "libreadline" then it isn't a derived work of
readline, and therefore could be licensed under the LGPL, like the rest of
Racket. Furthermore, turning use of "libeditline" on by default wouldn't be
linking
On Fri, Nov 21, 2014 at 9:29 AM, Eli Barzilay wrote:
> On Fri, Nov 21, 2014 at 8:46 AM, Robby Findler
> wrote:
>> On Fri, Nov 21, 2014 at 12:34 AM, Eli Barzilay wrote:
>>> Not that it matters, but did you try to see if it's the file
>>> permissions?
>>
>> Oh, they are!
>>
>> [...]
>>
>> And that
On Nov 18, 2014, at 11:54 AM, Matthias Felleisen wrote:
>
>>
>> On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt
>> wrote:
>>
>>> On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
>>> wrote:
>>>>
>>>> It's quite possible tha
t 12:05 PM, Matthias Felleisen
wrote:
>
> What I sent is the exact program that produced the attached error in today's
> drracket [updated around 10am].
>
>
>
>
> On Nov 18, 2014, at 11:58 AM, Sam Tobin-Hochstadt
> wrote:
>
>> No, I ran it, it barfed, and then I
m
On Tue, Nov 18, 2014 at 11:54 AM, Matthias Felleisen
wrote:
>
> On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt
> wrote:
>
>> On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
>> wrote:
>>>
>>> It's quite possible that this is Eli's
On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen
wrote:
>
> It's quite possible that this is Eli's bug again, but boy this causes
> headaches:
>
>> Type Checker: parse error in type;
>> type variable must be used with ...
>> variable: Y in: Y
>
> And it points precisely to where Y is follo
ructure type and flat data
are communicated to handlers, and enforces that exception handlers
deal with all possible arguments. As a side-effect, previously
well-typed programs may fail to typecheck.
Sam
>
> Robby
>
> On Wed, Oct 29, 2014 at 5:12 PM, Sam Tobin-Hochstadt
> wrote:
On Wed, Oct 29, 2014 at 6:57 PM, Matthias Felleisen
wrote:
>
> properly -> corresponding fashion?
No, it's a different change (the one I numbered 1. in my first message).
Sam
>
> Otherwise fine
>
>
> On Oct 29, 2014, at 6:54 PM, Sam Tobin-Hochstadt wrote:
>
&g
restriction of an existing type system breaks existing
> programs. If you don't, I'd say
>
> Existing programs may suffer from new type errors
> due to this restriction.
>
>
>
>
>
>
>
> On Oct 29, 2014, at 6:32 PM, Sam Tobin-Hochstadt wrote:
>
Here's another idea:
* To ensure safety, Typed Racket now prohibits raising any values
other than exns and simple flat data. Some existing programs may now
have type errors because of this.
Sam
On Wed, Oct 29, 2014 at 6:12 PM, Sam Tobin-Hochstadt
wrote:
> The reason I don't li
etic.
> There was a problem, we fixed it, but the fix may require some pain of
> our users. There's nothing wrong with that; it's just a fact of life.
> No shame in hiding it.
>
> Robby
>
> On Wed, Oct 29, 2014 at 4:55 PM, Sam Tobin-Hochstadt
> wrote:
>> On
ing this hole
> requires us to disallow some programs that do not signal runtime
> errors." or something like that?
How about "This may result in type errors in existing programs that
rely on the original behavior; specifically, programs that `raise`
higher-order values."
Sam
&
m now rejects, I'd
> be in favor of a slightly different wording.
>
> Robby
>
> On Wed, Oct 29, 2014 at 2:35 PM, Sam Tobin-Hochstadt
> wrote:
>> On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper wrote:
>>>
>>> * Exception handling changed to be safe. This may b
On Wed, Oct 29, 2014 at 3:30 PM, Ryan Culpepper wrote:
>
> * Exception handling changed to be safe. This may break existing
> programs that rely on unsafe behavior.
>
> * Casts and predicates are supported in typed regions.
I think these two bullets (esp the first one) need to make clear that
t
On Tue, Oct 28, 2014 at 12:26 PM, Asumu Takikawa wrote:
> 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 w
ule-bound variable.
Does that sound right? This would be easy enough for me to do.
Sam
>
> At Tue, 21 Oct 2014 22:26:26 -0400, Sam Tobin-Hochstadt wrote:
>> I've found what I think is a bug in the expander where lexical
>> references can get an `identifier-binding` result that s
I've found what I think is a bug in the expander where lexical
references can get an `identifier-binding` result that suggests that
they're module-bound.
In particular, you need these three files:
bugtest.rkt:
(module bugtest "wraptest.rkt")
bugtest.scm:
(define (gcbench)
(define main #f)
Karttunen"
wrote:
>
>
> On Fri, Sep 26, 2014 at 4:05 PM, Sam Tobin-Hochstadt > wrote:
>
>> Instead of changing my Planet package, it would be better to provide
>> an FFI to cairo based on the existing one that's in the library you
>> mention. I don't t
Instead of changing my Planet package, it would be better to provide
an FFI to cairo based on the existing one that's in the library you
mention. I don't think any of my package would be useful for that,
though.
Sam
On Fri, Sep 26, 2014 at 8:44 AM, Antti Karttunen
wrote:
>
> Another question:
>
On Wed, Sep 3, 2014 at 10:53 AM, Jay McCarthy wrote:
> I need to revert this because it horribly breaks the bootstrapping
> phase. It may be possible to make the core have a package in the
> future, but it's not an easy change.
Is this because code expects #f instead of "base"? Or for some other
On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt wrote:
> At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:
>>
>> Can you provide some guidelines on docs naming?
>> I am responsible for half of the conflicts. :-)
>
> A package "X" that provides a collection "X" of the same name should
> probably
;trusted'
> 'thing' in this case except that this would open the door for other such
> things.
>
>
>
>
> On Aug 17, 2014, at 3:39 PM, Sam Tobin-Hochstadt wrote:
>
>> How would that change things here? The issue is about
>> finalizer-for-what,
How would that change things here? The issue is about
finalizer-for-what, and that chaperones/impersonators affect object
identity.
Sam
On Sun, Aug 17, 2014 at 3:37 PM, Matthias Felleisen
wrote:
>
> Could we benefit from an abstract/opaque Finalizer type here? I know we don't
> have those yet b
That's clearly the right solution for this particular bug, but it does
seem like there's a more general problem here.
Sam
On Sat, Aug 16, 2014 at 10:40 AM, Robby Findler
wrote:
> Seems simplest to be to have typed racket know to trust register finalizer
> and thus avoid wrapping it with a contra
How difficult would it be to allow the bootstrap process to use a
preexisting Racket installation? This would alleviate some of the
performance loss, for example in rebuilds by developers or in continuous
integration.
Sam
On Aug 11, 2014 11:16 PM, "Matthew Flatt" wrote:
> I've changed the Racket
Great, thanks.
On Jul 29, 2014 10:34 PM, "Matthew Flatt" wrote:
> Sorry that I lost track of this one. I've pushed a repair.
>
> At Tue, 29 Jul 2014 16:26:21 -0700, Sam Tobin-Hochstadt wrote:
> > Here's a simpler version of this problem:
> >
> > #la
Here's a simpler version of this problem:
#lang racket
(parameterize ([current-namespace (make-base-namespace)])
(expand (datum->syntax
#f
'(module m '#%kernel
(#%declare #:cross-phase-persistent)
Sam
On Wed, Jul 16, 2014 at 1
`#:when` and `#:unless` introduce nesting, a la `for/fold*`. So yes,
you should expect this.
Sam
On Tue, Jul 29, 2014 at 1:23 PM, J. Ian Johnson wrote:
> This will eat all your memory,
>
> (for/list ([x '(0 1 2 3 4 5 6)]
>#:unless (= x 4)
>[i (in-naturals)])
> x)
>
> an
Plumbers look like a fundamental new runtime system concept, and so I think
we should mention them, even though most people won't use them.
Sam
On Jul 29, 2014 4:02 AM, "Matthew Flatt" wrote:
> At Mon, 28 Jul 2014 14:33:07 -0400, Ryan Culpepper wrote:
> > mflatt:
> > - ARM JIT: fix software floa
On Fri, Jul 25, 2014 at 10:39 AM, wrote:
>
> | As far as I can tell, we have to compute ourselves whether a
> | date is in daylight-saving time based on specifications of
> | when daylight and standard times start. That part seems tricky
> | and could use extra review.
>From a quick search of th
ss I still have it wrong, the implementation of 2 was
> straightforward.
>
> I would have overlooked the need to restrict `chaperone-struct` to
> chaperones of accessors and mutators if you hadn't mentioned it.
>
> At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt
by
> >
> > On Thu, Jul 24, 2014 at 3:25 PM, Matthew Flatt
> wrote:
> >> Nice example. Offhand, I think that #2 is right, but I'll have to look
> >> at it more to be sure.
> >>
> >> At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
>
should be supported.
Sam
On Thu, Jul 24, 2014 at 4:25 PM, Matthew Flatt wrote:
> Nice example. Offhand, I think that #2 is right, but I'll have to look
> at it more to be sure.
>
> At Thu, 24 Jul 2014 15:45:18 -0400, Sam Tobin-Hochstadt wrote:
>> Consider the followi
that `y` has
no apparent binding.
At this point it seems unlikely that it's a bug, since it happens all
the time, but I still don't understand.
Sam
On Thu, Jul 24, 2014 at 4:08 PM, Sam Tobin-Hochstadt
wrote:
> If you take this program (which is a lot like the implementation of
> `racket/
If you take this program (which is a lot like the implementation of
`racket/fixnum`):
#lang racket/base
(require '#%flfxnum
racket/private/vector-wraps
racket/unsafe/ops
(for-syntax racket/base))
(define-vector-wraps "fxvector"
"fixnum?" fixnum?
fxvector? fxvector-
Consider the following module:
(module m racket
(struct x [a])
(define v1 (x 'secret))
(define v2 (x 'public))
(provide v1 v2)
(provide/contract [x-a (-> x? (not/c 'secret))]))
It appears that this ensures that you can't get 'secret. But, it turns
out that I can write a function outside
The margin-notes appear to work correctly on Chrome but wrong on
Firefox on my Linux system.
Sam
On Wed, Jul 23, 2014 at 8:13 AM, Robby Findler
wrote:
> Believe it or not I actually tried that. Screenshot:
> http://www.eecs.northwestern.edu/~robby/tmp/x.png (that's Chome and
> Safari).
>
> Robby
mbol that you need?
>
> At Wed, 16 Jul 2014 23:32:46 -0400, Sam Tobin-Hochstadt wrote:
> > Ok, I thought I had figured this out, but I was wrong.
> >
> > Here's what I want to be able to do:
> >
> > - take an identifier in a fully-expanded source file
>
Matthew Flatt wrote:
> Yes, it can be ".2", etc. The numbers are generated as needed to create
> distinct names --- deterministically for a given module compilation,
> assuming that all macros used by expansion are deterministic.
>
> At Wed, 16 Jul 2014 07:36:50 -0400, Sam Tobin-
Running `expand` on the module defined in `racket/tcp` errors.
In transcript form:
-> (define p (open-input-file
"/home/samth/sw/plt/racket/collects/racket/tcp.rkt"))
-> (define mod (read-syntax (object-name p) p))
-> (parameterize ([current-namespace (make-base-namespace)])
(expand (namespa
other words, `posn1.1` bridges (in an ugly way) the symbol-based
> world of module environments and the identifier-based world of syntax.
> In the future, I hope to shift module environments to be
> identifier-based to avoid these unreadable symbols.
>
> At Tue, 15 Jul 2014 09:10:26 -04
s helpful. I have not yet come
> across a need for this however.
> I can wait on this feature of struct-out (and probably contract-out's struct
> form as well).
If we don't actually have a need for this, then let's wait, since it
seems like it adds a bunch of complex
On Tue, Jul 15, 2014 at 9:23 AM, J. Ian Johnson wrote:
> I'm working on enhancing struct-info to carry field names as symbols to do
> nice hygienic things:
>
> http://lists.racket-lang.org/users/archive/2014-July/063271.html
>
> I now see that struct-out always provides all field accessors in the
If you take this program and fully-expand it in the macro stepper:
#lang racket
(struct posn (x y))
(define p1 (posn 1 2))
You see that the residual program has an application of the `posn1`
function, which is the hidden constructor. And indeed, the
fully-expanded program has a definition of `pos
't think the additional line in that error message is very
helpful, and it's already a long and scary error message.
Sam
> Let's try this experiment for a while and see what happens.
>
>
>
>
> On Jul 14, 2014, at 9:46 AM, Sam Tobin-Hochstadt wrote:
>
>
gument: the user didn't write the compiler but they
> wrote the contract.
>
> Robby
>
>
> On Monday, July 14, 2014, Sam Tobin-Hochstadt wrote:
>>
>> This seems like a situation where the new error message is potentially
>> more confusing, even though it
This seems like a situation where the new error message is potentially
more confusing, even though it's technically more correct. There are
lots of other caveats we could add ("assuming there isn't a compiler
bug", etc) but I think adding them would make Racket harder to use.
Sam
On Mon, Jul 14,
anks for the report!
>
> At Wed, 9 Jul 2014 09:39:50 -0400, Sam Tobin-Hochstadt wrote:
> > The following exchange with rudybot, which is running the programs in
> > a sandbox, demonstrates the issue:
> >
> > 09:35 rudybot: eval (let () (local-require compiler/zo-mars
The following exchange with rudybot, which is running the programs in
a sandbox, demonstrates the issue:
09:35 rudybot: eval (let () (local-require compiler/zo-marshal
compiler/zo-structs racket/fasl) (fasl->s-exp (zo-marshal
(compilation-top 3 (prefix 0 '() '()) (let-void 1 #t (install-value 1
0
On Tue, Jul 8, 2014 at 11:35 AM, Matthew Flatt wrote:
> At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote:
>> - I wonder if using Docker instead of VirtualBox could make
>> incrementality easier, since that's one of things that they focus on.
>
> I don'
This is lovely.
A few thoughts:
- I wonder if using Docker instead of VirtualBox could make
incrementality easier, since that's one of things that they focus on.
- I wanted to be able to see which of my packages had problems, so I
wrote this PR: https://github.com/plt/racket/pull/721 but I'm not
On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt wrote:
> At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote:
>> On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote:
>> > The rightmost column of the table may need some explanation. The column
>> > highlights conflicts among names of package-inst
On Wed, Jul 2, 2014 at 12:52 AM, John Clements
wrote:
>
> On Jul 1, 2014, at 3:46 PM, Sam Tobin-Hochstadt wrote:
>
>> I disagree strongly that this is un-rackety. Consider the following loop:
>>
>> (define v )
>> (let loop ([i 100])
>> (define e (ve
I disagree strongly that this is un-rackety. Consider the following loop:
(define v )
(let loop ([i 100])
(define e (vector-ref v i))
(cond [(zero? i) null]
[(= 999 e) null]
[(even? e) (loop (add1 i))]
[else (cons e (loop add1 i))]))
I don't think that's un-
I think this is a good idea, and something that I've wanted for a long
time. But there are ways to make it much better, and generalize to all
loops.
First, recognize that a `for/...` loop is really a recursive function,
which is passing along a bunch of arguments. In this setting,
`continue` means
On Mon, Jun 30, 2014 at 5:25 AM, Matthew Flatt wrote:
> Similarly, I don't know how much it makes sense to document refinements
> to types in `typed/...` libraries (and I'll leave that question to the
> TR implementers).
I think we make a design choice to make a type stricter/less strict,
it's w
dfs in pdf.js via their demo features, I see
> no difference.
>
> What latex distribution are you using?
This is TeX Live, I think 2013 with some modifications that Debian/Ubuntu
makes.
Sam
> Robby
>
>
> On Mon, Jun 30, 2014 at 6:50 AM, Sam Tobin-Hochstadt
> wrote:
> >
On Fri, Jun 27, 2014 at 2:23 PM, Matthew Flatt wrote:
> At Fri, 27 Jun 2014 13:43:46 -0400, Sam Tobin-Hochstadt wrote:
>> On Fri, Jun 27, 2014 at 12:30 PM, Matthew Flatt wrote:
>> > At Fri, 27 Jun 2014 11:56:39 -0400, Sam Tobin-Hochstadt wrote:
>> >> On Fri, Jun
On Fri, Jun 27, 2014 at 12:30 PM, Matthew Flatt wrote:
> At Fri, 27 Jun 2014 11:56:39 -0400, Sam Tobin-Hochstadt wrote:
>> On Fri, Jun 27, 2014 at 11:45 AM, Matthew Flatt wrote:
>> > For some reason, the way that PDF fragments are pulled in by `pdflatex`
>> > makes
accurate format,
at least when self-contained and not using system fonts, and thus
there wouldn't be any such heuristics. Is that not true?
Sam
> At Fri, 27 Jun 2014 11:30:06 -0400, Sam Tobin-Hochstadt wrote:
>> I'm trying to determine how different they look on my machine, but
one screen shot than the other (the one whose name has
> "8.01.25" is the uglier one). This effect is, I believe, one of the
> main things people mean when they say that Redex's typesetting is ugly
> (and it is indeed ugly in larger quantities).
>
> Robby
>
>
And the one with the second x in the bottom line lower down is the one
that's from --pdf and is not intended? Are there other differences
between the pictures?
Sam
On Fri, Jun 27, 2014 at 9:02 AM, Robby Findler
wrote:
> On Fri, Jun 27, 2014 at 7:59 AM, Sam Tobin-Hochstadt
> wrote
t;
> But apparently if you have a retina mac, this flag isn't necessary.
>
> Robby
>
> On Fri, Jun 27, 2014 at 7:22 AM, Sam Tobin-Hochstadt
> wrote:
>> On Fri, Jun 27, 2014 at 4:30 AM, wrote:
>>>
>>>
>>> 5280395 Robby Findler 2014-06-27 03:2
On Fri, Jun 27, 2014 at 4:30 AM, wrote:
>
>
> 5280395 Robby Findler 2014-06-27 03:25
> :
> | add the --dvipdf flag to scribble
> |
> | This adds a new back-end pipeline for generating pdf to
> | scribble, with the hope that included picts (e.g., those
> | generated by Redex) will look better whe
Yeah, that looks nicer.
On Thu, Jun 26, 2014 at 9:47 AM, Asumu Takikawa wrote:
> 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 min
Can we make this error message a little more informative? People find this
confusing.
Sam
On Jun 26, 2014 2:22 AM, wrote:
> asumu has updated `master' from 5339cbaac9 to 9a14c9c420.
> http://git.racket-lang.org/plt/5339cbaac9..9a14c9c420
>
> =[ One Commit ]=
On Mon, Jun 23, 2014 at 8:29 AM, wrote:
>
> 6a5a303 Matthew Flatt 2014-06-23 13:23:47 +0100
> :
> | avoid getting stuck on non-UTF-8 symbol encodings in bytecode
> |
Does this fix apply to keywords as well?
I assume that strings are handled differently.
Sam
_
Racket
The current Travis build succeed https://travis-ci.org/plt/racket so I
think you probably have some stale compiled files somewhere.
Sam
On Fri, Jun 20, 2014 at 10:03 AM, J. Ian Johnson wrote:
> I just pulled and make gives me this
>
> libracket.a(optimize.o): In function `expr_implies_predicate'
Yes, I think this would allow all the optimizations that Eric talked about.
Sam
On Jun 13, 2014 4:26 AM, "Robby Findler"
wrote:
> Would it be useful to get blame information back from a value, just
> like you can currently get the contract back?
>
> Robby
>
> On Tue, Jun 10, 2014 at 11:53 AM, Ma
On Mon, Jun 9, 2014 at 3:19 AM, Eric Dobson wrote:
>
> It would be nice if the contract on the input to g could be elided. It
> seems like this could be done by using something like prop:contracted
> but that allowed accessing the parties that agreed to the contract.
>
> I'm imagining something li
On Mon, Jun 9, 2014 at 5:48 AM, Robby Findler
wrote:
> Am I right that the contract on 'f' is actually (-> symbol? any)? And
> if so, where is the information coming from that lets you elide the
> check?
No, the `(boxof symbol?)` contract has to be kept around because of mutability.
> One idea f
On Thu, May 29, 2014 at 4:26 AM, wrote:
>
> | optimizer: ad hoc optimization of predicates applied to constructions
> |
> | This is probably more of a job for Typed Racket, but maybe it's
> | useful to detect some obviously unnecessary allocations of lists, etc.
I think this is a useful discussi
1 - 100 of 889 matches
Mail list logo
