[racket-dev] Errors compiling on cygwin

2014-10-30 Thread Saurabh T

 Hi,

I downloaded racket-6.1-src-builtpkgs.tgz. According to src/README, this 
should be compilable on cygwin with --enable-shared. I did not have 
success doing so.

The first problem was dynsrc/mzdyn.c failed to 
compile due to "expected specifier-qualifier-list before ‘(’ token" 
error at schemex.h:1004. The line here reads
(*scheme_jit_find_code_end)(void *p);
I grepped some and stuck a void* in front of it, and compilation went ahead.

But then it failed with "'WINDOWS_DEFAULT_STACK_SIZE' undeclared (first use in 
this function)" at eval.c:546
intptr_t sz = WINDOWS_DEFAULT_STACK_SIZE;

I
 am at a loss at this point. Is racket not expected to compile on 
cygwin? If so, can someone remove the cygwin parts in src/README?

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


Re: [racket-dev] Release Announcement for v6.1.1, Second Draft

2014-10-30 Thread Robby Findler
I like the last sentence of Sam's latest bullet.

Robby

On Thursday, October 30, 2014, Matthias Felleisen 
wrote:

>
> On Oct 30, 2014, at 3:45 PM, Sam Tobin-Hochstadt  > wrote:
>
> >>
> >> How about this one? (Starting from Matthias's offering and editing the
> >> apology from Sam's a bit.)
> >>
> >> Typed Racket closes a safety hole in the typing for the
> >>  exception system. The revised type system restricts raise so
> >>  that only instances of the exn structure type and flat data
> >>  are communicated to handlers. As a side-effect, previously
> >>  well-typed programs may fail to typecheck.
> >
> > How about:
> >
> > Typed Racket now checks uses of the exception system more strictly,
> > eliminating safety bugs. The revised type system restricts raise so
> >  that only instances of the exn structure 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.
>
>
> Can we please, pretty please, pretty please, pretty please drop these
> "nows"?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v6.1.1, Second Draft

2014-10-30 Thread Matthias Felleisen

On Oct 30, 2014, at 3:45 PM, Sam Tobin-Hochstadt  wrote:

>> 
>> How about this one? (Starting from Matthias's offering and editing the
>> apology from Sam's a bit.)
>> 
>> Typed Racket closes a safety hole in the typing for the
>>  exception system. The revised type system restricts raise so
>>  that only instances of the exn structure type and flat data
>>  are communicated to handlers. As a side-effect, previously
>>  well-typed programs may fail to typecheck.
> 
> How about:
> 
> Typed Racket now checks uses of the exception system more strictly,
> eliminating safety bugs. The revised type system restricts raise so
>  that only instances of the exn structure 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.


Can we please, pretty please, pretty please, pretty please drop these 
"nows"? 
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Release Announcement for v6.1.1, Second Draft

2014-10-30 Thread Sam Tobin-Hochstadt
On Wed, Oct 29, 2014 at 9:46 PM, Robby Findler
 wrote:
> I don't think that "it's true of every type system everywhere" is a
> good rationale for not owning backwards-incompatible changes (even
> when they are "good" backwards incompatible changes, as this one
> certainly is). I do agree with you, however, that what is especially
> bad is requiring changes to "working" code bases (for whatever
> definition of that word you wish to take (that is most friendly to
> people that use Racket)).

I don't think I was not owning the existence of a
backwards-incompatible change. I just don't think that the distinction
about whether it rejects programs that run correctly is meaningful --
the other change to exception handling only affects programs that were
wrong, but has been a bigger issue in practice.

> How about this one? (Starting from Matthias's offering and editing the
> apology from Sam's a bit.)
>
> Typed Racket closes a safety hole in the typing for the
>   exception system. The revised type system restricts raise so
>   that only instances of the exn structure type and flat data
>   are communicated to handlers. As a side-effect, previously
>   well-typed programs may fail to typecheck.

How about:

 Typed Racket now checks uses of the exception system more strictly,
eliminating safety bugs. The revised type system restricts raise so
  that only instances of the exn structure 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:
>> The reason I don't like the second sentence you wrote is that it's
>> true of every type system everywhere. And also, the more significant
>> change for users will almost certainly be the first one (it's required
>> changes to several packages already) -- almost no one raises anything
>> that isn't an exn, and so I haven't seen any code actually affected by
>> the second change.
_
  Racket Developers list:
  http://lists.racket-lang.org/dev