At Fri, 5 Dec 2014 14:04:47 -0800, John Clements wrote:
> 1) compilation failed because it couldn't find the 'racket' collection, but
> I noticed that it was referring to a nonexistent path, presumably because I
> had moved the root of the installation. Has that always been a bad idea?
Ok, yes, i
I think this problem wasn't due to an interrupted `make`.
The "data-lib" package changed today in a way that made "data.scrbl"
run for a very long time. The problem has been fixed, which is why your
fresh clone worked.
Even though `raco setup` showed a status line for "search.scrbl", I
imagine th
One more issue,
If I resume an interrupted "make" with "make" again, the compile takes
around ~5hrs to complete on my (modern, lots of memory, desktop)
machine. It gets stuck around "search.scrbl", as Vincent mentioned on
IRC (but eventually finishes).
I just grabbed a fresh clone though and it c
Sorry --- I've figure out how I misread your message, and I'm no longer
interested in the output of `raco show`.
The log shown for step 3 makes sense, in that `make` doesn't currently
run `raco setup` at the end. So, if "main-distribution" is already
installed, then nothing more happens after the
Can you run `raco pkg show`? It looks like `raco pkg install` thinks
you have "main-distribution" and "main-distribution-test" installed
already.
At Fri, 5 Dec 2014 14:04:47 -0800, John Clements wrote:
> Urg... more interesting problems. I pulled and tried to rebuild, and things
> went pear-shaped
Urg... more interesting problems. I pulled and tried to rebuild, and things
went pear-shaped.
1) compilation failed because it couldn't find the 'racket' collection, but
I noticed that it was referring to a nonexistent path, presumably because I
had moved the root of the installation. Has that al
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
"raco pkg" uses the API when it prints out "Querying GitHub":
https://github.com/plt/racket/blob/master/racket/collects/pkg/private/stage.rkt#L668
But when it is just doing a download and it has a particularly
checksum, it just does a GET on a download URL:
https://github.com/plt/racket/blob/mas
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/animation.rkt:1:18: cannot open module file
module path: frtime
path: /home/stchang/plt-split/racket/share/pkgs/
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
Typed "make" and it timed out again.
Could it be a github rate limit?
https://developer.github.com/v3/rate_limit/
https://developer.github.com/v3/#rate-limiting
Downloading
https://github.com/racket/distributed-places/tarball/917d33e217b3b4897fd86a5a8116087b0714b279
Downloading
https://github.
Did a fresh clone and then make (Debian 7.4) and got the error below,
even though git is not down. Do we need to increase the timeout?
Downloading
https://github.com/racket/icons/tarball/d6ec572b628874361c104858dad2a574119872fb
Downloading
https://github.com/racket/images/tarball/3458568c6ba363a
In cooperation with Sam, I've pushed a change to the way that `make`
links the content of "pkgs". If you run `make` again, it should tell
you to delete your old
racket/etc/config.rktd
Also, the "native-pkgs" submodule is gone. The problem that John saw
with "libintl.8.dylib" has been fixed by
On Thu, Dec 4, 2014 at 12:50 PM, John Clements wrote:
> Okay, some teething problems.
>
> First time around, it finished way too fast. The problem seemed to be that
> it had an error in compiling a planet package... ah, I see, there was no
> 'at-exp-lib' installed? Presumably this is because plan
Okay, some teething problems.
First time around, it finished way too fast. The problem seemed to be that
it had an error in compiling a planet package... ah, I see, there was no
'at-exp-lib' installed? Presumably this is because planet packages don't
declare pkg dependencies? Anyhow, this aborted
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':
>
> $
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':
$ git clone git:plt plt2
$ cd plt2/
$ git submodule init
$ git submodul
Is this the expected behavior:
> $ git clone git:plt plt2
> $ cd plt2/
> $ make
...
> raco setup: --- post-installing collections ---
> raco setup: --- checking package dependencies ---
> make install-common-last
> make fix-paths
> if [ "" != "" ]; then \
> if [ "" = "" ]; then \
>
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
19 matches
Mail list logo
