That worked.
On Mon, Jul 26, 2010 at 8:44 AM, Matthew Flatt wrote:
> Yes, it's the ".ss"->".rkt' conversion yet again.
>
> I've pushed a repair. To speed things up, maybe you can try changing
> the definition of `get-source-sha1' in "collects/compiler/cm.rkt" to
>
> (define (get-source-sha1 p)
>
Yes, it's the ".ss"->".rkt' conversion yet again.
I've pushed a repair. To speed things up, maybe you can try changing
the definition of `get-source-sha1' in "collects/compiler/cm.rkt" to
(define (get-source-sha1 p)
(with-handlers ([exn:fail:filesystem?
(lambda (exn)
With last night's build, the error message is now:
cm: no SHA-1 for dependency: #"C:\\Documents and Settings\\williamsm\\My
Documents\\Development\\madness\\madness.rkt"
I am using a development link (using PLaneT) to reference the madness (which
is an acronym for Multi-Agent Dynamic Network Simu
Sam appears to be corrects.
If "No Debugging or profiling" is selected, I get the backtrace. If
"Debugging" is selected, I only get the error message. And, most
interestingly, if "Debugging and profiling" is selected, it runs correctly.
Also, Robby's suspicion that it would run correctly if "Popu
At Sun, 25 Jul 2010 11:22:19 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt wrote:
> >
> > It's worrying, though, that you're getting a DrRacket backtrace that
> > covers "cm.rkt". Files in the main installation normally should not be
> > instrumented for backtr
On Sun, Jul 25, 2010 at 8:27 AM, Matthew Flatt wrote:
>
> It's worrying, though, that you're getting a DrRacket backtrace that
> covers "cm.rkt". Files in the main installation normally should not be
> instrumented for backtraces. Does your installation have any "drracket"
> subdirectories of any
The immediate bug is now fixed (to show up in a nightly build until
tomorrow).
It's worrying, though, that you're getting a DrRacket backtrace that
covers "cm.rkt". Files in the main installation normally should not be
instrumented for backtraces. Does your installation have any "drracket"
subdire
I downloaded the nightly build version
5.0.1.1--2010-07-23(57d3dd7df753abacc8642809216a873962204d4f/a) [3m] and the
error message is now:
..\..\..\..\..\..\..\..\..\Program
Files\Racket\collects\compiler\cm.rkt:94:26: cdr: expects argument of type
; given #
and the backtrace is:
cdr: expects arg
That version is after I improved error message, but before the repair.
It looks like the nightly build failed last night, which is why the
repair wasn't in the build. We're working on that problem.
At Fri, 23 Jul 2010 16:11:37 -0600, Doug Williams wrote:
> I downloaded the latest nightly build (v
I downloaded the latest nightly build (version
5.0.1.1--2010-07-21(ca106a41343233e3e2e1d6393b97ff6de67e01c4/a) [3m]). Now I
get the following error message:
cm: no SHA-1 for dependency: (collects #"scheme" #"base" #"lang"
#"reader.rkt")
Doug
On Thu, Jul 22, 2010 at 5:47 PM, Matthew Flatt wrote:
At Wed, 21 Jul 2010 17:09:03 -0600, Matthew Flatt wrote:
> I've pushed a change to the git repo that I don't think will fix the
> problem, but I think it will give us better information when you get a
> chance to try it.
The new error message provoked a bug report that led to a repair. So,
please
I've pushed a change to the git repo that I don't think will fix the
problem, but I think it will give us better information when you get a
chance to try it.
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
Sorry-- I should have been more clear: this looks like a bug and we'll
try to get it fixed.
Robby
On Tue, Jul 20, 2010 at 3:12 PM, Doug Williams
wrote:
> Since it is autogenerated code, most of the time it is just run once (via a
> shell call) and discarded - it's the results that are important
Since it is autogenerated code, most of the time it is just run once (via a
shell call) and discarded - it's the results that are important and send
back to the knowledge base. So, I don't need to keep the .zo files up to
date. In fact, the only reason I ever execute the autogenerated code under
Dr
Did you try disabling the automatic compilation (in the details
portion of the language dialog)? My guess is that that will make the
problem go away. (If so, you can also then start running "raco make
" in the shell to keep the .zo files up to date and save
on load times.)
Robby
On Tue, Jul 20, 2
Okay, some more information.
If I execute DrRacket with the Monte Carlo file, make sure Debugging is
checked (in the Language dialog with Show Details), and hit Run, I get the
error:
string as 1st argument, given: #f; other arguments
were:
"0fe14e326dff1551df22271bdae03080a46dff5a9cd41e2f58a86ac8
I seem have hit the same (or related) bug that Laurent Orseau submitted as
bug 11017 (but in a completely different context that might help track it
down) and I haven't been able to find a workaround. The actual error message
I get is:
string as 1st argument, given: #f; other arguments
were:
"c2
17 matches
Mail list logo