Re: (run-shell-command ) with output

[Arthur A. Gleckler]

See the subprocess options documented here:

https://www.gnu.org/software/mit-scheme/documentation/stable/mit-scheme-ref/Subprocess-Options.html

I hope that helps.

Re: Swiss AI FTP site

[Arthur A. Gleckler]

On Mon, May 22, 2023 at 12:04 AM Lassi Kortela  wrote:

> Is there a live instance or an archive of ftp.swiss.ai.mit.edu aka
> ftp-swiss.ai.mit.edu remaining somewhere? Neither of those two hostnames
> serves HTTP or FTP anymore.
>

I'm not sure.  What was there before?

MIT Scheme releases are served from https://ftp.gnu.org/gnu/mit-scheme/.

Re: Latin Phrases on exit

[Arthur A. Gleckler]

On Thu, Feb 16, 2023 at 11:51 AM Clive Tovero  wrote:

> "Cogito, ergo sum, cogito."  (For fun, someone with access to ChatGPT
> might ask it to translate this.)
>

Here is ChatGPT's reply:

The phrase "Cogito, ergo sum, cogito" is originally in Latin and is
famously attributed to the French philosopher René Descartes. It can be
translated to English as "I think, therefore I am, I think." The phrase is
often used to illustrate Descartes' idea of radical skepticism and his
argument for the existence of the self or the "I" as a necessary condition
for thinking.


But, despite the confidence of ChatGPT's answer, it isn't right.  Descartes
didn't include the second "cogito."  As someone quipped, this is
"mansplaining as a service."

Re: Latin Phrases on exit

[Arthur A. Gleckler]

On Thu, Feb 16, 2023 at 8:21 AM Patrick Heil 
wrote:


> My name is Patrick. I'm a college student who worked with the MIT Scheme
> Interpreter in a Comparative Programming Languages course. I noticed the
> interpreter would exit with latin phrases such as "Fortitudine vincimus."
> I wanted to learn more about these phrases and their meaning but couldn't
> find any reference to them in the user manual or online (only translations
> of the phrase from other sources).I assume the "Fortitudine vincimus." is
> a joke about the (alleged) tediousness of the Scheme programming language.
>
> Does anyone know anything about the background for these messages? Were
> they added in the original MIT Scheme interpreter or added later by the GNU
> devs?
>

Originally, there was just one Latin message: *moriturus te saluto*: "I who
am about to die salute you."  It was added by Guillermo Rozas in reference
to the phrase *morituri te saltamus*, "we who are about to die salute you,"
shouted to the Roman emperor by gladiators before they began to fight in an
arena (Wikipedia
).  The
idea is that the Scheme process, singular, salutes the user before dying.
Much later, there was debate over the correctness of the conversion from
third person to first person: bug report
.  We changed the verb ending, but
I'm still not sure whether that was necessary.

Years after the original message was added, new maintainers removed it,
then added it back with other messages, chosen randomly.  You can find them
all in the sources
.
Here are the Latin ones, with translations:

*Ceterum censeo Carthaginem esse delendam.*

However, I think that Carthage should be destroyed.

*Fortitudine vincimus.*

By endurance, we conquer.

*Post proelium, praemium.*

After the battle, the reward.

*Pulvis et umbra sumus.*

We are dust and shadow.

There's also "Happy happy joy joy!", from The Ren & Stimpy Show
, and "..#]^@^@^@ NO
CARRIER", the text often displayed when a dial-up modem disconnects. (MIT
Scheme was begun in the 1980s, when one connected to the internet over
dial-up modems and phone lines, often at 1200 bits per second.)

Thanks for asking. This was a fun bit of history to write up.

P.S.: Scheme is the opposite of tedious. (Others may differ, but I would
award that moniker to C++ or Java.)

[CFP] Scheme 2022, 23rd Scheme and Functional Programming Workshop

[Arthur A. Gleckler]

The 2022 Scheme and Functional Programming Workshop is calling for
submissions.

We invite high-quality papers and talk proposals about novel research
results, lessons learned from practical experience in an industrial or
educational setting, and even new insights on old ideas. We welcome and
encourage submissions that apply to any dynamic functional language,
especially those that can be considered a Scheme: from strict subsets of
RnRS to other "Scheme" implementations, to Racket, to Lisp dialects
including Clojure, Emacs Lisp, Common Lisp, to functional languages with
continuations and/or macros (or extended to have them) such as Dylan,
ECMAScript, Hop, Lua, Scala, Rust, etc. The elegance of the paper and the
relevance of its topic to the interests of Schemers will matter more than
the surface syntax of the examples used.
Topics

Topics of interest include (but are not limited to):

   - Interaction: program-development environments, debugging, testing,
   refactoring
   - Implementation: interpreters, compilers, tools, garbage collectors,
   benchmarks
   - Extension: macros, hygiene, domain-specific languages, reflection, and
   how such extension affects interaction
   - Expression: control, modularity, ad hoc and parametric polymorphism,
   types, aspects, ownership models, concurrency, distribution, parallelism,
   non-determinism, probabilism, and other programming paradigms
   - Integration: build tools, deployment, interoperation with other
   languages and systems
   - Formal semantics: theory, analyses and transformations, partial
   evaluation
   - Human factors: past, present and future history, evolution and
   sociology of the language Scheme, its standard and its dialects
   - Education: approaches, experiences, curricula
   - Applications: industrial uses of Scheme
   - Scheme pearls: elegant, instructive uses of Scheme

Dates

   - Submission deadline is 2022-07-22.
   - Authors will be notified by 2022-08-15.
   - Camera-ready versions are due 2022-09-02.
   - Workshop will be held in Ljubljana, Slovenia on 2022-09-16.

All deadlines are 23:59 UTC-12, anywhere on Earth.
Submission Information

We encourage all kinds of submissions, including full papers, experience
reports, and lightning talks. Papers and experience reports are expected to
be 10–24 pages in length using the single-column SIGPLAN acmart style. (For
reference, this is about 5–12 pages of the older SIGPLAN 2-column 9pt
style.) Abstracts submitted for lightning talks should be limited to 192
words.

Authors of each accepted submission are invited to attend and be available
for the presentation of that paper at the conference. The schedule for
presentations will be determined and shared with authors after the full
program has been selected.

The size limits above exclude references and any optional appendices. There
are no size limits on appendices, but the papers should stand without the
need to read them, and reviewers are not required to read them.

Authors are encouraged to publish any code associated to their papers under
an open source license, so that reviewers may try the code and verify the
claims.

Proceedings will be uploaded to arXiv.org.

Publication of a paper at this workshop is not intended to replace
conference or journal publication, and does not preclude re-publication of
a more complete or finished version of the paper at some later conference
or in a journal.

Please submit papers through the workshop's HotCRP site
<https://scheme2022.hotcrp.com/>.
Lightweight double-blind reviewing

Scheme 2022 will use lightweight double-blind reviewing. Submitted papers
must omit author names and institutions and reference the authors’ own
related work in the third person (e.g., not “we build on our previous
work…” but rather “we build on the work of…”).

The purpose is to help the reviewers come to an initial judgment about the
paper without bias, not to make it impossible for them to discover the
authors if they were to try. Nothing should be done in the name of
anonymity that weakens the submission or makes the job of reviewing the
paper more difficult (e.g., important background references should not be
omitted or anonymized).
Formatting Information

Full papers and experience reports should use the SIGPLAN acmsmall option
to acmart. We recommend using the anonymous and review options to acmart
when submitting a paper; these options hide the author names and enable
line numbers for easy reference in review. LaTeX and Microsoft Word
templates for this format are available through SIGPLAN
<https://www.sigplan.org/Resources/Author/>.

Lightning talks can be submitted as either a text file or a PDF file.
International Conference on Functional Programming

The Scheme Workshop 2022 is being held as part of this year's International
Conference on Functional Programming. Here is the ICFP site
<https://icfp22.sigplan.org/home/scheme-2022> for the workshop.

Sincerely,

Andy Kee

blog post "MIT Scheme on Apple Silicon (M1 Mac)"

[Arthur A. Gleckler]

I thought you might be interested in this detailed blog post on running MIT
Scheme on the Apple M1:

https://www.kennethfriedman.org/thoughts/2021/mit-scheme-on-apple-silicon/

Re: fix:lsh signedness

[Arthur A. Gleckler]

On Fri, Oct 30, 2020 at 4:59 PM Taylor R Campbell <
campbell+mit-sch...@mumble.net> wrote:


> - When Arthur originally documented the fix:lsh procedure in 1991
>   (bbc428a9), he documented arithmetic right shift semantics.
>

I'm pretty sure I don't deserve credit for that.  If you look at the rest
of that commit, you can see that I checked in the entire reference manual
and user manual.  I did contribute a bunch of documentation, including much
of the original debugging documentation, but I definitely didn't write both
of those manuals.  In fact, you can see "@author by Chris Hanson" in both
of them.

What to do?


Considering how frequently people have come to different interpretations of
the abbreviation lsh, perhaps it should be renamed to logical-shift or
something else unambiguous.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Sat, May 2, 2020 at 12:07 AM Chris Hanson  wrote:

> Interesting. Every time the reader is called it creates a hash table, but
> inserting it into the population of address-hash tables requires scanning
> the population to determine if it’s already there.
>

Aha!


> I’ll generate an alternative for the situation where the object being
> added is known to be new, thus avoiding the scan, and change the hash table
> implementation to use it. I’ll check other uses as well.
>
>
Thank you so much.  All of my code that uses read is fast again.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 11:30 PM Arthur A. Gleckler 
wrote:


> I'm not sure how to proceed.  Suggestions welcome.
>

Oh, the solution is obvious: I'll create that hash table lazily.

Sorry for the flood of email.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 10:02 PM Arthur A. Gleckler 
wrote:


> Now back to the performance problems.
>

I'm consistently finding that code that calls read gets slower and slower
until I call gc-flip, when it suddenly becomes faster again, but only for a
while.  Setting *parser-associate-positions?* to #f doesn't change this
behavior, but that was my first guess.

Using the profiler shows what appears to be a hot spot in eqv?, with a lot
of frames involving weak pairs.  After a GC, that hot spot goes from 273
samples to 2.  Stack sampler output attached.

Replacing the reader's make-shared-objects with a procedure that always
returns the same hash table eliminates the problem.  So it appears that the
construction of the table is a bottleneck.  Just calling
make-strong-eqv-hash-table in a loop 1000 times isn't slow (80ms), so it
does appear to increase GC pressure over time.

I'm not sure how to proceed.  Suggestions welcome.

Thanks.
1 ]=> (begin (with-stack-sampling 10 (lambda () (do ((i 0 (1+ i))) ((= i 1000)) 
(with-input-from-string "foo" read unspecific)

;Stack-sampling... done
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime dynamic), parameterize*
;-> (runtime dynamic), (lambda)
;-> (runtime dynamic), create-binding
;-> (runtime hash-table), (lambda), (let), make-method:get, method:get
;-> (runtime hash-table), compute-address-hash, (lambda), loop
; evaluating
;(key-hash key (vector-length (... table)))
; for ### in
;(let ((hash |###|)) (if (... table) (begin ... ...) hash))
;-> (runtime hash-table), protected-key-hash, (lambda)
; evaluating
;(key-hash key modulus)
; for ### in
;(let ((hash |###|))
;  (if (not ...) (error:wrong-type-datum hash "index integer"))
;  (if (not ...) (error:datum-out-of-range hash))
;  hash)
;1
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime reader), read-top-level, restart
;-> (runtime reader), initial-db
;-> (runtime hash-table), %make-hash-table, (let), (let)
; evaluating
;(if (and initial-size (&> initial-size 4)) (begin (... table initial-size) 
(... table #t)))
; for ### in
;(begin |###| (reset-table! table) (if (... type) (record-address-hash-table! 
table)) table)
;-> (runtime state-space), %execute-at-new-state-point, (let), (let)
; evaluating
;(%translate-to-state-point old-root)
; for ### in
;(begin |###| value)
;1
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime string-i/o-port), with-input-from-string
; evaluating
;(open-input-string string)
; for ### in
;(cons current-input-port |###|)
;-> (runtime string-i/o-port), open-input-string
; evaluating
;(let ((end ...)) (let (...) (make-textual-port string-input-type ...)))
;1
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime reader), read-top-level, (let)
;-> (runtime reader), dispatch, (let), (let)
;-> (runtime reader), handler:symbol
;-> (runtime reader), read-atom, (let)
;-> (runtime list), for-each, map-1
;-> (runtime string), %make-string-builder, (let), append-char!
; evaluating
;(fix:max max-cp (char-code char))
; for ### in
;(set! max-cp |###|)
;-> (runtime primitive-arithmetic), loop
; evaluating
;(fx>? n m)
; for ### in
;(if |###| n m)
;1
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime dynamic), parameterize*
; evaluating
;(fold-right (lambda (p bindings) (cons ... bindings)) bindings new-bindings)
; for ### in
;(let ((temp |###|)) (let (...) (shallow-fluid-bind swap! thunk swap!)))
;-> (runtime dynamic), (lambda)
; evaluating
;(create-binding (car p) (cdr p))
; for ### in
;(cons |###| bindings)
;1
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
; evaluating compiled code
;4
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime reader), read-top-level, restart
;-> (runtime reader), initial-db
;-> (runtime hash-table), %make-hash-table, (let), (let)
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
; evaluating compiled code
;-> (runtime weak-pair), weak-list-set-add!, (let), loop
; evaluating
;(if (weak-pair? this) (let (... ...) (cond ... ... ...)) (begin (%record-set! 
set 2 ...) #t))
;11
;
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime reader), read-top-level, restart
;-> (runtime reader), initial-db
;-> (runtime hash-table), %make-hash-table, (let), (let)
;-> #[compiled-return-address 29 ("wind" #xc) #x11f #xcd0553]
;-> (runtime weak-pair), weak-list-set-add!, (let), loop, (let)
; evaluating
;(= item item*)
; for ### in
;(if |###| #f (loop next this))
;-> (runtime equality), eqv?
; evaluating
;(or (eq? x y) (and (let ... ...) (let ... ...) (number:eqv? x y)))
;273
;
;Unspecified return value

1 ]=> 

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 9:57 PM Taylor R Campbell 
wrote:


> I don't trust maintainer-clean, because the makefiles aren't very good
> at being around at all the right times; I always use `git clean -dxn'
> (and review what it will delete to make sure it's nothing important)
> and then `git clean -dxf'.
>

That's great information!  Thanks.  I had been trying to accomplish that by
hand.

Now back to the performance problems.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 9:33 PM Arthur A. Gleckler 
wrote:


> The error I get is:
>
> ;Unable to find file "edwin.bld" because: File does not exist.
>
>
Removing src/edwin/stamp-scheme fixed the problem.  Should that have been
removed automatically by make distclean?  It is in .gitignore, so it's
hidden build state.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 7:30 PM Chris Hanson  wrote:

> If you’re running a 10.90 cross-compiled by 10.1.10, you should do a
> native compilation from 10.90 to 10.90. Otherwise gc-renamed-object? won’t
> be open-coded, which could affect performance.
>

Thanks for the idea.  I'm doing that now on all three of my systems.


> As for other problems from this transformation, I’m working on cleaning up
> the system-pair-car usages. But so far there’s nothing problematic in the
> runtime system. There are known problems in sos and edwin though.
>

There must be a bug somewhere in the runtime system since I encountered
that error without using Edwin or SOS.  Sorry, though, I didn't manage to
capture a stack trace.  I assumed that I would be able to reproduce it, so
I didn't save the first one, and I haven't seen it happen again.  If I see
it, I'll capture one this time.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 4:59 PM Taylor R Campbell 
wrote:


> > ;The object #[weak-cons 32], passed as the first argument to set-cdr!, is
> > not the correct type.
>
> Sounds like fallout from the weak pair #f -> #!reclaimed changes.
>

That's what I was thinking.  Unfortunately, I haven't been able to
reproduce that.

But the slowness is definitely reproducible.  I'm trying to winnow the
problem down a smaller test case, though — one that doesn't involve my
entire web server and application stack.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

Interestingly, the more times I run my now-slow code, the slower it gets,
and the slower the trivial test expression I sent earlier gets, too.

And threads-list is now broken:

1 ]=> (threads-list)

;The object #[weak-cons 32], passed as the first argument to set-cdr!, is
not the correct type.
;To continue, call RESTART with an option number:
; (RESTART 1) => Return to read-eval-print level 1.

2 error> (debug)

There are 13 subproblems on the stack.

Subproblem level: 0 (this is the lowest subproblem level)
Expression (from stack):
(set-cdr! #[weak-cons 32] #[weak-cons 33])
There is no current environment.
There is no execution history for this subproblem.
You are now in the debugger.  Type q to quit, ? for commands.

Investigating.

Re: `read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

On Fri, May 1, 2020 at 1:56 PM Arthur A. Gleckler 
wrote:


> and under 10.1.90 at HEAD:
>
> ;process time: 8150 (8150 RUN + 0 GC); real time: 8149
>
>
> Does anyone have a clue what might have caused this decline?
>

Naturally, once I sent my message to the list, the numbers under 10.1.90
got substantially better.  That's surprising because I haven't changed
anything at all.  I had narrowed down a huge performance degradation in my
own code to the use of read, but the results are inconsistent, so I'll have
to keep digging.

`read' is now >200x slower than under 9.2 and 10.1.10.

[Arthur A. Gleckler]

I haven't tracked down the cause, but in a trivial test case, read is more
than 200x slower under 10.1.90 than under 9.2 and 10.1.10:

Executing this form:

(show-time (lambda () (do ((i 0 (1+ i))) ((= i 1000))
(with-input-from-string "foo" read

here is the time under 9.2:

;process time: 30 (30 RUN + 0 GC); real time: 35

and under 10.1.10:

;process time: 40 (40 RUN + 0 GC); real time: 47


and under 10.1.90 at HEAD:

;process time: 8150 (8150 RUN + 0 GC); real time: 8149


Does anyone have a clue what might have caused this decline?

Re: installing Info documentation

[Arthur A. Gleckler]

On Thu, Apr 30, 2020 at 7:14 PM Taylor R Campbell 
wrote:


> cd mit-scheme/doc
> autoconf
> ./configure
> make
> make install
>

Thanks!

Amazingly, after all these years, I don't think I had ever run autoconf, at
least not manually.

installing Info documentation

[Arthur A. Gleckler]

What's the standard way to install Info documentation these days?  I see
doc/Makefile.in, but no Makefile nor .info files.

Thanks.

Re: *.bci missing

[Arthur A. Gleckler]

On Thu, Apr 30, 2020 at 12:12 AM Taylor R Campbell 
wrote:


> git pull and try again?
>

Thank you so much!  That worked.

Debugging is so much harder when almost every stack frame looks like this:

...
17   ;compiled code
18   ;compiled code
19   ;compiled code
20   ;compiled code
21   ;compiled code
22   ;compiled code
...

*.bci missing

[Arthur A. Gleckler]

*.bci files aren't installed when I do make install (sudo make install, in
fact).  I see bug 33898 , which
reports that they aren't installed, but in my case, they don't even seem to
have been generated, at least not in the directories where install expects
them, e.g. ~/mit-scheme/src/runtime.  There are *.bci files under
src/tools/runtime/, though.  Is this because I built with
--enable-cross-compiling?  I'd love to have debugging information for
compiled code again.

Thanks.

Re: Macro bug

[Arthur A. Gleckler]

On Wed, Feb 12, 2020 at 5:26 AM Joe Marshall  wrote:

> Macros don't seem to be hygienic in Release 10.1.10
> (define (quux) (display "quux") 'quux)
> (define (foo) (display "foo") #f)
>
> (define-syntax or2
>   (syntax-rules ()
> ((or2 form1 form2)
>  (let ((temp form1))
>(if temp
>temp
>form2)
>
> (let ((temp (quux))) (or2 (foo) temp))
> quuxfoo
> #f  ; Wrong! Should be 'quux
>

I just checked, and this returns quux as of HEAD (9f175968f).  (CPH has
made several macro fixes recently.)

dropped syntactic closure in 10.90

[Arthur A. Gleckler]

I've been trying to debug a macro that worked under 9.2.1 but fails under
10.90 (76bb84eaa).  I've narrowed the problem down to the following
reproducible test case:

(define-syntax bar
  (sc-macro-transformer
   (lambda (exp env)
 (let ((bindings (let ((sc (close-syntax (cadr exp) env)))
   (list sc sc
   `(let* (,bindings)
 'x)

(define-syntax bat
  (syntax-rules ()
((_ body ...)
 (let ((md 'quux))
   (bar md)

;; Under 9.2.1:

;; 1 ]=> (pp (lambda () (bat x)))
;; (lambda ()
;;   (let ((md 'quux))
;; (let ((md md))
;;   'x)))
;; ;Unspecified return value
;;
;; 1 ]=>

;; Under 10.90 (76bb84eaa):

;; 1 ]=> (pp (lambda () (bat x)))
;; (lambda ()
;;   (let ((.md.1-0 'quux))
;; (let ((.md.2-1 md))
;;   'x)))
;; ;Unspecified return value
;;
;; 1 ]=>

Note that the expansion under 10.90 means that (bat x) will fail because
the variable md will be unbound.

Is this a bug in macro expansion in 10.90, or was there a bug in 9.2.1 that
caused my macro to work there?  Or am I hopelessly confused?

Thanks.

Re: [MIT-Scheme-devel] Blowfish, MD5, mcrypt, mhash

[Arthur A. Gleckler]

On Thu, Nov 2, 2017 at 10:35 PM, Taylor R Campbell 
wrote:


> Merely _using_ MD5 or Blowfish in a protocol is risky!
>

Yes, of course.


> That said, I am pretty well acquainted with what goes into crypto
> implementation.
>

It sounds like you do.  Thank you in advance for doing the work.  I have
several [ersonal projects that would benefit from easy access to good,
simple crypto.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Blowfish, MD5, mcrypt, mhash

[Arthur A. Gleckler]

I like the idea, but isn't it generally accepted that writing one's own
crypto is risky?
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Fixes pushed

[Arthur A. Gleckler]

Chris Hanson  writes:

| The documentation is in a separate subdirectory from src/, so it's
| built differently:
>
| cd doc/
| autoconf
| ./configure
| make

Thanks.  I can't believe I didn't think of .

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Fixes pushed

[Arthur A. Gleckler]

Chris Hanson  writes:

| Note that I haven't yet updated the documentation to
| reflect these changes.  I'll get around to that soon.

I'm embarrassed to say that I can't figure out how to build
the documentation.  I've been following these steps to build
and install the system:

  make maintainer-clean
  ./Setup.sh
  ./configure
  make
  sudo make install

But the documentation is never built.

What step am I missing?

Thanks.

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] removal of top-level "TAGS" file

[Arthur A. Gleckler]

Chris Hanson  writes:

| Oops. I had generated my own TAGS file there and was
| surprised when it tried to check it in. I should have
| looked at the original contents.
>
| Go ahead and put it back.

Done.

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] reduce-right

[Arthur A. Gleckler]

Chris Hanson  writes:

| Yes thanks.

Done.

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] reduce-right

[Arthur A. Gleckler]

Hi, Chris.  In change de2cb85c, "Put reduce-right back," you
restored the implementation of `reduce-left' (not
`reduce-right').  However, that change didn't restore the
documentation for `reduce-left', which was removed in
5410eb4b.  Shall I restore that, too?





Thanks.

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] removal of top-level "TAGS" file

[Arthur A. Gleckler]

Hi, Chris.  In change e0429c04, "TAGS shouldn't be in
commit," you removed the top-level "TAGS" file.  Unlike
other "TAGS" files, that file was not a generated file.
Having it made it possible to do tags searches across the
whole source code tree at once, not just one directory at a
time.

May I please restore it?



___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Arthur A. Gleckler  wrote:
>
> Okay, I know what to do now --basically what you said, but now I have
> figured out the details.  It should help me with another refactoring I was
> already planning, too.  I'll report back with the results.
>
Okay, none of my code uses recursive locks any more, and the code is still
clear and simple.  In the process of making the change, I implemented lock
upgrade (read-to-write) and better concurrency in general for my graph
database, and my logging system is no longer tied to my web server by a
shared mutex, so it can be used by other code, too.condition-variable-wait!

Thank you for implementing condition variables, by the way.  That wasn't
present when I started, but made the database work much easier.

The biggest hurdle, other than thinking the lock upgrade design through
carefully, was spending the good part of an afternoon discovering that
`unlock-thread-mutex-and-wait' didn't lock the mutex upon exit, and that I
should be using `condition-variable-wait!' instead.  Oops.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Tuesday, June 9, 2015, Taylor R Campbell  wrote:


> There is an implementation of Concurrent ML for MIT Scheme and others
> at
>
> http://mumble.net/~campbell/darcs/scheme-cml
>
> which includes multiplexed waits on synchronous channels.  If any of
> you are interested in using it, feel free to ask me questions -- or if
> you'd like to pick it up and extend it, perhaps along the lines of the
> TODO at .
>

I remember talking with you about this long ago.  Very cool!  I've put it
on my list to study.


> But simply throwing out objects called `mutexes' does not absolve you
> of the need to design the conservation laws that mutexes represent in
> a complex program.
>
> If you adopt the Erlang dogma of storing all state `immutably' in
> separate processes, then each process's state has conservation laws
> implied by the behaviour of that process.  If you want conservation
> laws that apply to the state of two processes in aggregate, you likely
> need to have an arbiter process to enforce them -- and in so doing,
> you've just created three locks and a lock order between them.
>

I like the Erlang model very much.  If threads are cheap enough, they're
almost always preferable to locks.  But there are always some
high-performance cases where raw locks are necessary, I suppose.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Jun 8, 2015 10:04 PM, "Arthur A. Gleckler"  wrote:

> Still, when logging is used in the web server, the lock needs to reside
somewhere.  It shouldn't have to be passed around separately from the web
server, so I just incorporated it into the web server.

Okay, I know what to do now --basically what you said, but now I have
figured out the details.  It should help me with another refactoring I was
already planning, too.  I'll report back with the results.

Thanks again.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Taylor R Campbell  wrote:


>The log file is specific to the particular web server instance, so the
> lock
>that controls the log file belongs in the web server data structure.
>Having two locks opens the possibility of ordering problems.  Having
> just
>one eliminates that issue.
>
> Only if your logging routines need to get at the rest of the web
> server data structures.  If your logging routines are self-contained,
> the lock ordering issue is trivial and needn't even be mentioned --
> you could factor logging out into another library, like C stdio.
>

Still, when logging is used in the web server, the lock needs to reside
somewhere.  It shouldn't have to be passed around separately from the web
server, so I just incorporated it into the web server.


> (C stdio streams have locks too -- but you don't usually notice, even
> if you call printf while you hold some pthread_mutex, because you
> ~never have to write code that runs with the stdio stream locked.)
>

Interesting.

I'm not sure what interactions might happen at the Scheme level, though.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Taylor R Campbell  wrote:


>Saying "don't rely on it, it's not documented" in reference to an
>essential service is basically saying "our system is an unfinished
>toy, we're sorry you decided to use it".
>
> That is basically true of the thread system at least.
>

Yes, that's fair.


> I've reverted the change, and added a WITH-THREAD-MUTEX-LOCK that is
> just a dynamic-wind of LOCK-THREAD-MUTEX/UNLOCK-THREAD-MUTEX, which
> already rejected recursion.
>
> (The revert could conceivably be cherry-picked into the release-9.2
> branch for a 9.2.1 release.)
>

Thanks.

I'm actually running tip-of-tree, so this is just fine for me.


> I still strongly advise designing your locks to avoid recursion: in
> almost all cases it will make reasoning about and understanding your
> program easier; in the few cases that remain you probably need other
> semantics anyway.
>

I still intend to look over the code to see what I can do cleanly.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Alexey Radul  wrote:


> As to ecosystem stewardship, do we as a community have the need and
> resources to maintain a package repository, such as
> hackage.haskell.org, planet.racket-lang.org, or even interoperate with
> snow.iro.umontreal.ca ?  That seems a more basic step than permitting
> fear of potential unknown users' potential unknown uses of system
> internals for nefarious purposes [+] to impede progress.


Alex Shinn is working on a replacement for Snow
 and is already encouraging people to
use it to package things.  I haven't had a chance to try it, but am eager
to.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Taylor R Campbell  wrote:


> It sounds like you would be better served by having two locks: the web
> server's data structure lock, and the logging lock.  The logging lock
> can be internal to the logging routines, and need not be exposed
> elsewhere in the web server at all.
>

The log file is specific to the particular web server instance, so the lock
that controls the log file belongs in the web server data structure.
Having two locks opens the possibility of ordering problems.  Having just
one eliminates that issue.


>I'll look over my code again, but all the cases where I am using
> recursive
>mutexes are of that flavor.
>
> In my experience, the added error detection of rejecting recursive
> locks -- and the resulting pressure to make it clear what's locked
> where and why, and to identify invariants and distinguish unrelated
> ones -- outweighs the convenience of avoiding the extra
> FROBNICATE/LOCKED routine every once in a while.
>

Initially, I changed me code that way, but the result was repetitive and
ugly.  I revived my own recursive `with-thread-mutex-locked' in a new
procedure called `with-thread-mutex-locked-recursive'.  That way, it's at
least marked.

I'm prepared to believe that the tradeoff works as you suggest in more
complex cases, but in such simple ones as this, it appears to work the
other way.


> The few cases actually requiring nontrivial recursion tend to have
> much more nuanced requirements than the normal mutex API can provide,
> e.g. reader/writer semantics with cheap readers to support suspending
> all operations without adding overhead (particularly interprocessor
> synchronization) to every operation[1].


Yes, but I would certainly label these cases "trivial recursion."
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Alexey Radul  wrote:


> Respectfully, in general, users who rely on subtleties of the detailed
> semantics of undocumented procedures [*] should expect occasional
> incompatible changes.  And what communication channel do we have
> except postings on the devel mailing list?


Just for the record, I agree, and I apologize once again for not having
noticed that message on the list.

I am grateful to Taylor for all his work on MIT Scheme, and for making
improvements to the thread system, which I use heavily in my web server and
other projects.  This change caused me grief, but I shouldn't complain
because I didn't speak up when Taylor asked.

I still think I'm using recursive mutexes in a reasonable way, but Taylor's
comments have convinced me to review everything, just in case.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

On Monday, June 8, 2015, Taylor R Campbell > wrote:


> Hi, Arthur!  I asked the list last year whether anyone relied on it:
>
> https://lists.gnu.org/archive/html/mit-scheme-devel/2014-11/msg5.html
>
> Nobody replied that they relied on it, and since the thread system is
> undocumented I expected its use outside the tree to be limited.
>

Oops.  Sorry, I somehow I missed that.


> The reason I decided to do this is that it is practically always a
> mistake to rely on recursion: for each mutex, you should know whether
> or not you hold it at each point when you need access to the resource
> it protects, and you should know what other locks are held in order to
> determine a consistent lock order.
>

In each case where I'm using them, there really is only one lock, so lock
order is not an issue.  Other locks that are not part of the system and are
held by callers are not relevant because third-party code is never called
in the contexts of the sections those locks control.

I know, in each case, that I need access to the resource being protected.
That's why I'm acquiring the lock.  The only question is whether is has
already been acquired.


> Utility routines whose callers might or might not hold the lock are
> suspect and tend to suggest insufficiently considered design:  What is
> the invariant the lock provides?  If the caller doesn't need to hold
> the lock, why does the lock need to be there at all?
>

Here's an example: I have a web server whose internal data structures are
rarely mutated.  I use a lock to prevent conflicts.  I also use that lock
to serialize the server's write access to its logs.  My logging procedures
are sometimes called by the server while it holds the lock, and sometimes
when it doesn't already hold the lock.  Rather than have two variants of
each logging procedure, one that expects the lock to be held already and
one that acquires it, I used recursive locks.  Now I can't do that, at
least with what's built into MIT Scheme.


> There are legitimate cases where recursive locks make sense, but most
> uses are best served by a nonrecursive lock abstraction.  You can
> always build a recursive lock out of a nonrecursive lock and a
> condition variable.
>

That's more complicated and prone to error.

I'll look over my code again, but all the cases where I am using recursive
mutexes are of that flavor.

Anyway, thanks for the explanation, and sorry for missing your earlier
message.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] non-recursive mutexes

[Arthur A. Gleckler]

Hi, Taylor.  Long time, no see.  I hope all is well.

I'm just upgrading to MIT Scheme 9.2, and my code is breaking in several
places because of your change to Remove support for recursion in
WITH-THREAD-MUTEX-LOCKED
.
Can you tell me why you made that change?  I can't see a correctness or
performance advantage, and the change list comment gives no justification.
Not supporting recursion is a nuisance in cases where one has utility
procedures that may or may not be run in a context where the lock is
already held.

Thanks.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] A tellurion for the faithful.

[Arthur A. Gleckler]

On Mon, Apr 15, 2013 at 2:37 PM, Matt Birkholz  wrote:


> Thanks to Brother Arthur I was able to complete a simple hymn -- a
> tellurion:
>
> http://birkholz.chandler.az.us/tellurion.png
>

Beautiful!

All glory be to Scheme!
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Bottlenecks

[Arthur A. Gleckler]

>
> Fluid-let seems to be rather expensive, and this one is called a lot.
>

Would it be better to create an object to contain all those variables and
then pass it around instead?
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] History of MIT Scheme Through 27 Aug 2011 Visualized Using Gource

[Arthur A. Gleckler]

I've just put up a video of the history of MIT Scheme created using
Gource
:

  http://www.youtube.com/watch?v=3czU5kBFhNI

It covers 1987 through today.  It's amazing to see the complete history
animated in this way.

Make sure to watch at 720p and full screen.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] named parameters

[Arthur A. Gleckler]

Thanks.  I just read the Racket paper.  It's quite a nice system, and now I
see the advantages of their approach, e.g. #%app.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

[Arthur A. Gleckler]

>
> The branch direction change.  Before, on pretty much every entry to a
> non-leaf procedure, the CPU would see a backward branch and predict it
> taken by default, if there were no dynamic profile data to inform the
> branch predictor.  But almost all of the time, that branch -- to
> handle interrupts -- would not be taken.
>
> So basically every non-leaf procedure call would cause a branch
> misprediction.
>
> We have a similar issue with branch target prediction: we don't pair
> CALL and RET.  Fixing that would be considerably trickier, and doing
> it really effectively may require ABI changes.
>

Wow, that's amazing.  I've always heard that branch prediction makes a big
difference, but I suppose that it's rarely the case that the problem is
systemic.  I imagine that it's usually one or two here and there, not nearly
every one in the entire code base.

Nice hack!
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

[Arthur A. Gleckler]

>
> Rather than wait longer for any objections, I've just committed this
> together with a change to the i386 and x86-64 back ends to improve
> overall system performance by 20%, using the same unscientific tests.
> (Do a two-stage build to get the effect.)
>

20%?!  That's a lot.  What do you attribute that to?  Is it the branch
direction change, or the SYMBOL-NAME change, or something else?
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

[Arthur A. Gleckler]

>
> It's not semantically necessary, since Free_primitive is defined with
> static storage, but I agree that it's clearer that way; I'll do that.
>

Exactly.  It makes your intent clear.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] symbol names

[Arthur A. Gleckler]

>
> I don't have a particular suggestion for what to do, but this seems
> wrong.
>

I propose fixing these cases one by one as they are encountered.  I can't
see a systematic way to address them all that doesn't reduce our Unicode
support.

My biggest concern is that whatever we do doesn't break the XML support.  I
use the XML parser in my WebDAV code, and I have to go on a bug-hunting
expedition every other few months because that library changes its API.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] bookkeeping memory allocated per primitive

[Arthur A. Gleckler]

>
> Any objections to committing this?
>

None from me.  This is a clean, simple solution to what initially sounded
like a complicated problem.

My only suggestion is to initialize  to zero explicitly.
 That makes it clearer how this test works:

  if (Free_primitive < heap_start)

Otherwise, if someone calls  outside of a primitive before any
primitive is ever invoked, you're relying on this variable being initialized
to zero implicitly in order to detect that condition.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Faster ports.

[Arthur A. Gleckler]

>
> > `Byte' won't make any sense when we get the PDP-10 port working again.
>
> That very old joke is why you can't say "byte"?  You can't be serious.
>

Yes, we should stop worrying about that.  "Byte" means eight bits except in
history books, and that's that.  English evolves.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] primitives, interrupts, allocation, and robustness

[Arthur A. Gleckler]

>
> (a) If a primitive performs a permanent side effect, it may not use
> any system call afterward that could ever conceivably block.  This
> means eliminating (or at least deprecating) complex primitives such as
> FILE-TOUCH and replacing them by Scheme code.
>

This is my favorite suggestion.  I've always wanted to eliminate, or at
least minimize, the microcode primitives layer.  Sometimes they're needed,
but I'd prefer either to eliminate C code or to talk with it at arm's
length, e.g. via an inter-thread or inter-process mailbox mechanism, when it
isn't absolutely necessary to have it linked in for performance.

Thanks for the detailed analysis, by the way.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] named parameters

[Arthur A. Gleckler]

>
> Any comments?  I don't plan to integrate it into the system any time
> soon, but it might be nice to do some day when we have less broken
> macros and modules, like Racket.
>

This would be great.  I've only skimmed your code so far, but I plan to come
back to it after I've had a chance to read the Racket paper.

Would you care to expand upon the relationship between this and "less broken
macros and modules?"  I'm not disagreeing, at least on the modules front,
but would just like to hear more.

Thanks.
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] GTk+ in MIT-Scheme?

[Arthur A. Gleckler]

>
> Bless me, like-minded entities, for I have Schemed.
>

Two highly worthy hacks, I must say!  No sin at all!
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] MIT-Scheme 9.0.1 performance problem. (cont.)

[Arthur A. Gleckler]

> I am waiting for your notes then. Every hint is valuable for me.

Here's what I wrote in my notes:

  (load "~/tmp/macro-definition.scm")
  (fluid-let ((sf/default-syntax-table (->environment '(user
  (cf "~/tmp/macro-user.scm"))

This will make sure that the macros defined in "macro-definition" are
available to the compiler when it compiles "macro-user.scm".  It's
kludgy, but I just confirmed that it works.

Good luck!

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] MIT-Scheme 9.0.1 performance problem. (cont.)

[Arthur A. Gleckler]

>
> Hmm, it's a mess, I agree.
> Loading definer.scm before execution of (cf "luser.scm") does not
> help. I load the definer.scm, then compile the luser.scm and get the
> error. I read somewhere that the compiler uses only the predefined
> macros from the Scheme build (let's say included in all.com only). If
> it is like that I have to add my macros to the distribution and
> recompile the compiler. Then it should work.


I've forgotten the precise instructions, but I have some notes at home.
 I'll send them to you when I get home this evening (US Pacific time).
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] specifying hash table weakness

[Arthur A. Gleckler]

> (MAKE-x-HASH-TABLE*  #!OPTIONAL ),
>  x \in {EQ, EQV, EQUAL, STRING}

I wonder whether it makes sense to make X a parameter, too.  That
wouldn't prevent special treatment of EQ.

The other obvious possibility is to make a hash table constructor
maker, i.e. to curry the construction of hash tables, e.g.:

  ((make-hash-table-constructor comparator weakness) initial-size)

That requires the addition of the fewest new identifiers.  We can
watch to see which combinations are actually used and then make
shortcut identifiers for them.

Keep painting!

___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] make-eq-hash-table

[Arthur A. Gleckler]

> OK?

That's an excellent plan.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] make-eq-hash-table

[Arthur A. Gleckler]

> Comments?

I agree with your recommendation.

On a related note, in a recent build, I noticed some of my code
failing sporadically to find certain values in EQ hash tables.
Depending on the order in which the code was loaded, one particular
symbol value would be missing from one such table, which was used to
represent a set of symbols.  I haven't had a chance to track that
down.  I did spend a few hours trying to create a reproducible test
case, but failed.  Could this have been caused by the keys being held
weakly?  In this hash table, the keys are symbols and the values are
always #t.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> The last line overrides the default code generator which is i386 --
> incorrect for snow leopard, and perhaps the source of the problems
> here.

Yes, that did it for me.  Thanks.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> By the way, if your goal is just to build the latest Scheme, you can
> start with
>
> 
>
> by untarring it in $prefix and then running `./configure && make &&
> make install' in the microcode alone, without needing any prior Scheme
> system or a C build.

Cool.  Thanks.

For now, I'm running a build I did successfully on Snow Leopard in
early November.  But I'll do that when I need to get the latest.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> (vector-ref (gc-space-status) 0)

Result: 8.  (See attached transcript.)  So, alas, that looks right.
bash-3.2$ mit-scheme-c
MIT/GNU Scheme running under MacOSX
Type `^C' (control-C) followed by `H' to obtain information about interrupts.

Copyright (C) 1986, 1987, 1988, 1989, 1990, 1991, 1992, 1993, 1994,
1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008 Massachusetts Institute of Technology
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Image saved on Sunday December 6, 2009 at 6:07:54 PM
  Release 7.7.90.+ || Microcode 15.1 || Runtime 15.7 || SF 4.41 || LIAR/C 4.118
  Edwin 3.116

1 ]=> (vector-ref (gc-space-status) 0)

;Value: 8___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> And just to confirm one last detail, can you start up the 20090107
> version of Scheme with the C back end (i.e. the one you're using to
> buil the x86-64 version), and tell me the value of the following
> expression?
>
> (vector-ref (gc-space-status) 0)

No problem.  I'll check that tonight when I get home.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> Just to clarify: do you mean that you had the 20090107 snapshot with
> the C back end installed, and you fetched a clean Git repository, in
> which you ran Setup.sh and etc/make-native.sh?  And did it fail at the
> same time as for Derrell Piper as shown in his transcript?

Here are the steps I followed:

  1) I downloaded the 20090107 C back end ".tgz" file and installed
  it.

  2) I fetched a clean Git repository.

  3) I ran .  (I didn't run "Setup.sh" since
  "make-native.sh" does that.)

It failed at exactly the same place as it did for Derrell:

  ;  Compiling file: "crypto.bin" => "crypto.moc"...
  ;non-pointer datum out of range 288230376151711743

> I'll try again to reproduce this tomorrow.  However, I don't have
> access to any x86-64 machine running Snow Leopard; I can test it only
> under GNU/Linux.

I was able to build a native x86-64 version on Snow Leopard in
mid-November (but on a different machine), so I doubt that it's Snow
Leopard that makes the difference.  I wonder whether any of the recent
arithmetic fixes introduced a bug.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Re: missing "runtime-unx.c"

[Arthur A. Gleckler]

> If you have Scheme with the C back end installed, and you want to
> build Scheme with a native back end, run make-native.sh.

Alas, that doesn't work right now (";non-pointer datum out of range
288230376151711743").

> If you have Scheme with a native back end installed, and you want to
> build Scheme with the C back end, run make-liarc-dist.sh and then
> make-liarc.sh.  (You can tar up the directory after make-liarc-dist.sh
> and before make-liarc.sh to get a mit-scheme-c-MMDD.tar.gz tarball
> pretty much as the releases contain.)

Aha!  I didn't know about the  step.  Thanks.

Would it be reasonable to have  do that automatically
if it isn't already done?


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] building for X86_64 on OS X Snow Leopard (10.6)

[Arthur A. Gleckler]

> Hmm, I'm afraid I can't reproduce this -- but I don't have any
> machines running Snow Leopard to test on.  Can anyone who does
> reproduce this (using the 20090107 snapshot, which is what I have
> been using to bootstrap the x86-64 port)?

Yes, I was just able to reproduce this:

  ;non-pointer datum out of range 288230376151711743

I'm running on Snow Leopard with a just-compiled build of the released
C ".tgz" from 20090107.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] Re: missing "runtime-unx.c"

[Arthur A. Gleckler]

Is it actually possible to build starting with only an installed
20090107 binary and an up-to-date Git repository?  Or does one have to
build from a ".tgz" file for the 20090107 C release, then proceed?  I
thought that I had built on my Mac Pro without downloading the C
release, but neither "make-native.sh" nor "make-liarc.sh" works for me
today on my Mac Mini.  The former seems to depends on the existence of
 and the latter can't find "runtime-unx.c".  But I've
probably just forgotten that step in my current jet-lagged state.

I need to understand our build system better.  It's black magic to me right now.

In the meantime, I've managed to build the C back end from the ".tgz"
file for the C release.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] missing "runtime-unx.c"

[Arthur A. Gleckler]

I'm trying to build the latest MIT Scheme on an OS X 10.6 system and
running into a new problem.  I've run:

  ./Setup.sh
  ./configure
  sh etc/make-liarc.sh

The third command fails with:

  gcc -DHAVE_CONFIG_H -DMIT_SCHEME
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme/src/boot-root/lib/mit-scheme-c\"
-I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline -Wstrict-prototypes
-Wnested-externs -Wredundant-decls -Wextra -Wno-sign-compare
-Wno-unused-parameter -Wold-style-definition  -isysroot
/Developer/SDKs/MacOSX10.6.sdk -fconstant-cfstrings -o unstackify.o -c
unstackify.c
  make[1]: *** No rule to make target `../runtime/runtime-unx.c',
needed by `compinit.c'.  Stop.
  make: *** [compile-microcode] Error 2

This is with a fresh install of the 7 Jan 2009 distribution and a
fresh pull of the latest sources from the Git repository.

Does this ring any bells?  It's a new one for me.

Thanks.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] Recent Win32 microcode?

[Arthur A. Gleckler]

> I believe Chris is referring to microcode/cmpauxmd/i386-ntw.asm, which
> is generated when you run Setup.sh.

Here's mine, which is from 9 Nov.  Is that recent enough?


i386-ntw.asm
Description: Binary data
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

[Arthur A. Gleckler]

>    CFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" etc/make-liarc.sh

Hurrah!  That did it.  Once that built, I was able to build the native
x64-64 version.

Thanks again to you both.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

[Arthur A. Gleckler]

> There may be other lurking space-sensitive `pathname' arguments among
> the scripts -- you could also try renaming the directory from `MIT
> Scheme' to `mit-scheme' or something without any spaces in it.

Gee whiz.  Sorry to bother you with such a trivial problem.  I had
built successfully earlier, then had archived the directory under a
directory with a space in its name without noticing the space.

Now that I've renamed the directory, it's building now.

Thanks again.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

[Arthur A. Gleckler]

> Thank you!  I didn't do that, but will try it now.

Alas, I didn't get far.  (See attached.)

It appears that  on OS X expects ,  or  as the
value of <-arch>.  But that doesn't seem to be what this error is
complaining about.

I have machines running 10.6 at home.  I'll see whether this works there.
bash-3.2$ etc/make-liarc.sh 'CFLAGS=-arch x86_64'
run_cmd: ./configure --prefix=/Users/arthur/Downloads/Scheme/MIT 
Scheme/mit-scheme-c-20090107/src/boot-root --enable-native-code=c
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: 
Scheme/mit-scheme-c-20090107/src/boot-root
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
Makefiles already created.
configure: creating ./config.status
config.status: creating Makefile
config.status: creating 6001/Makefile
config.status: creating compiler/Makefile
config.status: creating cref/Makefile
config.status: creating edwin/Makefile
config.status: creating imail/Makefile
config.status: creating runtime/Makefile
config.status: creating sf/Makefile
config.status: creating sos/Makefile
config.status: creating ssp/Makefile
config.status: creating star-parser/Makefile
config.status: creating win32/Makefile
config.status: creating xdoc/Makefile
config.status: creating xml/Makefile
=== configuring in microcode (/Users/arthur/Downloads/Scheme/MIT 
Scheme/mit-scheme-c-20090107/src/microcode)
configure: running /bin/sh ./configure 
'--prefix=/Users/arthur/Downloads/Scheme/MIT'  
'Scheme/mit-scheme-c-20090107/src/boot-root' '--enable-native-code=c' 
'build_alias=Scheme/mit-scheme-c-20090107/src/boot-root' 
'host_alias=Scheme/mit-scheme-c-20090107/src/boot-root' 
'target_alias=Scheme/mit-scheme-c-20090107/src/boot-root' 
--cache-file=/dev/null --srcdir=.
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: 
Scheme/mit-scheme-c-20090107/src/boot-root
checking whether make sets $(MAKE)... yes
checking build system type... Invalid configuration 
`Scheme/mit-scheme-c-20090107/src/boot-root': machine 
`Scheme/mit-scheme-c-20090107/src/boot' not recognized
configure: error: /bin/sh ./config.sub 
Scheme/mit-scheme-c-20090107/src/boot-root failed
configure: error: ./configure failed for microcode___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] Re: problems with the x86-64 build on OS X 10.5

[Arthur A. Gleckler]

> I haven't tried building it on OS X at all, but did you build the C
> distribution as i386 or as x86-64?  If i386, that will cause make.bin
> to be a 32-bit fasl, which the 64-bit microcode won't know how to
> read.  You may need to build the C distribution with
>
> sh etc/make-liarc.sh 'CFLAGS=-arch x86_64'

Thank you!  I didn't do that, but will try it now.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] problems with the x86-64 build on OS X 10.5

[Arthur A. Gleckler]

I'm re-sending this message with an abbreviated transcript because the
first attempt bounced from .

On Mon, Nov 9, 2009 at 5:50 PM, Arthur A. Gleckler  wrote:
> Has anyone tried the x86-64 build on OS X 10.5?  I've built from an
> up-to-date, clean repository on a machine with the most recent
> official C build installed, and I'm getting this error:
>
>  Microcode Error: No error handlers.
>  Error code 0x18 (fasl-file-bad-data).
>
> I'm asking about 10.5 since that's the only difference between my
> setup and what I expect you're running (10.6).
>
> I've attached a transcript in case that helps.
>
> Thanks.
bash-3.2$ etc/make-native.sh --enable-native-code=x86-64
run_cmd: ./Setup.sh
autoconf
run_cmd: mkdir lib
run_cmd: mkdir lib/lib
run_cmd: ln -s ../edwin lib/edwin
run_cmd: ln -s ../microcode lib/include
run_cmd: ln -s ../etc/optiondb.scm lib/optiondb.scm
run_cmd: ln -s ../runtime lib/runtime
setting up cref
...
./makegen/m4.sh  cmpauxmd.m4 > cmpauxmd.s
as -arch x86_64  -o cmpauxmd.o cmpauxmd.s
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o terminfo.o -c 
terminfo.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o pruxdld.o -c 
pruxdld.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o x11base.o -c 
x11base.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o x11term.o -c 
x11term.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o x11graph.o -c 
x11graph.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o x11color.o -c 
x11color.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o cmpint.o -c 
cmpint.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fconstant-cfstrings -o cmpintmd.o -c 
cmpintmd.c
gcc -DHAVE_CONFIG_H -DMIT_SCHEME 
-DDEFAULT_LIBRARY_PATH=\"/Users/arthur/mit-scheme-git/src/boot-root/lib/mit-scheme-x86-64\"
 -I/usr/X11/include -I. -I. -O3 -Wall -Wundef -Wpointer-arith -Winline 
-Wstrict-prototypes -Wnested-externs -Wredundant-decls -Wextra 
-Wno-sign-compare -Wno-unused-parameter -Wold-style-definition -arch x86_64  
-isysroot /Developer/SDKs/MacOSX10.5.sdk

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

[Arthur A. Gleckler]

> It seems to lack all floating point:
>
> 1 ]=> (/ 3.0 1.2)

That expression works for me -- even when included in a compiled procedure.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

[Arthur A. Gleckler]

Very nice!  I'm able to make some awfully large heaps.

Thanks for doing this, Taylor.  This is going to make a lot of people happy.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] MIT Scheme on the AMD x86-64

[Arthur A. Gleckler]

> My guess is that you have a stale configure script for the microcode
> which doesn't know about x86-64 native code.  Rerun autoconf in the
> `microcode/' directory, or run `make maintainer-clean' and then start
> over.  Also, run `git pull' again -- I have just pushed a fix to an
> unrelated problem that would probably rear its head later in the
> process for you.

I'm sure you're right.  I should have thought to do .  In any case, I did a completely fresh clone a
while back and am already past the original problem.

Any guess about whether this will run on OS X?  (I'm building it on
Linux right now.)


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> The second time I try that in any directory where I've done  clone> earlier, it works fine.  Is this normal?

Oh, I bet I know what's going on.  I did  in a directory
which was a copy of the directory I had pulled down.  It must be
comparing the hash of the enclosing directory's name with the hash of
the original enclosing directory's name.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> Thanks.  I've fixed that in git.

Thank you, thank you!  I pulled that down and have now successfully
built on Snow Leopard.

By the way, I consistently get this error the first time I do :

  bash-3.2$ git pull
  remote: Counting objects: 9, done.
  remote: Compressing objects: 100% (5/5), done.
  remote: Total 5 (delta 4), reused 0 (delta 0)
  Unpacking objects: 100% (5/5), done.
  From git://git.savannah.gnu.org/mit-scheme
   + 0b6cd5c...f2b42a4 HEAD   -> origin/HEAD  (forced update)
  error: Ref refs/remotes/origin/master is at
f2b42a44bdb4ba11b97b4d7360fc1031700ba8c3 but expected
0b6cd5c8751417c92dce72203ec016a97a422a09
   ! 0b6cd5c..f65896e  master -> origin/master  (unable to update local ref)

The second time I try that in any directory where I've done  earlier, it works fine.  Is this normal?


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> I'll look into this further tonight.

Oh, I see.  This doesn't include the  change to add <-arch i386>.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> OK, I've made some changes to "configure.ac".  It should automatically
> adapt to the correct SDK.  Please "git pull" and try again to test.

I'm getting this again:

  cmpaux-i386.s:166:suffix or operands invalid for `push'

I tried both with and without the <--with-macosx-version=10.6> argument.

I'll look into this further tonight.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> OK, good.  Now add a binding AS_FLAGS="-arch i386" to that same part
> of configure.ac that sets MACOSX_CFLAGS.

Hurrah!  It's compiling the compiler now, so we're definitely past
those problems.

I'm not yet a Git Achiever, so I've attached the changed section of
"configure.ac".  I will get up to speed soon, but if you wouldn't mind
submitting this change, please do.

Thanks so much!  It's great to be able to build and run on Snow Leopard.
darwin*)
MACOSX=yes
MACOSX_SYSROOT=/Developer/SDKs/MacOSX10.6.sdk
if test -d ${MACOSX_SYSROOT}; then
MACOSX_CFLAGS="-arch i386 -mmacosx-version-min=10.4 -isysroot 
${MACOSX_SYSROOT}"
AS_FLAGS="-arch i386 ${AS_FLAGS}"
MACOSX_LDFLAGS="${MACOSX_CFLAGS} -Wl,-syslibroot,${MACOSX_SYSROOT}"
CFLAGS="${CFLAGS} ${MACOSX_CFLAGS}"
LDFLAGS="${LDFLAGS} ${MACOSX_LDFLAGS}"
fi
MODULE_LDFLAGS="${MODULE_LDFLAGS} -bundle -bundle_loader "'${SCHEME_EXE}'
;;
netbsd*)
___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> OK, add -arch i386 too.

By editing "configure.ac" somehow or as an argument to "configure"?

> Did you try a liarc build with this?

Not this time.  But when I tried yesterday, it failed.  I don't have
the transcript for that any more.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> 1. Test whether the directory "/Developer/SDKs/MacOSX10.4u.sdk" exists
> in your installation.

Aha!  I don't have that directory.

> 2b. If not, change microcode/configure.ac to refer to a different sdk
> that _is_ present.  This would explain why the liarc binary wouldn't
> work.

I change that line to this:

  MACOSX_SYSROOT=/Developer/SDKs/MacOSX10.6.sdk

I triple-checked that that directory does exist.

Unfortunately, the build is failing in the same place:

  confshared.h:638:58: error: Error: confshared.h: Unknown PC
alignment.: No such file or directory

(I started from a completely clean copy of the repository.)


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> I'll send you the transcript tonight.

I've attached the transcript.  The build fails here in "microcode/confshared.h":

  #ifndef PC_ZERO_BITS
  #  ifdef CC_IS_NATIVE
  #include "Error: confshared.h: Unknown PC alignment."
  #  else
  #define PC_ZERO_BITS 0
  #  endif
  #endif

My guess is that the problem is that <__IA32__> isn't defined, and
therefore  is never defined.  But when I define it, I
eventually get lots of errors like this:

  cmpaux-i386.s:188:32-bit absolute addressing is not supported for x86-64

There must be some way to force a 32-bit compile at the GCC level.
Doesn't it look like that's what's needed?

> I managed to find a machine running 10.5.8 and the build worked fine.
> That means that Snow Leopard is the cause, directly or indirectly.
> I'm hoping that the binary I just built will work fine on Snow
> Leopard.  We'll see.

The binary built on 10.5.8 works fine on Snow Leopard.
bash-3.2$ rm -rf mit-scheme-git*
bash-3.2$ mkdir mit-scheme-git
bash-3.2$ cd mit-scheme-git/
bash-3.2$ git clone git://git.savannah.gnu.org/mit-scheme.git .
Initialized empty Git repository in /Users/arthur/mit-scheme-git/.git/
remote: Counting objects: 128562, done.
remote: Compressing objects: 100% (29755/29755), done.
remote: Total 128562 (delta 95911), reused 122017 (delta 89451)
Receiving objects: 100% (128562/128562), 34.46 MiB | 307 KiB/s, done.
Resolving deltas: 100% (95911/95911), done.
Checking out files: 100% (1732/1732), done.
bash-3.2$ cd src
bash-3.2$ ./Setup.sh
autoconf
run_cmd: mkdir lib
run_cmd: mkdir lib/lib
run_cmd: ln -s ../edwin lib/edwin
run_cmd: ln -s ../microcode lib/include
run_cmd: ln -s ../etc/optiondb.scm lib/optiondb.scm
run_cmd: ln -s ../runtime lib/runtime
run_cmd: ln -s ../microcode/utabmd.bin lib/utabmd.bin
setting up cref
run_cmd: ln -s ../etc/Setup.sh cref/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up edwin
run_cmd: ln -s ../etc/Setup.sh edwin/Setup.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up imail
run_cmd: ln -s ../etc/Setup.sh imail/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up sf
run_cmd: ln -s ../etc/Setup.sh sf/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up sos
run_cmd: ln -s ../etc/Setup.sh sos/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up ssp
run_cmd: ln -s ../etc/Setup.sh ssp/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up star-parser
run_cmd: ln -s ../etc/Setup.sh star-parser/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up xml
run_cmd: ln -s ../etc/Setup.sh xml/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up 6001
run_cmd: ln -s ../etc/Setup.sh 6001/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up compiler
run_cmd: ln -s instr1.scm machines/vax/dinstr1.scm
run_cmd: ln -s instr2.scm machines/vax/dinstr2.scm
run_cmd: ln -s instr3.scm machines/vax/dinstr3.scm
setting up rcs
run_cmd: ln -s ../etc/Setup.sh rcs/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up runtime
run_cmd: ln -s ../etc/Setup.sh runtime/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
run_cmd: ln -s ed-ffi.scm .edwin-ffi
setting up win32
run_cmd: ln -s ../etc/Setup.sh win32/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up xdoc
run_cmd: ln -s ../etc/Setup.sh xdoc/Setup.sh
run_cmd: ln -s ../etc/Clean.sh Clean.sh
run_cmd: ln -s ../etc/Stage.sh Stage.sh
run_cmd: ln -s ../etc/Tags.sh Tags.sh
setting up microcode
autoheader
autoconf
rm -f i386-nt.asm
./m4-dos -P "WIN32,1" < i386.m4 > i386-nt.asm
rm -f i386-ntw.asm
./m4-dos -P "WIN32,1" -P "WCC386R,1" < i386.m4 > i386-ntw.asm
checking whether make sets $(MAKE)... yes
checking build system type... i386-apple-darwin10.0.0
checking host system type... i386-apple-darwin10.0.0
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling.

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> OK, send me the transcript and I'll try to figure it out.  I have the
> Snow Leopard upgrade, but haven't installed it because it breaks
> ToonTown, and that would be *very bad* for the rest of my family.  And
> I'm not touching the Google machine until it's officially supported.
> So at the moment I have no way to test this.  (I guess, at the worst,
> I could come by your house sometime.)

I'll send you the transcript tonight.

I managed to find a machine running 10.5.8 and the build worked fine.
That means that Snow Leopard is the cause, directly or indirectly.
I'm hoping that the binary I just built will work fine on Snow
Leopard.  We'll see.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

> Nothing special is required to compile 32-bit native binary.  From a
> fresh git checkout:
>
> ./Setup.sh
> ./configure
> make
> make install

Yeah, that's what I did.  I'll send along the transcript when I get
home tonight.

> You've installed Xcode?  We haven't tested other compilers.

Yes.

> Is this machine running Snow Leopard?  I haven't tested that.

Yes.  It's a great OS, but now I'm regretting having upgraded both of
my machines.

> Have you checked in your bug fixes?

Oh, yes, back in February:

  



___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] compiling for OS X

[Arthur A. Gleckler]

I just bought a new Mac Mini to replace my aging iMac G5.  Now that I
have an x86, I'd love to run the prebuilt binary, but it doesn't
include some bug fixes I made recently that I need for a project.
Unfortunately, I can't get MIT Scheme to compile using either the x86
back end or the C back end after doing .  I suspect that
the problem with the x86 back end is that GCC is perhaps trying to
build a 64-bit app, but I have no idea what's wrong with the C back
end.

Was there anything special required to build the x86 OS X binary at
?For example, is there a
 step to force the building of a 32-bit binary?  (A 32-bit
binary would be fine with me.)

I'll dig in and try to solve this on my own if no one knows what's
going on, but thank you for any hints.

(I can follow up later with precise error messages.  I'm at work work
now and don't have access to them here.)


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] savannah problems

[Arthur A. Gleckler]

> No, the two are independent, except for the project web pages, which
> are managed by CVS on savannah.  But I'm not very excited about moving
> at the moment, although Google Code does have some nice features.

Yeah, I understand.  I thought I should mention it since this would be
the easiest time to switch.

I suppose it won't be that hard for us to keep backups ourselves,
especially with a distributed version control system like Git.

Now that it's back up, it looks great.  For one thing, the browseable
Git history is infinitely nicer than the old browseable CVS history.

Time for me to learn Git!


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] savannah problems

[Arthur A. Gleckler]

> Savannah crashed a couple of days due to hardware problems.  We lost
> the git repository because it wasn't backed up (apparently there was
> some issue with backups in the time leading up to the failure -- what
> do you want for a free service, anyway).  The CVS repository is not at
> issue because I have a complete snapshot from the day we switched
> over.

Let's consider hosting MIT Scheme on another service.  Google Code's
project hosting service, for example, has full-time staff making sure
that it's up and backed up.  It also has a much cleaner UI.  And now
that we've already had one big accident with Git, we might find being
able to use Mercurial instead to be a blessing.

I know that MIT Scheme is now MIT/GNU Scheme, but is there anything
that says we have to be on Savannah?


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] git?

[Arthur A. Gleckler]

> CVS may be crusty, but personally I'm still not remotely comfortable
> using Git after some three-odd attempts to learn to use it.  However,
> if I'm the only one to whom it is nearly as unusably opaque as Arch,
> then it is probably not worth stalling for my sake alone.

I'm not a fan of git, either, but would prefer it over CVS, which
doesn't preserve important information, e.g. change sets.

Savannah appears to support either CVS or git, but nothing else, so
the choices are limited if the project is to remain there.

I vote for git despite its unpleasantness.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] "Unknown directive name" while compiling "turtle.scm"

[Arthur A. Gleckler]

On Aug 7, 2006, at 10:56 PM, Arthur A. Gleckler wrote:

Even after doing , I'm consistently getting the error  
"Unknown directive name" while compiling "turtle.scm" as part of  
.  Has anyone else seen this?


Aha!  I found Chris's 29 Jun 2006 answer to another question about  
this problem here:


  http://lists.gnu.org/archive/html/mit-scheme-users/2006-06/ 
msg00015.html



This is a problem with staging.  The *PARSER subsystem needs to be
upgraded before the XML subsystem can be compiled.  I'm not sure if
there's a simple answer to this or if I'll have to partially revert
that change.


I also had the problem with a missing "make.com", and looked back  
through my transcript to find the real error.


I'll just patch my changes into the binary distribution until the  
next release.



___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

[MIT-Scheme-devel] "Unknown directive name" while compiling "turtle.scm"

[Arthur A. Gleckler]

Even after doing , I'm consistently getting the error  
"Unknown directive name" while compiling "turtle.scm" as part of  
.  Has anyone else seen this?


Thanks.


___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel

Re: [MIT-Scheme-devel] intel macs

[Arthur A. Gleckler]

On Mar 31, 2006, at 5:50 AM, Dan Starr wrote:

Will be getting a new Intel-based Macintosh.  Have checked web-page  
for building MIT/Scheme on "other Unix" platforms.  Has this been  
done yet?  Since other Unix and x86 platforms are already used,  
this should be relatively easy.  Willing to do some leg-work, and  
really need a lisp, but am not a Unix professional.  Would need to  
volley emails of error messages, most likely to pull it off.   
should I just wait?  Please advise.  -- Dan Starr


It hasn't been done yet, unfortunately.  I'm planning to do it once I  
buy an Intel-based Mac laptop, but I'm waiting for the next  
generation to come out first.




___
MIT-Scheme-devel mailing list
MIT-Scheme-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/mit-scheme-devel