From robby at eecs.northwestern.edu Sat Aug 1 13:59:18 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Sat Aug 1 13:59:36 2009
Subject: [plt-dev] Re: [plt-scheme] Automatic compilation for drscheme's
Module language
In-Reply-To: <932b2f1f0907311947g5e1241d6p1e9f0013e8d6af11@mail.gmail.com>
References: <932b2f1f0907292239i4069f0f1h4e088c2ee2c57c8@mail.gmail.com>
<63bb19ae0907300835q1ebe1118rf3ea83b58d34b206@mail.gmail.com>
<932b2f1f0907301336s1f9e67b0j6a1ad57c7c527d0a@mail.gmail.com>
<63bb19ae0907301359u100ef554r481163c08828ec26@mail.gmail.com>
<932b2f1f0907301822y32863fe3wb653ee48ae787f20@mail.gmail.com>
<932b2f1f0907311947g5e1241d6p1e9f0013e8d6af11@mail.gmail.com>
Message-ID: <932b2f1f0908011059pf3ac1d8nbfc8f6fad5253142@mail.gmail.com>
JFYI: Jay pointed out a problem with drscheme's automatic compilation
that, when I fixed it, makes me think that drscheme and mz should now
behave the same when requiring non-existent files.
Robby
From kwinterling at gmail.com Sun Aug 2 20:43:18 2009
From: kwinterling at gmail.com (Karl Winterling)
Date: Sun Aug 2 21:04:03 2009
Subject: [plt-dev] Documentation Suggestion for mred-text
Message-ID: <5dd359570908021743l15696157n1549489a620796a5@mail.gmail.com>
Per a discussion with Eli today on #scheme, I've modified a copy of
http://svn.plt-scheme.org/plt/trunk/collects/scribblings/guide/running.scrbl
to include instructions for running MrEd applications in text terminal
or editor. Specifically, I put the following just before
`start-module-mode':
@subsubsection[#:tag "start-mred-text"]{Using @exec{mred} in a Text Interface}
Programmers who wish to use libraries that require @exec{mred} (such as
@schememodname{scheme/gui}) interactively in a text-based interface like
a terminal window or text editor should use the @exec{mred-text}
executable. Using @exec{mred-text} lets the programmer interactively
debug graphical applications without using DrScheme or the MrEd GUI
@tech{REPL}. Running @exec{mred} with @Flag{z} gives similar behavior
but causes some problems, especially on Windows.
---Karl
From hkBst at gentoo.org Mon Aug 3 11:52:08 2009
From: hkBst at gentoo.org (Marijn Schouten (hkBst))
Date: Mon Aug 3 12:10:12 2009
Subject: [plt-dev] typo in src/mzscheme/gc2/newgc.c triggered by
--enable-backtrace
Message-ID: <4A7707A8.8060508@gentoo.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
there is a typo in src/mzscheme/gc2/newgc.c triggered which is triggered by
configuring with --enable-backtrace.[1]
diff -ur plt-4.2.1.orig/src/mzscheme/gc2/newgc.c plt-4.2.1/src/mzscheme/gc2/newgc.c
- --- plt-4.2.1.orig/src/mzscheme/gc2/newgc.c 2009-07-16 14:28:05.000000000 +0200
+++ plt-4.2.1/src/mzscheme/gc2/newgc.c 2009-08-03 13:58:23.000000000 +0200
@@ -2331,7 +2331,7 @@
sizes[tag] += info->size;
}
if (tag == trace_for_tag) {
- - register_traced_object(obj_staart);
+ register_traced_object(obj_start);
if (for_each_found)
for_each_found(obj_start);
}
fixes it.
Marijn
[1]:http://bugs.gentoo.org/show_bug.cgi?id=280166
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkp3BygACgkQp/VmCx0OL2zQ3ACgrcwePhTp4soyG1kjQKU/D2UB
GsAAn3YIs2ZuCKTpkAifncrU/btON6in
=XLdM
-----END PGP SIGNATURE-----
From cce at ccs.neu.edu Mon Aug 3 12:11:39 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Mon Aug 3 12:12:17 2009
Subject: [plt-dev] drscheme:debug:get-cm-key
Message-ID: <990e0c030908030911j6092146m63843bd88f6a5072@mail.gmail.com>
I use SchemeUnit 2:11 (the last version to have a GUI), and now every
time I open DrScheme I get an error from SchemeUnit about
"drscheme:debug:get-cm-key" being undefined. Is this an intentional
API change? If not, we should fix it; if so hopefully we can get
either a GUI for SchemeUnit 3 (or the collects SchemeUnit), or a patch
release of SchemeUnit 2 that doesn't use this binding.
Carl Eastlund
From ryanc at ccs.neu.edu Mon Aug 3 12:47:13 2009
From: ryanc at ccs.neu.edu (Ryan Culpepper)
Date: Mon Aug 3 12:47:37 2009
Subject: [plt-dev] drscheme:debug:get-cm-key
In-Reply-To: <990e0c030908030911j6092146m63843bd88f6a5072@mail.gmail.com>
References: <990e0c030908030911j6092146m63843bd88f6a5072@mail.gmail.com>
Message-ID: <99492E98-95D8-4CB3-BC95-437B2ED5C21B@ccs.neu.edu>
On Aug 3, 2009, at 12:11 PM, Carl Eastlund wrote:
> I use SchemeUnit 2:11 (the last version to have a GUI), and now every
> time I open DrScheme I get an error from SchemeUnit about
> "drscheme:debug:get-cm-key" being undefined. Is this an intentional
> API change? If not, we should fix it; if so hopefully we can get
> either a GUI for SchemeUnit 3 (or the collects SchemeUnit), or a patch
> release of SchemeUnit 2 that doesn't use this binding.
If this is an intentional change, I can create a minor release of
schemeunit:2 to update the gui.
Ryan
From tewk at cs.utah.edu Mon Aug 3 16:53:33 2009
From: tewk at cs.utah.edu (Kevin Tew)
Date: Mon Aug 3 16:53:56 2009
Subject: [plt-dev] typo in src/mzscheme/gc2/newgc.c triggered
by --enable-backtrace
In-Reply-To: <4A7707A8.8060508@gentoo.org>
References: <4A7707A8.8060508@gentoo.org>
Message-ID: <4A774E4D.2050008@cs.utah.edu>
Should be fixed upstream in plt SVN.
Kevin
Marijn Schouten (hkBst) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> there is a typo in src/mzscheme/gc2/newgc.c triggered which is triggered by
> configuring with --enable-backtrace.[1]
>
> diff -ur plt-4.2.1.orig/src/mzscheme/gc2/newgc.c plt-4.2.1/src/mzscheme/gc2/newgc.c
> - --- plt-4.2.1.orig/src/mzscheme/gc2/newgc.c 2009-07-16 14:28:05.000000000 +0200
> +++ plt-4.2.1/src/mzscheme/gc2/newgc.c 2009-08-03 13:58:23.000000000 +0200
> @@ -2331,7 +2331,7 @@
> sizes[tag] += info->size;
> }
> if (tag == trace_for_tag) {
> - - register_traced_object(obj_staart);
> + register_traced_object(obj_start);
> if (for_each_found)
> for_each_found(obj_start);
> }
>
> fixes it.
>
> Marijn
>
> [1]:http://bugs.gentoo.org/show_bug.cgi?id=280166
>
> - --
> If you cannot read my mind, then listen to what I say.
>
> Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
> , #gentoo-{lisp,ml} on FreeNode
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkp3BygACgkQp/VmCx0OL2zQ3ACgrcwePhTp4soyG1kjQKU/D2UB
> GsAAn3YIs2ZuCKTpkAifncrU/btON6in
> =XLdM
> -----END PGP SIGNATURE-----
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
From cce at ccs.neu.edu Wed Aug 5 14:33:29 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Wed Aug 5 14:34:10 2009
Subject: [plt-dev] Universe & HtDP/2e build errors
Message-ID: <990e0c030908051133w589470f8tf8c3f8a3d515ccd1@mail.gmail.com>
I get the following errors from the HtDP/2e and Universe stuff when I
run 'setup-plt -D':
setup-plt: version: 4.2.1.5 [3m]
setup-plt: variants: 3m
setup-plt: main collects: /Users/cce/plt/trunk/collects
setup-plt: collects paths:
setup-plt: /Users/cce/Library/PLT Scheme/4.2.1.5/collects
setup-plt: /Users/cce/plt/trunk/collects
setup-plt: --- pre-installing collections ---
setup-plt: pre-installing: plot
setup-plt: pre-installing: profj (ProfessorJ)
setup-plt: pre-installing: sgl
setup-plt: --- compiling collections ---
setup-plt: making: 2htdp (HtDP/2e Teachpacks)
setup-plt: in 2htdp
dynamic-require: unknown module: '#%mred-kernel; need to run in mred
instead of mzscheme
setup-plt: making: 2htdp/private
setup-plt: in 2htdp/private
check-aux.ss:190:9: module: identifier is already imported at:
check-color in: (define-values (check-color) (new-lambda (tag width
rank) (check-arg tag (or (symbol? width) (string? width)) "color
symbol or string" rank width)))
setup-plt: making: 2htdp/uchat
setup-plt: in 2htdp
dynamic-require: unknown module: '#%mred-kernel; need to run in mred
instead of mzscheme
setup-plt: making: afm
setup-plt: making: algol60
setup-plt: making: algol60/examples
setup-plt: making: at-exp
setup-plt: making: at-exp/lang
setup-plt: making: browser
setup-plt: making: browser/private
setup-plt: making: combinator-parser
setup-plt: making: combinator-parser/private-combinator
setup-plt: making: compiler
setup-plt: making: compiler/private
setup-plt: making: config
setup-plt: making: defaults
setup-plt: making: deinprogramm (DeinProgramm)
setup-plt: making: deinprogramm/DMdA
setup-plt: making: deinprogramm/DMdA-advanced
setup-plt: making: deinprogramm/DMdA-advanced/lang
setup-plt: making: deinprogramm/DMdA-assignments
setup-plt: making: deinprogramm/DMdA-assignments/lang
setup-plt: making: deinprogramm/DMdA-beginner
setup-plt: making: deinprogramm/DMdA-beginner/lang
setup-plt: making: deinprogramm/DMdA-vanilla
setup-plt: making: deinprogramm/DMdA-vanilla/lang
setup-plt: making: deinprogramm/DMdA/lang
setup-plt: making: deinprogramm/contract
setup-plt: making: deinprogramm/scribblings
setup-plt: making: drscheme
setup-plt: making: drscheme/private
setup-plt: making: dynext
setup-plt: making: dynext/private
setup-plt: making: embedded-gui
setup-plt: making: embedded-gui/private
setup-plt: making: embedded-gui/scribblings
setup-plt: making: eopl
setup-plt: making: eopl/lang
setup-plt: making: eopl/private
setup-plt: making: errortrace
setup-plt: making: errortrace/scribblings
setup-plt: making: ffi (Sample FFIs)
setup-plt: making: ffi/private
setup-plt: making: file
setup-plt: making: file/private
setup-plt: making: file/scribblings
setup-plt: making: framework
setup-plt: making: framework/private
setup-plt: making: frtime (FrTime)
setup-plt: making: frtime/animation
setup-plt: making: frtime/core
setup-plt: making: frtime/frlibs
setup-plt: making: frtime/gui
setup-plt: making: frtime/lang
setup-plt: making: frtime/opt
setup-plt: making: frtime/reactive
setup-plt: making: frtime/reactive/lang
setup-plt: making: frtime/scribblings
setup-plt: making: frtime/tool (FrTime Tool)
setup-plt: making: games
setup-plt: in 2htdp
dynamic-require: unknown module: '#%mred-kernel; need to run in mred
instead of mzscheme
setup-plt: making: games/aces
setup-plt: making: games/blackjack
setup-plt: making: games/cards
setup-plt: making: games/cards/hicolor
setup-plt: making: games/cards/locolor
setup-plt: making: games/chat-noir (Chat Noir)
setup-plt: in 2htdp
dynamic-require: unknown module: '#%mred-kernel; need to run in mred
instead of mzscheme
setup-plt: making: games/checkers
setup-plt: making: games/crazy8s (Crazy 8s)
setup-plt: making: games/crazy8s/images
setup-plt: making: games/doors
setup-plt: making: games/doors/private
setup-plt: making: games/gcalc (GCalc)
setup-plt: making: games/ginrummy (Rummy)
setup-plt: making: games/gl-board-game
setup-plt: making: games/gobblet
setup-plt: making: games/gofish (Go Fish)
setup-plt: making: games/jewel
setup-plt: making: games/lights-out
setup-plt: making: games/memory
setup-plt: making: games/memory/images
setup-plt: making: games/mines (Minesweeper)
setup-plt: making: games/mines/images
setup-plt: making: games/paint-by-numbers
setup-plt: making: games/parcheesi
setup-plt: making: games/pousse
setup-plt: making: games/same
setup-plt: making: games/scribblings
setup-plt: making: games/slidey
setup-plt: making: games/spider
setup-plt: making: graphics
setup-plt: making: graphics/scribblings
setup-plt: making: gui-debugger
setup-plt: making: gui-debugger/icons
setup-plt: making: guibuilder
setup-plt: making: handin-client (Course)
setup-plt: making: handin-server
setup-plt: making: handin-server/overridden-collects
setup-plt: making: handin-server/overridden-collects/fake-teachpack
setup-plt: making: handin-server/overridden-collects/fake-teachpack/htdp
setup-plt: making: handin-server/private
setup-plt: making: handin-server/scribblings
setup-plt: making: help
setup-plt: making: help/private
setup-plt: making: hierlist
setup-plt: making: honu
setup-plt: making: honu/lang
setup-plt: making: honu/private
setup-plt: making: htdch (Java Teachpacks)
setup-plt: making: htdch/colors
setup-plt: making: htdch/draw
setup-plt: making: htdch/geometry
setup-plt: making: htdch/graphics
setup-plt: making: htdch/idraw (Imperative Drawing)
setup-plt: making: htdp (HtDP Teachpacks)
setup-plt: in htdp
world.ss:414:9: module: identifier is already imported at: check-color
in: (define-values (check-color) (new-lambda (tag width rank)
(check-arg tag (or (symbol? width) (string? width)) "color symbol or
string" rank width)))
setup-plt: making: html
setup-plt: making: icons
setup-plt: making: info-domain
setup-plt: making: lang (HtDP Languages)
setup-plt: making: lang/private
setup-plt: making: lang/private/contracts
setup-plt: making: launcher
setup-plt: making: lazy (Lazy Scheme)
setup-plt: making: lazy/lang
setup-plt: making: macro-debugger
setup-plt: making: macro-debugger/model (Expansion Model)
setup-plt: making: macro-debugger/syntax-browser
setup-plt: making: macro-debugger/util
setup-plt: making: macro-debugger/view
setup-plt: making: make
setup-plt: making: mred
setup-plt: making: mred/lang
setup-plt: making: mred/private
setup-plt: making: mred/private/wxme
setup-plt: making: mrlib
setup-plt: making: mrlib/hierlist
setup-plt: making: mrlib/private
setup-plt: making: mrlib/private/aligned-pasteboard
setup-plt: making: mrlib/scribblings
setup-plt: making: mrlib/scribblings/aligned-pasteboard
setup-plt: making: mrlib/scribblings/graph
setup-plt: making: mrlib/scribblings/hierlist
setup-plt: making: mysterx
setup-plt: making: mysterx/private
setup-plt: making: mysterx/scribblings
setup-plt: making: mzcom
setup-plt: making: mzlib
setup-plt: making: mzlib/private
setup-plt: making: mzlib/scribblings
setup-plt: making: mzscheme
setup-plt: making: mzscheme/lang
setup-plt: making: net
setup-plt: making: net/private
setup-plt: making: net/scribblings
setup-plt: making: openssl
setup-plt: making: parser-tools
setup-plt: making: parser-tools/examples
setup-plt: making: parser-tools/private-lex
setup-plt: making: parser-tools/private-yacc
setup-plt: making: planet (PLaneT)
setup-plt: making: planet/lang
setup-plt: making: planet/private
setup-plt: making: plot
setup-plt: making: plot/fonts
setup-plt: making: plot/src
setup-plt: making: plot/src/all
setup-plt: making: plot/src/fit
setup-plt: making: preprocessor
setup-plt: making: preprocessor/scribblings
setup-plt: making: profile
setup-plt: making: profile/scribblings
setup-plt: making: profj (ProfessorJ)
setup-plt: making: profj/classpath
setup-plt: making: profj/comb-parsers
setup-plt: making: profj/libs
setup-plt: making: profj/libs/java
setup-plt: making: profj/libs/java/io
setup-plt: making: profj/libs/java/lang
setup-plt: making: profj/libs/java/tester
setup-plt: making: profj/libs/java/util
setup-plt: making: profj/parsers
setup-plt: making: profj/scribblings
setup-plt: making: profjWizard (ProfessorJ Wizard)
setup-plt: making: r5rs
setup-plt: making: r5rs/lang
setup-plt: making: r5rs/private
setup-plt: making: r6rs
setup-plt: making: r6rs/lang
setup-plt: making: r6rs/private
setup-plt: making: r6rs/scribblings
setup-plt: making: readline
setup-plt: making: redex (PLT Redex)
setup-plt: making: redex/examples (Reduction Semantics examples)
setup-plt: making: redex/private
setup-plt: making: redex/private/bmps
setup-plt: making: repos-time-stamp
setup-plt: making: rnrs
setup-plt: making: rnrs/arithmetic
setup-plt: making: rnrs/io
setup-plt: making: rnrs/records
setup-plt: making: s-exp
setup-plt: making: s-exp/lang
setup-plt: making: scheme
setup-plt: making: scheme/base
setup-plt: making: scheme/base/lang
setup-plt: making: scheme/gui
setup-plt: making: scheme/gui/lang
setup-plt: making: scheme/lang
setup-plt: making: scheme/load
setup-plt: making: scheme/load/lang
setup-plt: making: scheme/match
setup-plt: making: scheme/private
setup-plt: making: scheme/signature
setup-plt: making: scheme/signature/lang
setup-plt: making: scheme/unit
setup-plt: making: scheme/unit/lang
setup-plt: making: schemeunit (SchemeUnit)
setup-plt: making: schemeunit/scribblings
setup-plt: making: scribble
setup-plt: making: scribble/base
setup-plt: making: scribble/base/lang
setup-plt: making: scribble/doc
setup-plt: making: scribble/doc/lang
setup-plt: making: scribble/lp
setup-plt: making: scribble/lp/lang
setup-plt: making: scribble/manual
setup-plt: making: scribble/manual/lang
setup-plt: making: scribble/private
setup-plt: making: scribble/sigplan
setup-plt: making: scribble/sigplan/lang
setup-plt: making: scribble/text
setup-plt: making: scribble/text/lang
setup-plt: making: scribblings (Documentation Sources)
setup-plt: making: scribblings/drscheme
setup-plt: making: scribblings/foreign
setup-plt: making: scribblings/framework
setup-plt: making: scribblings/gui
setup-plt: making: scribblings/guide
setup-plt: making: scribblings/honu
setup-plt: making: scribblings/htdp-langs
setup-plt: making: scribblings/inside
setup-plt: making: scribblings/main
setup-plt: making: scribblings/main/private
setup-plt: making: scribblings/main/user
setup-plt: making: scribblings/more
setup-plt: making: scribblings/mzc
setup-plt: making: scribblings/quick
setup-plt: making: scribblings/quick/images
setup-plt: making: scribblings/reference
setup-plt: making: scribblings/scribble
setup-plt: making: scribblings/setup-plt
setup-plt: making: scribblings/slideshow
setup-plt: making: scribblings/tools
setup-plt: making: scriblib
setup-plt: making: scriblib/private
setup-plt: making: scriblib/scribblings
setup-plt: making: setup
setup-plt: making: setup/infotab
setup-plt: making: setup/infotab/lang
setup-plt: making: setup/private
setup-plt: making: sgl
setup-plt: making: sgl/scribblings
setup-plt: making: sirmail
setup-plt: making: sirmail/emoticon
setup-plt: making: slatex
setup-plt: making: slideshow
setup-plt: making: slideshow/lang
setup-plt: making: slideshow/private
setup-plt: making: srfi
setup-plt: making: srfi/%3a1
setup-plt: making: srfi/%3a11
setup-plt: making: srfi/%3a13
setup-plt: making: srfi/%3a14
setup-plt: making: srfi/%3a16
setup-plt: making: srfi/%3a17
setup-plt: making: srfi/%3a18
setup-plt: making: srfi/%3a19
setup-plt: making: srfi/%3a2
setup-plt: making: srfi/%3a23
setup-plt: making: srfi/%3a25
setup-plt: making: srfi/%3a26
setup-plt: making: srfi/%3a27
setup-plt: making: srfi/%3a28
setup-plt: making: srfi/%3a29
setup-plt: making: srfi/%3a31
setup-plt: making: srfi/%3a38
setup-plt: making: srfi/%3a39
setup-plt: making: srfi/%3a41
setup-plt: making: srfi/%3a42
setup-plt: making: srfi/%3a43
setup-plt: making: srfi/%3a45
setup-plt: making: srfi/%3a48
setup-plt: making: srfi/%3a5
setup-plt: making: srfi/%3a54
setup-plt: making: srfi/%3a57
setup-plt: making: srfi/%3a59
setup-plt: making: srfi/%3a6
setup-plt: making: srfi/%3a60
setup-plt: making: srfi/%3a61
setup-plt: making: srfi/%3a63
setup-plt: making: srfi/%3a64
setup-plt: making: srfi/%3a66
setup-plt: making: srfi/%3a67
setup-plt: making: srfi/%3a69
setup-plt: making: srfi/%3a71
setup-plt: making: srfi/%3a74
setup-plt: making: srfi/%3a78
setup-plt: making: srfi/%3a8
setup-plt: making: srfi/%3a86
setup-plt: making: srfi/%3a87
setup-plt: making: srfi/%3a9
setup-plt: making: srfi/1
setup-plt: making: srfi/13
setup-plt: making: srfi/14
setup-plt: making: srfi/17
setup-plt: making: srfi/19
setup-plt: making: srfi/2
setup-plt: making: srfi/25
setup-plt: making: srfi/26
setup-plt: making: srfi/27
setup-plt: making: srfi/29
setup-plt: making: srfi/29/bundles
setup-plt: making: srfi/29/bundles/es
setup-plt: making: srfi/31
setup-plt: making: srfi/32
setup-plt: making: srfi/34
setup-plt: making: srfi/35
setup-plt: making: srfi/38
setup-plt: making: srfi/40
setup-plt: making: srfi/41
setup-plt: making: srfi/42
setup-plt: making: srfi/42ref
setup-plt: making: srfi/43
setup-plt: making: srfi/45
setup-plt: making: srfi/48
setup-plt: making: srfi/5
setup-plt: making: srfi/54
setup-plt: making: srfi/57
setup-plt: making: srfi/59
setup-plt: making: srfi/60
setup-plt: making: srfi/61
setup-plt: making: srfi/63
setup-plt: making: srfi/64
setup-plt: making: srfi/67
setup-plt: making: srfi/69
setup-plt: making: srfi/7
setup-plt: making: srfi/71
setup-plt: making: srfi/74
setup-plt: making: srfi/78
setup-plt: making: srfi/8
setup-plt: making: srfi/86
setup-plt: making: srfi/87
setup-plt: making: srfi/9
setup-plt: making: stepper
setup-plt: making: stepper/private
setup-plt: making: string-constants
setup-plt: making: string-constants/private
setup-plt: making: stxclass
setup-plt: making: stxclass/private
setup-plt: making: stxclass/scribblings
setup-plt: making: stxclass/util
setup-plt: making: swindle
setup-plt: making: swindle/lang
setup-plt: making: syntax
setup-plt: making: syntax-color
setup-plt: making: syntax/private
setup-plt: making: syntax/private/stxparse
setup-plt: making: syntax/private/util
setup-plt: making: syntax/scribblings
setup-plt: making: teachpack
setup-plt: in htdp
/Users/cce/plt/trunk/collects/htdp/world.ss:414:9: module: identifier
is already imported at: check-color in: (define-values (check-color)
(new-lambda (tag width rank) (check-arg tag (or (symbol? width)
(string? width)) "color symbol or string" rank width)))
setup-plt: making: teachpack/2htdp
setup-plt: in 2htdp
dynamic-require: unknown module: '#%mred-kernel; need to run in mred
instead of mzscheme
setup-plt: making: teachpack/2htdp/scribblings
setup-plt: making: teachpack/deinprogramm
setup-plt: making: teachpack/htdp
setup-plt: in htdp
/Users/cce/plt/trunk/collects/htdp/world.ss:414:9: module: identifier
is already imported at: check-color in: (define-values (check-color)
(new-lambda (tag width rank) (check-arg tag (or (symbol? width)
(string? width)) "color symbol or string" rank width)))
setup-plt: making: teachpack/htdp/scribblings
setup-plt: making: test-box-recovery
setup-plt: making: test-engine
setup-plt: making: tests (Test Suites)
setup-plt: making: tests/drscheme
setup-plt: making: tests/file
setup-plt: making: tests/framework
setup-plt: making: tests/lazy
setup-plt: making: tests/net
setup-plt: making: tests/profile
setup-plt: making: tests/scribble
setup-plt: making: tests/utils
setup-plt: making: tex2page
setup-plt: making: texpict
setup-plt: making: texpict/private
setup-plt: making: trace (Calltrace)
setup-plt: making: trace/scribblings
setup-plt: making: typed
setup-plt: making: typed-scheme
setup-plt: making: typed-scheme/env
setup-plt: making: typed-scheme/infer
setup-plt: making: typed-scheme/lang
setup-plt: making: typed-scheme/no-check
setup-plt: making: typed-scheme/no-check/lang
setup-plt: making: typed-scheme/private
setup-plt: making: typed-scheme/rep
setup-plt: making: typed-scheme/typecheck
setup-plt: making: typed-scheme/types
setup-plt: making: typed-scheme/utils
setup-plt: making: typed/file
setup-plt: making: typed/framework
setup-plt: making: typed/mred
setup-plt: making: typed/net
setup-plt: making: typed/private
setup-plt: making: typed/srfi
setup-plt: making: version
setup-plt: making: waterworld
setup-plt: making: web-server
setup-plt: making: web-server/configuration
setup-plt: making: web-server/dispatch
setup-plt: making: web-server/dispatchers
setup-plt: making: web-server/formlets
setup-plt: making: web-server/http
setup-plt: making: web-server/insta
setup-plt: making: web-server/insta/lang
setup-plt: making: web-server/lang
setup-plt: making: web-server/managers
setup-plt: making: web-server/private
setup-plt: making: web-server/scribblings
setup-plt: making: web-server/scribblings/tutorial
setup-plt: making: web-server/scribblings/tutorial/images
setup-plt: making: web-server/servlet
setup-plt: making: web-server/stuffers
setup-plt: making: wxme
setup-plt: making: wxme/private
setup-plt: making: xml
setup-plt: making: xml/private
setup-plt: making: /Users/cce/research/planet/dracula (Dracula)
setup-plt: in /Users/cce/research/planet/dracula/teachpacks/
teachpacks/universe.ss:429:9: module: identifier is already imported
at: check-color in: (define-values (check-color) (new-lambda (tag
width rank) (check-arg tag (or (symbol? width) (string? width)) "color
symbol or string" rank width)))
setup-plt: making: /Users/cce/research/planet/dracula/acl2
setup-plt: making: /Users/cce/research/planet/dracula/drscheme
setup-plt: making: /Users/cce/research/planet/dracula/guide
setup-plt: making: /Users/cce/research/planet/dracula/guide/images
setup-plt: making: /Users/cce/research/planet/dracula/images
setup-plt: making: /Users/cce/research/planet/dracula/lang
setup-plt: making: /Users/cce/research/planet/dracula/lang/primitive-procedures
setup-plt: making: /Users/cce/research/planet/dracula/modular
setup-plt: in /Users/cce/research/planet/dracula/teachpacks/
/Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
setup-plt: making: /Users/cce/research/planet/dracula/modular/lang
setup-plt: making: /Users/cce/research/planet/dracula/modular/nonstd
setup-plt: making: /Users/cce/research/planet/dracula/modular/nonstd/lang
setup-plt: making: /Users/cce/research/planet/dracula/private
setup-plt: making: /Users/cce/research/planet/dracula/proof
setup-plt: making: /Users/cce/research/planet/dracula/reference
setup-plt: making: /Users/cce/research/planet/dracula/reference/acl2
setup-plt: making: /Users/cce/research/planet/dracula/reference/modular
setup-plt: making: /Users/cce/research/planet/dracula/reference/teachpacks
setup-plt: making: /Users/cce/research/planet/dracula/teachpacks
setup-plt: in /Users/cce/research/planet/dracula/teachpacks/
universe.ss:429:9: module: identifier is already imported at:
check-color in: (define-values (check-color) (new-lambda (tag width
rank) (check-arg tag (or (symbol? width) (string? width)) "color
symbol or string" rank width)))
setup-plt: making: /Users/cce/research/planet/dracula/test
setup-plt: in /Users/cce/research/planet/dracula/teachpacks/
/Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
setup-plt: making: /Users/cce/research/planet/experimental
setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2
setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/data
setup-plt: making:
/Users/cce/research/planet/experimental/hygienic-acl2/expansion
setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/lang
setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/test
setup-plt: making: /Users/cce/research/planet/experimental/lang
setup-plt: making: /Users/cce/research/planet/experimental/private
setup-plt: making: /Users/cce/research/planet/fasttest (FastTest)
setup-plt: making: /Users/cce/research/planet/fasttest/examples
setup-plt: making: /Users/cce/research/planet/fasttest/private
setup-plt: making: /Users/cce/research/planet/object-debugger (Object Debugger)
setup-plt: making: /Users/cce/research/planet/object-debugger/gui
setup-plt: making: /Users/cce/research/planet/object-debugger/model
setup-plt: making: /Users/cce/research/planet/object-debugger/private
setup-plt: making: /Users/cce/research/planet/scheme (Scheme
Utilities: (planet cce/scheme))
setup-plt: making: /Users/cce/research/planet/scheme/private
setup-plt: making: /Users/cce/research/planet/scheme/reference
setup-plt: making: /dherman/inspector.plt/1/0 (inspector)
setup-plt: making: /dherman/struct.plt/2/4 (struct)
setup-plt: making: /dherman/struct.plt/2/4/private
setup-plt: making: /dherman/struct.plt/2/4/private/tests
setup-plt: making: /dyoo/version-case.plt/1/8 (version-case)
setup-plt: making: /dyoo/version-case.plt/1/8/planet-docs
setup-plt: making: /dyoo/version-case.plt/1/8/planet-docs/version-case
setup-plt: making: /dyoo/version-case.plt/1/8/private
setup-plt: making: /schematics/random.plt/1/0 (Random)
setup-plt: making: /schematics/schemeunit.plt/2/12 (schemeunit)
setup-plt: --- updating info-domain tables ---
setup-plt: updating: info-domain/compiled/cache.ss
setup-plt: updating: /Users/cce/Library/PLT Scheme/planet/300/4.2.1.5/cache.ss
setup-plt: --- creating launchers ---
setup-plt: launcher: /mzc
setup-plt: launcher: /DrScheme.app
setup-plt: launcher: /bin/drscheme [script-3m]
setup-plt: launcher: /PLT Games.app
setup-plt: launcher: /bin/plt-games [script-3m]
setup-plt: launcher: /planet
setup-plt: launcher: /mzpp
setup-plt: launcher: /mztext
setup-plt: launcher: /plt-r5rs
setup-plt: launcher: /plt-r6rs
setup-plt: launcher: /scribble
setup-plt: launcher: /setup-plt
setup-plt: launcher: /SirMail.app
setup-plt: launcher: /bin/sirmail [script-3m]
setup-plt: launcher: /slatex
setup-plt: launcher: /pdf-slatex
setup-plt: launcher: /Slideshow.app
setup-plt: launcher: /bin/slideshow [script-3m]
setup-plt: launcher: /swindle
setup-plt: launcher: /tex2page
setup-plt: launcher: /plt-web-server
setup-plt: --- installing collections ---
setup-plt: installing: htdch (Java Teachpacks)
setup-plt: installing: profj (ProfessorJ)
setup-plt: --- post-installing collections ---
setup-plt: post-installing: help
setup-plt: post-installing: mred
setup-plt: post-installing: mysterx
setup-plt: post-installing: mzcom
setup-plt: done
setup-plt:
setup-plt: error: during making for 2htdp (HtDP/2e Teachpacks)
setup-plt: dynamic-require: unknown module: '#%mred-kernel; need to
run in mred instead of mzscheme
setup-plt: error: during making for 2htdp/private
setup-plt: check-aux.ss:190:9: module: identifier is already
imported at: check-color in: (define-values (check-color) (new-lambda
(tag width rank) (check-arg tag (or (symbol? width) (string? width))
"color symbol or string" rank width)))
setup-plt: error: during making for 2htdp/uchat
setup-plt: dynamic-require: unknown module: '#%mred-kernel; need to
run in mred instead of mzscheme
setup-plt: error: during making for games
setup-plt: dynamic-require: unknown module: '#%mred-kernel; need to
run in mred instead of mzscheme
setup-plt: error: during making for games/chat-noir (Chat Noir)
setup-plt: dynamic-require: unknown module: '#%mred-kernel; need to
run in mred instead of mzscheme
setup-plt: error: during making for htdp (HtDP Teachpacks)
setup-plt: world.ss:414:9: module: identifier is already imported
at: check-color in: (define-values (check-color) (new-lambda (tag
width rank) (check-arg tag (or (symbol? width) (string? width)) "color
symbol or string" rank width)))
setup-plt: error: during making for teachpack
setup-plt: /Users/cce/plt/trunk/collects/htdp/world.ss:414:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
setup-plt: error: during making for teachpack/2htdp
setup-plt: dynamic-require: unknown module: '#%mred-kernel; need to
run in mred instead of mzscheme
setup-plt: error: during making for teachpack/htdp
setup-plt: /Users/cce/plt/trunk/collects/htdp/world.ss:414:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
setup-plt: error: during making for /Users/cce/research/planet/dracula (Dracula)
setup-plt: teachpacks/universe.ss:429:9: module: identifier is
already imported at: check-color in: (define-values (check-color)
(new-lambda (tag width rank) (check-arg tag (or (symbol? width)
(string? width)) "color symbol or string" rank width)))
setup-plt: error: during making for /Users/cce/research/planet/dracula/modular
setup-plt: /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
setup-plt: error: during making for
/Users/cce/research/planet/dracula/teachpacks
setup-plt: universe.ss:429:9: module: identifier is already imported
at: check-color in: (define-values (check-color) (new-lambda (tag
width rank) (check-arg tag (or (symbol? width) (string? width)) "color
symbol or string" rank width)))
setup-plt: error: during making for /Users/cce/research/planet/dracula/test
setup-plt: /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
module: identifier is already imported at: check-color in:
(define-values (check-color) (new-lambda (tag width rank) (check-arg
tag (or (symbol? width) (string? width)) "color symbol or string" rank
width)))
From cce at ccs.neu.edu Wed Aug 5 15:16:57 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Wed Aug 5 15:17:35 2009
Subject: [plt-dev] Default syntax printer
Message-ID: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
Is there any chance we can change the default printer to show the
syntax->datum of syntax objects? Instead of # in error
messages, it would be much more helpful to see something like #'(foo
x) or #. Even the error printer, which cuts off at a
certain point with "...", would be preferable to the current total
opacity.
Carl Eastlund
From robby at eecs.northwestern.edu Wed Aug 5 15:44:18 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 5 15:44:43 2009
Subject: [plt-dev] Universe & HtDP/2e build errors
In-Reply-To: <990e0c030908051133w589470f8tf8c3f8a3d515ccd1@mail.gmail.com>
References: <990e0c030908051133w589470f8tf8c3f8a3d515ccd1@mail.gmail.com>
Message-ID: <932b2f1f0908051244w78666134le4e8c1c916dc4e38@mail.gmail.com>
Looks like some of that is my fault. I added a dependency on mred to
htdp/error. But I don't see why that file should be being loaded at
compile time so I changed syn-aux.ss to not load syn-aux-aux.ss at
(its) runtime, but only for-template.
I also removed an unused definition of check-color from
2htdp/private/check-aux.ss and changed the name of the check-color
function in htdp/world.ss so it doesn't conflict with the new one in
htdp/error.ss
---
Also, looking at syn-aux.ss, I see this:
;; Symbol (Symbol X -> X) -> (X -> X)
(define (check-flat-spec tag coerce>)
(lambda (p)
(syntax-case p ()
[(b) #'(coerce> tag b)]
[_ (err tag p)])))
which seems like it has to be wrong (that's going to always introduce
a free variable, right?). I think it should probably be define-syntax,
but I didn't change it.
Robby
On Wed, Aug 5, 2009 at 1:33 PM, Carl Eastlund wrote:
> I get the following errors from the HtDP/2e and Universe stuff when I
> run 'setup-plt -D':
>
> setup-plt: version: 4.2.1.5 [3m]
> setup-plt: variants: ?3m
> setup-plt: main collects: /Users/cce/plt/trunk/collects
> setup-plt: collects paths:
> setup-plt: ? /Users/cce/Library/PLT Scheme/4.2.1.5/collects
> setup-plt: ? /Users/cce/plt/trunk/collects
> setup-plt: --- pre-installing collections ---
> setup-plt: pre-installing: plot
> setup-plt: pre-installing: profj (ProfessorJ)
> setup-plt: pre-installing: sgl
> setup-plt: --- compiling collections ---
> setup-plt: making: 2htdp (HtDP/2e Teachpacks)
> setup-plt: ?in 2htdp
> dynamic-require: unknown module: '#%mred-kernel; need to run in mred
> instead of mzscheme
> setup-plt: making: 2htdp/private
> setup-plt: ?in 2htdp/private
> check-aux.ss:190:9: module: identifier is already imported at:
> check-color in: (define-values (check-color) (new-lambda (tag width
> rank) (check-arg tag (or (symbol? width) (string? width)) "color
> symbol or string" rank width)))
> setup-plt: making: 2htdp/uchat
> setup-plt: ?in 2htdp
> dynamic-require: unknown module: '#%mred-kernel; need to run in mred
> instead of mzscheme
> setup-plt: making: afm
> setup-plt: making: algol60
> setup-plt: making: algol60/examples
> setup-plt: making: at-exp
> setup-plt: making: at-exp/lang
> setup-plt: making: browser
> setup-plt: making: browser/private
> setup-plt: making: combinator-parser
> setup-plt: making: combinator-parser/private-combinator
> setup-plt: making: compiler
> setup-plt: making: compiler/private
> setup-plt: making: config
> setup-plt: making: defaults
> setup-plt: making: deinprogramm (DeinProgramm)
> setup-plt: making: deinprogramm/DMdA
> setup-plt: making: deinprogramm/DMdA-advanced
> setup-plt: making: deinprogramm/DMdA-advanced/lang
> setup-plt: making: deinprogramm/DMdA-assignments
> setup-plt: making: deinprogramm/DMdA-assignments/lang
> setup-plt: making: deinprogramm/DMdA-beginner
> setup-plt: making: deinprogramm/DMdA-beginner/lang
> setup-plt: making: deinprogramm/DMdA-vanilla
> setup-plt: making: deinprogramm/DMdA-vanilla/lang
> setup-plt: making: deinprogramm/DMdA/lang
> setup-plt: making: deinprogramm/contract
> setup-plt: making: deinprogramm/scribblings
> setup-plt: making: drscheme
> setup-plt: making: drscheme/private
> setup-plt: making: dynext
> setup-plt: making: dynext/private
> setup-plt: making: embedded-gui
> setup-plt: making: embedded-gui/private
> setup-plt: making: embedded-gui/scribblings
> setup-plt: making: eopl
> setup-plt: making: eopl/lang
> setup-plt: making: eopl/private
> setup-plt: making: errortrace
> setup-plt: making: errortrace/scribblings
> setup-plt: making: ffi (Sample FFIs)
> setup-plt: making: ffi/private
> setup-plt: making: file
> setup-plt: making: file/private
> setup-plt: making: file/scribblings
> setup-plt: making: framework
> setup-plt: making: framework/private
> setup-plt: making: frtime (FrTime)
> setup-plt: making: frtime/animation
> setup-plt: making: frtime/core
> setup-plt: making: frtime/frlibs
> setup-plt: making: frtime/gui
> setup-plt: making: frtime/lang
> setup-plt: making: frtime/opt
> setup-plt: making: frtime/reactive
> setup-plt: making: frtime/reactive/lang
> setup-plt: making: frtime/scribblings
> setup-plt: making: frtime/tool (FrTime Tool)
> setup-plt: making: games
> setup-plt: ?in 2htdp
> dynamic-require: unknown module: '#%mred-kernel; need to run in mred
> instead of mzscheme
> setup-plt: making: games/aces
> setup-plt: making: games/blackjack
> setup-plt: making: games/cards
> setup-plt: making: games/cards/hicolor
> setup-plt: making: games/cards/locolor
> setup-plt: making: games/chat-noir (Chat Noir)
> setup-plt: ?in 2htdp
> dynamic-require: unknown module: '#%mred-kernel; need to run in mred
> instead of mzscheme
> setup-plt: making: games/checkers
> setup-plt: making: games/crazy8s (Crazy 8s)
> setup-plt: making: games/crazy8s/images
> setup-plt: making: games/doors
> setup-plt: making: games/doors/private
> setup-plt: making: games/gcalc (GCalc)
> setup-plt: making: games/ginrummy (Rummy)
> setup-plt: making: games/gl-board-game
> setup-plt: making: games/gobblet
> setup-plt: making: games/gofish (Go Fish)
> setup-plt: making: games/jewel
> setup-plt: making: games/lights-out
> setup-plt: making: games/memory
> setup-plt: making: games/memory/images
> setup-plt: making: games/mines (Minesweeper)
> setup-plt: making: games/mines/images
> setup-plt: making: games/paint-by-numbers
> setup-plt: making: games/parcheesi
> setup-plt: making: games/pousse
> setup-plt: making: games/same
> setup-plt: making: games/scribblings
> setup-plt: making: games/slidey
> setup-plt: making: games/spider
> setup-plt: making: graphics
> setup-plt: making: graphics/scribblings
> setup-plt: making: gui-debugger
> setup-plt: making: gui-debugger/icons
> setup-plt: making: guibuilder
> setup-plt: making: handin-client (Course)
> setup-plt: making: handin-server
> setup-plt: making: handin-server/overridden-collects
> setup-plt: making: handin-server/overridden-collects/fake-teachpack
> setup-plt: making: handin-server/overridden-collects/fake-teachpack/htdp
> setup-plt: making: handin-server/private
> setup-plt: making: handin-server/scribblings
> setup-plt: making: help
> setup-plt: making: help/private
> setup-plt: making: hierlist
> setup-plt: making: honu
> setup-plt: making: honu/lang
> setup-plt: making: honu/private
> setup-plt: making: htdch (Java Teachpacks)
> setup-plt: making: htdch/colors
> setup-plt: making: htdch/draw
> setup-plt: making: htdch/geometry
> setup-plt: making: htdch/graphics
> setup-plt: making: htdch/idraw (Imperative Drawing)
> setup-plt: making: htdp (HtDP Teachpacks)
> setup-plt: ?in htdp
> world.ss:414:9: module: identifier is already imported at: check-color
> in: (define-values (check-color) (new-lambda (tag width rank)
> (check-arg tag (or (symbol? width) (string? width)) "color symbol or
> string" rank width)))
> setup-plt: making: html
> setup-plt: making: icons
> setup-plt: making: info-domain
> setup-plt: making: lang (HtDP Languages)
> setup-plt: making: lang/private
> setup-plt: making: lang/private/contracts
> setup-plt: making: launcher
> setup-plt: making: lazy (Lazy Scheme)
> setup-plt: making: lazy/lang
> setup-plt: making: macro-debugger
> setup-plt: making: macro-debugger/model (Expansion Model)
> setup-plt: making: macro-debugger/syntax-browser
> setup-plt: making: macro-debugger/util
> setup-plt: making: macro-debugger/view
> setup-plt: making: make
> setup-plt: making: mred
> setup-plt: making: mred/lang
> setup-plt: making: mred/private
> setup-plt: making: mred/private/wxme
> setup-plt: making: mrlib
> setup-plt: making: mrlib/hierlist
> setup-plt: making: mrlib/private
> setup-plt: making: mrlib/private/aligned-pasteboard
> setup-plt: making: mrlib/scribblings
> setup-plt: making: mrlib/scribblings/aligned-pasteboard
> setup-plt: making: mrlib/scribblings/graph
> setup-plt: making: mrlib/scribblings/hierlist
> setup-plt: making: mysterx
> setup-plt: making: mysterx/private
> setup-plt: making: mysterx/scribblings
> setup-plt: making: mzcom
> setup-plt: making: mzlib
> setup-plt: making: mzlib/private
> setup-plt: making: mzlib/scribblings
> setup-plt: making: mzscheme
> setup-plt: making: mzscheme/lang
> setup-plt: making: net
> setup-plt: making: net/private
> setup-plt: making: net/scribblings
> setup-plt: making: openssl
> setup-plt: making: parser-tools
> setup-plt: making: parser-tools/examples
> setup-plt: making: parser-tools/private-lex
> setup-plt: making: parser-tools/private-yacc
> setup-plt: making: planet (PLaneT)
> setup-plt: making: planet/lang
> setup-plt: making: planet/private
> setup-plt: making: plot
> setup-plt: making: plot/fonts
> setup-plt: making: plot/src
> setup-plt: making: plot/src/all
> setup-plt: making: plot/src/fit
> setup-plt: making: preprocessor
> setup-plt: making: preprocessor/scribblings
> setup-plt: making: profile
> setup-plt: making: profile/scribblings
> setup-plt: making: profj (ProfessorJ)
> setup-plt: making: profj/classpath
> setup-plt: making: profj/comb-parsers
> setup-plt: making: profj/libs
> setup-plt: making: profj/libs/java
> setup-plt: making: profj/libs/java/io
> setup-plt: making: profj/libs/java/lang
> setup-plt: making: profj/libs/java/tester
> setup-plt: making: profj/libs/java/util
> setup-plt: making: profj/parsers
> setup-plt: making: profj/scribblings
> setup-plt: making: profjWizard (ProfessorJ Wizard)
> setup-plt: making: r5rs
> setup-plt: making: r5rs/lang
> setup-plt: making: r5rs/private
> setup-plt: making: r6rs
> setup-plt: making: r6rs/lang
> setup-plt: making: r6rs/private
> setup-plt: making: r6rs/scribblings
> setup-plt: making: readline
> setup-plt: making: redex (PLT Redex)
> setup-plt: making: redex/examples (Reduction Semantics examples)
> setup-plt: making: redex/private
> setup-plt: making: redex/private/bmps
> setup-plt: making: repos-time-stamp
> setup-plt: making: rnrs
> setup-plt: making: rnrs/arithmetic
> setup-plt: making: rnrs/io
> setup-plt: making: rnrs/records
> setup-plt: making: s-exp
> setup-plt: making: s-exp/lang
> setup-plt: making: scheme
> setup-plt: making: scheme/base
> setup-plt: making: scheme/base/lang
> setup-plt: making: scheme/gui
> setup-plt: making: scheme/gui/lang
> setup-plt: making: scheme/lang
> setup-plt: making: scheme/load
> setup-plt: making: scheme/load/lang
> setup-plt: making: scheme/match
> setup-plt: making: scheme/private
> setup-plt: making: scheme/signature
> setup-plt: making: scheme/signature/lang
> setup-plt: making: scheme/unit
> setup-plt: making: scheme/unit/lang
> setup-plt: making: schemeunit (SchemeUnit)
> setup-plt: making: schemeunit/scribblings
> setup-plt: making: scribble
> setup-plt: making: scribble/base
> setup-plt: making: scribble/base/lang
> setup-plt: making: scribble/doc
> setup-plt: making: scribble/doc/lang
> setup-plt: making: scribble/lp
> setup-plt: making: scribble/lp/lang
> setup-plt: making: scribble/manual
> setup-plt: making: scribble/manual/lang
> setup-plt: making: scribble/private
> setup-plt: making: scribble/sigplan
> setup-plt: making: scribble/sigplan/lang
> setup-plt: making: scribble/text
> setup-plt: making: scribble/text/lang
> setup-plt: making: scribblings (Documentation Sources)
> setup-plt: making: scribblings/drscheme
> setup-plt: making: scribblings/foreign
> setup-plt: making: scribblings/framework
> setup-plt: making: scribblings/gui
> setup-plt: making: scribblings/guide
> setup-plt: making: scribblings/honu
> setup-plt: making: scribblings/htdp-langs
> setup-plt: making: scribblings/inside
> setup-plt: making: scribblings/main
> setup-plt: making: scribblings/main/private
> setup-plt: making: scribblings/main/user
> setup-plt: making: scribblings/more
> setup-plt: making: scribblings/mzc
> setup-plt: making: scribblings/quick
> setup-plt: making: scribblings/quick/images
> setup-plt: making: scribblings/reference
> setup-plt: making: scribblings/scribble
> setup-plt: making: scribblings/setup-plt
> setup-plt: making: scribblings/slideshow
> setup-plt: making: scribblings/tools
> setup-plt: making: scriblib
> setup-plt: making: scriblib/private
> setup-plt: making: scriblib/scribblings
> setup-plt: making: setup
> setup-plt: making: setup/infotab
> setup-plt: making: setup/infotab/lang
> setup-plt: making: setup/private
> setup-plt: making: sgl
> setup-plt: making: sgl/scribblings
> setup-plt: making: sirmail
> setup-plt: making: sirmail/emoticon
> setup-plt: making: slatex
> setup-plt: making: slideshow
> setup-plt: making: slideshow/lang
> setup-plt: making: slideshow/private
> setup-plt: making: srfi
> setup-plt: making: srfi/%3a1
> setup-plt: making: srfi/%3a11
> setup-plt: making: srfi/%3a13
> setup-plt: making: srfi/%3a14
> setup-plt: making: srfi/%3a16
> setup-plt: making: srfi/%3a17
> setup-plt: making: srfi/%3a18
> setup-plt: making: srfi/%3a19
> setup-plt: making: srfi/%3a2
> setup-plt: making: srfi/%3a23
> setup-plt: making: srfi/%3a25
> setup-plt: making: srfi/%3a26
> setup-plt: making: srfi/%3a27
> setup-plt: making: srfi/%3a28
> setup-plt: making: srfi/%3a29
> setup-plt: making: srfi/%3a31
> setup-plt: making: srfi/%3a38
> setup-plt: making: srfi/%3a39
> setup-plt: making: srfi/%3a41
> setup-plt: making: srfi/%3a42
> setup-plt: making: srfi/%3a43
> setup-plt: making: srfi/%3a45
> setup-plt: making: srfi/%3a48
> setup-plt: making: srfi/%3a5
> setup-plt: making: srfi/%3a54
> setup-plt: making: srfi/%3a57
> setup-plt: making: srfi/%3a59
> setup-plt: making: srfi/%3a6
> setup-plt: making: srfi/%3a60
> setup-plt: making: srfi/%3a61
> setup-plt: making: srfi/%3a63
> setup-plt: making: srfi/%3a64
> setup-plt: making: srfi/%3a66
> setup-plt: making: srfi/%3a67
> setup-plt: making: srfi/%3a69
> setup-plt: making: srfi/%3a71
> setup-plt: making: srfi/%3a74
> setup-plt: making: srfi/%3a78
> setup-plt: making: srfi/%3a8
> setup-plt: making: srfi/%3a86
> setup-plt: making: srfi/%3a87
> setup-plt: making: srfi/%3a9
> setup-plt: making: srfi/1
> setup-plt: making: srfi/13
> setup-plt: making: srfi/14
> setup-plt: making: srfi/17
> setup-plt: making: srfi/19
> setup-plt: making: srfi/2
> setup-plt: making: srfi/25
> setup-plt: making: srfi/26
> setup-plt: making: srfi/27
> setup-plt: making: srfi/29
> setup-plt: making: srfi/29/bundles
> setup-plt: making: srfi/29/bundles/es
> setup-plt: making: srfi/31
> setup-plt: making: srfi/32
> setup-plt: making: srfi/34
> setup-plt: making: srfi/35
> setup-plt: making: srfi/38
> setup-plt: making: srfi/40
> setup-plt: making: srfi/41
> setup-plt: making: srfi/42
> setup-plt: making: srfi/42ref
> setup-plt: making: srfi/43
> setup-plt: making: srfi/45
> setup-plt: making: srfi/48
> setup-plt: making: srfi/5
> setup-plt: making: srfi/54
> setup-plt: making: srfi/57
> setup-plt: making: srfi/59
> setup-plt: making: srfi/60
> setup-plt: making: srfi/61
> setup-plt: making: srfi/63
> setup-plt: making: srfi/64
> setup-plt: making: srfi/67
> setup-plt: making: srfi/69
> setup-plt: making: srfi/7
> setup-plt: making: srfi/71
> setup-plt: making: srfi/74
> setup-plt: making: srfi/78
> setup-plt: making: srfi/8
> setup-plt: making: srfi/86
> setup-plt: making: srfi/87
> setup-plt: making: srfi/9
> setup-plt: making: stepper
> setup-plt: making: stepper/private
> setup-plt: making: string-constants
> setup-plt: making: string-constants/private
> setup-plt: making: stxclass
> setup-plt: making: stxclass/private
> setup-plt: making: stxclass/scribblings
> setup-plt: making: stxclass/util
> setup-plt: making: swindle
> setup-plt: making: swindle/lang
> setup-plt: making: syntax
> setup-plt: making: syntax-color
> setup-plt: making: syntax/private
> setup-plt: making: syntax/private/stxparse
> setup-plt: making: syntax/private/util
> setup-plt: making: syntax/scribblings
> setup-plt: making: teachpack
> setup-plt: ?in htdp
> /Users/cce/plt/trunk/collects/htdp/world.ss:414:9: module: identifier
> is already imported at: check-color in: (define-values (check-color)
> (new-lambda (tag width rank) (check-arg tag (or (symbol? width)
> (string? width)) "color symbol or string" rank width)))
> setup-plt: making: teachpack/2htdp
> setup-plt: ?in 2htdp
> dynamic-require: unknown module: '#%mred-kernel; need to run in mred
> instead of mzscheme
> setup-plt: making: teachpack/2htdp/scribblings
> setup-plt: making: teachpack/deinprogramm
> setup-plt: making: teachpack/htdp
> setup-plt: ?in htdp
> /Users/cce/plt/trunk/collects/htdp/world.ss:414:9: module: identifier
> is already imported at: check-color in: (define-values (check-color)
> (new-lambda (tag width rank) (check-arg tag (or (symbol? width)
> (string? width)) "color symbol or string" rank width)))
> setup-plt: making: teachpack/htdp/scribblings
> setup-plt: making: test-box-recovery
> setup-plt: making: test-engine
> setup-plt: making: tests (Test Suites)
> setup-plt: making: tests/drscheme
> setup-plt: making: tests/file
> setup-plt: making: tests/framework
> setup-plt: making: tests/lazy
> setup-plt: making: tests/net
> setup-plt: making: tests/profile
> setup-plt: making: tests/scribble
> setup-plt: making: tests/utils
> setup-plt: making: tex2page
> setup-plt: making: texpict
> setup-plt: making: texpict/private
> setup-plt: making: trace (Calltrace)
> setup-plt: making: trace/scribblings
> setup-plt: making: typed
> setup-plt: making: typed-scheme
> setup-plt: making: typed-scheme/env
> setup-plt: making: typed-scheme/infer
> setup-plt: making: typed-scheme/lang
> setup-plt: making: typed-scheme/no-check
> setup-plt: making: typed-scheme/no-check/lang
> setup-plt: making: typed-scheme/private
> setup-plt: making: typed-scheme/rep
> setup-plt: making: typed-scheme/typecheck
> setup-plt: making: typed-scheme/types
> setup-plt: making: typed-scheme/utils
> setup-plt: making: typed/file
> setup-plt: making: typed/framework
> setup-plt: making: typed/mred
> setup-plt: making: typed/net
> setup-plt: making: typed/private
> setup-plt: making: typed/srfi
> setup-plt: making: version
> setup-plt: making: waterworld
> setup-plt: making: web-server
> setup-plt: making: web-server/configuration
> setup-plt: making: web-server/dispatch
> setup-plt: making: web-server/dispatchers
> setup-plt: making: web-server/formlets
> setup-plt: making: web-server/http
> setup-plt: making: web-server/insta
> setup-plt: making: web-server/insta/lang
> setup-plt: making: web-server/lang
> setup-plt: making: web-server/managers
> setup-plt: making: web-server/private
> setup-plt: making: web-server/scribblings
> setup-plt: making: web-server/scribblings/tutorial
> setup-plt: making: web-server/scribblings/tutorial/images
> setup-plt: making: web-server/servlet
> setup-plt: making: web-server/stuffers
> setup-plt: making: wxme
> setup-plt: making: wxme/private
> setup-plt: making: xml
> setup-plt: making: xml/private
> setup-plt: making: /Users/cce/research/planet/dracula (Dracula)
> setup-plt: ?in /Users/cce/research/planet/dracula/teachpacks/
> teachpacks/universe.ss:429:9: module: identifier is already imported
> at: check-color in: (define-values (check-color) (new-lambda (tag
> width rank) (check-arg tag (or (symbol? width) (string? width)) "color
> symbol or string" rank width)))
> setup-plt: making: /Users/cce/research/planet/dracula/acl2
> setup-plt: making: /Users/cce/research/planet/dracula/drscheme
> setup-plt: making: /Users/cce/research/planet/dracula/guide
> setup-plt: making: /Users/cce/research/planet/dracula/guide/images
> setup-plt: making: /Users/cce/research/planet/dracula/images
> setup-plt: making: /Users/cce/research/planet/dracula/lang
> setup-plt: making: /Users/cce/research/planet/dracula/lang/primitive-procedures
> setup-plt: making: /Users/cce/research/planet/dracula/modular
> setup-plt: ?in /Users/cce/research/planet/dracula/teachpacks/
> /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> setup-plt: making: /Users/cce/research/planet/dracula/modular/lang
> setup-plt: making: /Users/cce/research/planet/dracula/modular/nonstd
> setup-plt: making: /Users/cce/research/planet/dracula/modular/nonstd/lang
> setup-plt: making: /Users/cce/research/planet/dracula/private
> setup-plt: making: /Users/cce/research/planet/dracula/proof
> setup-plt: making: /Users/cce/research/planet/dracula/reference
> setup-plt: making: /Users/cce/research/planet/dracula/reference/acl2
> setup-plt: making: /Users/cce/research/planet/dracula/reference/modular
> setup-plt: making: /Users/cce/research/planet/dracula/reference/teachpacks
> setup-plt: making: /Users/cce/research/planet/dracula/teachpacks
> setup-plt: ?in /Users/cce/research/planet/dracula/teachpacks/
> universe.ss:429:9: module: identifier is already imported at:
> check-color in: (define-values (check-color) (new-lambda (tag width
> rank) (check-arg tag (or (symbol? width) (string? width)) "color
> symbol or string" rank width)))
> setup-plt: making: /Users/cce/research/planet/dracula/test
> setup-plt: ?in /Users/cce/research/planet/dracula/teachpacks/
> /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> setup-plt: making: /Users/cce/research/planet/experimental
> setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2
> setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/data
> setup-plt: making:
> /Users/cce/research/planet/experimental/hygienic-acl2/expansion
> setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/lang
> setup-plt: making: /Users/cce/research/planet/experimental/hygienic-acl2/test
> setup-plt: making: /Users/cce/research/planet/experimental/lang
> setup-plt: making: /Users/cce/research/planet/experimental/private
> setup-plt: making: /Users/cce/research/planet/fasttest (FastTest)
> setup-plt: making: /Users/cce/research/planet/fasttest/examples
> setup-plt: making: /Users/cce/research/planet/fasttest/private
> setup-plt: making: /Users/cce/research/planet/object-debugger (Object Debugger)
> setup-plt: making: /Users/cce/research/planet/object-debugger/gui
> setup-plt: making: /Users/cce/research/planet/object-debugger/model
> setup-plt: making: /Users/cce/research/planet/object-debugger/private
> setup-plt: making: /Users/cce/research/planet/scheme (Scheme
> Utilities: (planet cce/scheme))
> setup-plt: making: /Users/cce/research/planet/scheme/private
> setup-plt: making: /Users/cce/research/planet/scheme/reference
> setup-plt: making: /dherman/inspector.plt/1/0 (inspector)
> setup-plt: making: /dherman/struct.plt/2/4 (struct)
> setup-plt: making: /dherman/struct.plt/2/4/private
> setup-plt: making: /dherman/struct.plt/2/4/private/tests
> setup-plt: making: /dyoo/version-case.plt/1/8 (version-case)
> setup-plt: making: /dyoo/version-case.plt/1/8/planet-docs
> setup-plt: making: /dyoo/version-case.plt/1/8/planet-docs/version-case
> setup-plt: making: /dyoo/version-case.plt/1/8/private
> setup-plt: making: /schematics/random.plt/1/0 (Random)
> setup-plt: making: /schematics/schemeunit.plt/2/12 (schemeunit)
> setup-plt: --- updating info-domain tables ---
> setup-plt: updating: info-domain/compiled/cache.ss
> setup-plt: updating: /Users/cce/Library/PLT Scheme/planet/300/4.2.1.5/cache.ss
> setup-plt: --- creating launchers ---
> setup-plt: launcher: /mzc
> setup-plt: launcher: /DrScheme.app
> setup-plt: launcher: /bin/drscheme [script-3m]
> setup-plt: launcher: /PLT Games.app
> setup-plt: launcher: /bin/plt-games [script-3m]
> setup-plt: launcher: /planet
> setup-plt: launcher: /mzpp
> setup-plt: launcher: /mztext
> setup-plt: launcher: /plt-r5rs
> setup-plt: launcher: /plt-r6rs
> setup-plt: launcher: /scribble
> setup-plt: launcher: /setup-plt
> setup-plt: launcher: /SirMail.app
> setup-plt: launcher: /bin/sirmail [script-3m]
> setup-plt: launcher: /slatex
> setup-plt: launcher: /pdf-slatex
> setup-plt: launcher: /Slideshow.app
> setup-plt: launcher: /bin/slideshow [script-3m]
> setup-plt: launcher: /swindle
> setup-plt: launcher: /tex2page
> setup-plt: launcher: /plt-web-server
> setup-plt: --- installing collections ---
> setup-plt: installing: htdch (Java Teachpacks)
> setup-plt: installing: profj (ProfessorJ)
> setup-plt: --- post-installing collections ---
> setup-plt: post-installing: help
> setup-plt: post-installing: mred
> setup-plt: post-installing: mysterx
> setup-plt: post-installing: mzcom
> setup-plt: done
> setup-plt:
> setup-plt: error: during making for 2htdp (HtDP/2e Teachpacks)
> setup-plt: ? dynamic-require: unknown module: '#%mred-kernel; need to
> run in mred instead of mzscheme
> setup-plt: error: during making for 2htdp/private
> setup-plt: ? check-aux.ss:190:9: module: identifier is already
> imported at: check-color in: (define-values (check-color) (new-lambda
> (tag width rank) (check-arg tag (or (symbol? width) (string? width))
> "color symbol or string" rank width)))
> setup-plt: error: during making for 2htdp/uchat
> setup-plt: ? dynamic-require: unknown module: '#%mred-kernel; need to
> run in mred instead of mzscheme
> setup-plt: error: during making for games
> setup-plt: ? dynamic-require: unknown module: '#%mred-kernel; need to
> run in mred instead of mzscheme
> setup-plt: error: during making for games/chat-noir (Chat Noir)
> setup-plt: ? dynamic-require: unknown module: '#%mred-kernel; need to
> run in mred instead of mzscheme
> setup-plt: error: during making for htdp (HtDP Teachpacks)
> setup-plt: ? world.ss:414:9: module: identifier is already imported
> at: check-color in: (define-values (check-color) (new-lambda (tag
> width rank) (check-arg tag (or (symbol? width) (string? width)) "color
> symbol or string" rank width)))
> setup-plt: error: during making for teachpack
> setup-plt: ? /Users/cce/plt/trunk/collects/htdp/world.ss:414:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> setup-plt: error: during making for teachpack/2htdp
> setup-plt: ? dynamic-require: unknown module: '#%mred-kernel; need to
> run in mred instead of mzscheme
> setup-plt: error: during making for teachpack/htdp
> setup-plt: ? /Users/cce/plt/trunk/collects/htdp/world.ss:414:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> setup-plt: error: during making for /Users/cce/research/planet/dracula (Dracula)
> setup-plt: ? teachpacks/universe.ss:429:9: module: identifier is
> already imported at: check-color in: (define-values (check-color)
> (new-lambda (tag width rank) (check-arg tag (or (symbol? width)
> (string? width)) "color symbol or string" rank width)))
> setup-plt: error: during making for /Users/cce/research/planet/dracula/modular
> setup-plt: ? /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> setup-plt: error: during making for
> /Users/cce/research/planet/dracula/teachpacks
> setup-plt: ? universe.ss:429:9: module: identifier is already imported
> at: check-color in: (define-values (check-color) (new-lambda (tag
> width rank) (check-arg tag (or (symbol? width) (string? width)) "color
> symbol or string" rank width)))
> setup-plt: error: during making for /Users/cce/research/planet/dracula/test
> setup-plt: ? /Users/cce/research/planet/dracula/teachpacks/universe.ss:429:9:
> module: identifier is already imported at: check-color in:
> (define-values (check-color) (new-lambda (tag width rank) (check-arg
> tag (or (symbol? width) (string? width)) "color symbol or string" rank
> width)))
> _________________________________________________
> ?For list-related administrative tasks:
> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
From matthias at ccs.neu.edu Wed Aug 5 17:03:39 2009
From: matthias at ccs.neu.edu (Matthias Felleisen)
Date: Wed Aug 5 17:04:14 2009
Subject: [plt-dev] Universe & HtDP/2e build errors
In-Reply-To: <932b2f1f0908051244w78666134le4e8c1c916dc4e38@mail.gmail.com>
References: <990e0c030908051133w589470f8tf8c3f8a3d515ccd1@mail.gmail.com>
<932b2f1f0908051244w78666134le4e8c1c916dc4e38@mail.gmail.com>
Message-ID: <50D7C859-B45A-4DCD-B50F-A154745EB81B@ccs.neu.edu>
On Aug 5, 2009, at 3:44 PM, Robby Findler wrote:
> Also, looking at syn-aux.ss, I see this:
>
> ;; Symbol (Symbol X -> X) -> (X -> X)
> (define (check-flat-spec tag coerce>)
> (lambda (p)
> (syntax-case p ()
> [(b) #'(coerce> tag b)]
> [_ (err tag p)])))
>
> which seems like it has to be wrong (that's going to always introduce
> a free variable, right?). I think it should probably be define-syntax,
> but I didn't change it.
This is a left over experiment and can be deleted while you're fixing
2htdp Thanks -- Matthias
From robby at eecs.northwestern.edu Wed Aug 5 17:30:57 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 5 17:31:15 2009
Subject: [plt-dev] Universe & HtDP/2e build errors
In-Reply-To: <50D7C859-B45A-4DCD-B50F-A154745EB81B@ccs.neu.edu>
References: <990e0c030908051133w589470f8tf8c3f8a3d515ccd1@mail.gmail.com>
<932b2f1f0908051244w78666134le4e8c1c916dc4e38@mail.gmail.com>
<50D7C859-B45A-4DCD-B50F-A154745EB81B@ccs.neu.edu>
Message-ID: <932b2f1f0908051430k45c3c371j556295ebdf1f917e@mail.gmail.com>
I'm not actually doing anything with that code, but I went ahead and
removed it from the file in SVN.
Robby
On Wed, Aug 5, 2009 at 4:03 PM, Matthias Felleisen wrote:
>
> On Aug 5, 2009, at 3:44 PM, Robby Findler wrote:
>
>> Also, looking at syn-aux.ss, I see this:
>>
>> ;; Symbol (Symbol X -> X) -> (X -> X)
>> (define (check-flat-spec tag coerce>)
>> ?(lambda (p)
>> ? ?(syntax-case p ()
>> ? ? ?[(b) #'(coerce> tag b)]
>> ? ? ?[_ (err tag p)])))
>>
>> which seems like it has to be wrong (that's going to always introduce
>> a free variable, right?). I think it should probably be define-syntax,
>> but I didn't change it.
>
> This is a left over experiment and can be deleted while you're fixing 2htdp
> Thanks -- Matthias
>
>
From jpc-ml at zenburn.net Sat Aug 8 08:44:40 2009
From: jpc-ml at zenburn.net (=?UTF-8?B?SmFrdWIgUGlvdHIgQ8WCYXBh?=)
Date: Sat Aug 8 08:45:00 2009
Subject: [plt-dev] Default syntax printer
In-Reply-To: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
References: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
Message-ID: <4A7D7338.9030701@zenburn.net>
On 8/5/09 9:16 PM, Carl Eastlund wrote:
> Is there any chance we can change the default printer to show the
> syntax->datum of syntax objects? Instead of # in error
> messages, it would be much more helpful to see something like #'(foo
> x) or #. Even the error printer, which cuts off at a
> certain point with "...", would be preferable to the current total
> opacity.
I had a similar request for handling bytes printing. I have a function
for formatting bytes as nice strings of hex digits but I don't know of
any way to hook it up to the default printer.
--
regards,
Jakub Piotr C?apa
From mflatt at cs.utah.edu Mon Aug 10 18:02:45 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Mon Aug 10 18:03:05 2009
Subject: [plt-dev] Default syntax printer
In-Reply-To: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
References: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
Message-ID: <20090810220245.BCCE66500C9@mail-svr1.cs.utah.edu>
At Wed, 5 Aug 2009 15:16:57 -0400, Carl Eastlund wrote:
> Is there any chance we can change the default printer to show the
> syntax->datum of syntax objects? Instead of # in error
> messages, it would be much more helpful to see something like #'(foo
> x) or #. Even the error printer, which cuts off at a
> certain point with "...", would be preferable to the current total
> opacity.
Yes, I should have done that a long time ago.
v4.2.1.6 adds a `print-syntax-width' parameter that defaults to 32,
which means that up to 32 characters are used for printing a syntax
object's datum form within `#':
> #'(+ 1 2)
#
> (syntax-e #'(+ 1 2))
(# # #)
> #'((lambda (x) (x x)) (lambda (x) (x x)))
#
I don't know whether 32 is the right default. I think there are
probably times when I want to see a compact printed form for syntax
objects (especially when there are several in a list, or something like
that), and I bet that 32 is usually enough characters to tell me what
syntax object I'm looking at. Then again, +inf.0 seems like a more
natural default. For now, I've gone with the more conservative default
(with respect to previous versions), but after trying it out, let me
know if you think some else would be better.
From cce at ccs.neu.edu Mon Aug 10 18:45:54 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Mon Aug 10 18:46:36 2009
Subject: [plt-dev] Default syntax printer
In-Reply-To: <20090810220245.BCCE66500C9@mail-svr1.cs.utah.edu>
References: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
<20090810220245.BCCE66500C9@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908101545g66ed8eev697560bd0a8f3fde@mail.gmail.com>
On Mon, Aug 10, 2009 at 6:02 PM, Matthew Flatt wrote:
> At Wed, 5 Aug 2009 15:16:57 -0400, Carl Eastlund wrote:
>> Is there any chance we can change the default printer to show the
>> syntax->datum of syntax objects? ?Instead of # in error
>> messages, it would be much more helpful to see something like #'(foo
>> x) or #. ?Even the error printer, which cuts off at a
>> certain point with "...", would be preferable to the current total
>> opacity.
>
> Yes, I should have done that a long time ago.
>
> v4.2.1.6 adds a `print-syntax-width' parameter that defaults to 32,
> which means that up to 32 characters are used for printing a syntax
> object's datum form within `#':
>
> ?> #'(+ 1 2)
> ?#
>
> ?> (syntax-e #'(+ 1 2))
> ?(# # #)
>
> ?> #'((lambda (x) (x x)) (lambda (x) (x x)))
> ?#
>
> I don't know whether 32 is the right default. I think there are
> probably times when I want to see a compact printed form for syntax
> objects (especially when there are several in a list, or something like
> that), and I bet that 32 is usually enough characters to tell me what
> syntax object I'm looking at. Then again, +inf.0 seems like a more
> natural default. For now, I've gone with the more conservative default
> (with respect to previous versions), but after trying it out, let me
> know if you think some else would be better.
I like this move, but I'd prefer a different interface if we're going
to have customizable printing. I propose a 'current-syntax-printer'
parameter. If someone wants essentially the old behavior, they can
set it to void; for full printing they could use write or
pretty-print; the default could be the error printer (has a built-in
width and uses "..."). I can't imagine using print-syntax-width to
set a different number; if I ever used it, I'd set it to either 0 or
+inf.0. Custom printing provides more interesting flexibility.
--Carl
From mflatt at cs.utah.edu Tue Aug 11 08:58:53 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 08:59:15 2009
Subject: [plt-dev] Default syntax printer
In-Reply-To: <990e0c030908101545g66ed8eev697560bd0a8f3fde@mail.gmail.com>
References: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
<20090810220245.BCCE66500C9@mail-svr1.cs.utah.edu>
<990e0c030908101545g66ed8eev697560bd0a8f3fde@mail.gmail.com>
Message-ID: <20090811125855.F26A36500BA@mail-svr1.cs.utah.edu>
At Mon, 10 Aug 2009 18:45:54 -0400, Carl Eastlund wrote:
> On Mon, Aug 10, 2009 at 6:02 PM, Matthew Flatt wrote:
> > At Wed, 5 Aug 2009 15:16:57 -0400, Carl Eastlund wrote:
> >> Is there any chance we can change the default printer to show the
> >> syntax->datum of syntax objects? ?Instead of # in error
> >> messages, it would be much more helpful to see something like #'(foo
> >> x) or #. ?Even the error printer, which cuts off at a
> >> certain point with "...", would be preferable to the current total
> >> opacity.
> >
> > Yes, I should have done that a long time ago.
> >
> > v4.2.1.6 adds a `print-syntax-width' parameter that defaults to 32,
> > which means that up to 32 characters are used for printing a syntax
> > object's datum form within `#':
> >
> > ?> #'(+ 1 2)
> > ?#
> >
> > ?> (syntax-e #'(+ 1 2))
> > ?(# # #)
> >
> > ?> #'((lambda (x) (x x)) (lambda (x) (x x)))
> > ?#
> >
> > I don't know whether 32 is the right default. I think there are
> > probably times when I want to see a compact printed form for syntax
> > objects (especially when there are several in a list, or something like
> > that), and I bet that 32 is usually enough characters to tell me what
> > syntax object I'm looking at. Then again, +inf.0 seems like a more
> > natural default. For now, I've gone with the more conservative default
> > (with respect to previous versions), but after trying it out, let me
> > know if you think some else would be better.
>
> I like this move, but I'd prefer a different interface if we're going
> to have customizable printing. I propose a 'current-syntax-printer'
> parameter. If someone wants essentially the old behavior, they can
> set it to void; for full printing they could use write or
> pretty-print; the default could be the error printer (has a built-in
> width and uses "..."). I can't imagine using print-syntax-width to
> set a different number; if I ever used it, I'd set it to either 0 or
> +inf.0. Custom printing provides more interesting flexibility.
The `pretty-print' library already supports custom printing for all
values, not just syntax objects, right? Is there something special
about syntax objects that merits more general built-in treatment?
From cce at ccs.neu.edu Tue Aug 11 09:18:18 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 09:18:57 2009
Subject: [plt-dev] Default syntax printer
In-Reply-To: <20090811125855.F26A36500BA@mail-svr1.cs.utah.edu>
References: <990e0c030908051216h12eba21egb610f621707235c5@mail.gmail.com>
<20090810220245.BCCE66500C9@mail-svr1.cs.utah.edu>
<990e0c030908101545g66ed8eev697560bd0a8f3fde@mail.gmail.com>
<20090811125855.F26A36500BA@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908110618v44ecf0bdp85ce98b097b36f66@mail.gmail.com>
On Tue, Aug 11, 2009 at 8:58 AM, Matthew Flatt wrote:
> At Mon, 10 Aug 2009 18:45:54 -0400, Carl Eastlund wrote:
>> On Mon, Aug 10, 2009 at 6:02 PM, Matthew Flatt wrote:
>> >
>> > v4.2.1.6 adds a `print-syntax-width' parameter that defaults to 32,
>> > which means that up to 32 characters are used for printing a syntax
>> > object's datum form within `#':
>> >
>> > ?> #'(+ 1 2)
>> > ?#
>> >
>> > ?> (syntax-e #'(+ 1 2))
>> > ?(# # #)
>> >
>> > ?> #'((lambda (x) (x x)) (lambda (x) (x x)))
>> > ?#
>> >
>> > I don't know whether 32 is the right default. I think there are
>> > probably times when I want to see a compact printed form for syntax
>> > objects (especially when there are several in a list, or something like
>> > that), and I bet that 32 is usually enough characters to tell me what
>> > syntax object I'm looking at. Then again, +inf.0 seems like a more
>> > natural default. For now, I've gone with the more conservative default
>> > (with respect to previous versions), but after trying it out, let me
>> > know if you think some else would be better.
>>
>> I like this move, but I'd prefer a different interface if we're going
>> to have customizable printing. ?I propose a 'current-syntax-printer'
>> parameter. ?If someone wants essentially the old behavior, they can
>> set it to void; for full printing they could use write or
>> pretty-print; the default could be the error printer (has a built-in
>> width and uses "..."). ?I can't imagine using print-syntax-width to
>> set a different number; if I ever used it, I'd set it to either 0 or
>> +inf.0. ?Custom printing provides more interesting flexibility.
>
> The `pretty-print' library already supports custom printing for all
> values, not just syntax objects, right? Is there something special
> about syntax objects that merits more general built-in treatment?
On reflection, not really. The width values of 0, +inf.0, and some
arbitrary default in between cover the meaningful points in a default
datum-printing spectrum. Thanks for the feature! Carry on, nothing
to see here. ;)
--Carl
From cce at ccs.neu.edu Tue Aug 11 11:13:32 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 11:14:12 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
Message-ID: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
Running make install, I get a long series of errors of this form:
/Users/cce/plt/trunk/doc/algol60/in.sxref::0: read (compiled): code
compiled for version 4.2.1.5, not 4.2.1.6
/Users/cce/plt/trunk/doc/browser/in.sxref::0: read (compiled): code
compiled for version 4.2.1.5, not 4.2.1.6
/Users/cce/plt/trunk/doc/cards/in.sxref::0: read (compiled): code
compiled for version 4.2.1.5, not 4.2.1.6
.
.
.
What's going on here? Shouldn't setup-plt / make install be
rebuilding these? I got these yesterday during a setup-plt -D as
well, which is confusing because they appear to be documentation files
and I would expect them to be excluded from setup-plt -D.
Carl Eastlund
From mflatt at cs.utah.edu Tue Aug 11 11:22:43 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 11:23:04 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
Message-ID: <20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 11:13:32 -0400, Carl Eastlund wrote:
> Running make install, I get a long series of errors of this form:
>
> /Users/cce/plt/trunk/doc/algol60/in.sxref::0: read (compiled): code
> compiled for version 4.2.1.5, not 4.2.1.6
> /Users/cce/plt/trunk/doc/browser/in.sxref::0: read (compiled): code
> compiled for version 4.2.1.5, not 4.2.1.6
> /Users/cce/plt/trunk/doc/cards/in.sxref::0: read (compiled): code
> compiled for version 4.2.1.5, not 4.2.1.6
> .
> .
> .
>
> What's going on here? Shouldn't setup-plt / make install be
> rebuilding these? I got these yesterday during a setup-plt -D as
> well, which is confusing because they appear to be documentation files
> and I would expect them to be excluded from setup-plt -D.
Yes, that's puzzling.
Just to make sure, what are the timestamps on "algol60_scrbl.zo",
"algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
Where in the Setup PLT output do those warnings appear (with and
without `-D', if possible)?
From cce at ccs.neu.edu Tue Aug 11 11:31:31 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 11:39:42 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
On Tue, Aug 11, 2009 at 11:22 AM, Matthew Flatt wrote:
> At Tue, 11 Aug 2009 11:13:32 -0400, Carl Eastlund wrote:
>> Running make install, I get a long series of errors of this form:
>>
>> /Users/cce/plt/trunk/doc/algol60/in.sxref::0: read (compiled): code
>> compiled for version 4.2.1.5, not 4.2.1.6
>> /Users/cce/plt/trunk/doc/browser/in.sxref::0: read (compiled): code
>> compiled for version 4.2.1.5, not 4.2.1.6
>> /Users/cce/plt/trunk/doc/cards/in.sxref::0: read (compiled): code
>> compiled for version 4.2.1.5, not 4.2.1.6
>> .
>> .
>> .
>>
>> What's going on here? ?Shouldn't setup-plt / make install be
>> rebuilding these? ?I got these yesterday during a setup-plt -D as
>> well, which is confusing because they appear to be documentation files
>> and I would expect them to be excluded from setup-plt -D.
>
> Yes, that's puzzling.
>
> Just to make sure, what are the timestamps on "algol60_scrbl.zo",
> "algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
-rw-r--r-- 1 cce cce 7901 Aug 11 10:28
collects/algol60/compiled/algol60_scrbl.zo
-rw-r--r-- 1 cce cce 453 Aug 11 11:19 doc/algol60/in.sxref
-rw-r--r-- 1 cce cce 11165 Aug 10 13:01 doc/algol60/index.html
-rw-r--r-- 1 cce cce 2599 Aug 11 11:19 doc/algol60/out.sxref
> Where in the Setup PLT output do those warnings appear (with and
> without `-D', if possible)?
During both 'setup-plt -D' and 'make install' they occurred in the
middle of setting up my development links; Dracula in particular, in
between building the fasttest/private directory (from the FastTest
package, a dependency of Dracula) and the dracula/reference/modular
directory (which contains only a .scrbl file). I'm not sure if
building .scrbl files is expected or not for -D, either, but my -D
builds always go through long compiles in some of my reference
documentation directories anyway.
--Carl
From mflatt at cs.utah.edu Tue Aug 11 12:13:15 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 12:13:35 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
Message-ID: <20090811161316.50C7B65008C@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 11:31:31 -0400, Carl Eastlund wrote:
> On Tue, Aug 11, 2009 at 11:22 AM, Matthew Flatt wrote:
> > At Tue, 11 Aug 2009 11:13:32 -0400, Carl Eastlund wrote:
> >> Running make install, I get a long series of errors of this form:
> >>
> >> /Users/cce/plt/trunk/doc/algol60/in.sxref::0: read (compiled): code
> >> compiled for version 4.2.1.5, not 4.2.1.6
> >> /Users/cce/plt/trunk/doc/browser/in.sxref::0: read (compiled): code
> >> compiled for version 4.2.1.5, not 4.2.1.6
> >> /Users/cce/plt/trunk/doc/cards/in.sxref::0: read (compiled): code
> >> compiled for version 4.2.1.5, not 4.2.1.6
> >> .
> >> .
> >> .
> >>
> >> What's going on here? ?Shouldn't setup-plt / make install be
> >> rebuilding these? ?I got these yesterday during a setup-plt -D as
> >> well, which is confusing because they appear to be documentation files
> >> and I would expect them to be excluded from setup-plt -D.
> >
> > Yes, that's puzzling.
> >
> > Just to make sure, what are the timestamps on "algol60_scrbl.zo",
> > "algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
>
> -rw-r--r-- 1 cce cce 7901 Aug 11 10:28
> collects/algol60/compiled/algol60_scrbl.zo
> -rw-r--r-- 1 cce cce 453 Aug 11 11:19 doc/algol60/in.sxref
> -rw-r--r-- 1 cce cce 11165 Aug 10 13:01 doc/algol60/index.html
> -rw-r--r-- 1 cce cce 2599 Aug 11 11:19 doc/algol60/out.sxref
Still puzzling. I guess the ".sxref" files were updated because there
was a doc build (maybe for a planet package?) after `setup-plt -D'. But
then the files should have the right version. The ".sxref" files
really do start with the old version number, right?
> > Where in the Setup PLT output do those warnings appear (with and
> > without `-D', if possible)?
>
> During both 'setup-plt -D' and 'make install' they occurred in the
> middle of setting up my development links; Dracula in particular, in
> between building the fasttest/private directory (from the FastTest
> package, a dependency of Dracula) and the dracula/reference/modular
> directory (which contains only a .scrbl file).
I haven't yet managed to reproduce the problem. Does it happen with the
current Planet version of "fasttest.plt"?
> I'm not sure if
> building .scrbl files is expected or not for -D, either, but my -D
> builds always go through long compiles in some of my reference
> documentation directories anyway.
".scrbl" files are compiled even if you supply -D, since -D currently
only controls rendering. Now that you mention it, though, ".scrbl"
files could be skipped when you supply -D, and I'll look into that
change.
In any case, I don't see why ".sxref" files would be needed when
compiling ".scrbl" files, unless some for-syntax module explicitly
loads cross-reference information (e.g., though `load-collections-xref'
from `setup/xref').
From cce at ccs.neu.edu Tue Aug 11 12:14:41 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 12:15:18 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
Message-ID: <990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
On Tue, Aug 11, 2009 at 11:31 AM, Carl Eastlund wrote:
>>
>> Just to make sure, what are the timestamps on "algol60_scrbl.zo",
>> "algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
>
> -rw-r--r-- ?1 cce ?cce ? 7901 Aug 11 10:28
> collects/algol60/compiled/algol60_scrbl.zo
> -rw-r--r-- ?1 cce ?cce ? ?453 Aug 11 11:19 doc/algol60/in.sxref
> -rw-r--r-- ?1 cce ?cce ?11165 Aug 10 13:01 doc/algol60/index.html
> -rw-r--r-- ?1 cce ?cce ? 2599 Aug 11 11:19 doc/algol60/out.sxref
That was during the 'make install'. After it finished, the timestamps became:
-rw-r--r-- 1 cce cce 7901 Aug 11 10:28
collects/algol60/compiled/algol60_scrbl.zo
-rw-r--r-- 1 cce cce 524 Aug 11 11:59 doc/algol60/in.sxref
-rw-r--r-- 1 cce cce 11165 Aug 11 11:30 doc/algol60/index.html
-rw-r--r-- 1 cce cce 2599 Aug 11 11:19 doc/algol60/out.sxref
Immediately subsequent runs of setup-plt -D and make install did not
generate the error messages.
--Carl
From mflatt at cs.utah.edu Tue Aug 11 12:19:31 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 12:19:50 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
Message-ID: <20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 12:14:41 -0400, Carl Eastlund wrote:
> On Tue, Aug 11, 2009 at 11:31 AM, Carl Eastlund wrote:
> >>
> >> Just to make sure, what are the timestamps on "algol60_scrbl.zo",
> >> "algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
> >
> > -rw-r--r-- ?1 cce ?cce ? 7901 Aug 11 10:28
> > collects/algol60/compiled/algol60_scrbl.zo
> > -rw-r--r-- ?1 cce ?cce ? ?453 Aug 11 11:19 doc/algol60/in.sxref
> > -rw-r--r-- ?1 cce ?cce ?11165 Aug 10 13:01 doc/algol60/index.html
> > -rw-r--r-- ?1 cce ?cce ? 2599 Aug 11 11:19 doc/algol60/out.sxref
>
> That was during the 'make install'.
After it started the "building documentation" phase?
From cce at ccs.neu.edu Tue Aug 11 12:20:53 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 12:21:31 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
<20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908110920m3cb852b9ib891646950934c29@mail.gmail.com>
On Tue, Aug 11, 2009 at 12:19 PM, Matthew Flatt wrote:
> At Tue, 11 Aug 2009 12:14:41 -0400, Carl Eastlund wrote:
>> On Tue, Aug 11, 2009 at 11:31 AM, Carl Eastlund wrote:
>> >>
>> >> Just to make sure, what are the timestamps on "algol60_scrbl.zo",
>> >> "algol60/index.html", "algol60/in.sxref", and "algol60/out.sxref"?
>> >
>> > -rw-r--r-- ?1 cce ?cce ? 7901 Aug 11 10:28
>> > collects/algol60/compiled/algol60_scrbl.zo
>> > -rw-r--r-- ?1 cce ?cce ? ?453 Aug 11 11:19 doc/algol60/in.sxref
>> > -rw-r--r-- ?1 cce ?cce ?11165 Aug 10 13:01 doc/algol60/index.html
>> > -rw-r--r-- ?1 cce ?cce ? 2599 Aug 11 11:19 doc/algol60/out.sxref
>>
>> That was during the 'make install'.
>
> After it started the "building documentation" phase?
I believe it was still building source code at the time.
--Carl
From mflatt at cs.utah.edu Tue Aug 11 12:29:08 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 12:29:29 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110920m3cb852b9ib891646950934c29@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
<20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
<990e0c030908110920m3cb852b9ib891646950934c29@mail.gmail.com>
Message-ID: <20090811162908.C98C865008C@mail-svr1.cs.utah.edu>
Do any of your linked planet packages refer to regular Planet packages
(which must be downloaded and installed)?
From cce at ccs.neu.edu Tue Aug 11 12:30:23 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 12:31:01 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <20090811162908.C98C865008C@mail-svr1.cs.utah.edu>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
<20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
<990e0c030908110920m3cb852b9ib891646950934c29@mail.gmail.com>
<20090811162908.C98C865008C@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908110930y63c3f64bne7658d289683b98b@mail.gmail.com>
On Tue, Aug 11, 2009 at 12:29 PM, Matthew Flatt wrote:
> Do any of your linked planet packages refer to regular Planet packages
> (which must be downloaded and installed)?
Yes.
--Carl
From mflatt at cs.utah.edu Tue Aug 11 12:36:48 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 12:37:06 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <990e0c030908110930y63c3f64bne7658d289683b98b@mail.gmail.com>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<990e0c030908110914s6481c73dr6fde978fc8b146fa@mail.gmail.com>
<20090811161931.8D8C365008C@mail-svr1.cs.utah.edu>
<990e0c030908110920m3cb852b9ib891646950934c29@mail.gmail.com>
<20090811162908.C98C865008C@mail-svr1.cs.utah.edu>
<990e0c030908110930y63c3f64bne7658d289683b98b@mail.gmail.com>
Message-ID: <20090811163648.C0D4C6500BA@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 12:30:23 -0400, Carl Eastlund wrote:
> On Tue, Aug 11, 2009 at 12:29 PM, Matthew Flatt wrote:
> > Do any of your linked planet packages refer to regular Planet packages
> > (which must be downloaded and installed)?
>
> Yes.
Ah, that must be it. After the Planet package is installed, Planet
attempts to update the user-specific documentation index. But the rest
of the documentation files are not in shape for a mere "update".
If you don't use -D, then `setup-plt' eventually starts working on
documentation. It fixes the user-specific documentation index, so
everything is right in the end --- but you see error messages along the
way.
I'm not immediately sure how to fix this, and I'll think about it more.
From cce at ccs.neu.edu Tue Aug 11 13:16:58 2009
From: cce at ccs.neu.edu (Carl Eastlund)
Date: Tue Aug 11 13:17:37 2009
Subject: [plt-dev] Rationale for kernel-form-identifier-list
Message-ID: <990e0c030908111016j742c3b33n4548a1df259299bc@mail.gmail.com>
The kernel-form-identifier-list function from syntax/kerncase is
useful for head expansion and similar low-level macro hackery, but its
specifications is somewhat quirky. It leaves out (module-)top-level
forms (module, #%plain-module-begin, #%require, and #%provide), and
includes the non-fully-expanded form letrec-syntaxes+values. Is there
a compelling reason for this? Local (usually head-)expansion in
internal definition contexts doesn't need the extra bindings, but I
don't see that it would hurt to include them. However, local
expansion in a module context does need the extra bindings, so it
would help to add them (and I don't see that we need a separate
binding for it).
As for letrec-syntaxes+values, if it gets expanded away, I don't see
why it's in the list at all. If it doesn't, it should be included in
the "Fully Expanded Programs" grammar.
Carl Eastlund
From mflatt at cs.utah.edu Tue Aug 11 13:50:49 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Tue Aug 11 13:51:07 2009
Subject: [plt-dev] Rationale for kernel-form-identifier-list
In-Reply-To: <990e0c030908111016j742c3b33n4548a1df259299bc@mail.gmail.com>
References: <990e0c030908111016j742c3b33n4548a1df259299bc@mail.gmail.com>
Message-ID: <20090811175049.60FE16500B7@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 13:16:58 -0400, Carl Eastlund wrote:
> The kernel-form-identifier-list function from syntax/kerncase is
> useful for head expansion and similar low-level macro hackery, but its
> specifications is somewhat quirky. It leaves out (module-)top-level
> forms (module, #%plain-module-begin, #%require, and #%provide), and
> includes the non-fully-expanded form letrec-syntaxes+values. Is there
> a compelling reason for this? Local (usually head-)expansion in
> internal definition contexts doesn't need the extra bindings, but I
> don't see that it would hurt to include them. However, local
> expansion in a module context does need the extra bindings, so it
> would help to add them (and I don't see that we need a separate
> binding for it).
>
> As for letrec-syntaxes+values, if it gets expanded away, I don't see
> why it's in the list at all. If it doesn't, it should be included in
> the "Fully Expanded Programs" grammar.
I can't think of a reason to leave out the module top-level forms. I'm
not sure why they were left out, and when I've thought about it in the
past, I didn't see a good reason to leave them out. So, let's add them.
The `letrec-syntaxes+values' form is special in that it appears in the
result of `local-expand', even with an empty stop list. More generally,
it's the core form for local compile-time bindings. I'll fix the docs.
From clements at brinckerhoff.org Wed Aug 12 10:07:53 2009
From: clements at brinckerhoff.org (John Clements)
Date: Wed Aug 12 10:09:36 2009
Subject: [plt-dev] JFYI OS X DrScheme core dump
Message-ID: <6C64A946-11A3-49D5-A7ED-61D14FEEDB48@brinckerhoff.org>
DrScheme dumped core during GC, here's the CrashReporter stacktrace,
ignore if not useful.
John Clements
Process: DrScheme [43147]
Path: /Users/clements/plt/bin/../DrScheme.app/Contents/
MacOS/DrScheme
Identifier: org.plt-scheme.DrScheme
Version: 4.2.1.3 (4.2.1.3)
Code Type: X86 (Native)
Parent Process: bash [29564]
Date/Time: 2009-08-12 10:02:10.013 -0400
OS Version: Mac OS X 10.5.7 (9J61)
Report Version: 6
Anonymous UUID: 874BB998-0981-4A79-B046-2FEEBB7BB98B
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000025af3ffc
Crashed Thread: 0
Thread 0 Crashed:
0 org.plt-scheme.PLT_MrEd 0x00754bdf GC_mark + 575
(mem_account.c:266)
1 org.plt-scheme.PLT_MrEd 0x007385d5 cpointer_obj_MARK + 21
2 org.plt-scheme.PLT_MrEd 0x00752631 BTC_do_accounting + 993
(mem_account.c:341)
3 org.plt-scheme.PLT_MrEd 0x007545e7 garbage_collect + 6311
(newgc.c:3189)
4 org.plt-scheme.PLT_MrEd 0x007573ee GC_malloc_one_tagged +
398 (newgc.c:737)
5 org.plt-scheme.PLT_MrEd 0x006dac7a scheme_alloc_char_string
+ 90
6 org.plt-scheme.PLT_MrEd 0x006db093 make_string + 147
7 ??? 0x16a67fea 0 + 380010474
8 ??? 0x1724931d 0 + 388272925
9 ??? 0x16a2707d 0 + 379744381
10 ??? 0x1724985d 0 + 388274269
11 ??? 0x16a2785d 0 + 379746397
12 ??? 0x16a275bd 0 + 379745725
13 org.plt-scheme.PLT_MrEd 0x005f046c scheme_do_eval + 6748
14 org.plt-scheme.PLT_MrEd 0x00616bb8
scheme_finish_apply_for_prompt + 584
15 org.plt-scheme.PLT_MrEd 0x00616d25 scheme_apply_for_prompt
+ 85
16 org.plt-scheme.PLT_MrEd 0x006177fa call_with_prompt + 1034
17 ??? 0x16a403f6 0 + 379847670
18 org.plt-scheme.PLT_MrEd 0x005f046c scheme_do_eval + 6748
19 org.plt-scheme.PLT_MrEd 0x0060c19b apply_k + 155
20 org.plt-scheme.PLT_MrEd 0x0060bc98
scheme_top_level_do_worker + 968
21 org.plt-scheme.PLT_MrEd 0x0060c2f2
scheme_apply_thread_thunk + 98
22 org.plt-scheme.PLT_MrEd 0x00732fc1 start_child + 801
23 org.plt-scheme.PLT_MrEd 0x007360bf make_subprocess + 383
24 org.plt-scheme.PLT_MrEd 0x007362d5 scheme_thread_w_details
+ 293
25 ??? 0xbfffda80 0 + 3221215872
26 ??? 0x1f70cff8 0 + 527486968
Thread 1:
0 libSystem.B.dylib 0x9349a286 mach_msg_trap + 10
1 libSystem.B.dylib 0x934a1a7c mach_msg + 72
2 org.plt-scheme.PLT_MrEd 0x0074f632 exception_thread + 162
(vm_osx.c:250)
3 libSystem.B.dylib 0x934cb155 _pthread_start + 321
4 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 2:
0 libSystem.B.dylib 0x934a146e __semwait_signal + 10
1 libSystem.B.dylib 0x934cbdcd pthread_cond_wait
$UNIX2003 + 73
2 libGLProgrammability.dylib 0x93a63b32 glvmDoWork + 162
3 libSystem.B.dylib 0x934cb155 _pthread_start + 321
4 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 3:
0 libSystem.B.dylib 0x934a146e __semwait_signal + 10
1 libSystem.B.dylib 0x934cbdcd pthread_cond_wait
$UNIX2003 + 73
2 org.plt-scheme.PLT_MrEd 0x0069a1cd run_itimer + 141
3 libSystem.B.dylib 0x934cb155 _pthread_start + 321
4 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 4:
0 libSystem.B.dylib 0x934e96fa select$DARWIN_EXTSN + 10
1 libSystem.B.dylib 0x934cb155 _pthread_start + 321
2 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 5:
0 libSystem.B.dylib 0x934a146e __semwait_signal + 10
1 libSystem.B.dylib 0x934cbdcd pthread_cond_wait
$UNIX2003 + 73
2 org.plt-scheme.PLT_MrEd 0x0069a3ac pt_sema_wait + 92
3 org.plt-scheme.PLT_MrEd 0x0069a44b do_watch + 59
4 libSystem.B.dylib 0x934cb155 _pthread_start + 321
5 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 6:
0 libSystem.B.dylib 0x9349a286 mach_msg_trap + 10
1 libSystem.B.dylib 0x934a1a7c mach_msg + 72
2 com.apple.CoreFoundation 0x923be04e CFRunLoopRunSpecific +
1790
3 com.apple.CoreFoundation 0x923becd4 CFRunLoopRun + 84
4 com.apple.DesktopServices 0x93060e17
TSystemNotificationTask::SystemNotificationTaskProc(void*) + 123
5 ...ple.CoreServices.CarbonCore 0x9172b057 PrivateMPEntryPoint + 56
6 libSystem.B.dylib 0x934cb155 _pthread_start + 321
7 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 7:
0 libSystem.B.dylib 0x9349a286 mach_msg_trap + 10
1 libSystem.B.dylib 0x934a1a7c mach_msg + 72
2 com.apple.CoreFoundation 0x923be04e CFRunLoopRunSpecific +
1790
3 com.apple.CoreFoundation 0x923becd4 CFRunLoopRun + 84
4 com.apple.DesktopServices 0x93060f90
TFSEventsNotificationTask::FSEventsNotificationTaskProc(void*) + 216
5 ...ple.CoreServices.CarbonCore 0x9172b057 PrivateMPEntryPoint + 56
6 libSystem.B.dylib 0x934cb155 _pthread_start + 321
7 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 8:
0 libSystem.B.dylib 0x934a146e __semwait_signal + 10
1 libSystem.B.dylib 0x934cbdcd pthread_cond_wait
$UNIX2003 + 73
2 ...ple.CoreServices.CarbonCore 0x9172ce83 TSWaitOnCondition + 126
3 ...ple.CoreServices.CarbonCore 0x9170bd6a
TSWaitOnConditionTimedRelative + 202
4 ...ple.CoreServices.CarbonCore 0x9172cb00 MPWaitOnQueue + 208
5 com.apple.DesktopServices 0x9306bf72
TNodeSyncTask::SyncTaskProc(void*) + 84
6 ...ple.CoreServices.CarbonCore 0x9172b057 PrivateMPEntryPoint + 56
7 libSystem.B.dylib 0x934cb155 _pthread_start + 321
8 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 9:
0 libSystem.B.dylib 0x934ca9c6 kevent + 10
1 libSystem.B.dylib 0x934cb155 _pthread_start + 321
2 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 10:
0 libSystem.B.dylib 0x9349a2e6
semaphore_timedwait_signal_trap + 10
1 libSystem.B.dylib 0x934cc2af _pthread_cond_wait + 1244
2 libSystem.B.dylib 0x934cdb33
pthread_cond_timedwait_relative_np + 47
3 com.apple.Foundation 0x92637dcc -[NSCondition
waitUntilDate:] + 236
4 com.apple.Foundation 0x92637be0 -[NSConditionLock
lockWhenCondition:beforeDate:] + 144
5 com.apple.Foundation 0x92637b45 -[NSConditionLock
lockWhenCondition:] + 69
6 com.apple.AppKit 0x9546dd20 -[NSUIHeartBeat
_heartBeatThread:] + 753
7 com.apple.Foundation 0x925f1e0d -[NSThread main] + 45
8 com.apple.Foundation 0x925f19b4 __NSThread__main__ + 308
9 libSystem.B.dylib 0x934cb155 _pthread_start + 321
10 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 11:
0 libSystem.B.dylib 0x9349a2e6
semaphore_timedwait_signal_trap + 10
1 libSystem.B.dylib 0x934cc2af _pthread_cond_wait + 1244
2 libSystem.B.dylib 0x934cdb33
pthread_cond_timedwait_relative_np + 47
3 ...ple.CoreServices.CarbonCore 0x9170bd96
TSWaitOnConditionTimedRelative + 246
4 ...ple.CoreServices.CarbonCore 0x9170bb76 TSWaitOnSemaphoreCommon
+ 422
5 ...ickTimeComponents.component 0x96993aa2
ReadSchedulerThreadEntryPoint + 4724
6 libSystem.B.dylib 0x934cb155 _pthread_start + 321
7 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 12:
0 libSystem.B.dylib 0x9349a286 mach_msg_trap + 10
1 libSystem.B.dylib 0x934a1a7c mach_msg + 72
2 com.apple.CoreFoundation 0x923be04e CFRunLoopRunSpecific +
1790
3 com.apple.CoreFoundation 0x923bec78 CFRunLoopRunInMode + 88
4 com.apple.audio.CoreAudio 0x914235f8
HALRunLoop::OwnThread(void*) + 160
5 com.apple.audio.CoreAudio 0x91423480
CAPThread::Entry(CAPThread*) + 96
6 libSystem.B.dylib 0x934cb155 _pthread_start + 321
7 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 13:
0 libSystem.B.dylib 0x9349a2e6
semaphore_timedwait_signal_trap + 10
1 libSystem.B.dylib 0x934cc2af _pthread_cond_wait + 1244
2 libSystem.B.dylib 0x934cdb33
pthread_cond_timedwait_relative_np + 47
3 ...ple.CoreServices.CarbonCore 0x9170bd96
TSWaitOnConditionTimedRelative + 246
4 ...ple.CoreServices.CarbonCore 0x9172cb00 MPWaitOnQueue + 208
5 com.apple.DesktopServices 0x9306debc
TFolderSizeTask::FolderSizeTaskProc(void*) + 104
6 ...ple.CoreServices.CarbonCore 0x9172b057 PrivateMPEntryPoint + 56
7 libSystem.B.dylib 0x934cb155 _pthread_start + 321
8 libSystem.B.dylib 0x934cb012 thread_start + 34
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x25af4000 ebx: 0x007549b1 ecx: 0x001098b0 edx: 0x000096bd
edi: 0x23cebbf0 esi: 0x000002db ebp: 0xbfffced8 esp: 0xbfffce90
ss: 0x0000001f efl: 0x00010246 eip: 0x00754bdf cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0x25af3ffc
Binary Images:
0x1000 - 0x9fff +org.plt-scheme.DrScheme 4.2.1.3 (4.2.1.3)
<4905519b6c23437c3d65620b1f987100> /Users/clements/plt/DrScheme.app/
Contents/MacOS/DrScheme
0x4bd000 - 0x7d1ff2 +org.plt-scheme.PLT_MrEd 4.2.1.3 (4.2.1.3)
<30e8584b7586eded5866ae39ec586e67> /Users/clements/plt/lib/
PLT_MrEd.framework/Versions/4.2.1.3_3m/PLT_MrEd
0xbc8000 - 0xbe4ff7 GLRendererFloat ??? (???)
<927b7d5ce6a7c21fdc761f6f29cdf4ee> /System/Library/Frameworks/
OpenGL.framework/Versions/A/Resources/GLRendererFloat.bundle/
GLRendererFloat
0xdbe000 - 0xf43fe3 GLEngine ??? (???)
<3bd4729832411ff31de5bb9d97e3718d> /System/Library/Frameworks/
OpenGL.framework/Resources/GLEngine.bundle/GLEngine
0x11d2d000 - 0x12096fe8 com.apple.GeForce8xxxGLDriver 1.5.44 (5.4.4)
<59268db992cb4c6d08ca7b5bba366863> /System/Library/Extensions/
GeForce8xxxGLDriver.bundle/Contents/MacOS/GeForce8xxxGLDriver
0x1808e000 - 0x18295fef com.apple.RawCamera.bundle 2.0.15 (471)
<557c94fbd7c15219746393464a79cf87> /System/Library/CoreServices/
RawCamera.bundle/Contents/MacOS/RawCamera
0x1e728000 - 0x1e72afe8 +libogg.0.dylib ??? (???)
<662e844de2b28f80aed01ad5d69c88d1> /opt/local/lib/libogg.0.dylib
0x21040000 - 0x21043fff com.apple.audio.AudioIPCPlugIn 1.0.6 (1.0.6)
<63c9ef8da77eb8768e03991ec0e413fd> /System/Library/Extensions/
AudioIPCDriver.kext/Contents/Resources/AudioIPCPlugIn.bundle/Contents/
MacOS/AudioIPCPlugIn
0x21088000 - 0x2108dfff com.apple.audio.AppleHDAHALPlugIn 1.6.8
(1.6.8a3) /System/Library/Extensions/AppleHDA.kext/Contents/PlugIns/
AppleHDAHALPlugIn.bundle/Contents/MacOS/AppleHDAHALPlugIn
0x21f0a000 - 0x21f0fff3 libCGXCoreImage.A.dylib ??? (???)
<3a78abc535c80f9819931b670da804a2> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
CoreGraphics.framework/Versions/A/Resources/libCGXCoreImage.A.dylib
0x22a41000 - 0x22a4bffe com.apple.URLMount 3.1.1 (3.1.1)
/System/Library/PrivateFrameworks/
URLMount.framework/URLMount
0x25198000 - 0x251beffd +libvorbis.0.dylib ??? (???)
/opt/local/lib/libvorbis.0.dylib
0x2557c000 - 0x255d8ff3 +libsndfile.dylib ??? (???)
/opt/local/lib/libsndfile.dylib
0x25978000 - 0x259bcfef +libFLAC.8.dylib ??? (???)
/opt/local/lib/libFLAC.8.dylib
0x26100000 - 0x261e2fff +libvorbisenc.2.dylib ??? (???)
<2a77d3050d3d4f8912e4601d6db567b5> /opt/local/lib/libvorbisenc.2.dylib
0x70000000 - 0x700e6ff2 com.apple.audio.units.Components 1.5.2
(1.5.2) /System/Library/Components/CoreAudio.component/Contents/MacOS/
CoreAudio
0x8fe00000 - 0x8fe2db43 dyld 97.1 (???)
<100d362e03410f181a34e04e94189ae5> /usr/lib/dyld
0x90003000 - 0x90003ffd com.apple.Accelerate 1.4.2 (Accelerate
1.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/
Accelerate
0x90004000 - 0x900cffff com.apple.ColorSync 4.5.1 (4.5.1) /System/
Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/
ColorSync.framework/Versions/A/ColorSync
0x904e5000 - 0x90557ff7 com.apple.iLifeMediaBrowser 2.0.3 (346)
<2f558ebc56b9b3122efac1bcad78a0db> /System/Library/PrivateFrameworks/
iLifeMediaBrowser.framework/Versions/A/iLifeMediaBrowser
0x90588000 - 0x905a6ff3 com.apple.DirectoryService.Framework 3.5.6
(3.5.6) /System/Library/Frameworks/
DirectoryService.framework/Versions/A/DirectoryService
0x905a7000 - 0x90778ffb com.apple.security 5.0.5 (36371)
/System/Library/Frameworks/
Security.framework/Versions/A/Security
0x90779000 - 0x907a1ff7 com.apple.shortcut 1.0.1 (1.0)
<131202e7766e327d02d55c0f5fc44ad7> /System/Library/PrivateFrameworks/
Shortcut.framework/Versions/A/Shortcut
0x907a2000 - 0x907b8fff com.apple.DictionaryServices 1.0.0 (1.0.0)
<7d20b8d1fb238c3e71d0fa6fda18c4f7> /System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/
DictionaryServices.framework/Versions/A/DictionaryServices
0x907b9000 - 0x907b9ffd com.apple.vecLib 3.4.2 (vecLib 3.4.2) /System/
Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x907ba000 - 0x907baffe com.apple.quartzframework 1.5 (1.5)
<6865aa0aeaa584b5a54d43f2f21d6c08> /System/Library/Frameworks/
Quartz.framework/Versions/A/Quartz
0x907cb000 - 0x908abfff libobjc.A.dylib ??? (???)
<400e943f9e8a678eea22a1d1205490ee> /usr/lib/libobjc.A.dylib
0x908ac000 - 0x908affff com.apple.help 1.1 (36)
<1a25a8fbb49a830efb31d5c0a52939cd> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x908b0000 - 0x9090cff7 com.apple.htmlrendering 68 (1.1.3)
<1c5c0c417891b920dfe139385fc6c155> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/
Versions/A/HTMLRendering
0x9090d000 - 0x90914fe9 libgcc_s.1.dylib ??? (???)
/usr/lib/libgcc_s.1.dylib
0x90915000 - 0x90c3bfe2 com.apple.QuickTime 7.6.2 (1327)
<3754e41d846b7948f96c9ec4c690b520> /System/Library/Frameworks/
QuickTime.framework/Versions/A/QuickTime
0x90c3c000 - 0x90c96ff7 com.apple.CoreText 2.0.4 (???)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/
Versions/A/CoreText
0x90c97000 - 0x90c99fff com.apple.securityhi 3.0 (30817)
<40562b85d99118354c974e76c32fa6fb> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/
SecurityHI
0x90c9a000 - 0x90dd2fe7 com.apple.imageKit 1.0.2 (1.0)
<2e354566521df8b1e3a78e9aeab5e6b4> /System/Library/Frameworks/
Quartz.framework/Versions/A/Frameworks/ImageKit.framework/Versions/A/
ImageKit
0x90dd3000 - 0x90e24ff7 com.apple.HIServices 1.7.0 (???)
<01b690d1f376e400ac873105533e39eb> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
HIServices.framework/Versions/A/HIServices
0x90e25000 - 0x90e2cffe libbsm.dylib ??? (???)
/usr/lib/libbsm.dylib
0x90e32000 - 0x90e39ff7 libCGATS.A.dylib ??? (???)
<211348279493364e9920adc86484cedd> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
0x90e3a000 - 0x90e52ff7 com.apple.CoreVideo 1.6.0 (20.0)
/System/Library/Frameworks/
CoreVideo.framework/Versions/A/CoreVideo
0x90e53000 - 0x91211fea libLAPACK.dylib ??? (???) /System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libLAPACK.dylib
0x91261000 - 0x91269fff com.apple.DiskArbitration 2.2.1 (2.2.1)
<2664eeb3a4d0c95a21c089892a0ae8d0> /System/Library/Frameworks/
DiskArbitration.framework/Versions/A/DiskArbitration
0x9126a000 - 0x9126afff com.apple.Carbon 136 (136)
<4177916bbf70e0ddc446f94001d54c95> /System/Library/Frameworks/
Carbon.framework/Versions/A/Carbon
0x9126b000 - 0x912eaff5 com.apple.SearchKit 1.2.1 (1.2.1)
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/
Versions/A/SearchKit
0x912ff000 - 0x91303fff libGIF.dylib ??? (???)
<7714ae24eb64b48fa719fb99bcbe34f3> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/Resources/libGIF.dylib
0x91304000 - 0x91343fef libTIFF.dylib ??? (???)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/Resources/libTIFF.dylib
0x91344000 - 0x913d7fff com.apple.ink.framework 101.3 (86)
/System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x913d8000 - 0x91405feb libvDSP.dylib ??? (???)
<4daafed78a471133ec30b3ae634b6d3e> /System/Library/Frameworks/
Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/
libvDSP.dylib
0x91406000 - 0x91483feb com.apple.audio.CoreAudio 3.1.2 (3.1.2)
<5a4e6329f8dbca5dcd70924525afd24a> /System/Library/Frameworks/
CoreAudio.framework/Versions/A/CoreAudio
0x91484000 - 0x91499ffb com.apple.ImageCapture 5.0.2 (5.0.2) /System/
Library/Frameworks/Carbon.framework/Versions/A/Frameworks/
ImageCapture.framework/Versions/A/ImageCapture
0x9149a000 - 0x9149affe com.apple.MonitorPanelFramework 1.2.0 (1.2.0)
<1f4c10fcc17187a6f106e0a0be8236b0> /System/Library/PrivateFrameworks/
MonitorPanel.framework/Versions/A/MonitorPanel
0x9149b000 - 0x9149bff8 com.apple.Cocoa 6.5 (???)
/System/Library/Frameworks/
Cocoa.framework/Versions/A/Cocoa
0x91541000 - 0x91551fff com.apple.speech.synthesis.framework 3.7.1
(3.7.1) <273d96ff861dc68be659c07ef56f599a> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x91552000 - 0x91552ff8 com.apple.ApplicationServices 34 (34)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/ApplicationServices
0x9156b000 - 0x91622ff3 com.apple.QTKit 7.6.2 (1327) /System/Library/
Frameworks/QTKit.framework/Versions/A/QTKit
0x91623000 - 0x9162dfeb com.apple.audio.SoundManager 3.9.2 (3.9.2)
/System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/
A/CarbonSound
0x9162e000 - 0x916d1ff7 com.apple.QuickTimeImporters.component 7.6.2
(1327) /System/Library/QuickTime/QuickTimeImporters.component/Contents/
MacOS/QuickTimeImporters
0x916d2000 - 0x916e1ffe com.apple.DSObjCWrappers.Framework 1.3 (1.3)
<182986b74247b459b2a67a47071bdc6b> /System/Library/PrivateFrameworks/
DSObjCWrappers.framework/Versions/A/DSObjCWrappers
0x916e2000 - 0x919bcff3 com.apple.CoreServices.CarbonCore 786.11
(786.13) <9e2d85d52e5e2951aa4dd53c48ccc52f> /System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/
Versions/A/CarbonCore
0x92252000 - 0x922ccff8 com.apple.print.framework.PrintCore 5.5.4
(245.6) <03d0585059c20cb0bde5e000438c49e1> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
PrintCore.framework/Versions/A/PrintCore
0x92312000 - 0x9232dffb libPng.dylib ??? (???)
<0d6b991afc831ea06f2958e5933d33dd> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/Resources/libPng.dylib
0x9234b000 - 0x9247efef com.apple.CoreFoundation 6.5.6 (476.18)
<2d52bab73660117571bd6486dc318f8e> /System/Library/Frameworks/
CoreFoundation.framework/Versions/A/CoreFoundation
0x9247f000 - 0x9248afe7 libCSync.A.dylib ??? (???)
<9e3544fe087bb4dc760b7afe0850dd6c> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x9248b000 - 0x92517ff7 com.apple.framework.IOKit 1.5.2 (???)
<97b9f9d584f48891377f0481b9104434> /System/Library/Frameworks/
IOKit.framework/Versions/A/IOKit
0x92518000 - 0x9251dfff com.apple.CommonPanels 1.2.4 (85)
/System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/
A/CommonPanels
0x9251e000 - 0x92523fff com.apple.DisplayServicesFW 2.0.2 (2.0.2)
<97878a73074e7da4fe31ea010a5d5ae1> /System/Library/PrivateFrameworks/
DisplayServices.framework/Versions/A/DisplayServices
0x9252e000 - 0x92559fe7 libauto.dylib ??? (???)
<2e44c523b851e8e25f05d13a48070a58> /usr/lib/libauto.dylib
0x9255a000 - 0x9259bfe7 libRIP.A.dylib ??? (???)
<69bd09fcd8d8b235cee7a405290d6818> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x9259c000 - 0x925a9fe7 com.apple.opengl 1.5.10 (1.5.10)
<5a2813f80c9441170cc1ab8a3dac5038> /System/Library/Frameworks/
OpenGL.framework/Versions/A/OpenGL
0x925e7000 - 0x92863fe7 com.apple.Foundation 6.5.8 (677.24)
/System/Library/Frameworks/
Foundation.framework/Versions/C/Foundation
0x92864000 - 0x92872ffd libz.1.dylib ??? (???)
/usr/lib/libz.1.dylib
0x92873000 - 0x9291afeb com.apple.QD 3.11.56 (???)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/QD.framework/
Versions/A/QD
0x9291b000 - 0x92952fff com.apple.SystemConfiguration 1.9.2 (1.9.2)
/System/Library/Frameworks/
SystemConfiguration.framework/Versions/A/SystemConfiguration
0x92956000 - 0x9297ffff libcups.2.dylib ??? (???)
<1b0435164b9dc6c773d0b1f24701e554> /usr/lib/libcups.2.dylib
0x92980000 - 0x929ddffb libstdc++.6.dylib ??? (???)
/usr/lib/libstdc++.6.dylib
0x929f0000 - 0x92aa0fff edu.mit.Kerberos 6.0.13 (6.0.13)
<804bd1b3f08fb57396781f012006367c> /System/Library/Frameworks/
Kerberos.framework/Versions/A/Kerberos
0x92aa1000 - 0x92ad0fe3 com.apple.AE 402.3 (402.3)
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x92ade000 - 0x92af6fff com.apple.openscripting 1.2.8 (???)
<0129d2f750f5ddcb92f4acf8a3541952> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/
Versions/A/OpenScripting
0x92af7000 - 0x92c7ffe3 com.apple.JavaScriptCore 5530.19 (5530.19)
/System/Library/Frameworks/
JavaScriptCore.framework/Versions/A/JavaScriptCore
0x92c80000 - 0x92d32ffb libcrypto.0.9.7.dylib ??? (???)
<9d714c92872a93dd127ea8556b2c8945> /usr/lib/libcrypto.0.9.7.dylib
0x92d33000 - 0x92d37fff libmathCommon.A.dylib ??? (???) /usr/lib/
system/libmathCommon.A.dylib
0x92d38000 - 0x92e7eff7 com.apple.ImageIO.framework 2.0.4 (2.0.4)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/ImageIO
0x92e7f000 - 0x92f0bff7 com.apple.LaunchServices 290.3 (290.6)
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/
Versions/A/LaunchServices
0x92f0c000 - 0x92f2bffa libJPEG.dylib ??? (???)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/Resources/libJPEG.dylib
0x92f2c000 - 0x92f33fff com.apple.agl 3.0.9 (AGL-3.0.9)
<2f39c480cfcee9358a23d61b20a6aa56> /System/Library/Frameworks/
AGL.framework/Versions/A/AGL
0x92f34000 - 0x92f83fff com.apple.QuickLookUIFramework 1.3.1 (170.9) /
System/Library/PrivateFrameworks/QuickLookUI.framework/Versions/A/
QuickLookUI
0x9305f000 - 0x930e9fe3 com.apple.DesktopServices 1.4.8 (1.4.8)
<3065de6531ce839c7cb5b6dd70e03f4f> /System/Library/PrivateFrameworks/
DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x930ea000 - 0x933f2fff com.apple.HIToolbox 1.5.5 (???)
/System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/
HIToolbox
0x933f3000 - 0x933ffff9 com.apple.helpdata 1.0.1 (14.2) /System/
Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x93400000 - 0x93431ffb com.apple.quartzfilters 1.5.0 (1.5.0)
<92b4f39479fdcabae0d8f53febd22fad> /System/Library/Frameworks/
Quartz.framework/Versions/A/Frameworks/QuartzFilters.framework/
Versions/A/QuartzFilters
0x93499000 - 0x93600ff3 libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib
0x93606000 - 0x93648fef com.apple.NavigationServices 3.5.2 (163)
<72cdc9d21f6690837870923e7b8ca358> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/
Versions/A/NavigationServices
0x93684000 - 0x93686ff5 libRadiance.dylib ??? (???)
<82d606c49f5dc77231f9d0e2be9ed6ab> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
Versions/A/Resources/libRadiance.dylib
0x93687000 - 0x936f9fff com.apple.PDFKit 2.1.2 (2.1.2) /System/
Library/Frameworks/Quartz.framework/Versions/A/Frameworks/
PDFKit.framework/Versions/A/PDFKit
0x936fa000 - 0x9373afff com.apple.CoreMediaIOServicesPrivate 20.0
(20.0) /System/Library/PrivateFrameworks/
CoreMediaIOServicesPrivate.framework/Versions/A/
CoreMediaIOServicesPrivate
0x9373b000 - 0x937ceff3 com.apple.ApplicationServices.ATS 3.7 (???)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/
Versions/A/ATS
0x937cf000 - 0x9380dfff libGLImage.dylib ??? (???)
/System/Library/Frameworks/
OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
0x9380e000 - 0x9380effa com.apple.CoreServices 32 (32)
<373d6a888f9204641f313bc6070ae065> /System/Library/Frameworks/
CoreServices.framework/Versions/A/CoreServices
0x9380f000 - 0x93833fff libxslt.1.dylib ??? (???)
<0a9778d6368ae668826f446878deb99b> /usr/lib/libxslt.1.dylib
0x9383a000 - 0x9398cff3 com.apple.audio.toolbox.AudioToolbox 1.5.2
(1.5.2) /System/Library/Frameworks/AudioToolbox.framework/Versions/A/
AudioToolbox
0x9398d000 - 0x9398effc libffi.dylib ??? (???)
/usr/lib/libffi.dylib
0x9398f000 - 0x9399bffe libGL.dylib ??? (???) /System/Library/
Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
0x939f3000 - 0x93a1cfff com.apple.CoreMediaPrivate 15.0 (15.0) /
System/Library/PrivateFrameworks/CoreMediaPrivate.framework/Versions/A/
CoreMediaPrivate
0x93a1d000 - 0x93a3bfff libresolv.9.dylib ??? (???)
<9ed809256ce8913cddc3269c2e364654> /usr/lib/libresolv.9.dylib
0x93a3c000 - 0x93f0dfbe libGLProgrammability.dylib ??? (???)
<7f18294a7bd0b6afe4319f29187fc70d> /System/Library/Frameworks/
OpenGL.framework/Versions/A/Libraries/libGLProgrammability.dylib
0x93f0e000 - 0x942abfef com.apple.QuartzCore 1.5.8 (1.5.8)
/System/Library/Frameworks/
QuartzCore.framework/Versions/A/QuartzCore
0x942ac000 - 0x94350fec com.apple.CFNetwork 438.10 (438.12)
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/
Versions/A/CFNetwork
0x9439c000 - 0x943a2fff com.apple.print.framework.Print 218.0.3
(220.2) <5b7f4ef7c2df36aff9605377775781e4> /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x943a3000 - 0x943a3ffd com.apple.Accelerate.vecLib 3.4.2 (vecLib
3.4.2) /System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/vecLib
0x943a4000 - 0x94485ff7 libxml2.2.dylib ??? (???)
<2f6b294896866822330a8888b7f53b75> /usr/lib/libxml2.2.dylib
0x94486000 - 0x9454dff2 com.apple.vImage 3.0 (3.0) /System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/
Versions/A/vImage
0x9454e000 - 0x946ddfe7 com.apple.CoreAUC 3.07.3 (3.07.3)
/System/Library/PrivateFrameworks/
CoreAUC.framework/Versions/A/CoreAUC
0x9485e000 - 0x94997ff7 libicucore.A.dylib ??? (???)
/usr/lib/libicucore.A.dylib
0x949cb000 - 0x94abfff4 libiconv.2.dylib ??? (???)
<96ff4c6f84c4a1623cb78287371cdd3f> /usr/lib/libiconv.2.dylib
0x94ac0000 - 0x94c7cff3 com.apple.QuartzComposer 2.1 (106.13)
<40f034e8c8fd31c9081f5283dcf22b78> /System/Library/Frameworks/
Quartz.framework/Versions/A/Frameworks/QuartzComposer.framework/
Versions/A/QuartzComposer
0x94cd5000 - 0x94cdefff com.apple.speech.recognition.framework 3.7.24
(3.7.24) /System/Library/Frameworks/
Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/
Versions/A/SpeechRecognition
0x94cdf000 - 0x94cefffc com.apple.LangAnalysis 1.6.4 (1.6.4)
/System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
LangAnalysis.framework/Versions/A/LangAnalysis
0x94cf0000 - 0x95100fef libBLAS.dylib ??? (???) /System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libBLAS.dylib
0x95101000 - 0x951bbfe3 com.apple.CoreServices.OSServices 227 (227)
<30cebcb68b1b571df7d77474e0c31556> /System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/OSServices.framework/
Versions/A/OSServices
0x951bc000 - 0x952a4ff3 com.apple.CoreData 100.2 (186.1)
<8fb61e1714a4b8d587ce97605ad32547> /System/Library/Frameworks/
CoreData.framework/Versions/A/CoreData
0x952a5000 - 0x952eefef com.apple.Metadata 10.5.2 (398.25)
/System/Library/Frameworks/
CoreServices.framework/Versions/A/Frameworks/Metadata.framework/
Versions/A/Metadata
0x952ef000 - 0x9530cff7 com.apple.QuickLookFramework 1.3.1 (170.9) /
System/Library/Frameworks/QuickLook.framework/Versions/A/QuickLook
0x9530d000 - 0x9538afef libvMisc.dylib ??? (???) /System/Library/
Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/
Versions/A/libvMisc.dylib
0x953c0000 - 0x953c0ffb com.apple.installserver.framework 1.0 (8) /
System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/
InstallServer
0x953c7000 - 0x95bc5fef com.apple.AppKit 6.5.7 (949.46)
/System/Library/Frameworks/
AppKit.framework/Versions/C/AppKit
0x95bc6000 - 0x96266fe3 com.apple.CoreGraphics 1.409.3 (???)
<25dceb14af3455b768f56e8765ecf3ca> /System/Library/Frameworks/
ApplicationServices.framework/Versions/A/Frameworks/
CoreGraphics.framework/Versions/A/CoreGraphics
0x96267000 - 0x962c0ff7 libGLU.dylib ??? (???)
/System/Library/Frameworks/
OpenGL.framework/Versions/A/Libraries/libGLU.dylib
0x962c1000 - 0x9729cff6 com.apple.QuickTimeComponents.component 7.6.2
(1327) /System/Library/QuickTime/QuickTimeComponents.component/
Contents/MacOS/QuickTimeComponents
0x9729d000 - 0x972d7fe7 com.apple.coreui 1.2 (62) /System/Library/
PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x972d8000 - 0x9735fff7 libsqlite3.0.dylib ??? (???)
<3334ea5af7a911637413334154bb4100> /usr/lib/libsqlite3.0.dylib
0x97360000 - 0x97360ffc com.apple.audio.units.AudioUnit 1.5 (1.5) /
System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0xfffe8000 - 0xfffebfff libobjc.A.dylib ??? (???) /usr/lib/
libobjc.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/
libSystem.B.dylib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2484 bytes
Desc: not available
Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090812/ead65cbc/smime-0001.bin
From mflatt at cs.utah.edu Wed Aug 12 10:32:43 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Wed Aug 12 10:33:05 2009
Subject: [plt-dev] JFYI OS X DrScheme core dump
In-Reply-To: <6C64A946-11A3-49D5-A7ED-61D14FEEDB48@brinckerhoff.org>
References: <6C64A946-11A3-49D5-A7ED-61D14FEEDB48@brinckerhoff.org>
Message-ID: <20090812143245.92B666500AC@mail-svr1.cs.utah.edu>
At Wed, 12 Aug 2009 10:07:53 -0400, John Clements wrote:
> DrScheme dumped core during GC, here's the CrashReporter stacktrace,
> ignore if not useful.
The trace includes
1 org.plt-scheme.PLT_MrEd 0x007385d5 cpointer_obj_MARK + 21
which is the GC tracing some pointer wrapped by the FFI. Were you
running some `scheme/foreign'-based code earlier? If so, my guess is
that it freed a C-level object without either clearing the associated
pointer object or ensuring that the object is inaccessible.
From matthias at ccs.neu.edu Wed Aug 12 10:52:03 2009
From: matthias at ccs.neu.edu (Matthias Felleisen)
Date: Wed Aug 12 10:52:53 2009
Subject: [plt-dev] problem with optimistic compilation
Message-ID:
Now that drscheme compiles things behind my back, I am encountering a
new problem al the time.
1. I have a fair number of scripts. Usually I run them with
mzscheme ... or mred ... or it may even have the right Unix
incantations in the file.
2. I also tend to use auxiliary files and my own small private
collects of auxiliaries.
3. On some occasion (I thought it was rare but it happens often
enough since the switch for me to notice) I open these scripts in drs
and run them. Now the aux files are compiled.
4. I regularly update my plt installation from source (say 3-4 times
per week; usually every day).
5. Oops, I can no longer run the scripts because the compiled files
are version n-1.
I'll just stick to describing the problem here, just in case there's
an obvious solution. -- Matthias
From clements at brinckerhoff.org Wed Aug 12 11:19:02 2009
From: clements at brinckerhoff.org (John Clements)
Date: Wed Aug 12 11:19:26 2009
Subject: [plt-dev] JFYI OS X DrScheme core dump
In-Reply-To: <20090812143245.92B666500AC@mail-svr1.cs.utah.edu>
References: <6C64A946-11A3-49D5-A7ED-61D14FEEDB48@brinckerhoff.org>
<20090812143245.92B666500AC@mail-svr1.cs.utah.edu>
Message-ID:
On Aug 12, 2009, at 10:32 AM, Matthew Flatt wrote:
> At Wed, 12 Aug 2009 10:07:53 -0400, John Clements wrote:
>> DrScheme dumped core during GC, here's the CrashReporter stacktrace,
>> ignore if not useful.
>
> The trace includes
>
> 1 org.plt-scheme.PLT_MrEd 0x007385d5 cpointer_obj_MARK + 21
>
> which is the GC tracing some pointer wrapped by the FFI. Were you
> running some `scheme/foreign'-based code earlier? If so, my guess is
> that it freed a C-level object without either clearing the associated
> pointer object or ensuring that the object is inaccessible.
Absolutely, yes: libsndfile.
I should have seen this, thanks for the help.
John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2484 bytes
Desc: not available
Url : http://list.cs.brown.edu/pipermail/plt-dev/attachments/20090812/13aed6ba/smime.bin
From robby at eecs.northwestern.edu Wed Aug 12 11:42:14 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 11:42:31 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To:
References:
Message-ID: <932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
I see a few possibilities. I think that this is a problem specific to
people who work regularly with SVN, so we can expect such people to
have extra sophistication:
- (IMO, the second best option and one that is available now):
instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
file.ss".
- (IMO the best option): mzscheme should get a commandline option
that amounts to doing the above for you automatically. So intead of
"mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
something.
- disable automatic compilation in drscheme.
- (the saddest option): by default, have automatic compilation in
drscheme turned off by default
Robby
On Wed, Aug 12, 2009 at 9:52 AM, Matthias Felleisen wrote:
>
> Now that drscheme compiles things behind my back, I am encountering a new
> problem al the time.
>
> 1. I have a fair number of scripts. Usually I run them with mzscheme ... or
> mred ... or it may even have the right Unix incantations in the file.
>
> 2. I also tend to use auxiliary files and my own small private collects of
> auxiliaries.
>
> 3. On some occasion (I thought it was rare but it happens often enough since
> the switch for me to notice) I open these scripts in drs and run them. Now
> the aux files are compiled.
>
> 4. I regularly update my plt installation from source (say 3-4 times per
> week; usually every day).
>
> 5. Oops, I can no longer run the scripts because the compiled files are
> version n-1.
>
> I'll just stick to describing the problem here, just in case there's an
> obvious solution. -- Matthias
>
>
From matthias at ccs.neu.edu Wed Aug 12 11:44:37 2009
From: matthias at ccs.neu.edu (Matthias Felleisen)
Date: Wed Aug 12 11:45:35 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
Message-ID: <5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
Perhaps I am naive, but could mzscheme just automatically compile
files when it finds that compiled/ is out of date? or use the source
file instead?
On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
> I see a few possibilities. I think that this is a problem specific to
> people who work regularly with SVN, so we can expect such people to
> have extra sophistication:
>
> - (IMO, the second best option and one that is available now):
> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
> file.ss".
>
> - (IMO the best option): mzscheme should get a commandline option
> that amounts to doing the above for you automatically. So intead of
> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
> something.
>
> - disable automatic compilation in drscheme.
>
> - (the saddest option): by default, have automatic compilation in
> drscheme turned off by default
>
> Robby
>
> On Wed, Aug 12, 2009 at 9:52 AM, Matthias
> Felleisen wrote:
>>
>> Now that drscheme compiles things behind my back, I am
>> encountering a new
>> problem al the time.
>>
>> 1. I have a fair number of scripts. Usually I run them with
>> mzscheme ... or
>> mred ... or it may even have the right Unix incantations in the file.
>>
>> 2. I also tend to use auxiliary files and my own small private
>> collects of
>> auxiliaries.
>>
>> 3. On some occasion (I thought it was rare but it happens often
>> enough since
>> the switch for me to notice) I open these scripts in drs and run
>> them. Now
>> the aux files are compiled.
>>
>> 4. I regularly update my plt installation from source (say 3-4
>> times per
>> week; usually every day).
>>
>> 5. Oops, I can no longer run the scripts because the compiled
>> files are
>> version n-1.
>>
>> I'll just stick to describing the problem here, just in case
>> there's an
>> obvious solution. -- Matthias
>>
>>
From robby at eecs.northwestern.edu Wed Aug 12 11:47:32 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 11:47:51 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
Message-ID: <932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
Yes, it could. That's the second option I suggested below. I was more
conservative, tho, and suggested that it only be turned on with a
flag. But perhaps it should be disabled with a flag instead. I think
we probably want it off by default for the mzscheme binary, tho, since
mzscheme will inprinciple be running in all kinds of places that
shouldn't do things like write to the fileysystem.
Robby
On Wed, Aug 12, 2009 at 10:44 AM, Matthias
Felleisen wrote:
>
> Perhaps I am naive, but could mzscheme just automatically compile files when
> it finds that compiled/ is out of date? or use the source file instead?
>
>
> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>
>> I see a few possibilities. I think that this is a problem specific to
>> people who work regularly with SVN, so we can expect such people to
>> have extra sophistication:
>>
>> ?- (IMO, the second best option and one that is available now):
>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>> file.ss".
>>
>> ?- ?(IMO the best option): mzscheme should get a commandline option
>> that amounts to doing the above for you automatically. So intead of
>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>> something.
>>
>> ?- disable automatic compilation in drscheme.
>>
>> ?- (the saddest option): by default, have automatic compilation in
>> drscheme turned off by default
>>
>> Robby
>>
>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias Felleisen
>> wrote:
>>>
>>> Now that drscheme compiles things behind my back, I am encountering a new
>>> problem al the time.
>>>
>>> 1. I have a fair number of scripts. Usually I run them with mzscheme ...
>>> or
>>> mred ... or it may even have the right Unix incantations in the file.
>>>
>>> 2. I also tend to use auxiliary files and my own small private collects
>>> of
>>> auxiliaries.
>>>
>>> 3. On some occasion (I thought it was rare but it happens often enough
>>> since
>>> the switch for me to notice) I open these scripts in drs and run them.
>>> Now
>>> the aux files are compiled.
>>>
>>> 4. I regularly update my plt installation from source (say 3-4 times per
>>> week; usually every day).
>>>
>>> 5. Oops, I can no longer run the scripts because the compiled files are
>>> version n-1.
>>>
>>> I'll just stick to describing the problem here, just in case there's an
>>> obvious solution. -- Matthias
>>>
>>>
>
>
From matthias at ccs.neu.edu Wed Aug 12 11:49:14 2009
From: matthias at ccs.neu.edu (Matthias Felleisen)
Date: Wed Aug 12 11:49:58 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
Message-ID:
On Aug 12, 2009, at 11:47 AM, Robby Findler wrote:
> Yes, it could. That's the second option I suggested below. I was more
> conservative, tho, and suggested that it only be turned on with a
> flag. But perhaps it should be disabled with a flag instead. I think
> we probably want it off by default for the mzscheme binary, tho, since
> mzscheme will inprinciple be running in all kinds of places that
> shouldn't do things like write to the fileysystem.
That's why I said 'use source'.
I like this best. (And yes, I am an svn user and by golly I can get
around this, but I wouldn't be surprised if this could happen to
'regular' people.)
-- Matthias
>
> Robby
>
> On Wed, Aug 12, 2009 at 10:44 AM, Matthias
> Felleisen wrote:
>>
>> Perhaps I am naive, but could mzscheme just automatically compile
>> files when
>> it finds that compiled/ is out of date? or use the source file
>> instead?
>>
>>
>> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>>
>>> I see a few possibilities. I think that this is a problem
>>> specific to
>>> people who work regularly with SVN, so we can expect such people to
>>> have extra sophistication:
>>>
>>> - (IMO, the second best option and one that is available now):
>>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>>> file.ss".
>>>
>>> - (IMO the best option): mzscheme should get a commandline option
>>> that amounts to doing the above for you automatically. So intead of
>>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>>> something.
>>>
>>> - disable automatic compilation in drscheme.
>>>
>>> - (the saddest option): by default, have automatic compilation in
>>> drscheme turned off by default
>>>
>>> Robby
>>>
>>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias
>>> Felleisen
>>> wrote:
>>>>
>>>> Now that drscheme compiles things behind my back, I am
>>>> encountering a new
>>>> problem al the time.
>>>>
>>>> 1. I have a fair number of scripts. Usually I run them with
>>>> mzscheme ...
>>>> or
>>>> mred ... or it may even have the right Unix incantations in the
>>>> file.
>>>>
>>>> 2. I also tend to use auxiliary files and my own small private
>>>> collects
>>>> of
>>>> auxiliaries.
>>>>
>>>> 3. On some occasion (I thought it was rare but it happens often
>>>> enough
>>>> since
>>>> the switch for me to notice) I open these scripts in drs and run
>>>> them.
>>>> Now
>>>> the aux files are compiled.
>>>>
>>>> 4. I regularly update my plt installation from source (say 3-4
>>>> times per
>>>> week; usually every day).
>>>>
>>>> 5. Oops, I can no longer run the scripts because the compiled
>>>> files are
>>>> version n-1.
>>>>
>>>> I'll just stick to describing the problem here, just in case
>>>> there's an
>>>> obvious solution. -- Matthias
>>>>
>>>>
>>
>>
From robby at eecs.northwestern.edu Wed Aug 12 11:55:09 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 11:55:28 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To:
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
Message-ID: <932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
On Wed, Aug 12, 2009 at 10:49 AM, Matthias
Felleisen wrote:
>
> On Aug 12, 2009, at 11:47 AM, Robby Findler wrote:
>
>> Yes, it could. That's the second option I suggested below. I was more
>> conservative, tho, and suggested that it only be turned on with a
>> flag. But perhaps it should be disabled with a flag instead. I think
>> we probably want it off by default for the mzscheme binary, tho, since
>> mzscheme will inprinciple be running in all kinds of places that
>> shouldn't do things like write to the fileysystem.
>
> That's why I said 'use source'.
I have no idea what this means.
> I like this best. (And yes, I am an svn user and by golly I can get around
> this, but I wouldn't be surprised if this could happen to 'regular' people.)
This will happen to people who switch versions, so yeah, you're probably right.
Perhaps mzscheme should not signal errors for .zo files that are the
wrong verison, but instead just ignore them?
Robby
> -- Matthias
>
>
>
>
>
>
>>
>> Robby
>>
>> On Wed, Aug 12, 2009 at 10:44 AM, Matthias
>> Felleisen wrote:
>>>
>>> Perhaps I am naive, but could mzscheme just automatically compile files
>>> when
>>> it finds that compiled/ is out of date? or use the source file instead?
>>>
>>>
>>> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>>>
>>>> I see a few possibilities. I think that this is a problem specific to
>>>> people who work regularly with SVN, so we can expect such people to
>>>> have extra sophistication:
>>>>
>>>> ?- (IMO, the second best option and one that is available now):
>>>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>>>> file.ss".
>>>>
>>>> ?- ?(IMO the best option): mzscheme should get a commandline option
>>>> that amounts to doing the above for you automatically. So intead of
>>>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>>>> something.
>>>>
>>>> ?- disable automatic compilation in drscheme.
>>>>
>>>> ?- (the saddest option): by default, have automatic compilation in
>>>> drscheme turned off by default
>>>>
>>>> Robby
>>>>
>>>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias
>>>> Felleisen
>>>> wrote:
>>>>>
>>>>> Now that drscheme compiles things behind my back, I am encountering a
>>>>> new
>>>>> problem al the time.
>>>>>
>>>>> 1. I have a fair number of scripts. Usually I run them with mzscheme
>>>>> ...
>>>>> or
>>>>> mred ... or it may even have the right Unix incantations in the file.
>>>>>
>>>>> 2. I also tend to use auxiliary files and my own small private collects
>>>>> of
>>>>> auxiliaries.
>>>>>
>>>>> 3. On some occasion (I thought it was rare but it happens often enough
>>>>> since
>>>>> the switch for me to notice) I open these scripts in drs and run them.
>>>>> Now
>>>>> the aux files are compiled.
>>>>>
>>>>> 4. I regularly update my plt installation from source (say 3-4 times
>>>>> per
>>>>> week; usually every day).
>>>>>
>>>>> 5. Oops, I can no longer run the scripts because the compiled files are
>>>>> version n-1.
>>>>>
>>>>> I'll just stick to describing the problem here, just in case there's an
>>>>> obvious solution. -- Matthias
>>>>>
>>>>>
>>>
>>>
>
>
From fahree at gmail.com Wed Aug 12 11:55:51 2009
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed Aug 12 11:56:32 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
Message-ID: <653bea160908120855r32e204f3w24d09e9d9a0b58fa@mail.gmail.com>
What if you actively want to use two (or more) different versions of
PLT? Say, one for "stable" developments, one for experimenting with
the implementation?
If that scenario is improbable/unsupported, then automatic compilation
is probably the right thing.
If that scenario is probable/supported, then you might still
automatically compile, but put the compiled files in directories the
name of which identify the implementation.
(In CL, where people commonly use multiple implementations and
versions thereof, things like asdf-binary-locations, cl-launch, slime
or common-lisp-controller will indeed ensure that compiled files are
stored in a place that depends on the implementation and its version.)
[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Laziness is mother of Intelligence. Father unknown. [Rumor has it it's Greed.]
2009/8/12 Matthias Felleisen :
>
> Perhaps I am naive, but could mzscheme just automatically compile files when
> it finds that compiled/ is out of date? or use the source file instead?
>
>
> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>
>> I see a few possibilities. I think that this is a problem specific to
>> people who work regularly with SVN, so we can expect such people to
>> have extra sophistication:
>>
>> ?- (IMO, the second best option and one that is available now):
>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>> file.ss".
>>
>> ?- ?(IMO the best option): mzscheme should get a commandline option
>> that amounts to doing the above for you automatically. So intead of
>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>> something.
>>
>> ?- disable automatic compilation in drscheme.
>>
>> ?- (the saddest option): by default, have automatic compilation in
>> drscheme turned off by default
>>
>> Robby
>>
>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias Felleisen
>> wrote:
>>>
>>> Now that drscheme compiles things behind my back, I am encountering a new
>>> problem al the time.
>>>
>>> 1. I have a fair number of scripts. Usually I run them with mzscheme ...
>>> or
>>> mred ... or it may even have the right Unix incantations in the file.
>>>
>>> 2. I also tend to use auxiliary files and my own small private collects
>>> of
>>> auxiliaries.
>>>
>>> 3. On some occasion (I thought it was rare but it happens often enough
>>> since
>>> the switch for me to notice) I open these scripts in drs and run them.
>>> Now
>>> the aux files are compiled.
>>>
>>> 4. I regularly update my plt installation from source (say 3-4 times per
>>> week; usually every day).
>>>
>>> 5. Oops, I can no longer run the scripts because the compiled files are
>>> version n-1.
>>>
>>> I'll just stick to describing the problem here, just in case there's an
>>> obvious solution. -- Matthias
From d.j.gurnell at gmail.com Wed Aug 12 12:14:58 2009
From: d.j.gurnell at gmail.com (Dave Gurnell)
Date: Wed Aug 12 12:15:19 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <653bea160908120855r32e204f3w24d09e9d9a0b58fa@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<653bea160908120855r32e204f3w24d09e9d9a0b58fa@mail.gmail.com>
Message-ID: <6BB25D81-2AA9-4B07-8CCE-81DD412914FC@gmail.com>
> What if you actively want to use two (or more) different versions of
> PLT? Say, one for "stable" developments, one for experimenting with
> the implementation?
I do this a fair bit, and my code is big enough to make compilation a
practical necessity. I use the mzc && mzscheme solution.
However, there are still some oddities. I have loads of dev links to
PLaneT packages, and those have to be recompiled too.
Sometimes (not sure what the trigger for this is) mzc doesn't follow the
dependencies properly and I have to some bytecode nuking to get things
working.
> If that scenario is probable/supported, then you might still
> automatically compile, but put the compiled files in directories the
> name of which identify the implementation.
This is something I'd be very much in favour of. I think it would fix
all of
the above problems.
Cheers,
-- Dave
From fahree at gmail.com Wed Aug 12 12:25:47 2009
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Wed Aug 12 12:33:17 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <6BB25D81-2AA9-4B07-8CCE-81DD412914FC@gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<653bea160908120855r32e204f3w24d09e9d9a0b58fa@mail.gmail.com>
<6BB25D81-2AA9-4B07-8CCE-81DD412914FC@gmail.com>
Message-ID: <653bea160908120925m54caa2b0ta2b360126f77448a@mail.gmail.com>
One more thing -- because bugs happen in the application,
implementation or underlying system, I have found that atomicity in
filesystem operations is very useful in avoiding corrupt half-compiled
objects that pollute the build in ways that the user doesn't always
suspect (and therefore spends countless hours chasing).
Lacking a transaction interface to the filesystem from the OS, you can
cheaply achieve atomicity in the creation of object files by first
non-atomically creating an object file with a temporary name (such as
foo.o.tmp or foo.o.tmp-$HOSTNAME-$PID-$TIMESTAMP) and atomically
rename it when it is complete (bonus if you check whether it creates
any change, and abort the new file if no change was necessary - you'll
play much nicer with timestamp-based dependency managers).
In my experience, implementing such a technique is cheap, and leads to
much more robust (and faster) incremental building of large systems.
(I haven't checked, so maybe PLT already does that in which case,
congratulations!)
[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The program isn't debugged until the last user is dead.
2009/8/12 Dave Gurnell :
>> What if you actively want to use two (or more) different versions of
>> PLT? Say, one for "stable" developments, one for experimenting with
>> the implementation?
>
> I do this a fair bit, and my code is big enough to make compilation a
> practical necessity. I use the mzc && mzscheme solution.
>
> However, there are still some oddities. I have loads of dev links to
> PLaneT packages, and those have to be recompiled too.
>
> Sometimes (not sure what the trigger for this is) mzc doesn't follow the
> dependencies properly and I have to some bytecode nuking to get things
> working.
>
>> If that scenario is probable/supported, then you might still
>> automatically compile, but put the compiled files in directories the
>> name of which identify the implementation.
>
> This is something I'd be very much in favour of. I think it would fix all of
> the above problems.
>
> Cheers,
>
> -- Dave
>
> _________________________________________________
> ?For list-related administrative tasks:
> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
From ryanc at ccs.neu.edu Wed Aug 12 12:57:57 2009
From: ryanc at ccs.neu.edu (Ryan Culpepper)
Date: Wed Aug 12 12:58:21 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
Message-ID:
On Aug 12, 2009, at 11:55 AM, Robby Findler wrote:
>
> Perhaps mzscheme should not signal errors for .zo files that are the
> wrong verison, but instead just ignore them?
Yes!
+1
Actually, is there something one can put in .mzschemerc to load the
compilation manager? Would that also fix the problem (although with
many more recompilations)?
Ryan
From robby at eecs.northwestern.edu Wed Aug 12 13:49:56 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 13:50:15 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To:
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
Message-ID: <932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
On Wed, Aug 12, 2009 at 11:57 AM, Ryan Culpepper wrote:
> Actually, is there something one can put in .mzschemerc to load the
> compilation manager? Would that also fix the problem (although with many
> more recompilations)?
Yes, there is. This is essentially what the flag I was suggesting
would turn on. I forget the exact name, but it is in the compiler/cm
library and should be obvious.
Robby
From robby at eecs.northwestern.edu Wed Aug 12 15:44:38 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 15:44:58 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
Message-ID: <932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
Okay, after some more thought and offline consultation, I've changed
the way DrScheme works wrt to saving compiled .zo files. It now saves
its compiled files in compiled/drscheme/ (and
compiled/drscheme/errortrace), meaning that the files will be ignored
when mzscheme runs. It also only looks in those directories when it is
in compiled-file-generation mode.
Robby
From matthias at ccs.neu.edu Wed Aug 12 15:50:57 2009
From: matthias at ccs.neu.edu (Matthias Felleisen)
Date: Wed Aug 12 15:51:41 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
Message-ID: <8EFA904D-3752-4472-91E6-F51EA4DCE826@ccs.neu.edu>
Thanks. Nice and fast service, as always :-)
On Aug 12, 2009, at 3:44 PM, Robby Findler wrote:
> Okay, after some more thought and offline consultation, I've changed
> the way DrScheme works wrt to saving compiled .zo files. It now saves
> its compiled files in compiled/drscheme/ (and
> compiled/drscheme/errortrace), meaning that the files will be ignored
> when mzscheme runs. It also only looks in those directories when it is
> in compiled-file-generation mode.
>
> Robby
From samth at ccs.neu.edu Wed Aug 12 17:21:47 2009
From: samth at ccs.neu.edu (Sam TH)
Date: Wed Aug 12 17:22:09 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
Message-ID: <63bb19ae0908121421j36d716cbqf59d4ca48a55e9db@mail.gmail.com>
What if mzscheme-compiled files already exist? Does it use those? If
it doesn't, won't it recompile the entire collects tree the first time
you try to do anything?
Also, this seems like it's papering over the problem. We should be
able to come up with a solution that works for both DrScheme and
mzscheme.
On Wed, Aug 12, 2009 at 3:44 PM, Robby
Findler wrote:
> Okay, after some more thought and offline consultation, I've changed
> the way DrScheme works wrt to saving compiled .zo files. It now saves
> its compiled files in compiled/drscheme/ (and
> compiled/drscheme/errortrace), meaning that the files will be ignored
> when mzscheme runs. It also only looks in those directories when it is
> in compiled-file-generation mode.
>
> Robby
> _________________________________________________
> ?For list-related administrative tasks:
> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
--
sam th
samth@ccs.neu.edu
From eli at barzilay.org Wed Aug 12 17:45:54 2009
From: eli at barzilay.org (Eli Barzilay)
Date: Wed Aug 12 17:46:15 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
Message-ID: <19075.14354.813640.99649@winooski.ccs.neu.edu>
On Aug 12, Robby Findler wrote:
> Okay, after some more thought and offline consultation, I've changed
> the way DrScheme works wrt to saving compiled .zo files. It now
> saves its compiled files in compiled/drscheme/ (and
> compiled/drscheme/errortrace), meaning that the files will be
> ignored when mzscheme runs. It also only looks in those directories
> when it is in compiled-file-generation mode.
Won't this have the same problem with multiple versions of drscheme
using the same file?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
From robby at eecs.northwestern.edu Wed Aug 12 19:47:04 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 19:47:23 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <19075.14354.813640.99649@winooski.ccs.neu.edu>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<19075.14354.813640.99649@winooski.ccs.neu.edu>
Message-ID: <932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
On Wed, Aug 12, 2009 at 4:45 PM, Eli Barzilay wrote:
> On Aug 12, Robby Findler wrote:
>> Okay, after some more thought and offline consultation, I've changed
>> the way DrScheme works wrt to saving compiled .zo files. It now
>> saves its compiled files in compiled/drscheme/ (and
>> compiled/drscheme/errortrace), meaning that the files will be
>> ignored when mzscheme runs. It also only looks in those directories
>> when it is in compiled-file-generation mode.
>
> Won't this have the same problem with multiple versions of drscheme
> using the same file?
Not unless there is a bug in CM; it should just recompile files when
they are out of date.
Robby
From robby at eecs.northwestern.edu Wed Aug 12 19:49:34 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 19:49:51 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <63bb19ae0908121421j36d716cbqf59d4ca48a55e9db@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<63bb19ae0908121421j36d716cbqf59d4ca48a55e9db@mail.gmail.com>
Message-ID: <932b2f1f0908121649w1b1ddff3uf7365d87daa967b3@mail.gmail.com>
On Wed, Aug 12, 2009 at 4:21 PM, Sam TH wrote:
> What if mzscheme-compiled files already exist? ?Does it use those?
Yes. With preference given to the drscheme ones.
> If
> it doesn't, won't it recompile the entire collects tree the first time
> you try to do anything?
No, the "don't save any compiled files for anything in the collects
tree" caveat is still in place, as before.
> Also, this seems like it's papering over the problem. ?We should be
> able to come up with a solution that works for both DrScheme and
> mzscheme.
I'll leave this one to Matthew to try to explain. I think you're
probably wrong, but I'm not sure precisely why. It is a big hairy
mess.
I think the short version is that unless you're willing to take over
responsibility for this thing (which means, I think, compiler/cm -- I
can handle setting various parameters and loading the libraries into
drscheme) this line of inquiry won't go anywhere.
Robby
From eli at barzilay.org Wed Aug 12 21:33:15 2009
From: eli at barzilay.org (Eli Barzilay)
Date: Wed Aug 12 21:33:36 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<19075.14354.813640.99649@winooski.ccs.neu.edu>
<932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
Message-ID: <19075.27995.527296.935748@winooski.ccs.neu.edu>
On Aug 12, Robby Findler wrote:
> On Wed, Aug 12, 2009 at 4:45 PM, Eli Barzilay wrote:
> > On Aug 12, Robby Findler wrote:
> >> Okay, after some more thought and offline consultation, I've
> >> changed the way DrScheme works wrt to saving compiled .zo
> >> files. It now saves its compiled files in compiled/drscheme/ (and
> >> compiled/drscheme/errortrace), meaning that the files will be
> >> ignored when mzscheme runs. It also only looks in those
> >> directories when it is in compiled-file-generation mode.
> >
> > Won't this have the same problem with multiple versions of
> > drscheme using the same file?
>
> Not unless there is a bug in CM; it should just recompile files when
> they are out of date.
I'm talking about:
* Create a file
* Run in drscheme, creating a compiled version
* Update PLT to a newer version
* Run the file again -- so the compiled file is still newer, but has
the wrong version.
BTW, I tried to check it, but for some reason I don't get any
compilation to happen -- is there some option I'm forgetting?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
From robby at eecs.northwestern.edu Wed Aug 12 22:37:21 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Wed Aug 12 22:37:40 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <19075.27995.527296.935748@winooski.ccs.neu.edu>
References:
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<19075.14354.813640.99649@winooski.ccs.neu.edu>
<932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
<19075.27995.527296.935748@winooski.ccs.neu.edu>
Message-ID: <932b2f1f0908121937h530c7231ya5986c03d8d2d11b@mail.gmail.com>
On Wed, Aug 12, 2009 at 8:33 PM, Eli Barzilay wrote:
> On Aug 12, Robby Findler wrote:
>> On Wed, Aug 12, 2009 at 4:45 PM, Eli Barzilay wrote:
>> > On Aug 12, Robby Findler wrote:
>> >> Okay, after some more thought and offline consultation, I've
>> >> changed the way DrScheme works wrt to saving compiled .zo
>> >> files. It now saves its compiled files in compiled/drscheme/ (and
>> >> compiled/drscheme/errortrace), meaning that the files will be
>> >> ignored when mzscheme runs. It also only looks in those
>> >> directories when it is in compiled-file-generation mode.
>> >
>> > Won't this have the same problem with multiple versions of
>> > drscheme using the same file?
>>
>> Not unless there is a bug in CM; it should just recompile files when
>> they are out of date.
>
> I'm talking about:
>
> ?* Create a file
> ?* Run in drscheme, creating a compiled version
> ?* Update PLT to a newer version
> ?* Run the file again -- so the compiled file is still newer, but has
> ? ?the wrong version.
>
> BTW, I tried to check it, but for some reason I don't get any
> compilation to happen -- is there some option I'm forgetting?
The file has to be outside of the PLT tree, maybe?
What you're describing sounds like it would be a bug in CM. I was
under the impression that this particular bug does not exist in CM but
I may be wrong.
Robby
From eli at barzilay.org Wed Aug 12 23:01:06 2009
From: eli at barzilay.org (Eli Barzilay)
Date: Wed Aug 12 23:01:26 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121937h530c7231ya5986c03d8d2d11b@mail.gmail.com>
References:
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<19075.14354.813640.99649@winooski.ccs.neu.edu>
<932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
<19075.27995.527296.935748@winooski.ccs.neu.edu>
<932b2f1f0908121937h530c7231ya5986c03d8d2d11b@mail.gmail.com>
Message-ID: <19075.33266.5335.824879@winooski.ccs.neu.edu>
On Aug 12, Robby Findler wrote:
> On Wed, Aug 12, 2009 at 8:33 PM, Eli Barzilay wrote:
> > On Aug 12, Robby Findler wrote:
> >> On Wed, Aug 12, 2009 at 4:45 PM, Eli Barzilay wrote:
> >> > On Aug 12, Robby Findler wrote:
> >> >> Okay, after some more thought and offline consultation, I've
> >> >> changed the way DrScheme works wrt to saving compiled .zo
> >> >> files. It now saves its compiled files in compiled/drscheme/ (and
> >> >> compiled/drscheme/errortrace), meaning that the files will be
> >> >> ignored when mzscheme runs. It also only looks in those
> >> >> directories when it is in compiled-file-generation mode.
> >> >
> >> > Won't this have the same problem with multiple versions of
> >> > drscheme using the same file?
> >>
> >> Not unless there is a bug in CM; it should just recompile files when
> >> they are out of date.
> >
> > I'm talking about:
> >
> > ?* Create a file
> > ?* Run in drscheme, creating a compiled version
> > ?* Update PLT to a newer version
> > ?* Run the file again -- so the compiled file is still newer, but has
> > ? ?the wrong version.
> >
> > BTW, I tried to check it, but for some reason I don't get any
> > compilation to happen -- is there some option I'm forgetting?
>
> The file has to be outside of the PLT tree, maybe?
It was outside (I even tried to move it in, with no visible effect).
I just tried it again with no ~/.plt-scheme and didn't get a compiled
directory either.
> What you're describing sounds like it would be a bug in CM. I was
> under the impression that this particular bug does not exist in CM
> but I may be wrong.
I don't know what CM is doing, but I don't see any reason for it to
remove a newer file when the version doesn't match.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
From jos.koot at telefonica.net Thu Aug 13 06:23:36 2009
From: jos.koot at telefonica.net (Jos Koot)
Date: Thu Aug 13 06:26:21 2009
Subject: [plt-dev] Re: problem with optimistic compilation
References: <932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com><5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu><932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
Message-ID:
Hi,
'regular' applies to me, I think. I use PLT Scheme a rather simple way and nevertheless came accross the same problem. I frequently
update to the most recent PLT Scheme Full from http://pre.plt-scheme.org/installers/ (option 1). I run my modules by means of
DrScheme or by means of executables made by DrScheme's menu Scheme/Create Executable. It would be nice to have an option to
automatically recompile from source in case zo files do not correspond to the correct version, just like they are automatically
recompiled after the source has been modified.
Jos
----- Original Message -----
From: "Matthias Felleisen"
To: "Robby Findler"
Cc: "PLT Developers"
Sent: Wednesday, August 12, 2009 5:49 PM
Subject: [plt-dev] Re: problem with optimistic compilation
>
> On Aug 12, 2009, at 11:47 AM, Robby Findler wrote:
>
>> Yes, it could. That's the second option I suggested below. I was more
>> conservative, tho, and suggested that it only be turned on with a
>> flag. But perhaps it should be disabled with a flag instead. I think
>> we probably want it off by default for the mzscheme binary, tho, since
>> mzscheme will inprinciple be running in all kinds of places that
>> shouldn't do things like write to the fileysystem.
>
> That's why I said 'use source'.
>
> I like this best. (And yes, I am an svn user and by golly I can get around this, but I wouldn't be surprised if this could happen
> to 'regular' people.)
>
> -- Matthias
>
>
>
>
>
>
>>
>> Robby
>>
>> On Wed, Aug 12, 2009 at 10:44 AM, Matthias
>> Felleisen wrote:
>>>
>>> Perhaps I am naive, but could mzscheme just automatically compile files when
>>> it finds that compiled/ is out of date? or use the source file instead?
>>>
>>>
>>> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>>>
>>>> I see a few possibilities. I think that this is a problem specific to
>>>> people who work regularly with SVN, so we can expect such people to
>>>> have extra sophistication:
>>>>
>>>> - (IMO, the second best option and one that is available now):
>>>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>>>> file.ss".
>>>>
>>>> - (IMO the best option): mzscheme should get a commandline option
>>>> that amounts to doing the above for you automatically. So intead of
>>>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>>>> something.
>>>>
>>>> - disable automatic compilation in drscheme.
>>>>
>>>> - (the saddest option): by default, have automatic compilation in
>>>> drscheme turned off by default
>>>>
>>>> Robby
>>>>
>>>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias Felleisen
>>>> wrote:
>>>>>
>>>>> Now that drscheme compiles things behind my back, I am encountering a new
>>>>> problem al the time.
>>>>>
>>>>> 1. I have a fair number of scripts. Usually I run them with mzscheme ...
>>>>> or
>>>>> mred ... or it may even have the right Unix incantations in the file.
>>>>>
>>>>> 2. I also tend to use auxiliary files and my own small private collects
>>>>> of
>>>>> auxiliaries.
>>>>>
>>>>> 3. On some occasion (I thought it was rare but it happens often enough
>>>>> since
>>>>> the switch for me to notice) I open these scripts in drs and run them.
>>>>> Now
>>>>> the aux files are compiled.
>>>>>
>>>>> 4. I regularly update my plt installation from source (say 3-4 times per
>>>>> week; usually every day).
>>>>>
>>>>> 5. Oops, I can no longer run the scripts because the compiled files are
>>>>> version n-1.
>>>>>
>>>>> I'll just stick to describing the problem here, just in case there's an
>>>>> obvious solution. -- Matthias
>>>>>
>>>>>
>>>
>>>
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
From mflatt at cs.utah.edu Thu Aug 13 07:04:08 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Thu Aug 13 07:04:30 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <19075.33266.5335.824879@winooski.ccs.neu.edu>
References:
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<19075.14354.813640.99649@winooski.ccs.neu.edu>
<932b2f1f0908121647j4cbf70ddn26ba6effc48e651a@mail.gmail.com>
<19075.27995.527296.935748@winooski.ccs.neu.edu>
<932b2f1f0908121937h530c7231ya5986c03d8d2d11b@mail.gmail.com>
<19075.33266.5335.824879@winooski.ccs.neu.edu>
Message-ID: <20090813110410.9A08E6500B7@mail-svr1.cs.utah.edu>
At Wed, 12 Aug 2009 23:01:06 -0400, Eli Barzilay wrote:
> On Aug 12, Robby Findler wrote:
> > On Wed, Aug 12, 2009 at 8:33 PM, Eli Barzilay wrote:
> > > On Aug 12, Robby Findler wrote:
> > >> On Wed, Aug 12, 2009 at 4:45 PM, Eli Barzilay wrote:
> > >> > On Aug 12, Robby Findler wrote:
> > >> >> Okay, after some more thought and offline consultation, I've
> > >> >> changed the way DrScheme works wrt to saving compiled .zo
> > >> >> files. It now saves its compiled files in compiled/drscheme/ (and
> > >> >> compiled/drscheme/errortrace), meaning that the files will be
> > >> >> ignored when mzscheme runs. It also only looks in those
> > >> >> directories when it is in compiled-file-generation mode.
> > >> >
> > >> > Won't this have the same problem with multiple versions of
> > >> > drscheme using the same file?
> > >>
> > >> Not unless there is a bug in CM; it should just recompile files when
> > >> they are out of date.
> > >
> > > I'm talking about:
> > >
> > > ?* Create a file
> > > ?* Run in drscheme, creating a compiled version
> > > ?* Update PLT to a newer version
> > > ?* Run the file again -- so the compiled file is still newer, but has
> > > ? ?the wrong version.
> > >
> > > [...]
>
> I don't know what CM is doing, but I don't see any reason for it to
> remove a newer file when the version doesn't match.
See `compiler/cm'. The version number of a compiled file is recorded in
".dep", and if it doesn't match (or if the ".dep" file doesn't exist),
then the file is recompiled.
From robby at eecs.northwestern.edu Thu Aug 13 07:47:03 2009
From: robby at eecs.northwestern.edu (Robby Findler)
Date: Thu Aug 13 07:47:25 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To:
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
Message-ID: <932b2f1f0908130447m7034c55dh8602134cf790870e@mail.gmail.com>
I assume you're creating "launcher" style executables, not
distributions or stand-alone executables?
The change I committed yesterday should help, then.
Robby
On Thu, Aug 13, 2009 at 5:23 AM, Jos Koot wrote:
> Hi,
> 'regular' applies to me, I think. I use PLT Scheme a rather simple way and
> nevertheless came accross the same problem. I frequently update to the most
> recent PLT Scheme Full from http://pre.plt-scheme.org/installers/ (option
> 1). I run my modules by means of DrScheme or by means of executables made by
> DrScheme's menu Scheme/Create Executable. It would be nice to have an option
> to automatically recompile from source in case zo files do not correspond to
> the correct version, just like they are automatically recompiled after the
> source has been modified.
> Jos
>
> ----- Original Message ----- From: "Matthias Felleisen"
>
> To: "Robby Findler"
> Cc: "PLT Developers"
> Sent: Wednesday, August 12, 2009 5:49 PM
> Subject: [plt-dev] Re: problem with optimistic compilation
>
>
>>
>> On Aug 12, 2009, at 11:47 AM, Robby Findler wrote:
>>
>>> Yes, it could. That's the second option I suggested below. I was more
>>> conservative, tho, and suggested that it only be turned on with a
>>> flag. But perhaps it should be disabled with a flag instead. I think
>>> we probably want it off by default for the mzscheme binary, tho, since
>>> mzscheme will inprinciple be running in all kinds of places that
>>> shouldn't do things like write to the fileysystem.
>>
>> That's why I said 'use source'.
>>
>> I like this best. (And yes, I am an svn user and by golly I can get
>> ?around this, but I wouldn't be surprised if this could happen to ?'regular'
>> people.)
>>
>> -- Matthias
>>
>>
>>
>>
>>
>>
>>>
>>> Robby
>>>
>>> On Wed, Aug 12, 2009 at 10:44 AM, Matthias
>>> Felleisen wrote:
>>>>
>>>> Perhaps I am naive, but could mzscheme just automatically compile ?files
>>>> when
>>>> it finds that compiled/ is out of date? or use the source file ?instead?
>>>>
>>>>
>>>> On Aug 12, 2009, at 11:42 AM, Robby Findler wrote:
>>>>
>>>>> I see a few possibilities. I think that this is a problem ?specific to
>>>>> people who work regularly with SVN, so we can expect such people to
>>>>> have extra sophistication:
>>>>>
>>>>> ?- (IMO, the second best option and one that is available now):
>>>>> instead of saying "mzscheme file.ss", say "mzc file.ss && mzscheme
>>>>> file.ss".
>>>>>
>>>>> ?- ?(IMO the best option): mzscheme should get a commandline option
>>>>> that amounts to doing the above for you automatically. So intead of
>>>>> "mzscheme file.ss" yo'd say "mzscheme --compile-zo file.ss" or
>>>>> something.
>>>>>
>>>>> ?- disable automatic compilation in drscheme.
>>>>>
>>>>> ?- (the saddest option): by default, have automatic compilation in
>>>>> drscheme turned off by default
>>>>>
>>>>> Robby
>>>>>
>>>>> On Wed, Aug 12, 2009 at 9:52 AM, Matthias
>>>>> ?Felleisen
>>>>> wrote:
>>>>>>
>>>>>> Now that drscheme compiles things behind my back, I am ?encountering a
>>>>>> new
>>>>>> problem al the time.
>>>>>>
>>>>>> 1. I have a fair number of scripts. Usually I run them with ?mzscheme
>>>>>> ...
>>>>>> or
>>>>>> mred ... or it may even have the right Unix incantations in the ?file.
>>>>>>
>>>>>> 2. I also tend to use auxiliary files and my own small private
>>>>>> ?collects
>>>>>> of
>>>>>> auxiliaries.
>>>>>>
>>>>>> 3. On some occasion (I thought it was rare but it happens often
>>>>>> ?enough
>>>>>> since
>>>>>> the switch for me to notice) I open these scripts in drs and run
>>>>>> ?them.
>>>>>> Now
>>>>>> the aux files are compiled.
>>>>>>
>>>>>> 4. I regularly update my plt installation from source (say 3-4 ?times
>>>>>> per
>>>>>> week; usually every day).
>>>>>>
>>>>>> 5. Oops, I can no longer run the scripts because the compiled ?files
>>>>>> are
>>>>>> version n-1.
>>>>>>
>>>>>> I'll just stick to describing the problem here, just in case ?there's
>>>>>> an
>>>>>> obvious solution. -- Matthias
>>>>>>
>>>>>>
>>>>
>>>>
>>
>> _________________________________________________
>> ?For list-related administrative tasks:
>> ?http://list.cs.brown.edu/mailman/listinfo/plt-dev
>>
>
>
>
From mflatt at cs.utah.edu Thu Aug 13 08:38:08 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Thu Aug 13 08:38:31 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <932b2f1f0908121649w1b1ddff3uf7365d87daa967b3@mail.gmail.com>
References:
<932b2f1f0908120842s7aeea0f6n522d94ed14214297@mail.gmail.com>
<5AA9A018-91F5-466C-9AA2-A372D7B29E62@ccs.neu.edu>
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<63bb19ae0908121421j36d716cbqf59d4ca48a55e9db@mail.gmail.com>
<932b2f1f0908121649w1b1ddff3uf7365d87daa967b3@mail.gmail.com>
Message-ID: <20090813123810.B26286500B7@mail-svr1.cs.utah.edu>
At Wed, 12 Aug 2009 18:49:34 -0500, Robby Findler wrote:
> On Wed, Aug 12, 2009 at 4:21 PM, Sam TH wrote:
> > What if mzscheme-compiled files already exist? ?Does it use those?
>
> Yes. With preference given to the drscheme ones.
>
> > If
> > it doesn't, won't it recompile the entire collects tree the first time
> > you try to do anything?
>
> No, the "don't save any compiled files for anything in the collects
> tree" caveat is still in place, as before.
>
> > Also, this seems like it's papering over the problem. ?We should be
> > able to come up with a solution that works for both DrScheme and
> > mzscheme.
>
> I'll leave this one to Matthew to try to explain. I think you're
> probably wrong, but I'm not sure precisely why. It is a big hairy
> mess.
And I'm not sure precisely why, either. This one of those areas where I
suffer from the same affliction as many sysadmins: to users, there are
many changes that would be obviously better, but I've been burnt by so
many obvious changes that I'm reluctant to try more. Lots of competing
demands have been balanced through a slow evolution, and then lots of
other strategies and techniques evolve to fit that design; I'm leary of
re-living it all for a different design point.
Here's an attempt to list relevant issues and competing demands on the
general issue of source and compiled files:
* Timestamps allow relatively efficient tracking of dependencies, but
timestamps are also somewhat fragile.
* There's a significant run-time cost to checking timestamps and/or
following a search path to locate the "best" version of a file.
* Search paths and other rules that can "fail" silently create
mystery. (Why does my program take so long to load? Oh, I need to
recompile file X.... But it is compiled, and the timestamp is later!
Oh, it's apparently the wrong version.)
* Some directories are writable and some are not. Some directories are
writable but aren't really intended to be modified.
* Sometimes `mzscheme' is used in development mode and sometimes in
execution mode. (Recall how we eventually learned that defaulting
development mode and requiring "-q" for execution mode was a bad
idea.)
* Sometimes files don't exist for required modules, even if they're
named through collection paths. (I have in mind the modules that are
in a `"stand-alone" executable.)
* Programs might be loaded concurrently on the same filesystem, and
synchronizing them is a pain, at best. (Are we at least past the
days of NFS, where you don't get the normal filesystem atomicity
guarantees?)
* Different versions might be used.
* Different compilation options might be used, and they may allow
different development and/or deployment possibilities. (For example,
`enter!' can re-load changed modules only when they are compiled
with `compile-enforce-module-constants' set to #f, but that same
setting has a negative effect on performance.)
* Sometimes different compilation options are used in the same
program, and the user needs some control over which modules use
which options. (Currently, our tools choose to do X or Y based on
whether a compiled file exists for a module.)
* Using multiple namespaces or other parameter-based configurations
can easily collide.
* Sometimes you want to refer to compiled files outside of PLT Scheme.
(For example, I often write makefiles that use `mzc' and then
trigger other actions based on the timestamp of the compiler file
--- and that would be more difficult if the compiled-file path were
version-specific, though maybe I should not be doing that in
makefiles.)
* When version-specific files are generated for and users upgrade
frequently, the filesystem can become littered with useless files
from old versions. (This bugs me about Planet, but it's all on one
place, so I can clean up easily enough.)
* Although there are many cases where changing a module forces
recompilation of importing module, there are also many cases where
the new module can be used from source without recompiling
everything that depends on it.
* Bootstrapping is tricky. (I sometimes get into trouble by using
`mzc' after I change a file in "collects/scheme" without recompiling
everything. Because of the way that compilation hooks into the
module-loading process, and because `mzc' itself uses the changed
files, running `mzc' multiple times doesn't converge in a nice way.)
* Some people want to distribute bytecode files without source.
I'm sure the list is incomplete, but that's all I can think of. In any
case, if someone believes that the current approach to bytecode files
is fundamentally wrong, the above list may be useful. My sense is that
a better approach is out there, but that it's only slightly better and
not worth the effort to get from here to there; then again, that sense
is based more on vague impressions from (limited) experience, rather
than any solid technical argument.
On the specific issue of how the changes in DrScheme relate to
MzScheme, though, I agree that the DrScheme capability should be
available in MzScheme in some sort of development mode. As Robby noted,
you can get `mzc'-like automatic compilation of files by adding
(require compiler/cm)
(current-load/use-compiled
(make-compilation-manager-load/use-compiled-handler))
to your ".mzschemerc". I think it would make sense to have DrScheme's
extra tools (i.e., to compile only sources not in the main "collects")
similarly available in library form.
From fahree at gmail.com Thu Aug 13 09:14:24 2009
From: fahree at gmail.com (=?ISO-8859-1?Q?Far=E9?=)
Date: Thu Aug 13 09:15:06 2009
Subject: [plt-dev] Re: problem with optimistic compilation
In-Reply-To: <20090813123810.B26286500B7@mail-svr1.cs.utah.edu>
References:
<932b2f1f0908120847u6febfe6at4ed1f6c7f2c67760@mail.gmail.com>
<932b2f1f0908120855k6ee328bdy5980595738d0e1c5@mail.gmail.com>
<932b2f1f0908121049h701a310euda7dcc5614ff0c20@mail.gmail.com>
<932b2f1f0908121244q4af104bbp8ef85c488f98e957@mail.gmail.com>
<63bb19ae0908121421j36d716cbqf59d4ca48a55e9db@mail.gmail.com>
<932b2f1f0908121649w1b1ddff3uf7365d87daa967b3@mail.gmail.com>
<20090813123810.B26286500B7@mail-svr1.cs.utah.edu>
Message-ID: <653bea160908130614w2b117443tb8922f5c0dd0f621@mail.gmail.com>
All of these issues would be solved if mzscheme had a *pure* approach
to managing compilation state: a given pathname, if naming an actual
file, should only possibly contain a uniquely identified content.
Example implementation (used by OMake?): the name of the object file
is a hash based on the name of the source file, the hash of its
contents, the hash of any other dependency read during compilation,
the hash of the implementation itself.
Simpler approximation (used by cl-launch): include the directory name
for your object cache the version of the implementation, the
architecture, the path of the source file, etc., and otherwise use
timestamps to detect that source files have changed.
Note that with a simple atomicity trick (atomic rename of a temporary
file) you also solve all the concurrency issues (e.g. NFS home
directory in which several versions of DrScheme run on multiple
machines try to share their cache).
Functional purity can make whole categories of problems disappear. Whodathunk?
[ Fran?ois-Ren? ?VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
When a pamphlet was published entitled "100 Authors Against Einstein", Einstein
retorted "If I were wrong, one would be enough."
2009/8/13 Matthew Flatt :
> At Wed, 12 Aug 2009 18:49:34 -0500, Robby Findler wrote:
>> On Wed, Aug 12, 2009 at 4:21 PM, Sam TH wrote:
>> > What if mzscheme-compiled files already exist? ?Does it use those?
>>
>> Yes. With preference given to the drscheme ones.
>>
>> > If
>> > it doesn't, won't it recompile the entire collects tree the first time
>> > you try to do anything?
>>
>> No, the "don't save any compiled files for anything in the collects
>> tree" caveat is still in place, as before.
>>
>> > Also, this seems like it's papering over the problem. ?We should be
>> > able to come up with a solution that works for both DrScheme and
>> > mzscheme.
>>
>> I'll leave this one to Matthew to try to explain. I think you're
>> probably wrong, but I'm not sure precisely why. It is a big hairy
>> mess.
>
> And I'm not sure precisely why, either. This one of those areas where I
> suffer from the same affliction as many sysadmins: to users, there are
> many changes that would be obviously better, but I've been burnt by so
> many obvious changes that I'm reluctant to try more. Lots of competing
> demands have been balanced through a slow evolution, and then lots of
> other strategies and techniques evolve to fit that design; I'm leary of
> re-living it all for a different design point.
>
> Here's an attempt to list relevant issues and competing demands on the
> general issue of source and compiled files:
>
> ?* Timestamps allow relatively efficient tracking of dependencies, but
> ? timestamps are also somewhat fragile.
>
> ?* There's a significant run-time cost to checking timestamps and/or
> ? following a search path to locate the "best" version of a file.
>
> ?* Search paths and other rules that can "fail" silently create
> ? mystery. (Why does my program take so long to load? Oh, I need to
> ? recompile file X.... But it is compiled, and the timestamp is later!
> ? Oh, it's apparently the wrong version.)
>
> ?* Some directories are writable and some are not. Some directories are
> ? writable but aren't really intended to be modified.
>
> ?* Sometimes `mzscheme' is used in development mode and sometimes in
> ? execution mode. (Recall how we eventually learned that defaulting
> ? development mode and requiring "-q" for execution mode was a bad
> ? idea.)
>
> ?* Sometimes files don't exist for required modules, even if they're
> ? named through collection paths. (I have in mind the modules that are
> ? in a `"stand-alone" executable.)
>
> ?* Programs might be loaded concurrently on the same filesystem, and
> ? synchronizing them is a pain, at best. (Are we at least past the
> ? days of NFS, where you don't get the normal filesystem atomicity
> ? guarantees?)
>
> ?* Different versions might be used.
>
> ?* Different compilation options might be used, and they may allow
> ? different development and/or deployment possibilities. (For example,
> ? `enter!' can re-load changed modules only when they are compiled
> ? with `compile-enforce-module-constants' set to #f, but that same
> ? setting has a negative effect on performance.)
>
> ?* Sometimes different compilation options are used in the same
> ? program, and the user needs some control over which modules use
> ? which options. (Currently, our tools choose to do X or Y based on
> ? whether a compiled file exists for a module.)
>
> ?* Using multiple namespaces or other parameter-based configurations
> ? can easily collide.
>
> ?* Sometimes you want to refer to compiled files outside of PLT Scheme.
> ? (For example, I often write makefiles that use `mzc' and then
> ? trigger other actions based on the timestamp of the compiler file
> ? --- and that would be more difficult if the compiled-file path were
> ? version-specific, though maybe I should not be doing that in
> ? makefiles.)
>
> ?* When version-specific files are generated for and users upgrade
> ? frequently, the filesystem can become littered with useless files
> ? from old versions. (This bugs me about Planet, but it's all on one
> ? place, so I can clean up easily enough.)
>
> ?* Although there are many cases where changing a module forces
> ? recompilation of importing module, there are also many cases where
> ? the new module can be used from source without recompiling
> ? everything that depends on it.
>
> ?* Bootstrapping is tricky. (I sometimes get into trouble by using
> ? `mzc' after I change a file in "collects/scheme" without recompiling
> ? everything. Because of the way that compilation hooks into the
> ? module-loading process, and because `mzc' itself uses the changed
> ? files, running `mzc' multiple times doesn't converge in a nice way.)
>
> ?* Some people want to distribute bytecode files without source.
>
> I'm sure the list is incomplete, but that's all I can think of. In any
> case, if someone believes that the current approach to bytecode files
> is fundamentally wrong, the above list may be useful. My sense is that
> a better approach is out there, but that it's only slightly better and
> not worth the effort to get from here to there; then again, that sense
> is based more on vague impressions from (limited) experience, rather
> than any solid technical argument.
>
>
> On the specific issue of how the changes in DrScheme relate to
> MzScheme, though, I agree that the DrScheme capability should be
> available in MzScheme in some sort of development mode. As Robby noted,
> you can get `mzc'-like automatic compilation of files by adding
>
> ?(require compiler/cm)
> ?(current-load/use-compiled
> ?(make-compilation-manager-load/use-compiled-handler))
>
> to your ".mzschemerc". I think it would make sense to have DrScheme's
> extra tools (i.e., to compile only sources not in the main "collects")
> similarly available in library form.
From mflatt at cs.utah.edu Thu Aug 13 12:24:27 2009
From: mflatt at cs.utah.edu (Matthew Flatt)
Date: Thu Aug 13 12:24:48 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <20090811161316.50C7B65008C@mail-svr1.cs.utah.edu>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<20090811161316.50C7B65008C@mail-svr1.cs.utah.edu>
Message-ID: <20090813162428.52C5A6500B9@mail-svr1.cs.utah.edu>
At Tue, 11 Aug 2009 10:13:15 -0600, Matthew Flatt wrote:
> > I'm not sure if
> > building .scrbl files is expected or not for -D, either, but my -D
> > builds always go through long compiles in some of my reference
> > documentation directories anyway.
>
> ".scrbl" files are compiled even if you supply -D, since -D currently
> only controls rendering. Now that you mention it, though, ".scrbl"
> files could be skipped when you supply -D, and I'll look into that
> change.
Done: -D now skips ".scrbl" files. More precisely, it ignores the
'scribblings' field of "info.ss".
From carl.eastlund at gmail.com Thu Aug 13 12:28:26 2009
From: carl.eastlund at gmail.com (Carl Eastlund)
Date: Thu Aug 13 12:29:04 2009
Subject: [plt-dev] setup-plt errors: in.sxref compiled for wrong version
In-Reply-To: <20090813162428.52C5A6500B9@mail-svr1.cs.utah.edu>
References: <990e0c030908110813t6c01126axfea0bddb4701a7e8@mail.gmail.com>
<20090811152245.6436A6500C7@mail-svr1.cs.utah.edu>
<990e0c030908110831q4833585agdf50d333b3edfb54@mail.gmail.com>
<20090811161316.50C7B65008C@mail-svr1.cs.utah.edu>
<20090813162428.52C5A6500B9@mail-svr1.cs.utah.edu>
Message-ID: <990e0c030908130928pe24ebcap660827e26f8d2613@mail.gmail.com>
On Thu, Aug 13, 2009 at 12:24 PM, Matthew Flatt wrote:
> At Tue, 11 Aug 2009 10:13:15 -0600, Matthew Flatt wrote:
>> > I'm not sure if
>> > building .scrbl files is expected or not for -D, either, but my -D
>> > builds always go through long compiles in some of my reference
>> > documentation directories anyway.
>>
>> ".scrbl" files are compiled even if you supply -D, since -D currently
>> only controls rendering. Now that you mention it, though, ".scrbl"
>> files could be skipped when you supply -D, and I'll look into that
>> change.
>
> Done: -D now skips ".scrbl" files. More precisely, it ignores the
> 'scribblings' field of "info.ss".
Thanks. This will probably speed up my incremental builds of Dracula IMMENSELY.
--Carl
From jos.koot at telefonica.net Thu Aug 13 16:31:48 2009
From: jos.koot at telefonica.net (Jos Koot)
Date: Thu Aug 13 16:32:20 2009
Subject: [plt-dev] Re: problem with optimistic compilation
References: