Re: [racket-dev] [plt] Push #21156: master branch updated

2010-09-28 Thread John Clements

On Sep 28, 2010, at 10:09 AM, Eli Barzilay wrote:

> An hour ago, John Clements wrote:
>> 
>> On Sep 28, 2010, at 8:23 AM, Eli Barzilay wrote:
>> 
>>> Can we please not have this??  The whole point of having uniform names
>>> is that you can use require/provide things easily so there's no need
>>> for a library.
>> 
>> Sure, I don't feel strongly about it.  Done.
> 
> Thanks(!)
> 
> I should have clarified further -- what we have at the momemt is a
> consisten use of an "unsafe" part in the path for potentially
> segfaulting functionality.  So having some unsafe/safe thing doesn't
> make much sense (and begs the question about undebugging some things
> with unsafe/safe/unsafe).
> 
> In any case, I think that something that would have made you happier
> is for the `unsafe/foo' libraries to provide the same name as the safe
> ones.  This way you'd only need to toggle the `unsafe/' prefix on or
> off.  (I'd like that change too, but we're probably deep enough in the
> current setup to change that...)

I thought about this, but I really like the current setup, where the 
unsafe-ness must be indicated at the use of the function.  I think this is 
especially true of common primitives like "vector-length".  If I were debugging 
a piece of code, it would never occur to me that an ordinary-looking call to 
'vector-length' might actually be unsafe.

> 
> 
>> To be clear, my use case is this: I'm trying to debug a seg fault in
>> a large library, with >500 uses of 'unsafe-' operators.  I want to
>> see whether using the corresponding safe variants eliminates the
>> crash.  The global search and replace is a bit of a pain; replacing
>> racket/unsafe/ops with racket/unsafe/safe-ops is much easier.
>> 
>> Naturally, though, you can always roll your own as needed.
> 
> First, I think that what was suggested earlier should work -- changing
> this:
> 
>  (require unsafe/foo)
>  ->
>  (require (prefix-in unsafe- foo))

This doesn't work for (require racket/unsafe/ops); that's why I wanted to add 
it.

> 
> But the more common use case (which I've done in a number of places)
> is to use `foo' first, make sure the code runs and write a ton of
> tests, then turn the require into one that *drops* the `unsafe-'
> prefix.

This frightens me, for the reasons I describe above.

> 
> A slightly different approach is in `racket/private/sort' -- define
> names that are used throughout, and switch the definition from a safe
> one to an unsafe one.

That sounds like what you described before, though perhaps I'm not 
understanding you.


John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [plt] Push #21156: master branch updated

2010-09-28 Thread Eli Barzilay
An hour ago, John Clements wrote:
> 
> On Sep 28, 2010, at 8:23 AM, Eli Barzilay wrote:
> 
> > Can we please not have this??  The whole point of having uniform names
> > is that you can use require/provide things easily so there's no need
> > for a library.
> 
> Sure, I don't feel strongly about it.  Done.

Thanks(!)

I should have clarified further -- what we have at the momemt is a
consisten use of an "unsafe" part in the path for potentially
segfaulting functionality.  So having some unsafe/safe thing doesn't
make much sense (and begs the question about undebugging some things
with unsafe/safe/unsafe).

In any case, I think that something that would have made you happier
is for the `unsafe/foo' libraries to provide the same name as the safe
ones.  This way you'd only need to toggle the `unsafe/' prefix on or
off.  (I'd like that change too, but we're probably deep enough in the
current setup to change that...)


> To be clear, my use case is this: I'm trying to debug a seg fault in
> a large library, with >500 uses of 'unsafe-' operators.  I want to
> see whether using the corresponding safe variants eliminates the
> crash.  The global search and replace is a bit of a pain; replacing
> racket/unsafe/ops with racket/unsafe/safe-ops is much easier.
> 
> Naturally, though, you can always roll your own as needed.

First, I think that what was suggested earlier should work -- changing
this:

  (require unsafe/foo)
  ->
  (require (prefix-in unsafe- foo))

But the more common use case (which I've done in a number of places)
is to use `foo' first, make sure the code runs and write a ton of
tests, then turn the require into one that *drops* the `unsafe-'
prefix.

A slightly different approach is in `racket/private/sort' -- define
names that are used throughout, and switch the definition from a safe
one to an unsafe one.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


Re: [racket-dev] [plt] Push #21156: master branch updated

2010-09-28 Thread John Clements

On Sep 28, 2010, at 8:23 AM, Eli Barzilay wrote:

> Can we please not have this??  The whole point of having uniform names
> is that you can use require/provide things easily so there's no need
> for a library.

Sure, I don't feel strongly about it.  Done.

To be clear, my use case is this: I'm trying to debug a seg fault in a large 
library, with >500 uses of 'unsafe-' operators.  I want to see whether using 
the corresponding safe variants eliminates the crash.  The global search and 
replace is a bit of a pain; replacing racket/unsafe/ops with 
racket/unsafe/safe-ops is much easier.

Naturally, though, you can always roll your own as needed.

John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] [plt] Push #21156: master branch updated

2010-09-28 Thread Eli Barzilay
Can we please not have this??  The whole point of having uniform names
is that you can use require/provide things easily so there's no need
for a library.

In addition, the usual way things went so far was to write safe code,
and then "turn on" unsafely by adding requires with dropping the
prefix, or do it locally by adding `unsafe-'.  Now the development
line would be to start safely, then add unsafe, then to debug you add
this other unsafe thing which is really not unsafe.


7 minutes ago, cleme...@racket-lang.org wrote:
> collects/racket/unsafe/safe-ops.rkt
> ~~~
> --- /dev/null
> +++ NEW/collects/racket/unsafe/safe-ops.rkt
> @@ -0,0 +1,25 @@
> +#lang racket
> +
> +(require racket/fixnum
> + racket/flonum)
> +
> +
> +;; the point of this file is to provide functions that are labeled
> +;; as unsafe but are actually safe.  This provides an easy means to
> +;; disable unsafety; a require of racket/unsafe/ops can be replaced
> +;; with a require of racket/unsafe/safe-ops. 
> +
> +;; this list is almost certainly incomplete; I feel partially justified
> +;; in adding it to the tree anyhow because 
> +;; a) it's easy to extend, and
> +;; b) it appears to me (based on the require of #%unsafe in the corresponding
> +;; 'ops' library) that determining the full set of functions will require
> +;; mucking around in the C source, and not being very confident about 
> +;; my conclusions.
> +
> +
> +(provide (prefix-out unsafe- (all-from-out racket/fixnum))
> + (prefix-out unsafe- (all-from-out racket/flonum))
> + (prefix-out unsafe- (combine-out vector-length
> +  vector-ref
> +  vector-set!)))

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev