Re: [racket-users] DrRacket rendering issues OS X
I've pushed a repair for this problem. The short version is that a workaround for an old OS X bug seems to run into a new OS X bug, but the old OS X bug appears to be fixed in 10.10, so the workaround (and the new bug) can be avoided. At Tue, 18 Aug 2015 20:09:59 +, Andrew Kent wrote: Just an update/bump: I'm still seeing this issue in DrRacket on the latest git checkouts. I went ahead replicated the issue on a friend's mac w/ OS X Yosemite w/ the 6.2 release as well (just to make sure I wasn't crazy or causing the issue on my machine).[image: Screen Shot 2015-08-18 at 4.07.23 PM.png] On Wed, Jun 17, 2015 at 7:13 PM Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 17 Jun 2015 12:35:36 -0700 (PDT), Andrew Kent wrote: On Wednesday, June 17, 2015 at 3:10:51 PM UTC-4, Alex Knauth wrote: One data point: I’m using DrRacket version 6.2.0.4--2015-06-08 with OS X Version 10.9.5, and if I remember correctly it was a Racket plus Tests 64-bit installation. I tried those steps, and it worked fine, with no weird black areas, though I do remember occasionally getting similar small black areas in the past, covering just the tab bar or something like that, and when I moved my mouse over it it fixed itself? I’m not sure if I remember that correctly, and I’m not sure if that could be related to what you got, because that wasn’t with full screen or the mission control screen, and I could not produce that consistently. On Jun 17, 2015, at 12:25 PM, Andrew Kent andm...@indiana.edu wrote: Good day all! First, I just wanted to say DrRacket is *amazing* and thank all who have helped it become what it is today! I'm currently using it to work on Typed Racket and it is a godsend. Right now, unfortunately, I am having some problems w/ DrRacket rendering in OS X -- I am getting large black areas appearing in full screen mode in DrRacket. They seem pretty serious/severe, and I was curious if anyone else has seen this behavior? PDF w/ screenshots some attempt to describe problem(s): https://drive.google.com/file/d/0B-HcU1nZPrwJWXFNbEdOV0doeUE/view?usp=sharing Steps that seem to recreate issue: 1) Open DrRacket 2) Make it full screen by clicking green button at top left of DrRacket 3) Open OS X ‘Mission Control’ (cmd+up or 3-finger-swipe up on touchpad) 4) Close OS X ‘Mission Control’ (cmd+down or 3-finger-swipe downon touchpad) nd 5) Repeat 3-4 a couple times (after the 2 time it seemed to consistently happen on my machine) - This worked whether or not I was plugged into the external monitor - the snapshots reproduced the issue on were the Racket plus Tests | Mac OS X | 32-bit Intel distribution for version 6.2.0.4 (20150609-bf12a2b) version 6.2.0.4 (20150617-97827ac) - I’m running the latest OS X Yosemite (Version 10.10.3 (14D136)) on a early 2013 13” MacBook Air Best, Andrew Additional note/update: When I was writing up the bug description those steps _were_ working consistently for me. Now, however, they do not... but somewhat erratically jumping workspaces left to right (I have Powerpoint full screened at the moment as well) mixed w/ some Mission Control access can cause it. So, I can't figure out how to do it 100% consistently, but it is definitely a reoccurring issue and sometimes I end up just having to close DrRacket to make it go away. I haven't been able to replicate the problem, but I'm also using Mavericks. This problem could easily be specific to Yosemite, and I'll check when I get back to my Yosemite machine in a couple of weeks. -- [image/png Screen Shot 2015-08-18 at 4.07.23 PM.png] [~/Desktop open] [~/Temp open] . -- 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.
Re: [racket-users] Capability security in Racket?
Hi Sean, An alternative approach you might consider instead of relying heavily on sandboxes and namespaces is to define your own #lang where you can carefully control how different objects are allowed to communicate with each other. This approach could have two advantages: 1) you can use lighter-weight mechanisms to represent objects, and 2) you can restrict things to make it much less likely that you would get bitten by a misunderstanding how namespaces and require, etc, work. We used a similar approach when writing Shill, our capability-based shell scripting language based on Racket (shill-lang.org). You can find a short description of how we did this in section 3.1 of the paper ( http://shill.seas.harvard.edu/shill-osdi-2014.pdf). Cheers, Scott On Tue, Aug 18, 2015 at 12:48 AM, Sean Lynch se...@literati.org wrote: Hi, folks. I'd like to implement an LPMUD-like multi-user programmable environment in Racket. The idea is that an object would be a module plus some state, similar to a gen_server in Erlang. Objects would each live in their own sandbox and communicate with one another via message passing, probably via channels. So far so good; despite my inexperience with Racket, I am fairly certain this should be straightforward to implement. And a sandbox per persistent object and message passing between them doesn't seem like it would be too high a price to pay, since this is what Erlang does, and it's similar to what LPMUD and MOO and Genesis do. However, users nee to be able to extend and reuse one another's code, and I'd like them to be able to do that without having to trust the code not to leak private state or affect their own code's behavior in unexpected ways. It seems like I can use contracts to some extent to help users from accidentally passing or returning excessively powerful capabilities (however I implement those: proxies, closures, etc); But at the very least I know that any function called in a required module can inspect and modify the current namespace, which will affect dynamic code even if it doesn't affect module code. And I imagine there are probably other introspection functions that could enable access at least to any state stored in top-level variables. So my question is: assuming it is even practical to protect state from code in required modules running in the same sandbox, what would be the best way to go about this? Or are sandboxes and channels (or some other way to pass messages between sandboxes) cheap enough that that's the best way? -- 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 https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optoutd=BQMFaQc=WO-RGvefibhHBZq3fL85hQr=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iMm=vNTo0BhTaa0rf5fiErRpax-tpq3uFcfyQMrQ0pZ_dccs=xIiHlc9nqPBTsx6n-KUJPsWMGd6iTGjpZyp6arDHCJoe= . -- 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.
[racket-users] Racket Language Track for Exercism
Hi all - I'm adding Racket to exercism.io: http://exercism.io Basically, Exercism is an app where users submit solutions to problems, and receive feedback for said solutions. Exercism currently supports 26 languages, with a minimum of 10 exercises for each language. Most, if not all, languages provide more than 10 problem sets. For Racket, I've set it so that each exercise provides a stub file along with the required test file. There's also an example file, which isn't provided to the user. The example files are viewable through the public repo, however. I want to make sure that Racket is properly represented in Exercism - I don't want users to see poor code in the examples and test files. With that in mind, I'm asking anyone willing to please fork the repo and submit improvements to the existing exercises: https://github.com/exercism/xracket You're also welcome to contribute new exercises; here's the list of exercise ideas: https://github.com/exercism/x-common Feel free to add unlisted exercises, as well. Also on the lookout for nitpickers to provide feedback for user submissions, and track implementors to help mentor the language track: https://github.com/exercism/xracket/issues/1 Cheers, Floyd -- 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.
Re: [racket-users] Capability security in Racket?
Thanks for the pointer, Scott! I had been slowly coming to the conclusion I was going to need to define a #lang, and I'd even run across your paper, though I was holding out hope that there was some kind of shortcut for code running in a sandbox. I definitely like the idea of being able to use regular objects, and locking things down with a custom language means I'm also less likely to get bitten by future changes to Racket the way changes to Python made rexec stop working. I think I may still want to stick with having classes be modules, because that makes code replacement much easier to reason about. But if I can force everything that can be referenced from a module variable to be immutable and disallow anything that could modify the namespace after loading the module, it seems like I should be able to share a single namespace among all instances of a given class. Time for me to go code up a proof-of-concept. On Wed, Aug 19, 2015 at 10:05 AM Scott Moore sdmo...@fas.harvard.edu wrote: Hi Sean, An alternative approach you might consider instead of relying heavily on sandboxes and namespaces is to define your own #lang where you can carefully control how different objects are allowed to communicate with each other. This approach could have two advantages: 1) you can use lighter-weight mechanisms to represent objects, and 2) you can restrict things to make it much less likely that you would get bitten by a misunderstanding how namespaces and require, etc, work. We used a similar approach when writing Shill, our capability-based shell scripting language based on Racket (shill-lang.org). You can find a short description of how we did this in section 3.1 of the paper ( http://shill.seas.harvard.edu/shill-osdi-2014.pdf). Cheers, Scott On Tue, Aug 18, 2015 at 12:48 AM, Sean Lynch se...@literati.org wrote: Hi, folks. I'd like to implement an LPMUD-like multi-user programmable environment in Racket. The idea is that an object would be a module plus some state, similar to a gen_server in Erlang. Objects would each live in their own sandbox and communicate with one another via message passing, probably via channels. So far so good; despite my inexperience with Racket, I am fairly certain this should be straightforward to implement. And a sandbox per persistent object and message passing between them doesn't seem like it would be too high a price to pay, since this is what Erlang does, and it's similar to what LPMUD and MOO and Genesis do. However, users nee to be able to extend and reuse one another's code, and I'd like them to be able to do that without having to trust the code not to leak private state or affect their own code's behavior in unexpected ways. It seems like I can use contracts to some extent to help users from accidentally passing or returning excessively powerful capabilities (however I implement those: proxies, closures, etc); But at the very least I know that any function called in a required module can inspect and modify the current namespace, which will affect dynamic code even if it doesn't affect module code. And I imagine there are probably other introspection functions that could enable access at least to any state stored in top-level variables. So my question is: assuming it is even practical to protect state from code in required modules running in the same sandbox, what would be the best way to go about this? Or are sandboxes and channels (or some other way to pass messages between sandboxes) cheap enough that that's the best way? -- 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 https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optoutd=BQMFaQc=WO-RGvefibhHBZq3fL85hQr=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iMm=vNTo0BhTaa0rf5fiErRpax-tpq3uFcfyQMrQ0pZ_dccs=xIiHlc9nqPBTsx6n-KUJPsWMGd6iTGjpZyp6arDHCJoe= . -- 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.
[racket-users] Re: Garbage Collection of Places
On 08/18/2015 08:24 PM, Matthew Flatt wrote: At Mon, 17 Aug 2015 12:21:41 -0700 (PDT), Jack Firth wrote: On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote: That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. Would it be worthwhile to hook up a tool like Valgrind for catching these sorts of VM memory bugs to the Travis CI builds and tests of Racket? (Or is there already some such process in the builds, in which case why didn't it catch this?) From my limited experience with C, I've learned it's pretty much impossible to expect any sane human to keep track of memory perfectly. The last time I tried Valgrind was in March. I got it to work with some small adjustments to Racket: http://lists.racket-lang.org/users/archive/2015-March/066287.html I'm sure more could be done with Valgrind. Catching a bug like the one with place channels in an automated way would be difficult; it would be a matter of calling the right function enough to distinguish it from once-per-process allocations that are intended to be cleaned up implicitly by the process exiting. Although the runtime system has a lot of C code, memory leaks are relatively rare because most allocation is through the GC --- even for internal data structures. In other words, I mostly work in garbage-collected dialect of C. Take a look to -fsanitize in the latest versions of gcc and clang. It includes a lot of options and could find some bugs in the code. -- 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.
Re: [racket-users] Capability security in Racket?
This idea in general is very cool, so do let us (or at least me) know when you've got a prototype working. I'm quite curious to see the inner workings. -- 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.
