Re: [racket-dev] A proposal for parametric opaque types in Typed Racket
On Jan 30, 2015, at 3:59 PM, Alexis King lexi.lam...@gmail.com wrote: No, the typechecker can’t make any assumptions about the results of opaque types. If you explicitly instantiate a Posn with the type Real, the typechecker should only guarantee the result will be Real. Annotate the type as (U 1 2), though, and obviously it would need to ensure that remains invariant. How about this program: untyped.rkt: #lang racket (provide (all-defined-out)) (define (make-posn x y) (list 3 y)) ; bad typed.rkt: #lang typed/racket ; make Posn parametric (define-type (Posn X Y) (List X Y)) (require/typed untyped.rkt [make-posn (All (X Y) X Y - (Posn X Y))]) (: p : (Posn Real Real)) (define p (make-posn 1 2)) This gives this error: . . make-posn: broke its contract promised: X3 produced: 3 in: the car of the range of (parametric-/c (X3 Y4) (-* (X3 Y4) () (values (cons/c X3 (cons/c Y4 g6) contract from: (interface for make-posn) blaming: (interface for make-posn) (assuming the contract is correct) at: …./typed.rkt:5.16 I think it’s a good thing that it checks that it actually gives you the value that you gave it, and not just something like 3 even if it happens to match the type you want. And I think parametric opaque types should behave in a similar way, and to do that you would need the opaque value to be wrapped in another opaque structure, which would store either the contracts or the set of values that would pass the contracts or something like that. On Jan 30, 2015, at 12:30, Alexander D. Knauth alexan...@knauth.org wrote: On Jan 30, 2015, at 1:53 PM, Alexis King lexi.lam...@gmail.com wrote: No, it doesn’t need to be wrapped in an opaque structure. Wrapping it in an opaque structure would add a layer of indirection for absolutely no gain. Remember, the value itself is already, by definition, opaque. The only way typed code can manipulate the value is by passing it to other functions imported via require/typed. This means that contracts only need to be generated wherever those functions are called. This can be done without wrapping or unwrapping anything because all the information required to generate those contracts is known at expansion-time. The typechecker simply needs to insert the relevant contracts at the relevant locations. Imagine a program like this: #lang typed/racket (require typed/lang/posn) (: p : (Posn Real Real)) ; I’m assuming Posn is parametric over 2 tvars, not 1 (define p (posn 1 2)) (: x : Real) (define x (posn-x p)) As far as the type checker would check, it would check that the result of posn-x is a Real, but I think that the runtime contract it should also check that it returns 1, because posn could have been instantiated as (Posn 1 2). #lang typed/racket (require typed/lang/posn/mutable) ; like typed/lang/posn, but providing mutation too (: p : (Posn Real Real)) (define p (posn 1 2)) (: x : Real) (define x (posn-x p)) (set-posn-x! p 3) (: x2 : Real) (define x2 (posn-x p)) Here, even though the type checker only cares that it’s a number, it should check that x2 definition returns either 1 or 3, since both were provided as x values for the posn p. For it to keep track of these at runtime, (and it would have to be runtime) the contracts would have to be with the actual posn value in an opaque structure, which would have contracts sort of like (new-∀/c) that would check these things, although I don’t think it would have to wrap the inner values, but just record them so that when posn-x is called on one of these things, it checks that it was one of the values that was passed in to either a constructor or setter function. On Jan 30, 2015, at 07:27, Alexander D. Knauth alexan...@knauth.org wrote: On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote: It isn’t wrapped in an opaque structure. That wasn’t a part of my proposal, and while I didn’t think of it until you brought it up, I still think it’s unnecessary and doesn’t add any convenience. I think the opaque structures would be necessary for the kind of sharing wrappers between functions that you describe just before section 2.1, except that instead of the sub-values being wrapped on the untyped side, the whole thing is wrapped on the typed side, and there is a contract that wraps it and unwraps it when it goes from untyped to typed and back. For parametric types, they have to also work if the type was constrained to the exact set of values that were provided, which means that if you provide two numbers, say 1 and 2, it has to return a posn with not just any two numbers, but values of the type (U 1 2), since A could have been constrained to (U 1 2). So it has to be wrapped somehow, and I think wrapping it on the typed side makes more sense. Perhaps I’m not understanding you properly, but your “one-length string
Re: [racket-dev] A proposal for parametric opaque types in Typed Racket
On Jan 30, 2015, at 1:53 PM, Alexis King lexi.lam...@gmail.com wrote: No, it doesn’t need to be wrapped in an opaque structure. Wrapping it in an opaque structure would add a layer of indirection for absolutely no gain. Remember, the value itself is already, by definition, opaque. The only way typed code can manipulate the value is by passing it to other functions imported via require/typed. This means that contracts only need to be generated wherever those functions are called. This can be done without wrapping or unwrapping anything because all the information required to generate those contracts is known at expansion-time. The typechecker simply needs to insert the relevant contracts at the relevant locations. Imagine a program like this: #lang typed/racket (require typed/lang/posn) (: p : (Posn Real Real)) ; I’m assuming Posn is parametric over 2 tvars, not 1 (define p (posn 1 2)) (: x : Real) (define x (posn-x p)) As far as the type checker would check, it would check that the result of posn-x is a Real, but I think that the runtime contract it should also check that it returns 1, because posn could have been instantiated as (Posn 1 2). #lang typed/racket (require typed/lang/posn/mutable) ; like typed/lang/posn, but providing mutation too (: p : (Posn Real Real)) (define p (posn 1 2)) (: x : Real) (define x (posn-x p)) (set-posn-x! p 3) (: x2 : Real) (define x2 (posn-x p)) Here, even though the type checker only cares that it’s a number, it should check that x2 definition returns either 1 or 3, since both were provided as x values for the posn p. For it to keep track of these at runtime, (and it would have to be runtime) the contracts would have to be with the actual posn value in an opaque structure, which would have contracts sort of like (new-∀/c) that would check these things, although I don’t think it would have to wrap the inner values, but just record them so that when posn-x is called on one of these things, it checks that it was one of the values that was passed in to either a constructor or setter function. On Jan 30, 2015, at 07:27, Alexander D. Knauth alexan...@knauth.org wrote: On Thu, Jan 29, 2015, at 09:03 PM, Alexis King wrote: It isn’t wrapped in an opaque structure. That wasn’t a part of my proposal, and while I didn’t think of it until you brought it up, I still think it’s unnecessary and doesn’t add any convenience. I think the opaque structures would be necessary for the kind of sharing wrappers between functions that you describe just before section 2.1, except that instead of the sub-values being wrapped on the untyped side, the whole thing is wrapped on the typed side, and there is a contract that wraps it and unwraps it when it goes from untyped to typed and back. For parametric types, they have to also work if the type was constrained to the exact set of values that were provided, which means that if you provide two numbers, say 1 and 2, it has to return a posn with not just any two numbers, but values of the type (U 1 2), since A could have been constrained to (U 1 2). So it has to be wrapped somehow, and I think wrapping it on the typed side makes more sense. Perhaps I’m not understanding you properly, but your “one-length string” idea sounds like it has little to do with this opaque type problem and more to do with the fact that you want refinement types in Typed Racket. I do, too! But I don’t think hacking the opaque type system is going to help you with that. Well, yeah, refinement types would be the real solution for this particular example, but if I do want to constrain it to strings of length 1, opaque types are the only option for now, and they actually work fine. My point was you couldn't do this type of thing with the opaque structures and you would probably get weird errors if you tried. (See below because there might be a solution?) (Also, as for the box example, I’m actually a little surprised that doesn’t contract error. Seems like a bug to me, but perhaps I’m missing some idiosyncrasies of the type system. Either way, it’s precisely that kind of craziness I was referring to when I compared casting parametric opaque types to casting mutable types.) There is a bug report for it here, and the solution proposed by Sam Tobin-Hochstadt would be for cast to generate 2 contracts, one for the original type, one for the new type, but that never got implemented. http://bugs.racket-lang.org/query/?cmd=viewpr=13626 Actually now that I think about it the two-contract solution might be able to solve the previous problem, since the original contract could unwrap the value before it is passed to the new contract? I'm not sure though. The value inside the cast would be from the typed side, then it is passed through the orig contract as if it were going to the typed side, This was a typo, I meant to say “as if it were going
Re: [racket-dev] A proposal for parametric opaque types in Typed Racket
On Jan 29, 2015, at 11:34 PM, Alexis King lexi.lam...@gmail.com wrote: But the problem is that if it’s an opaque type then it can’t unwrap it once the value is returned from make-posn. Yes, that’s precisely the problem. Your point about implementing everything as single-valued structs on the typed side is an interesting one, though I don’t think it ultimately solves any problems. The fact that the typed side knows nothing about the contents of the value is what makes this such a tricky problem. As for this: But then you couldn’t do any operations on it except those that you use import with require/typed, right? That’s completely correct. That’s why it’s “opaque.” And what happens if you use cast on one of these things? That’s a little more interesting. Using cast on an object of this type would never fail (unless, of course, it didn’t actually satisfy the basic posn? predicate), but it would possibly introduce failures in the future since it would affect the contracts generated for posn-x and posn-y, for example. To make that more clear, casting a (Posn Real) to a (Posn String) would work fine until you tried to call posn-x on the instance, in which case it would raise a contract error. Note that this isn’t really any different from casting mutable data types. But if it were wrapped in an opaque structure, then that structure wouldn’t satisfy the posn? predicate, unless of course the posn? predicate has a contract that unwraps it. So all of the operations on it would have to have contracts that would unwrap it. This might actually make sense if the type is meant to be actually opaque, but if it’s an opaque type that represents a normal non-opaque value, then it will still work as an opaque type, but it won’t be a normal non-opaque value anymore on the typed side. But the reason I asked about cast was because normally I can use cast with a value that has an opaque type, but it’s wrapped on the typed side in this opaque structure, then the contracts on the cast would see this opaque structure instead of the actual value. I’m thinking of an opaque typed representing a string with length 1, which I can use as long as I use either (cast x String) or (assert x string?) whenever I pass it to a string operation. But if it were an opaque type, I don’t think I could do that. There could be a 1string-string function that could take one of these 1strings and convert it to a string, but that seems like it should be unnecessary, but made necessary by this opaque structure thing. And for “this isn’t really any different from casting mutable data types,” look at this: #lang typed/racket (: b : (Boxof Number)) (define b (box 1)) (set-box! (cast b (Boxof (U Number String))) I am a string) (ann (unbox b) Number) ;I am a string” ; not a contract error On Jan 29, 2015, at 20:20, Alexander D. Knauth alexan...@knauth.org wrote: Furthermore, even if the wrappers were shared between functions, untyped code would recieved wrapped values, which would render them quite useless. If it’s not an opaque type, but something like a list, then this works, and the untyped code receiving wrapped values isn’t a problem here: #lang typed/racket ; make Posn parametric (define-type (Posn A) (List A A)) (provide Posn) (require/typed/provide untyped.rkt [make-posn (All (A) A A - (Posn A))] [posn-x (All (A) (Posn A) - A)] [posn-y (All (A) (Posn A) - A)] [real-posn? [(Posn Any) - Boolean]]) (define p (make-posn 1 2)) (make-posn #A6 #A6) ; a printf that I put in make-posn from “untyped.rkt p - : (Listof Positive-Byte) [more precisely: (List Positive-Byte Positive-Byte)] '(1 2) ; unwrapped (posn-x p) - : Integer [more precisely: Positive-Byte] 1 (posn-y p) - : Integer [more precisely: Positive-Byte] 2 (real-posn? p) - : Boolean #t Even though for a short time it's wrapped, it’s unwrapped as soon as make-posn returns, and then after that if it flows into untyped code again it’s not wrapped and functions like real-posn? work fine. But the problem is that if it’s an opaque type then it can’t unwrap it once the value is returned from make-posn. And I don’t think parametric opaque types could solve this unless all posns themselves were wrapped with an opaque struct on the typed side, which I guess does make sense now that I think about it. But then you couldn’t do any operations on it except those that you use import with require/typed, right? Or not? And what happens if you use cast on one of these things? On Jan 29, 2015, at 9:25 PM, Alexis King lexi.lam...@gmail.com wrote: I recently ran into a problem in which opaque types (types imported from untyped code) cannot by parameterized by Typed Racket. I initially encountered this problem in my attempt to port 2htdp/image to TR. After some further consideration, I’m interested in adding support to make something like this possible, which
Re: [racket-dev] A proposal for parametric opaque types in Typed Racket
Um, for this: (module typed typed/racket/base (provide (struct-out Foo)) (struct [A] Foo ([x : A] [y : A]) #:transparent)) (Foo a 'b) Should be fine because Foo could be instantiated at the type (U String Symbol). On Jan 29, 2015, at 9:25 PM, Alexis King lexi.lam...@gmail.com wrote: I recently ran into a problem in which opaque types (types imported from untyped code) cannot by parameterized by Typed Racket. I initially encountered this problem in my attempt to port 2htdp/image to TR. After some further consideration, I’m interested in adding support to make something like this possible, which would certainly have additional benefits beyond this specific use-case. I’ve outlined my proposal here: http://lexi-lambda.github.io/racket-parametric-opaque-types/ Any feedback, suggestions, or advice would be appreciated, especially from those who are familiar with Typed Racket’s internals. Thank you, Alexis _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A proposal for parametric opaque types in Typed Racket
Furthermore, even if the wrappers were shared between functions, untyped code would recieved wrapped values, which would render them quite useless. If it’s not an opaque type, but something like a list, then this works, and the untyped code receiving wrapped values isn’t a problem here: #lang typed/racket ; make Posn parametric (define-type (Posn A) (List A A)) (provide Posn) (require/typed/provide untyped.rkt [make-posn (All (A) A A - (Posn A))] [posn-x (All (A) (Posn A) - A)] [posn-y (All (A) (Posn A) - A)] [real-posn? [(Posn Any) - Boolean]]) (define p (make-posn 1 2)) (make-posn #A6 #A6) ; a printf that I put in make-posn from “untyped.rkt p - : (Listof Positive-Byte) [more precisely: (List Positive-Byte Positive-Byte)] '(1 2) ; unwrapped (posn-x p) - : Integer [more precisely: Positive-Byte] 1 (posn-y p) - : Integer [more precisely: Positive-Byte] 2 (real-posn? p) - : Boolean #t Even though for a short time it's wrapped, it’s unwrapped as soon as make-posn returns, and then after that if it flows into untyped code again it’s not wrapped and functions like real-posn? work fine. But the problem is that if it’s an opaque type then it can’t unwrap it once the value is returned from make-posn. And I don’t think parametric opaque types could solve this unless all posns themselves were wrapped with an opaque struct on the typed side, which I guess does make sense now that I think about it. But then you couldn’t do any operations on it except those that you use import with require/typed, right? Or not? And what happens if you use cast on one of these things? On Jan 29, 2015, at 9:25 PM, Alexis King lexi.lam...@gmail.com wrote: I recently ran into a problem in which opaque types (types imported from untyped code) cannot by parameterized by Typed Racket. I initially encountered this problem in my attempt to port 2htdp/image to TR. After some further consideration, I’m interested in adding support to make something like this possible, which would certainly have additional benefits beyond this specific use-case. I’ve outlined my proposal here: http://lexi-lambda.github.io/racket-parametric-opaque-types/ Any feedback, suggestions, or advice would be appreciated, especially from those who are familiar with Typed Racket’s internals. Thank you, Alexis _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] In Typed Racket, struct declarations do not work in an internal definition context
There’s a bug report about this here: http://bugs.racket-lang.org/query/?cmd=viewpr=14524 Though I notice it gives a different error message now. But why should structure type declarations being a module-wide construct? Internal function definitions work, and internal type definitions work, so why shouldn’t internal structure definitions? On Jan 22, 2015, at 3:57 PM, Alexis King lexi.lam...@gmail.com wrote: Simple enough. This works: #lang racket (define (make-me-a-struct) (struct foo ()) (foo)) (make-me-a-struct) ; = #foo This does not: #lang typed/racket (define (make-me-a-struct) (struct foo ()) (foo)) ; error: cannot apply a function with unknown arity (make-me-a-struct) This problem makes sense. Type declarations seem to be a module-wide construct, so a type that should be scoped to a single function doesn’t work. I’m running into this issue when trying to create an executable struct using define-struct/exec from within a macro, which doesn’t work due to this particular problem. 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 resolve this type of problem? Since it seems to be an issue with how TR handles types at its core, I’m not even sure how feasible it would be. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] question, issue(?) with the scope of identifiers passed into define-syntax-rule
But I think it’s important that it doesn’t use gensym or something like that, it uses syntax-marks, which means you can break these lexical scoping rules if you want/need to by using either syntax-local-introduce or datum-syntax: #lang racket (require syntax/parse/define) (define-simple-macro (with-tables stem body ...) #:with table-author-id (syntax-local-introduce #'table-author) (let([table-publication (string-append stem _publication)] [table-author-id (string-append stem _author)] [table-bridge-publication-author (string-append stem _bridge_publication_author)] [table-unique-counters (string-append stem _unique_counters)] ) body ... )) (with-tables x table-author) ;”x_author On Jan 15, 2015, at 9:23 PM, Alexander McLin alex.mc...@gmail.com wrote: Warning I am still a Racket intermediate user but I've been studying syntactic extensions a lot the past several months. The problem here is macros in Racket have lexical scope just like procedures, they are hygienic macros. The identifiers you introduced in the with-tables macro only exist or refer to other bindings in the same lexical scope as where you originally wrote the macro. When you invoke the macro and pass in table-author, even though it is spelled the same as the identifier you wrote in the macro definition, they are not the same. When the macro expands, hygiene is implemented by renaming all identifiers in the macro to unique non-clashing symbols that don't conflict with others existing in the scope the macro is expanding in. The table-author identifier in the macro in the let form is renamed to something different like g6271 or something along those lines. Furthermore, you need to be careful about what you mean by evaluation. In the presence of macros, you have the concept of syntax phase(or compile-time or expand-time) evaluation versus run-time evaluation. When the macro is expanding, it does it thing, processing the original syntax into the new piece of syntax that replaces what was there previously such as (with-tables x table-author) which is then finally evaluated during run-time. (with-tables x table-author) will expand into something looking similar to the following, just to give you an idea of what macro expansion looks like: (let ((g6191 (string-append x _publication)) (g6271 (string-append x _author)) (g6369 (string-append x _bridge_publication_author)) (g6445 (string-append x _unique_counters))) table-author) Note that the original table-author identifier has been replaced by a different identifier that still has the same binding you originally defined. The table-author identifier you passed to the macro gets inserted in the body position and then the expanded code is evaluated at run-time and of course gives you a run-time error since table-author does not refer to anything and thus when it's evaluated, it is recognized as an undefined identifier. (with-tables x hello) works because what you get in return is: (let ((g6191 (string-append x _publication)) (g6271 (string-append x _author)) (g6369 (string-append x _bridge_publication_author)) (g6445 (string-append x _unique_counters))) hello) hello is just a self-evaluating string giving you back hello from within the let form. On Thu, Jan 15, 2015 at 12:12 AM, Thomas Lynch thomas.ly...@reasoningtechnology.com wrote: I have a simple syntax rule: Welcome to Racket v5.2.1. racket@ (define-syntax-rule (with-tables stem body ...) (let( [table-publication (string-append stem _publication)] [table-author (string-append stem _author)] [table-bridge-publication-author (string-append stem _bridge_publication_author)] [table-unique-counters (string-append stem _unique_counters)] ) body ... )) Which works fine when I don't reference the environment defined by the let: racket@ racket@ (with-tables x hello) hello However when I pass it an identifier corresponding to one of the variables defined in the let: racket@ (with-tables x table-author) reference to undefined identifier: table-author stdin::1167: table-author The identifier passed in doesn't seem to be part of the local let context, but carried in a different context, or perhaps it was evaluated as an operand. I didn't expect either of those. Can someone point me at a description of the expected behavior, or give me a tip here on what is happening and why. ... in Wolfram language there is a 'Hold' operator for situations like this. Apparently inside the macro we have to do some evaluation to handle the work of the macro, is that why the operand is evaluated? Thanks in advance for explaining the evaluation/context model here. Thomas _ Racket Developers list:
Re: [racket-dev] parse errors in types, poly-dots cause me headaches
In terms of bugs, it’s probably related to this problem with call-with-values and poly-dots: #lang typed/racket (: f : (All (a ...) [(- (values Any ... a)) - Void])) (define (f g) (call-with-values g void)) ;= . . ../../Applications/Racket v6.1.1/share/pkgs/typed-racket-lib/typed-racket/typecheck/tc-app/tc-app-values.rkt:22:4: match: no matching clause for (tc-results '() (cons Any 'a)) On Nov 18, 2014, at 11:54 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Nov 18, 2014, at 11:34 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: On Tue, Nov 18, 2014 at 10:45 AM, Matthias Felleisen matth...@ccs.neu.edu 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 followed by ... The problem here is that you're using -* without using the syntax of -*. Fortunately, this program doesn't need -* at all. Unfortunately, I don't know how to make this function type check yet, but I'll keep playing with it. Are you blaming the victim here? Please run what I send out and experience how the type checker barfs on you. This is a bug report. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Help with build failed error message
Ok it turns out I had done (syntax/loc stx #’template) instead of (syntax/loc stx template) and somehow that seems to have triggered some kind of infinite recursive loop or something. But I fixed it and got another error that makes no sense at all. It seems like somehow a struct constructor is returning #f. raco setup: 0 making: pkgs/racket-test/tests/future struct-type/sc: broke its contract promised: static-contract? produced: #f in: the range of (- any/c static-contract?) contract from: pkgs/typed-racket-lib/typed-racket/static-contracts/combinators/struct.rkt blaming: pkgs/typed-racket-lib/typed-racket/static-contracts/combinators/struct.rkt (assuming the contract is correct) at: pkgs/typed-racket-lib/typed-racket/static-contracts/combinators/struct.rkt:19.5 (lines 1217-1227 of https://travis-ci.org/AlexKnauth/racket/jobs/30418536) Where struct-type/sc is defined like this in pkgs/typed-racket-lib/typed-racket/static-contracts/combinators/struct.rkt: (struct struct-type/sc combinator () #:transparent #:property prop:combinator-name struct-type/sc #:methods gen:sc [(define (sc-map v f) (match v [(struct-type/sc args) (struct-type/sc (map (λ (a) (f a 'covariant)) args))])) (define (sc-traverse v f) (match v [(struct-type/sc args) (for-each (λ (a) (f a 'covariant)) args) (void)])) (define (sc-contract v f) (match v [(struct-type/sc args) #`(struct-type/c #f)])) (define (sc-constraints v f) (match v [(struct-type/sc args) (simple-contract-restrict 'chaperone)]))]) I have no idea what to do. On Jul 20, 2014, at 2:15 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Killed means that the OS terminated the `racket/racket3m` process from the outside. For example, the process may have exceeded a memory-use limit. At Sat, 19 Jul 2014 20:25:24 -0400, Alexander D. Knauth wrote: I made a fork of the racket repo and committed some changes in a topic branch, but I got this: make[8]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[7]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[6]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' racket/racket3m -X /home/travis/build/AlexKnauth/racket/racket/collects -G /home/travis/build/AlexKnauth/racket/racket/etc -G /home/travis/build/AlexKnauth/racket/build/config -N raco -l- setup --no-user -j 2 raco setup: bootstrapping from source... Killed make[5]: *** [install-3m] Error 137 make[5]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[4]: *** [install] Error 2 make[4]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[3]: *** [base] Error 2 make[3]: Leaving directory `/home/travis/build/AlexKnauth/racket' make[2]: *** [plain-in-place] Error 2 make[2]: Leaving directory `/home/travis/build/AlexKnauth/racket' make[1]: *** [cpus-in-place] Error 2 make[1]: Leaving directory `/home/travis/build/AlexKnauth/racket' make: *** [in-place] Error 2 The command make CPUS=2 PKGS=racket-test db-test unstable-flonum-lib net-test exited with 2. (lines 812-830 of https://travis-ci.org/AlexKnauth/racket/jobs/30368892) What does this mean? What does the “Killed” mean? And what is error 137? _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Help with build failed error message
I made a fork of the racket repo and committed some changes in a topic branch, but I got this: make[8]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[7]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[6]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' racket/racket3m -X /home/travis/build/AlexKnauth/racket/racket/collects -G /home/travis/build/AlexKnauth/racket/racket/etc -G /home/travis/build/AlexKnauth/racket/build/config -N raco -l- setup --no-user -j 2 raco setup: bootstrapping from source... Killed make[5]: *** [install-3m] Error 137 make[5]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[4]: *** [install] Error 2 make[4]: Leaving directory `/home/travis/build/AlexKnauth/racket/racket/src/build' make[3]: *** [base] Error 2 make[3]: Leaving directory `/home/travis/build/AlexKnauth/racket' make[2]: *** [plain-in-place] Error 2 make[2]: Leaving directory `/home/travis/build/AlexKnauth/racket' make[1]: *** [cpus-in-place] Error 2 make[1]: Leaving directory `/home/travis/build/AlexKnauth/racket' make: *** [in-place] Error 2 The command make CPUS=2 PKGS=racket-test db-test unstable-flonum-lib net-test exited with 2. (lines 812-830 of https://travis-ci.org/AlexKnauth/racket/jobs/30368892) What does this mean? What does the “Killed” mean? And what is error 137? _ Racket Developers list: http://lists.racket-lang.org/dev