As of now, I haven't experienced any more problem of this sort since then. Admittedly I haven't tried hard either to reproduce this behavior.
So thank you so much for the time you took to look into this! Very appreciated. On Sat, Mar 26, 2016 at 11:53 PM, Robby Findler <ro...@eecs.northwestern.edu > wrote: > Matthew and I have figured out one way in which DrRacket could go > wrong here and implemented a better strategy. The problem we > identified doesn't explain the symptoms expressed here in this thread > exactly, but it is a complex system and maybe there was some piece > missing from the explanations that I didn't think to ask about. > Finger's crossed that it helps! > > In any case, if you are still experiencing the bad symptom after you > get the latest code, please let me know. > > Thanks, > Robby > > On Mon, Feb 1, 2016 at 9:03 AM, Laurent <laurent.ors...@gmail.com> wrote: > > I would be so happy if this kind of error could be resolved! (even when > all > > files are compiled by DrRacket) > > Usually, I just turn off "populate 'compiled' directories", but then > > DrRacket needs to compile the file on each F5, which can take some > precious > > time. > > Thank you both then :) > > > > On Sun, Jan 31, 2016 at 11:19 PM, jon stenerson < > jonstener...@comcast.net> > > wrote: > >> > >> > >> The simplest thing I can find: I have three files in two directories. > >> The first directory, called junk, contains a.rkt and b.rkt. > >> The second directory is a sibling to junk called local-libs and contains > >> c.rkt. (local-libs is known to the package manager; it was installed > via the > >> DrRacket interface). > >> If I open all three files in DrRacket and try running a.rkt, sometimes > it > >> works, sometimes not. By modifiying a, b, c in some order (in the > DrRacket > >> editor) I can toggle the work/not work flag. As you say, it's a little > >> non-deterministic. > >> > >> Thanks, > >> Jon > >> > >> > >> a.rkt: > >> #lang racket > >> (require "b.rkt") > >> > >> b.rkt > >> #lang racket > >> (require "../local-libs/c.rkt") > >> (s 1) > >> > >> c.rkt > >> #lang racket > >> (provide (struct-out s) ) > >> (struct s (p)) > >> > >> > >> > >> > >> On 1/31/2016 4:03 PM, Robby Findler wrote: > >>> > >>> Then it would be helpful to us if you could provide some (hopefully > >>> small) program and instructions to reproduce the problem. > >>> > >>> Thanks, > >>> Robby > >>> > >>> > >>> On Sun, Jan 31, 2016 at 4:51 PM, jon stenerson < > jonstener...@comcast.net> > >>> wrote: > >>>> > >>>> Just using DrRacket 6.3 on Win 10. > >>>> > >>>> Jon > >>>> > >>>> > >>>> On 1/31/2016 3:22 PM, Robby Findler wrote: > >>>>> > >>>>> The compilation of racket is (not yet) deterministic so things like > >>>>> that can throw off internal tables in the .zo files (and a .zo files > >>>>> is loaded without checking dependencies, optimistically hoping that > >>>>> the files are not changed). > >>>>> > >>>>> So: are you using "raco make" or somehow mangaging .zo files > yourself, > >>>>> or are you seeing this with the .zo files that DrRacket maintains for > >>>>> your automatically? If the former, then you need to adapt your > >>>>> workflow to either not use .zo files or to keep them up to date. If > >>>>> the latter, then it is a bug. > >>>>> > >>>>> Robby > >>>>> > >>>>> > >>>>> > >>>>> On Sun, Jan 31, 2016 at 4:17 PM, jon stenerson > >>>>> <jonstener...@comcast.net> > >>>>> wrote: > >>>>>> > >>>>>> I have some .rkt files and, depending on which file was edited most > >>>>>> recently, either it works fine or it gives a compilation error. (By > >>>>>> "edited" > >>>>>> I mean just adding or subtracting a blank line to change the > >>>>>> timestamp). > >>>>>> I > >>>>>> can submit a simplified example if nobody else has seen this > problem. > >>>>>> If > >>>>>> this is well-known, what is the fix? > >>>>>> > >>>>>> link: bad variable linkage; > >>>>>> reference to a variable that is not a procedure or structure-type > >>>>>> constant > >>>>>> across all instantiations > >>>>>> reference phase level: 0 > >>>>>> variable module: <some path 1> > >>>>>> variable phase: 0 > >>>>>> reference in module: <some path 2> in: <something> > >>>>>> > >>>>>> -- > >>>>>> You received this message because you are subscribed to the Google > >>>>>> Groups > >>>>>> "Racket Users" group. > >>>>>> To unsubscribe from this group and stop receiving emails from it, > send > >>>>>> an > >>>>>> email to racket-users+unsubscr...@googlegroups.com. > >>>>>> For more options, visit https://groups.google.com/d/optout. > >>>> > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups > >>>> "Racket Users" group. > >>>> To unsubscribe from this group and stop receiving emails from it, send > >>>> an > >>>> email to racket-users+unsubscr...@googlegroups.com. > >>>> For more options, visit https://groups.google.com/d/optout. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Racket Users" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to racket-users+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
