Re: [racket-dev] (current-date)
Oh! I see. Sorry for the confusion. I misunderstood what you're written. Robby On Fri, Feb 1, 2013 at 7:01 PM, Matthew Flatt wrote: > `date->seconds' did not change; it still returns an exact integer. > > At Fri, 1 Feb 2013 18:57:57 -0600, Robby Findler wrote: > > Does this mean that date->seconds always returns inexacts now? Or does it > > return inexacts only when it wouldn't be an integer? > > > > (I'm not excited about either possibility but the second seems bad only > if > > you consider TR.) > > > > Robby > > > > > > On Fri, Feb 1, 2013 at 5:22 PM, Matthew Flatt > wrote: > > > > > At Wed, 30 Jan 2013 22:23:04 -0500, Asumu Takikawa wrote: > > > > On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote: > > > > >Any reason not to define current-date in this way? there's a > > > nanosecond > > > > >field there wanting to get into action. > > > > > > > > While we're on the subject, it's also weird that `date->seconds` has > a > > > > contract accepting date? and so doesn't handle date*'s extra > nanosecond > > > > field (note that `seconds->date` produces date*s): > > > > > > > > Welcome to Racket v5.3.2.3. > > > > -> (require racket/date) > > > > -> (define s (* #i1/1000 (current-inexact-milliseconds))) > > > > -> s > > > > 1359602380.5059009 > > > > -> (date->seconds (seconds->date s)) > > > > 1359602380 > > > > > > I've changed `current-date'. > > > > > > Some existing code may rely on `date->seconds' returning an exact > > > integer, so I've added `date*->seconds'. > > > > > > _ > > > Racket Developers list: > > > http://lists.racket-lang.org/dev > > > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] (current-date)
`date->seconds' did not change; it still returns an exact integer. At Fri, 1 Feb 2013 18:57:57 -0600, Robby Findler wrote: > Does this mean that date->seconds always returns inexacts now? Or does it > return inexacts only when it wouldn't be an integer? > > (I'm not excited about either possibility but the second seems bad only if > you consider TR.) > > Robby > > > On Fri, Feb 1, 2013 at 5:22 PM, Matthew Flatt wrote: > > > At Wed, 30 Jan 2013 22:23:04 -0500, Asumu Takikawa wrote: > > > On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote: > > > >Any reason not to define current-date in this way? there's a > > nanosecond > > > >field there wanting to get into action. > > > > > > While we're on the subject, it's also weird that `date->seconds` has a > > > contract accepting date? and so doesn't handle date*'s extra nanosecond > > > field (note that `seconds->date` produces date*s): > > > > > > Welcome to Racket v5.3.2.3. > > > -> (require racket/date) > > > -> (define s (* #i1/1000 (current-inexact-milliseconds))) > > > -> s > > > 1359602380.5059009 > > > -> (date->seconds (seconds->date s)) > > > 1359602380 > > > > I've changed `current-date'. > > > > Some existing code may rely on `date->seconds' returning an exact > > integer, so I've added `date*->seconds'. > > > > _ > > Racket Developers list: > > http://lists.racket-lang.org/dev > > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] (current-date)
Does this mean that date->seconds always returns inexacts now? Or does it return inexacts only when it wouldn't be an integer? (I'm not excited about either possibility but the second seems bad only if you consider TR.) Robby On Fri, Feb 1, 2013 at 5:22 PM, Matthew Flatt wrote: > At Wed, 30 Jan 2013 22:23:04 -0500, Asumu Takikawa wrote: > > On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote: > > >Any reason not to define current-date in this way? there's a > nanosecond > > >field there wanting to get into action. > > > > While we're on the subject, it's also weird that `date->seconds` has a > > contract accepting date? and so doesn't handle date*'s extra nanosecond > > field (note that `seconds->date` produces date*s): > > > > Welcome to Racket v5.3.2.3. > > -> (require racket/date) > > -> (define s (* #i1/1000 (current-inexact-milliseconds))) > > -> s > > 1359602380.5059009 > > -> (date->seconds (seconds->date s)) > > 1359602380 > > I've changed `current-date'. > > Some existing code may rely on `date->seconds' returning an exact > integer, so I've added `date*->seconds'. > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compilation of 5.3.2 fails on some compilers
Thanks for the detailed explanation. It's a lot clearer now why it's needed. But i figured out that the real culprit was cross-compilation in combination with autoconf. autoconfs default rule for test results when running cross-compilation was set to noinline not available, and therefore setting the define to expand to nothing. It should be, in this case and for inline too, enough to check for compilation, not for running the test. If the attribute is not supported the compilation should already fail. I attached a patch to change these two test and fix a typo. Compilation runs without any errors then. While checking for more similar tests i noticed that the test for compare-and-swap is completely screwed up. Even on a modern Core i7 with gcc 4.x it fails with default settings on a 32bit OS. The CAS builtins need at least -march=i686 there to run, otherwise you get undefined symbol errors. That never happens on 64bit OS because gcc knows that every x86-64 processor has CAS operations. I think it would be a good choice to set -march when using gcc with 32bit OS, assuming at least a pentium pro processor might be ok nowadays. It must be remain unset for 64bit, or gcc throws errors. Unfortunately my autoconf skills are far too limited to provide a patch. Tobias On Fri, 01 Feb 2013 19:30:15 +0100, Matthew Flatt wrote: At Fri, 1 Feb 2013 12:23:59 +0100, Tobias Hammer wrote: i am getting the following error when i try to compile racket-textual on a a version of gcc that does not support the 'noinline' attribute: xsrc/place.c: In function 'place_start_proc': xsrc/place.c:2793: warning: assignment makes pointer from integer without a cast xsrc/place.c: At top level: xsrc/place.c:3185: error: conflicting types for 'place_start_proc_after_stack' xsrc/place.c:2793: note: previous implicit declaration of 'place_start_proc_after_stack' was here The cause is that the forward declaration of 'place_start_proc_after_stack' is missing. It was originally there (L 95) but the MZ_DO_NOT_INLINE macro expands to nothing, effectively removing the declaration. The wrapping macro was added in commit 9692765e2 but the commit message gives no real reason why it is needed. I am a bit worried to revert the change because i don't know which bug i could reintroduce. What would be the correct fix to compile 5.3.2? Hopefully, the right fix is to make `MZ_DO_NOT_INLINE(decl)' expand to `decl' if no "no inline" annotation is available. If place_start_proc_after_stack() is inlined at its only use, whcih is in place_start_proc(), then a new place will not register its stack bounds correctly for the implementation of continuations. The implementation of continuations assumes that local variables in place_start_proc_after_stack() are shallower on the stack than variables in place_start_proc(), and inlining can defeat that assumption. If there's no way to say "no inlining" and inlining of that function can still happen, then we'll have to work harder to confuse the C compiler. The same is true for any other use of MZ_DO_NOT_INLINE(). configure.ac.patch Description: Binary data _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] (current-date)
At Wed, 30 Jan 2013 22:23:04 -0500, Asumu Takikawa wrote: > On 2013-01-30 23:20:45 +0100, Pierpaolo Bernardi wrote: > >Any reason not to define current-date in this way? there's a nanosecond > >field there wanting to get into action. > > While we're on the subject, it's also weird that `date->seconds` has a > contract accepting date? and so doesn't handle date*'s extra nanosecond > field (note that `seconds->date` produces date*s): > > Welcome to Racket v5.3.2.3. > -> (require racket/date) > -> (define s (* #i1/1000 (current-inexact-milliseconds))) > -> s > 1359602380.5059009 > -> (date->seconds (seconds->date s)) > 1359602380 I've changed `current-date'. Some existing code may rely on `date->seconds' returning an exact integer, so I've added `date*->seconds'. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] request for code review on fix for pr 13471
I've written up a patch for PR 13471: https://github.com/dyoo/racket/commit/544918465b67cbf2e8ad40bd3c2b3ea90f33c085 I just want a second pair of eyes just to make sure I've done it correctly. I added a free-id-table that the parse function uses when walking across lex-abbrev syntaxes. Does this look ok? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] module->language-info and submodules
Some languages attach language info to their modules, but not all; for those that do, the intent isn't really to record the implementing language, but to potentially configure things like the printer. Looking forward, I think submodules should take over the role of language info. Language info is is attached to a top-level module via a `#lang' reader --- so that's why submodules tend not to have this information, and it also points to why (sub-)submodules are a better solution. At Fri, 01 Feb 2013 14:51:19 -0500, Vincent St-Amour wrote: > In all the cases I've tried, `module->language-info' returns `#f' when > passed a submodule path. Is that the intended behavior? If so, is there > a way to know which language a submodule is written in? > > I've observed the same thing with `module-compiled-language-info'. > > An example program is below. > > Vincent > > > > #lang racket > > (displayln ; prints: #(racket/language-info get-info #f) > (module->language-info > '(lib "math/private/matrix/untyped-matrix-arithmetic") > #t)) > (displayln ; prints: #f > (module->language-info > ;; (module typed-multiply-defs typed/racket/base ...) > '(submod (lib "math/private/matrix/untyped-matrix-arithmetic") >typed-multiply-defs) > #t)) > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Instantiation syntax of `new`
On 2013-02-01 15:35:23 -0500, Ryan Culpepper wrote: > It's ambiguous: > > (new c% (x y)) > > could mean "pass y for initialization argument x" or "pass (x y) as > the first positional argument". Oh right, thanks. I'll go back to the drawing board. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Instantiation syntax of `new`
On 02/01/2013 03:29 PM, Asumu Takikawa wrote: Hi all, I've found that when using racket/class, one syntactic pain point I keep encountering is that the instantiation is clumsy. This is especially true if I want to mix different styles of instantiation (keyword and positional). Is there any reason to not make the instantiation syntax of `new` more flexible? I most prefer `new` since it's the shortest and also most familiar of the three (the others being `make-object` and `instantiate`). In particular, I'm imagining the following syntax: (new c% 1 2 3) => (instantiate c% (1 2 3)) (new c% [x 1] [y 2]) => (instantiate c% [x 1] [y 2]) I think you mean (instantiate c% () [x 1] [y 2]). (new c% [z 3] 1 2) => (instantiate c% (1 2) [z 3]) (new c% 1 [z 3] 2) => (instantiate c% (1 2) [z 3]) and so on. Attached is a patch that implements this (modulo tests & docs). Any thoughts? It's ambiguous: (new c% (x y)) could mean "pass y for initialization argument x" or "pass (x y) as the first positional argument". Ryan _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Instantiation syntax of `new`
Hi all, I've found that when using racket/class, one syntactic pain point I keep encountering is that the instantiation is clumsy. This is especially true if I want to mix different styles of instantiation (keyword and positional). Is there any reason to not make the instantiation syntax of `new` more flexible? I most prefer `new` since it's the shortest and also most familiar of the three (the others being `make-object` and `instantiate`). In particular, I'm imagining the following syntax: (new c% 1 2 3) => (instantiate c% (1 2 3)) (new c% [x 1] [y 2]) => (instantiate c% [x 1] [y 2]) (new c% [z 3] 1 2) => (instantiate c% (1 2) [z 3]) (new c% 1 [z 3] 2) => (instantiate c% (1 2) [z 3]) and so on. Attached is a patch that implements this (modulo tests & docs). Any thoughts? Cheers, Asumu >From cb0bfa789dc9d0a1c59f8090e9b967bb56f9ff9d Mon Sep 17 00:00:00 2001 From: Asumu Takikawa Date: Fri, 1 Feb 2013 15:09:51 -0500 Subject: [PATCH] Add more flexible instantiation syntax for `new` --- collects/racket/private/class-internal.rkt | 41 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/collects/racket/private/class-internal.rkt b/collects/racket/private/class-internal.rkt index 2c03780..57d08e7 100644 --- a/collects/racket/private/class-internal.rkt +++ b/collects/racket/private/class-internal.rkt @@ -3808,24 +3808,31 @@ An example ;; instantiation ;; +;; class instantiation syntax, allows mixed keywords and positionals (define-syntax (new stx) - (syntax-case stx () -[(_ cls (id arg) ...) - (andmap identifier? (syntax->list (syntax (id ... - (quasisyntax/loc stx - (instantiate cls () (id arg) ...))] -[(_ cls (id arg) ...) - (for-each (lambda (id) - (unless (identifier? id) - (raise-syntax-error 'new "expected identifier" stx id))) - (syntax->list (syntax (id ...] -[(_ cls pr ...) - (for-each - (lambda (pr) -(syntax-case pr () - [(x y) (void)] - [else (raise-syntax-error 'new "expected name and value binding" stx pr)])) - (syntax->list (syntax (pr ...])) + (syntax-parse stx +[(_ cls arg ...) + (define-values (kw-args pos-args) + (parse-init-args #'(arg ...))) + (with-syntax ([(kw ...) kw-args] + [(pos ...) pos-args]) + (quasisyntax/loc stx +(instantiate cls (pos ...) kw ...)))])) + +(begin-for-syntax + ;; listof -> (values listof listof) + ;; parses arguments for `new` and collects them into two lists + (define (parse-init-args stx) + (define stxs (syntax->list stx)) + (define-values (kw-args pos-args) + (for/fold ([kw-args '()] +[pos-args '()]) + ([stx stxs]) + (syntax-parse stx + [(kw:id arg) + (values (cons stx kw-args) pos-args)] + [arg (values kw-args (cons stx pos-args))]))) + (values kw-args (reverse pos-args (define ((make-object/proc blame) class . args) (do-make-object blame class args null)) -- 1.7.10.4 _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] module->language-info and submodules
In all the cases I've tried, `module->language-info' returns `#f' when passed a submodule path. Is that the intended behavior? If so, is there a way to know which language a submodule is written in? I've observed the same thing with `module-compiled-language-info'. An example program is below. Vincent #lang racket (displayln ; prints: #(racket/language-info get-info #f) (module->language-info '(lib "math/private/matrix/untyped-matrix-arithmetic") #t)) (displayln ; prints: #f (module->language-info ;; (module typed-multiply-defs typed/racket/base ...) '(submod (lib "math/private/matrix/untyped-matrix-arithmetic") typed-multiply-defs) #t)) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Compilation of 5.3.2 fails on some compilers
At Fri, 1 Feb 2013 12:23:59 +0100, Tobias Hammer wrote: > i am getting the following error when i try to compile racket-textual on a > a version of gcc that does not support the 'noinline' attribute: > > xsrc/place.c: In function 'place_start_proc': > xsrc/place.c:2793: warning: assignment makes pointer from integer without > a cast > xsrc/place.c: At top level: > xsrc/place.c:3185: error: conflicting types for > 'place_start_proc_after_stack' > xsrc/place.c:2793: note: previous implicit declaration of > 'place_start_proc_after_stack' was here > > The cause is that the forward declaration of > 'place_start_proc_after_stack' is missing. It was originally there (L 95) > but the MZ_DO_NOT_INLINE macro expands to nothing, effectively removing > the declaration. > > The wrapping macro was added in commit 9692765e2 but the commit message > gives no real reason why it is needed. I am a bit worried to revert the > change because i don't know which bug i could reintroduce. What would be > the correct fix to compile 5.3.2? Hopefully, the right fix is to make `MZ_DO_NOT_INLINE(decl)' expand to `decl' if no "no inline" annotation is available. If place_start_proc_after_stack() is inlined at its only use, whcih is in place_start_proc(), then a new place will not register its stack bounds correctly for the implementation of continuations. The implementation of continuations assumes that local variables in place_start_proc_after_stack() are shallower on the stack than variables in place_start_proc(), and inlining can defeat that assumption. If there's no way to say "no inlining" and inlining of that function can still happen, then we'll have to work harder to confuse the C compiler. The same is true for any other use of MZ_DO_NOT_INLINE(). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Installing Optimization Coach broke Racket's reader
As you mention, the OC package doesn't touch any collect except its own,
so I don't know what's going on.
Neil, can you reproduce this with other packages, or is this OC-specific?
Also, does OC work properly now?
Vincent
At Fri, 1 Feb 2013 06:19:23 -0700,
Jay McCarthy wrote:
>
> I think Vincent needs to answer the core question. But when you
> install a package it can extend any collection, so all collections
> that it mentions are built. In the case of OC, it only mentions OC so
> it would run "raco setup OC" which could cause other collections to be
> built as well, during the raco bootstrap phase, such as if you had
> done a "git pull" and didn't rebuild.
>
> Jay
>
> On Wed, Jan 30, 2013 at 5:34 PM, Neil Toronto wrote:
> > This worked:
> >
> > ~/plt/collects$ find . -name "compiled" -exec rm -rf \{\} \;
> > ~/plt/collects$ ../bin/raco setup
> >
> > That first command to delete the ghosts of misbegotten .zos is arcane and
> > dangerous. Why would installing a package create compiled files in
> > "collects"?
> >
> > Neil ⊥
> >
> >
> > On 01/30/2013 05:12 PM, Neil Toronto wrote:
> >>
> >> Setup finished, still had the reader error. I removed Optimization
> >> Coach, cleaned, and ran setup again. My reader is still broken.
> >>
> >> "git status" shows no changes in my local repo. "raco pkg show" shows no
> >> packages. "raco link -l" shows no additional links.
> >>
> >> Where are these invisible craptastic things that are breaking my stuff?
> >>
> >> Neil ⊥
> >>
> >> On 01/30/2013 04:47 PM, Neil Toronto wrote:
> >>>
> >>> Ran this program:
> >>>
> >>> #lang racket
> >>> (require planet2)
> >>> (install "optimization-coach")
> >>>
> >>> Realized setup was running on one thread, stopped program, closed
> >>> DrRacket.
> >>>
> >>> Figured Optimization Coach must have been downloaded already, so I ran
> >>> setup:
> >>>
> >>> $ ./raco setup
> >>>
> >>> Everything appeared to work. Started DrRacket:
> >>>
> >>> $ ./drracket &
> >>>
> >>> Got this error on startup:
> >>>
> >>> DrRacket:module-language.rkt:first-opened exn: link: bad variable
> >>> linkage;
> >>> reference to a variable that has the wrong procedure or structure-type
> >>> shape
> >>> reference phase level: 0
> >>> variable module: "/home/neil/plt/collects/syntax/module-reader.rkt"
> >>> variable phase: 0
> >>> reference in module: "/home/neil/plt/collects/racket/lang/reader.rkt"
> >>> (|[running body]| . #(struct:srcloc
> >>> # #f #f #f #f))
> >>> (call-with-limits . #(struct:srcloc
> >>> # 358 0 14429 1724))
> >>> (call-with-custodian-shutdown . #(struct:srcloc
> >>> # 406 0 16321 316))
> >>> (call-with-break-parameterization . #(struct:srcloc
> >>> # 146 2
> >>> 4832 517))
> >>> (loop . #(struct:srcloc
> >>> # 763 5 32166 1584))
> >>> (#f . #(struct:srcloc
> >>> # 451 6
> >>> 19918 1056))
> >>> (#f . #(struct:srcloc
> >>> # 502 32
> >>> 21905 120))
> >>> (call-with-break-parameterization . #(struct:srcloc
> >>> # 146 2
> >>> 4832 517))
> >>> (loop . #(struct:srcloc
> >>> # 397 18
> >>> 17838 540))
> >>>
> >>> But DrRacket still worked. Okay... ran the default program ("#lang
> >>> racket"), got this output:
> >>>
> >>> Module Language: invalid module text
> >>> link: bad variable linkage;
> >>> reference to a variable that has the wrong procedure or structure-type
> >>> shape
> >>> reference phase level: 0
> >>> variable module: "/home/neil/plt/collects/syntax/module-reader.rkt"
> >>> variable phase: 0
> >>> reference in module: "/home/neil/plt/collects/racket/lang/reader.rkt"
> >>> in: wrap-internal
> >>>
> >>> Just did "raco setup -c" and "raco setup", waiting for completion.
> >>>
> >>> Any idea what broke?
> >>>
> >>> Neil ⊥
> >>>
> >>
> >
> > _
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
>
>
>
> --
> Jay McCarthy
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg and github
2013/2/1 Asumu Takikawa : > On 2013-02-01 06:23:06 -0700, Jay McCarthy wrote: >> I had originally tried to do that, but Github wasn't providing tar >> balls for anything other than branch HEADs and tags. I'm surprised >> that it works for you and not for me. Am I just crazy or did you set >> something on your repository to make it work? > > Maybe it's a new feature they added recently? I think Jens was saying on > IRC that it wasn't documented in the API. It was about 6-7 months ago I checked, and back then I couldn't find anything. Now I see it here: http://developer.github.com/v3/repos/contents/#get-archive-link The v3 API was in beta from June, so I might have been looking at the v2 API back then. Anyways, great find Asumu. /Jens Axel _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] school of haskell
This morning I came across the "School of Haskell" at http://fpcomplete.com/school-of-haskell-goes-beta/ I know Shriram and Danny have been thinking along these lines, but the Haskellians seem to be there. Question is whether we could organize such a site as a community effort via Dec and Users? -- Matthias _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg and github
On 2013-02-01 06:23:06 -0700, Jay McCarthy wrote: > I had originally tried to do that, but Github wasn't providing tar > balls for anything other than branch HEADs and tags. I'm surprised > that it works for you and not for me. Am I just crazy or did you set > something on your repository to make it work? Maybe it's a new feature they added recently? I think Jens was saying on IRC that it wasn't documented in the API. I'm pretty sure it's not just for my repos. Here's a random example from one of yours: https://github.com/jeapostrophe/opencl/tarball/664c813c679b5c6f0f93fc1de4e908f6048c3acd Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] raco pkg and github
I had originally tried to do that, but Github wasn't providing tar balls for anything other than branch HEADs and tags. I'm surprised that it works for you and not for me. Am I just crazy or did you set something on your repository to make it work? Jay On Wed, Jan 30, 2013 at 3:48 PM, Asumu Takikawa wrote: > Hi all, > > One thing that a few people using `raco pkg` (including myself) have > found is that when you upload a package to pkg.racket-lang.org that's > hosted on github, you can easily get checksum errors. > > The checksum mismatch happens when the github HEAD has been updated, but > the checksum on the PNS is out of date. The behavior that I expected was > that `raco pkg` would just download the commit matching the PNS checksum > from github and use that. > > Is there any design reason to not do that instead? > > Attached is a hackish patch that just demonstrates that this is do-able. > As an example, you can try `raco pkg install sweet-exp`, which will > install commit fbd09b4be38b rather than the current github HEAD. > > Cheers, > Asumu > > _ > Racket Developers list: > http://lists.racket-lang.org/dev > -- Jay McCarthy Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay "The glory of God is Intelligence" - D&C 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Installing Optimization Coach broke Racket's reader
I think Vincent needs to answer the core question. But when you
install a package it can extend any collection, so all collections
that it mentions are built. In the case of OC, it only mentions OC so
it would run "raco setup OC" which could cause other collections to be
built as well, during the raco bootstrap phase, such as if you had
done a "git pull" and didn't rebuild.
Jay
On Wed, Jan 30, 2013 at 5:34 PM, Neil Toronto wrote:
> This worked:
>
> ~/plt/collects$ find . -name "compiled" -exec rm -rf \{\} \;
> ~/plt/collects$ ../bin/raco setup
>
> That first command to delete the ghosts of misbegotten .zos is arcane and
> dangerous. Why would installing a package create compiled files in
> "collects"?
>
> Neil ⊥
>
>
> On 01/30/2013 05:12 PM, Neil Toronto wrote:
>>
>> Setup finished, still had the reader error. I removed Optimization
>> Coach, cleaned, and ran setup again. My reader is still broken.
>>
>> "git status" shows no changes in my local repo. "raco pkg show" shows no
>> packages. "raco link -l" shows no additional links.
>>
>> Where are these invisible craptastic things that are breaking my stuff?
>>
>> Neil ⊥
>>
>> On 01/30/2013 04:47 PM, Neil Toronto wrote:
>>>
>>> Ran this program:
>>>
>>> #lang racket
>>> (require planet2)
>>> (install "optimization-coach")
>>>
>>> Realized setup was running on one thread, stopped program, closed
>>> DrRacket.
>>>
>>> Figured Optimization Coach must have been downloaded already, so I ran
>>> setup:
>>>
>>> $ ./raco setup
>>>
>>> Everything appeared to work. Started DrRacket:
>>>
>>> $ ./drracket &
>>>
>>> Got this error on startup:
>>>
>>> DrRacket:module-language.rkt:first-opened exn: link: bad variable
>>> linkage;
>>> reference to a variable that has the wrong procedure or structure-type
>>> shape
>>> reference phase level: 0
>>> variable module: "/home/neil/plt/collects/syntax/module-reader.rkt"
>>> variable phase: 0
>>> reference in module: "/home/neil/plt/collects/racket/lang/reader.rkt"
>>> (|[running body]| . #(struct:srcloc
>>> # #f #f #f #f))
>>> (call-with-limits . #(struct:srcloc
>>> # 358 0 14429 1724))
>>> (call-with-custodian-shutdown . #(struct:srcloc
>>> # 406 0 16321 316))
>>> (call-with-break-parameterization . #(struct:srcloc
>>> # 146 2
>>> 4832 517))
>>> (loop . #(struct:srcloc
>>> # 763 5 32166 1584))
>>> (#f . #(struct:srcloc
>>> # 451 6
>>> 19918 1056))
>>> (#f . #(struct:srcloc
>>> # 502 32
>>> 21905 120))
>>> (call-with-break-parameterization . #(struct:srcloc
>>> # 146 2
>>> 4832 517))
>>> (loop . #(struct:srcloc
>>> # 397 18
>>> 17838 540))
>>>
>>> But DrRacket still worked. Okay... ran the default program ("#lang
>>> racket"), got this output:
>>>
>>> Module Language: invalid module text
>>> link: bad variable linkage;
>>> reference to a variable that has the wrong procedure or structure-type
>>> shape
>>> reference phase level: 0
>>> variable module: "/home/neil/plt/collects/syntax/module-reader.rkt"
>>> variable phase: 0
>>> reference in module: "/home/neil/plt/collects/racket/lang/reader.rkt"
>>> in: wrap-internal
>>>
>>> Just did "raco setup -c" and "raco setup", waiting for completion.
>>>
>>> Any idea what broke?
>>>
>>> Neil ⊥
>>>
>>
>
> _
> Racket Developers list:
> http://lists.racket-lang.org/dev
--
Jay McCarthy
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay
"The glory of God is Intelligence" - D&C 93
_
Racket Developers list:
http://lists.racket-lang.org/dev
[racket-dev] Compilation of 5.3.2 fails on some compilers
Hi, i am getting the following error when i try to compile racket-textual on a a version of gcc that does not support the 'noinline' attribute: xsrc/place.c: In function 'place_start_proc': xsrc/place.c:2793: warning: assignment makes pointer from integer without a cast xsrc/place.c: At top level: xsrc/place.c:3185: error: conflicting types for 'place_start_proc_after_stack' xsrc/place.c:2793: note: previous implicit declaration of 'place_start_proc_after_stack' was here The cause is that the forward declaration of 'place_start_proc_after_stack' is missing. It was originally there (L 95) but the MZ_DO_NOT_INLINE macro expands to nothing, effectively removing the declaration. The wrapping macro was added in commit 9692765e2 but the commit message gives no real reason why it is needed. I am a bit worried to revert the change because i don't know which bug i could reintroduce. What would be the correct fix to compile 5.3.2? Tobias -- - Tobias Hammer DLR / Institute of Robotics and Mechatronics Muenchner Str. 20, D-82234 Wessling Tel.: 08153/28-1487 Mail: tobias.ham...@dlr.de _ Racket Developers list: http://lists.racket-lang.org/dev
