[racket] Understanding raco make and its correctness guarantees

You can use a little 'preload' script:

wrap-compile.rkt
#lang racket
(require compiler/cm)
(current-load/use-compiled
  (make-compilation-manager-load/use-compiled-handler))

and run with racket -t wrap-compile.rkt <more>
I would really love to see this functionality as a command line option to  
the console racket

Tobias




On Thu, 21 Mar 2013 16:31:51 +0100, Eric Dobson <eric.n.dobson at gmail.com>  
wrote:

> So anyone who just uses the command line tools is out of luck? I like
> my build system to be correct, and it seems weird that there is work
> to make sure the right zo file is matched with the source file but
> that it is incorrect in some simple cases.
>
> On Thu, Mar 21, 2013 at 8:19 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> Or use DrRacket and turn on the auto compilation feature. Or set up
>> compiler/cm yourself to do that.
>>
>> Robby
>>
>>
>> On Thu, Mar 21, 2013 at 10:16 AM, Eric Dobson <eric.n.dobson at gmail.com>
>> wrote:
>>>
>>> That doesn't explain why I can get the same behavior as the macro with
>>> a function call, probably inlining is responsible for that though.
>>>
>>> So the take away is that if I want my running system to represent the
>>> current state of the source files I either need to run raco make every
>>> single time, or never run raco make. That seems very counter
>>> intuitive.
>>>
>>> On Thu, Mar 21, 2013 at 1:51 AM, Tobias Hammer <tobias.hammer at dlr.de>
>>> wrote:
>>> > The difference lies in the method how racket and raco make check for
>>> > changes.
>>> > - racket only looks at each individual file's timestamp source and  
>>> .zo
>>> > timestamp and uses whichever is never.
>>> > - raco make always checks if the file has changed or any of its
>>> > dependencies
>>> > has changed to decide if it has to recompile the file.
>>> >
>>> > Whats happens in version 1 is that the macro is already expanded in  
>>> a.zo
>>> > and
>>> > a.zo is still never than a.rkt. Therefore racket loads a.zo (but  
>>> b.rkt)
>>> > and
>>> > prints 'version1.
>>> > In version 2 raco make (or more correctly compiler/cm) checks a.rkt,
>>> > finds
>>> > the dependency to b.rkt, notices the change in b.rkt (by calculating  
>>> a
>>> > checksum over the whole dependency tree if i remember correct) and
>>> > therefore
>>> > recompiles a.rkt AND b.rkt.
>>> >
>>> > Version 3 should as far as i understand never differ, assumed raco  
>>> make
>>> > works.
>>> >
>>> > Tobias
>>> >
>>> >
>>> >
>>> > On Thu, 21 Mar 2013 06:23:24 +0100, Eric Dobson
>>> > <eric.n.dobson at gmail.com>
>>> > wrote:
>>> >
>>> >> I'm trying to understand what are the guarantees that raco make is
>>> >> meant to provide. I'm going to limit this to simple programs, no  
>>> fancy
>>> >> dynamic requires, or trying to trick the compiler.
>>> >>
>>> >> In the following scenario:
>>> >> 1. Edit files
>>> >> 2. run 'raco make <files>'
>>> >> 3. Change files
>>> >> I expect all of these to have the same effect during the running of
>>> >> phase 0 when running racket.
>>> >> 4. racket <main-file>
>>> >> or
>>> >> 4. raco make <files>
>>> >> 5. racket <main-file>
>>> >> or
>>> >> 4. rm -rf compiled/
>>> >> 5. raco make <files>
>>> >> 6. racket <main-file>
>>> >>
>>> >> I can make version 1 and 2 differ with the following program:
>>> >> a.rkt
>>> >> #lang racket
>>> >> (require "b.rkt")
>>> >> (macro)
>>> >>
>>> >> #lang racket
>>> >> (provide maco)
>>> >> (define-syntax (macro stx)
>>> >>   #''version1)
>>> >>
>>> >> Where the edit is changing version1 to version2. I can also  
>>> replicate
>>> >> this with a function and not a macro.
>>> >>
>>> >> I thought I could make version 2 and version 3 differ, but cannot  
>>> seem
>>> >> to replicate it now, but it would be helpful to know if I see
>>> >> something that is fixed by clearing the compiled directories.
>>> >>
>>> >> My understanding was that racket used the same logic as raco make on
>>> >> whether or not to use the compiled versions versus recompiling, and
>>> >> this seems to refute that. Can someone give some insight on what I
>>> >> should be expecting?
>>> >> ____________________
>>> >>   Racket Users list:
>>> >>   http://lists.racket-lang.org/users
>>> >
>>> >
>>> >
>>> > --
>>> > ---------------------------------------------------------
>>> > Tobias Hammer
>>> > DLR / Robotics and Mechatronics Center (RMC)
>>> > Muenchner Str. 20, D-82234 Wessling
>>> > Tel.: 08153/28-1487
>>> > Mail: tobias.hammer at dlr.de
>>> ____________________
>>>   Racket Users list:
>>>   http://lists.racket-lang.org/users
>>
>>


-- 
---------------------------------------------------------
Tobias Hammer
DLR / Robotics and Mechatronics Center (RMC)
Muenchner Str. 20, D-82234 Wessling
Tel.: 08153/28-1487
Mail: tobias.hammer at dlr.de