On Jun 27, 2011, at 5:47 PM, Robby Findler wrote: > On Tue, Jun 28, 2011 at 8:41 AM, John Clements > <cleme...@brinckerhoff.org> wrote: >> >> On Jun 27, 2011, at 5:28 PM, Robby Findler wrote: >> >>> On Tue, Jun 28, 2011 at 8:19 AM, John Clements >>> <cleme...@brinckerhoff.org> wrote: >>>> >>>> On Jun 27, 2011, at 5:10 PM, Robby Findler wrote: >>>> >>>>> On Tue, Jun 28, 2011 at 7:52 AM, John Clements >>>>> <cleme...@brinckerhoff.org> wrote: >>>>>> >>>>>> On Jun 27, 2011, at 4:45 PM, Robby Findler wrote: >>>>>> >>>>>>> We're talking about relative requires only, right? >>>>>>> >>>>>>> How are you proposing to signal the error? >>>>>> >>>>>> My guess about how this works--correct me if I'm wrong--is that for >>>>>> unsaved buffers, DrR sets a parameter such that the expanded code has >>>>>> the current directory as (uh, part of?) the syntax-source of the >>>>>> expanded source. I'm guessing that I'm not right, or it would be as >>>>>> simple as disabling this for programs written in BSL et al. >>>>> >>>>> DrRacket does indeed set current-directory and could instead signal an >>>>> error instead of setting it. That would mean no unsaved file would >>>>> run, however. Is that really desired? >>>> >>>> Would it not be possible to set the syntax-source in such a way that >>>> relative requires would fail? We may be out of DrR and into just plain R >>>> here. >>> >>> Yes, we have to be, I'm pretty sure. >>> >>>> Indeed, I would be happy if buffers without a recorded save location >>>> couldn't make relative requires in *any* language level, though I realize >>>> that such a change would be more likely to have repercussions elsewhere. >>> >>> I think that would probably require a new parameter that controls >>> where relative requires are relative to being exported and allowing it >>> to have a value that says "no relative requires allowed". >>> (current-load-relative-directory is maybe already this, without the >>> extra functionality, maybe?) >>> >>>> I suppose there could be situations where users dynamically create syntax >>>> objects and set the current directory rather than setting the >>>> syntax-source of the objects, though that doesn't sound like the most >>>> robust way to write the code. >>> >>> I don't understand this comment. >>> >>> (I believe that the source field of a syntax objects is not involved >>> in resolving relative requires.) >> >> Ah! I understand better now. >> >> Okay, out of the realm of how-things-should-be and into the realm of >> how-things-are; you write that DrR sets 'current-directory'. Is there some >> reason to set 'current-directory' rather than >> 'current-load-relative-directory'? It looks to me like setting >> 'current-load-relative-directory' fixes the bug I'm tackling, but I want the >> stepper to accurately simulate DrR's behavior here. > > Oh, I see that current-load-relative-directory can already be #f. I > think that situation corresponds to "I'm not requiring anything", tho > and, according to the docs, that parameter is set by the require > machinery (not by drracket altho I didn't grep the sources to be > sure). So again, I think we're stuck if all we change is drracket. > > (I'm not sure, but I think that this is probably going to be more > trouble than it is worth.)
Okey dokey. I've verified that setting "current-directory" has the desired effect, so I'm just going to set it to the result of the tab's "get-directory" before calling the expander to pull the exprs out of the defns window. Let me know if this is obviously wrong. Thanks! John (lost dev on intermediate response, sorry)
smime.p7s
Description: S/MIME cryptographic signature
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev