Re: [racket-dev] DrRacket PF1 Search Bug?
Would bringing a browser view into DrRacket be a third way, or would that be no different? (That said the native win OS and apple OS 'help' browser viewers aren't exactly inspiring - are they a fourth option?) S. On Fri, 21 Nov 2014 at 21:26 Robby Findler wrote: > On Fri, Nov 21, 2014 at 3:13 PM, Eli Barzilay wrote: > > On Fri, Nov 21, 2014 at 3:16 PM, Robby Findler > > wrote: > >> > >> Oh, my apologies. I thought you meant something different. > >> > >> Yes, this works. > > > > Ah, in this case, the patch that I sent earlier should work fine. > > (I could do a pull request, but it should really be tested...) > > > >> I don't have a good idea which is the better approach now. > > > > [Bear in mind that I don't really know what the issue with the file > > permissions is (looks more like some security attributes):] > > > > I think that playing with such attributes is a worse option -- it's > > something that I'm not sure would work in all settings (but see above), > > and if there is a way to make it work now, it might not be possible in > > the future. The trampoline approach is relatively robust and well > > behaved. There is a minor price of these temporary files, but they do > > get cleaned out (whenever `send-url/contents' is called), so it should > > settle on a small number that will not grow indefinitely[*], so this is > > not a problem. > > > > Also, on the "it's already there" side -- this trampoline approach is > > already there for the windows version, and it's needed for the > > `xdg-open' thing anyway, so abstracting it into a new (internal) > > function makes sense already, so in terms of additional code there's no > > cost for doing the mac version too. > > > > > > ([*] It might be a problem if, for example, your cat sits on the f1 key > > and the os doesn't take the focus away from drracket... It might be > > useful to change it from using a random temp file to a name based on a > > hash of the forwarded url, which will further minimize the number of > > files.) > > Oh, absolutely. The two candidates are the trampoline approach and the > "just move the documentation files over into the user space as if a > package had been installed". > > I guess the latter is better because it means there will be more > homogeneity in the sets of files and whatnot, such that these kinds of > bugs will be less likely to be unnoticed by in house folk. That is, I > never noticed this problem because my documentation is already in the > user-specific place because I build from source. The other option will > make our users operate more like how my drracket operates. > > Robby > _ > Racket Developers list: > http://lists.racket-lang.org/dev > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 3:13 PM, Eli Barzilay wrote: > On Fri, Nov 21, 2014 at 3:16 PM, Robby Findler > wrote: >> >> Oh, my apologies. I thought you meant something different. >> >> Yes, this works. > > Ah, in this case, the patch that I sent earlier should work fine. > (I could do a pull request, but it should really be tested...) > >> I don't have a good idea which is the better approach now. > > [Bear in mind that I don't really know what the issue with the file > permissions is (looks more like some security attributes):] > > I think that playing with such attributes is a worse option -- it's > something that I'm not sure would work in all settings (but see above), > and if there is a way to make it work now, it might not be possible in > the future. The trampoline approach is relatively robust and well > behaved. There is a minor price of these temporary files, but they do > get cleaned out (whenever `send-url/contents' is called), so it should > settle on a small number that will not grow indefinitely[*], so this is > not a problem. > > Also, on the "it's already there" side -- this trampoline approach is > already there for the windows version, and it's needed for the > `xdg-open' thing anyway, so abstracting it into a new (internal) > function makes sense already, so in terms of additional code there's no > cost for doing the mac version too. > > > ([*] It might be a problem if, for example, your cat sits on the f1 key > and the os doesn't take the focus away from drracket... It might be > useful to change it from using a random temp file to a name based on a > hash of the forwarded url, which will further minimize the number of > files.) Oh, absolutely. The two candidates are the trampoline approach and the "just move the documentation files over into the user space as if a package had been installed". I guess the latter is better because it means there will be more homogeneity in the sets of files and whatnot, such that these kinds of bugs will be less likely to be unnoticed by in house folk. That is, I never noticed this problem because my documentation is already in the user-specific place because I build from source. The other option will make our users operate more like how my drracket operates. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 3:16 PM, Robby Findler wrote: > > Oh, my apologies. I thought you meant something different. > > Yes, this works. Ah, in this case, the patch that I sent earlier should work fine. (I could do a pull request, but it should really be tested...) > I don't have a good idea which is the better approach now. [Bear in mind that I don't really know what the issue with the file permissions is (looks more like some security attributes):] I think that playing with such attributes is a worse option -- it's something that I'm not sure would work in all settings (but see above), and if there is a way to make it work now, it might not be possible in the future. The trampoline approach is relatively robust and well behaved. There is a minor price of these temporary files, but they do get cleaned out (whenever `send-url/contents' is called), so it should settle on a small number that will not grow indefinitely[*], so this is not a problem. Also, on the "it's already there" side -- this trampoline approach is already there for the windows version, and it's needed for the `xdg-open' thing anyway, so abstracting it into a new (internal) function makes sense already, so in terms of additional code there's no cost for doing the mac version too. ([*] It might be a problem if, for example, your cat sits on the f1 key and the os doesn't take the focus away from drracket... It might be useful to change it from using a random temp file to a name based on a hash of the forwarded url, which will further minimize the number of files.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
No that doesn't work. You can see why if you follow the technical details in the thread (and get a Mac maybe). Matthew is adding something to the setup collection and drr will use it and we will be all set I expect. Sam doing some testing after that point will be useful tho. Robby On Friday, November 21, 2014, Eli Barzilay wrote: > On Fri, Nov 21, 2014 at 9:45 AM, Sam Tobin-Hochstadt > > wrote: > > > > We have labs of macs here at IU. > > [*sigh* at that kind of spending...] > > > >> And this is why I said that it's not really relevant -- AFAICT, the fact > >> that things are setup in a way that prevents passing queries and > >> fragments means that you just have to deal with it rather than try to > >> play games with the filesystem. > > > > Could we just write a file with the query embedded in it, and open that? > > That is exactly what that trampoline is: a page with just a immediate > redirection to the search file with the query. > > (Unless you mean write a version of the search page with a specific > query hard-wired into it, which is a bad idea for a reasons...) > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://barzilay.org/ Maze is Life! > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 9:45 AM, Sam Tobin-Hochstadt wrote: > > We have labs of macs here at IU. [*sigh* at that kind of spending...] >> And this is why I said that it's not really relevant -- AFAICT, the fact >> that things are setup in a way that prevents passing queries and >> fragments means that you just have to deal with it rather than try to >> play games with the filesystem. > > Could we just write a file with the query embedded in it, and open that? That is exactly what that trampoline is: a page with just a immediate redirection to the search file with the query. (Unless you mean write a version of the search page with a specific query hard-wired into it, which is a bad idea for a reasons...) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 9:29 AM, Eli Barzilay wrote: > On Fri, Nov 21, 2014 at 8:46 AM, Robby Findler > wrote: >> On Fri, Nov 21, 2014 at 12:34 AM, Eli Barzilay wrote: >>> Not that it matters, but did you try to see if it's the file >>> permissions? >> >> Oh, they are! >> >> [...] >> >> And that was it!! >> >> If I run: >> >> $ xattr -d com.apple.quarantine /Applications/r/doc/search/index.html >> >> then osascript works again! >> [...] >> >> ... I don't know the ramifications of just calling "xattr" from inside >> DrRacket to fix things up. It may be better to just create the file in >> the user's directory instead. > > That (the first thing) sounds like a very bad idea, and one that will > most likely fail in a case of a non-private machine. The second is also > pretty bad since you'd be exluding a central setup in such a situation. > (Not that I see any reason to have a lab of Macs...) We have labs of macs here at IU. > And this is why I said that it's not really relevant -- AFAICT, the fact > that things are setup in a way that prevents passing queries and > fragments means that you just have to deal with it rather than try to > play games with the filesystem. Could we just write a file with the query embedded in it, and open that? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 8:46 AM, Robby Findler wrote: > On Fri, Nov 21, 2014 at 12:34 AM, Eli Barzilay wrote: >> Not that it matters, but did you try to see if it's the file >> permissions? > > Oh, they are! > > [...] > > And that was it!! > > If I run: > > $ xattr -d com.apple.quarantine /Applications/r/doc/search/index.html > > then osascript works again! > [...] > > ... I don't know the ramifications of just calling "xattr" from inside > DrRacket to fix things up. It may be better to just create the file in > the user's directory instead. That (the first thing) sounds like a very bad idea, and one that will most likely fail in a case of a non-private machine. The second is also pretty bad since you'd be exluding a central setup in such a situation. (Not that I see any reason to have a lab of Macs...) And this is why I said that it's not really relevant -- AFAICT, the fact that things are setup in a way that prevents passing queries and fragments means that you just have to deal with it rather than try to play games with the filesystem. But of course there's another question of whether the trampoline will work -- the browser might itself detect the different owner and refuse to do the requested hop. Hopefully it doesn't. [And if it does, then I can only see ugly solutions like open a page with a known weird title, wait for it to come up and then send it a command to go to the real target... Or running a tiny web server at some known high port, and using an http://localhost:port/, and that web server will wait for a single request and spit out the forwarding line, dealing with multiple processes somehow (eg, some random number as a private identifying cookie).] -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] DrRacket PF1 Search Bug?
On Fri, Nov 21, 2014 at 12:34 AM, Eli Barzilay wrote: > On Thu, Nov 20, 2014 at 10:38 PM, Robby Findler > wrote: >> No, the browser isn't hiding the query part. >> >> Here are the content of two script files: >> >> $ cat a.scrpt >> open location "file:///Applications/r/doc/search/index.html?q=xyz" >> $ cat b.scrpt >> open location >> "file:///Users/robby/Library/Racket/development/doc/search/index.html?q=xyz" >> >> Running "osascript a.scrpt" doesn't work, but running "osascript >> b.scrpt" does work. And by "work" I mean that in both cases the >> corresponding webpage is visited in Safari, but in the first case, the >> q parameter disappears. > > Not that it matters, but did you try to see if it's the file > permissions? Oh, they are! $ ls -@l /Users/robby/Library/Racket/development/doc/search/index.html -rw-r--r-- 1 robby staff 5386 Nov 19 14:00 /Users/robby/Library/Racket/development/doc/search/index.html $ ls -@l /Applications/r/doc/search/index.html -rw-r--r--@ 1 robby admin 4929 Nov 20 03:41 /Applications/r/doc/search/index.html com.apple.quarantine 67 And that was it!! If I run: $ xattr -d com.apple.quarantine /Applications/r/doc/search/index.html then osascript works again! > Another thing: I googled "osascript open url drops query" and got a > bunch of racket results, and dropping "osascript" make the results more > sensible. So perhaps "osascript" is outdated? Some more searching > makes it look like you can just run the open command directly, and that > might make a difference. It's the same. ... I don't know the ramifications of just calling "xattr" from inside DrRacket to fix things up. It may be better to just create the file in the user's directory instead. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
