Re: [racket-dev] Release for v6.0 has begun

2013-11-21 Thread Matthew Flatt
At Fri, 22 Nov 2013 05:10:14 +0400, Aleksej Saushev wrote:
> It would be nice to change location of "config.rktd" file.
> 
> "config.rktd" looks like it cannot be changed by user at run time in any
> meaningful way. Thus it doesn't belong to sysconfdir.
> It should be placed into libdir instead.

It's intended to be changed by users, either directly or via tools like
`raco pkg config`:

 http://www.cs.utah.edu/plt/snapshots/current/doc/raco/config-file.html


> When building Racket tries to invoke i486--netbsdelf-ar which naturally
> doesn't exist. It would be nice if it used canonical archiver name first,
> which is "ar" per POSIX/SUS. Alternatively it should fall back to it when
> non-canonical one doesn't exist.

Right --- I've pushed a repair.

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


[racket-dev] unable to git fetch, or ssh -v to git.racket-lang.org ?

2013-11-21 Thread John Clements
This... doesn't look like something on my end?

oiseau:~/git-clements clements> ssh -v pltgit
OpenSSH_5.6p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/clements/.ssh/config
debug1: Applying options for pltgit
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to git.racket-lang.org [129.10.115.117] port 22.
debug1: Connection established.
debug1: identity file /Users/clements/.ssh/id_rsa type 1
debug1: identity file /Users/clements/.ssh/id_rsa-cert type -1
debug1: identity file /Users/clements/.ssh/id_rsa_plt-git type -1
debug1: identity file /Users/clements/.ssh/id_rsa_plt-git-cert type -1
debug1: identity file /Users/clements/.ssh/id_rsa_plt-git type -1
debug1: identity file /Users/clements/.ssh/id_rsa_plt-git-cert type -1
ssh_exchange_identification: Connection closed by remote host
oiseau:~/git-clements clements> git fetch
ssh_exchange_identification: Connection closed by remote host
fatal: The remote end hung up unexpectedly

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


Re: [racket-dev] Release for v6.0 has begun

2013-11-21 Thread Aleksej Saushev
Ryan Culpepper  writes:

>   >> NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT <<<

It would be nice to change location of "config.rktd" file.

"config.rktd" looks like it cannot be changed by user at run time in any
meaningful way. Thus it doesn't belong to sysconfdir.
It should be placed into libdir instead.

When building Racket tries to invoke i486--netbsdelf-ar which naturally
doesn't exist. It would be nice if it used canonical archiver name first,
which is "ar" per POSIX/SUS. Alternatively it should fall back to it when
non-canonical one doesn't exist.



patch-pkgs_drracket-pkgs_drracket-test_tests_drracket_run.sh
Description: Avoid non-portable "test \=\=".

-- 
BCE HA MOPE!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg install permission errors in 5.90?

2013-11-21 Thread Matthew Flatt
When I try similar steps, I get an error related to using the
installation's read-only documentation database (I'll investigate
more), but not a problem in the bytecode-building phase.


It looks like the failure is happening at a place where `raco setup` is
trying to fix up a file timestamps. That is, the timestamp on

 scheme-lib/scheme/compiled/serialize_rkt.zo

is apparently earlier than one of its dependencies. Based on SHA-1s,
`raco setup` knows that it doesn't need to recompile the file, but it's
trying to fix the timestamp.


Do you have any ideas on why file timestamps might be sync in the
installation?


At Wed, 20 Nov 2013 10:59:19 -0500, Greg Hendershott wrote:
> I've been meaning to ask.
> 
> With 5.90, `raco pkg install` gives a ton of permission errors... but
> works anyway.
> 
> Prior to 5.90 (e.g. with 5.3.5 and 5.3.6) this didn't happen.
> 
> I guess technically it is `raco setup` as run by `raco pkg install`.
> 
> Example transcript: https://gist.github.com/greghendershott/7565513
> 
> Is this as-intended and starting with 5.90 it needs to be `sudo`d?
> 
> (And if so, can someone explain more about why, and why there are
> errors but it works anyway?)
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Fwd: [DrDr] R27814 (timeout 0) (unclean 3) (stderr 3) (changes 17)

2013-11-21 Thread Robby Findler
This should be fixed now.

Robby


On Wed, Nov 20, 2013 at 11:14 PM, Sam Tobin-Hochstadt
wrote:

> It appears that Planet can't handle versions starting with 6. Is this
> something that can be fixed on the server?
>
> Sam
>
>
> -- Forwarded message --
> From:  
> Date: Wed, Nov 20, 2013 at 7:52 PM
> Subject: [DrDr] R27814 (timeout 0) (unclean 3) (stderr 3) (changes 17)
> To: sa...@racket-lang.org
>
>
> DrDr has finished building push #27814 after 1.17h.
>
> http://drdr.racket-lang.org/27814/
>
> A file you are responsible for has a condition that may need inspecting.
>   unclean:
>
> http://drdr.racket-lang.org/27814/pkgs/racket-pkgs/racket-benchmarks/tests/racket/benchmarks/mz/ssax.rktl
>
>   stderr:
>
> http://drdr.racket-lang.org/27814/pkgs/racket-pkgs/racket-benchmarks/tests/racket/benchmarks/mz/ssax.rktl
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] new package system status

2013-11-21 Thread Jay McCarthy
On Thu, Nov 21, 2013 at 9:39 AM, Greg Hendershott
 wrote:
> I think the interesting point is that you could make a (mostly) static
> web service, in which GET requests have ULRs that hit a static file
> server like Amazon S3, and only the PUT/POST/PATCH requests go to some
> live server.
>
> What about "dynamic" GETs like search by name or tag?
>
> 1. One choice is, don't support search. Client has to GET the full
> catalog, or GET a list of _all_ packages with tag X, and filter
> further itself. Not entirely unreasonable when there are hundreds not
> thousands of packages.

This is basically how it works. The /index.html from S3 reads the
/pkgs-all.json which is a JSON dump of the entire database and then
renders it. If you do any "active" stuff, then you send requests to
the dynamic server. /pkgs-all.json isn't the only available file
though.


-- 
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] Check syntax + phase levels

2013-11-21 Thread Asumu Takikawa
Hi all,

Would it be easy to supplement the current background syntax checking to
display the phase level of an identifier use or definition? I was
imagining it could draw the phase number next to the arrow.

I'd be willing to try to implement it myself if it's feasible and
someone points me in the right direction.

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] new package system status

2013-11-21 Thread Greg Hendershott
> What's the status of the package system?

I've used the package system pretty heavily for third-party stuff and
I think it's worked really well. IMHO it's less "heavy" for a package
developer, and for a package user.

(a) No hosted docs bugged me a lot at first, too. In practice I've
found that GitHub usually has the necessary info for a package. For a
simple package, a well-written README.md and a glance at the source is
enough for me to feel good about using it. For more complicated
packages, people are either hosting the Scribble HTML using GitHub
Pages or their own web server, or, using `scribble --markdown` to
generate the README.md.

(b) For me the biggest issue has been that the options have evolved
from 5.3.6. There's a subset of stuff that works on 5.3.5, .6, and
5.90. If you care about this let me know and I'll write up my notes.
However if you're comfortable telling folks, "just use Racket 6" then
it will be simpler plus you can use some of the conveniences (like
single-collection packages, #:version, and whatever else I'm
forgetting).

> * "https://pkg.racket-lang.org/"; has roughness like requiring JavaScript to
> navigate, which is not only bad for browsers but bad for search engines.
> (Usually, for this kind of site, we'd want to start with a page structure,
> and then add in backward-compatible JS for slickness.)

The status quo is a result of wanting to better uptime by making it as
static as possible, with things stored on Amazon S3. Originally it was
a fully live web server. Downtime meant nothing worked. Whereas now,
downtime means a dev can't add/update a package, but users (human and
automated builds) can still get packages. This is smart and good.

My only question is whether the core should be a web _site_. I think
probably the core should instead be a RESTful web _service_? That way,
it could be used by a variety of tools, as well as by various
front-end web sites, one of which would be pkg.r-l.org.

(A well-designed RESTful web service _can_ be navigated by humans in a
browser, even though it's not intended as the primary human UI, i.e.
not a web _site_ in the normal sense. e.g. If it returns XML responses
and your browser auto-linkifies URLs in XML, so you can click them,
you can navigate the web service API.)

I think the interesting point is that you could make a (mostly) static
web service, in which GET requests have ULRs that hit a static file
server like Amazon S3, and only the PUT/POST/PATCH requests go to some
live server.

What about "dynamic" GETs like search by name or tag?

1. One choice is, don't support search. Client has to GET the full
catalog, or GET a list of _all_ packages with tag X, and filter
further itself. Not entirely unreasonable when there are hundreds not
thousands of packages.

2. Another choice is that the write requests precompute the full set
of answers and update the static GET files. This may seem crazy, but
not necessarily depending on response space size. It's a sort of
over-eager evaluation with memoization. (Whereas a live web server is
as-needed eval without memoization, and a live web server with e.g.
Varnish in front is as-needed eval with memoization.)

(Sorry for the back seat thinking out loud.)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg install permission errors in 5.90?

2013-11-21 Thread Greg Hendershott
p.s. In the gist I linked to, I had deleted some stuff from the
beginning and end, because I thought it was N/A and the thing is
already very long.

In case I was wrong, the full raw log is here:

https://s3.amazonaws.com/archive.travis-ci.org/jobs/14278903/log.txt


On Thu, Nov 21, 2013 at 10:13 AM, Greg Hendershott
 wrote:
>> Do you have any ideas on why file timestamps might be sync in the
>> installation?
>
> The transcript I linked to is from a Travis CI session. It's a fairly
> clean slate.
>
> - VM with Ubuntu image and gcc tools.
> - Travis git clones the repo (being tested) source
> - Racke nightly build is downloaded, Racket install sh script is run.
> - raco pkg install --link 
>
> Hmm. As I type this, occurs to me: What if the nightly build file
> timestamps are Utah time, but the Travis server is running in a
> different time zone?  Could that explain it?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg install permission errors in 5.90?

2013-11-21 Thread Greg Hendershott
> Do you have any ideas on why file timestamps might be sync in the
> installation?

The transcript I linked to is from a Travis CI session. It's a fairly
clean slate.

- VM with Ubuntu image and gcc tools.
- Travis git clones the repo (being tested) source
- Racke nightly build is downloaded, Racket install sh script is run.
- raco pkg install --link 

Hmm. As I type this, occurs to me: What if the nightly build file
timestamps are Utah time, but the Travis server is running in a
different time zone?  Could that explain it?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] raco pkg install permission errors in 5.90?

2013-11-21 Thread Greg Hendershott
Here's simplest example I have so far:

https://travis-ci.org/greghendershott/rackjure/builds/14292882

I've been testing this package against 5.3.2, 5.3.5, 5.3.6. Building
fine against all.

Last night I thought, oh, I should add HEAD to the matrix.

It fails. In this case, as a result of just a `raco make main.rkt`.
But with similar error:

~~~

$ /usr/racket/bin/raco make main.rkt
open-output-file: cannot open output file
  path: 
/usr/racket/share/pkgs/rackunit-lib/rackunit/private/compiled/location_rkt.zo
  system error: Permission denied; errno=13
  context...:
   /usr/racket/collects/compiler/cm.rkt:221:4
   /usr/racket/collects/compiler/cm.rkt:510:0: maybe-compile-zo
   /usr/racket/collects/compiler/cm.rkt:622:2: do-check
   /usr/racket/collects/compiler/cm.rkt:661:15
   /usr/racket/collects/compiler/../racket/private/map.rkt:113:23: loop
   /usr/racket/collects/compiler/cm.rkt:622:2: do-check
   /usr/racket/collects/compiler/cm.rkt:661:15
   /usr/racket/collects/compiler/../racket/private/map.rkt:113:23: loop
   /usr/racket/collects/compiler/cm.rkt:622:2: do-check
   /usr/racket/collects/compiler/cm.rkt:661:15
   /usr/racket/collects/compiler/../racket/private/map.rkt:113:23: loop
   /usr/racket/collects/compiler/cm.rkt:622:2: do-check
   /usr/racket/collects/compiler/cm.rkt:661:15
   /usr/racket/collects/compiler/../racket/private/map.rkt:113:23: loop
   /usr/racket/collects/compiler/cm.rkt:622:2: do-check
   /usr/racket/collects/compiler/cm.rkt:732:4:
compilation-manager-load-handler...


The command "/usr/racket/bin/raco make main.rkt" exited with 1.
$ /usr/racket/bin/raco test -x .
raco test: (submod "./conditionals.rkt" test)
raco test: (submod "./dict.rkt" test)
raco test: (submod "./str.rkt" test)
raco test: (submod "./test.rkt" test)
raco test: (submod "./threading.rkt" test)
34 tests passed

The command "/usr/racket/bin/raco test -x ." exited with 0.

Done. Your build exited with 1.
~~~


On Thu, Nov 21, 2013 at 10:18 AM, Greg Hendershott
 wrote:
> p.s. In the gist I linked to, I had deleted some stuff from the
> beginning and end, because I thought it was N/A and the thing is
> already very long.
>
> In case I was wrong, the full raw log is here:
>
> https://s3.amazonaws.com/archive.travis-ci.org/jobs/14278903/log.txt
>
>
> On Thu, Nov 21, 2013 at 10:13 AM, Greg Hendershott
>  wrote:
>>> Do you have any ideas on why file timestamps might be sync in the
>>> installation?
>>
>> The transcript I linked to is from a Travis CI session. It's a fairly
>> clean slate.
>>
>> - VM with Ubuntu image and gcc tools.
>> - Travis git clones the repo (being tested) source
>> - Racke nightly build is downloaded, Racket install sh script is run.
>> - raco pkg install --link 
>>
>> Hmm. As I type this, occurs to me: What if the nightly build file
>> timestamps are Utah time, but the Travis server is running in a
>> different time zone?  Could that explain it?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev