Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian

[Doug Williams]

I have some scripts that still use planet. I use development links as
a substitute for a local PLaneT-like capability and have scripts to do
this for me. Some of these are on production servers. I would create
an alias for it anyway, but would rather it stayed as is.

Doug

On Sun, Jul 29, 2012 at 2:48 PM, Jay McCarthy  wrote:
> The Racket core distribution has already started deprecating the
> 'planet' command in favour of going through the 'raco' command and the
> 'planet' subcommand:
>
> raco planet ...
>
> rather than
>
> planet ...
>
> The current documentation does not refer to the 'planet' command at all.
>
> If users are still using it, then an alias would be sufficient, since
> it is unlikely that programs (certainly none in the Racket
> distribution) call 'planet' directly.
>
> Jay
>
> On Sun, Jul 29, 2012 at 1:46 PM, David Bremner  wrote:
>>
>> Hi All;
>>
>> We're currently trying to figure out the right way to handle a name
>> conflict in Debian between racket and an rss aggregator named
>> planet-venus.
>>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685
>>
>> I don't use the command /usr/bin/planet myself, so I was wondering if
>> anybody could explain the likely disruption caused by (hypothetically)
>> renaming it. In particular is it likely to be somether where people are
>> using it from scripts or cron jobs, or would making a shell alias
>> (alias planet planet-racket) suffice to avoid retraining fingers?
>>
>> Thanks
>>
>> David
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>
>
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] potentially renaming /usr/bin/planet to /usr/bin/planet-racket in Debian

[Matthias Felleisen]

It will stay 'as is' for this release. But we intend to deprecate 'planet' so 
that people begin to switch to 'raco planet'. -- Matthias



On Jul 30, 2012, at 9:43 AM, Doug Williams wrote:

> I have some scripts that still use planet. I use development links as
> a substitute for a local PLaneT-like capability and have scripts to do
> this for me. Some of these are on production servers. I would create
> an alias for it anyway, but would rather it stayed as is.
> 
> Doug
> 
> On Sun, Jul 29, 2012 at 2:48 PM, Jay McCarthy  wrote:
>> The Racket core distribution has already started deprecating the
>> 'planet' command in favour of going through the 'raco' command and the
>> 'planet' subcommand:
>> 
>> raco planet ...
>> 
>> rather than
>> 
>> planet ...
>> 
>> The current documentation does not refer to the 'planet' command at all.
>> 
>> If users are still using it, then an alias would be sufficient, since
>> it is unlikely that programs (certainly none in the Racket
>> distribution) call 'planet' directly.
>> 
>> Jay
>> 
>> On Sun, Jul 29, 2012 at 1:46 PM, David Bremner  wrote:
>>> 
>>> Hi All;
>>> 
>>> We're currently trying to figure out the right way to handle a name
>>> conflict in Debian between racket and an rss aggregator named
>>> planet-venus.
>>> 
>>>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680685
>>> 
>>> I don't use the command /usr/bin/planet myself, so I was wondering if
>>> anybody could explain the likely disruption caused by (hypothetically)
>>> renaming it. In particular is it likely to be somether where people are
>>> using it from scripts or cron jobs, or would making a shell alias
>>> (alias planet planet-racket) suffice to avoid retraining fingers?
>>> 
>>> Thanks
>>> 
>>> David
>>> 
>>> _
>>>  Racket Developers list:
>>>  http://lists.racket-lang.org/dev
>> 
>> 
>> 
>> --
>> Jay McCarthy 
>> Assistant Professor / Brigham Young University
>> http://faculty.cs.byu.edu/~jay
>> 
>> "The glory of God is Intelligence" - D&C 93
>> _
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] seeing segfaults on build on 64-bit ubuntu

[Matthew Flatt]

Thanks! Inspired by this information, I've managed to produce a
consistent crash on my machine by attempting to render the "plot"
documentation concurrently in three places.

My guess is that it's a thread-safety problem in Cairo. That is, Cairo
is supposed to be thread-safe, but maybe we're tripping over some
synchronization bug in Cairo.

I changed the `racket/draw' Cairo binding to force all uses of Cairo
through Racket's initial place, and then rendering consistently
succeeds on my machine. This change reduces the potential for
parallelism when using `racket/draw', and also slows drawing in any
place other than the initial place (so that the "plot" document, for
example, takes 77 seconds instead of 42 seconds to render). But if the
change solves the problem, then I don't see a good alternative. Also,
`racket/draw' already synchronizes all calls into Pango (which handles
font and glyph operations for `racket/draw' and does not claim to be
thread-safe).

I've pushed the change to the git repo's master branch. Please let me
know whether a build on your machine works with this change.

At Sun, 29 Jul 2012 12:40:07 -0400, Danny Yoo wrote:
> I tried building from scratch again from
> c9d0319a11cb2aae6d1e81d0c6465b4241a4ecff  and see the following:
> 
> 
> raco setup: 1 running: plot/scribblings/plot.scrbl
> raco setup: 2 running: preprocessor/scribblings/preprocessor.scrbl
> raco setup: 2 running: scribblings/quick/quick.scrbl
> raco setup: 2 running: r5rs/r5rs.scrbl
> raco setup: 2 running: r6rs/scribblings/r6rs.scrbl
> *** glibc detected *** racket/racket3m: double free or corruption
> (!prev): 0x2afccc1395e0 ***
> *** glibc detected *** racket/racket3m: double free or corruption
> (!prev): 0x2afccc1395e0 ***
> === Backtrace: =
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x7e626)[0x2afca64ad626]
> /usr/lib/x86_64-linux-gnu/libpixman-1.so.0(pixman_image_unref+0x17)[0x2afce1314a
> 97]
> /usr/lib/x86_64-linux-gnu/libcairo.so.2(+0x21fd1)/usr/lib/x86_64-linux-gnu/libca
> iro.so.2(+0x293cc/usr/lib/x86_64-linux-gnu/libcairo.so.2(cairo_stroke_preserve+0
> x20)[0x2afce102e250]
> /usr/lib/x86_64-linux-gnu/libcairo.so.2(cairo_stroke+0x9)[0x2afce102e269]
> racket/racket3m(/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x1e5)[0x2afca600
> f435]
> racket/racket3m(scheme_do_eval+0x295)[0x454bd5]
> racket/racket3m(ffi_do_call+0x70b)[0x6485eb]
> racket/racket3m(scheme_do_eval+0x295)[0xAborted (core dumped)
> make[1]: *** [install-3m] Error 134
> make[1]: Leaving directory `/home/dyoo/local/racket/src/build'
> make: *** [install] Error 2
> 
> 
> 
> dyoo@grom:~/local/racket/src/build$ gdb racket/racket3m core
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> ...
> Reading symbols from /home/dyoo/local/racket/src/build/racket/racket3m...done.
> 
> warning: core file may not match specified executable file.
> [New LWP 8450]
> [New LWP 6091]
> [New LWP 6090]
> [New LWP 8455]
> [New LWP 6092]
> [New LWP 8454]
> [New LWP 8448]
> [New LWP 8453]
> [New LWP 8449]
> [New LWP 8451]
> [New LWP 8452]
> 
> warning: Can't read pathname for load map: Input/output error.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `racket/racket3m -X
> /home/dyoo/local/racket/collects -N raco setup -l- setup --n'.
> Program terminated with signal 6, Aborted.
> #0  0x2afca6465445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) where
> #0  0x2afca6465445 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1  0x2afca6468bab in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2  0x2afca64a2e2e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #3  0x2afca64ad626 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #4  0x2afce1314a97 in pixman_image_unref ()
>from /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
> #5  0x2afce103c965 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #6  0x2afce103e3cc in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #7  0x2afce103f6eb in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #8  0x2afce103fe8b in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #9  0x2afce105d642 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #10 0x2afce1036fd1 in ?? () from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #11 0x2afce102e250 in cairo_stroke_preserve ()
>from /usr/lib/x86_64-linux-gnu/libcairo.so.2
> #12 0x2afce102e269 in cairo_stroke ()
>from /usr/lib/x86_64

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Matthew Flatt]

At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote:
> How about having a `compatibility' collect, which would include this and
> things like `racket/package' (compatibility with Chez) and `racket/mpair'
> (compatibility with Scheme)? It would be harder to confuse these things
> with blessed Racket features.

Sorry that I'm so late to this thread.

I think a "compatibility" collection is a good idea, and it's a fine
place for `defmacro'. I don't think `racket/...' libraries should move
there, though.

When the next big language shift comes, we should leave out some
libraries that are now in "racket", and then it may make sense to add
some left-out ones to "compatibility". As long as they stick around in
"racket" though (for compatibility!), I think there's little advantage
in adding them to "compatibility". 

FWIW, the `package' form wasn't even intended for compatibility. It was
intended to support namespace management --- possibly as an expansion
target for macros --- and to work in contexts other than module top
levels. It hasn't turned out to be useful, though.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Vincent St-Amour]

At Mon, 30 Jul 2012 13:10:28 -0600,
Matthew Flatt wrote:
> 
> At Fri, 20 Jul 2012 16:33:54 -0400, Vincent St-Amour wrote:
> > How about having a `compatibility' collect, which would include this and
> > things like `racket/package' (compatibility with Chez) and `racket/mpair'
> > (compatibility with Scheme)? It would be harder to confuse these things
> > with blessed Racket features.
> 
> Sorry that I'm so late to this thread.
> 
> I think a "compatibility" collection is a good idea, and it's a fine
> place for `defmacro'. I don't think `racket/...' libraries should move
> there, though.
> 
> When the next big language shift comes, we should leave out some
> libraries that are now in "racket", and then it may make sense to add
> some left-out ones to "compatibility". As long as they stick around in
> "racket" though (for compatibility!), I think there's little advantage
> in adding them to "compatibility". 

The main advantage (IMO) of having, say, mutable lists in
`compatibility' is that searching the docs points there instead of to
`racket'. This makes it clear that they are not a blessed Racket
feature. This is (IMO) the main point of the `compatibility' collect.

> FWIW, the `package' form wasn't even intended for compatibility. It was
> intended to support namespace management --- possibly as an expansion
> target for macros --- and to work in contexts other than module top
> levels. It hasn't turned out to be useful, though.

Now that we have submodules, are packages still useful? If not, we
should encourage the use of submodules over packages, and putting
packages in `compatibility' makes it clear that they are not the
preferred option.

Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Matthias Felleisen]

On Jul 30, 2012, at 3:52 PM, Vincent St-Amour wrote:

> The main advantage (IMO) of having, say, mutable lists in
> `compatibility' is that searching the docs points there instead of to
> `racket'. This makes it clear that they are not a blessed Racket
> feature. This is (IMO) the main point of the `compatibility' collect.


I fully and enthusiastically agree with this perspective but I don't think this 
is high on our list of things to do. 

When we consider such moves, we should always consider the opportunity cost. 
What could I accomplish instead? 

Having said that, I would like to propose that we COPY files/subcollections 
from racket/ to compatibility/ (and keep them in sync) if we wish to indicate 
that they are not really rackety. 

-- Matthias


_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Matthew Flatt]

At Mon, 30 Jul 2012 15:52:52 -0400, Vincent St-Amour wrote:
> The main advantage (IMO) of having, say, mutable lists in
> `compatibility' is that searching the docs points there instead of to
> `racket'. This makes it clear that they are not a blessed Racket
> feature. This is (IMO) the main point of the `compatibility' collect.

I agree that "compatibility" lets us add features that we don't really
like, but trying to shift existing bad ideas into "compatibility" seems
like a big detour (i.e., I'm agreeing with Matthias).


> Now that we have submodules, are packages still useful?

Submodules do not subsume packages; for example, `package' works in
definition contexts other than top-level modules. Whether packages are
still useful is maybe a moot point, since they don't seem to have been
ever useful. They were developed as an expansion target for an
implementation of ML, but even that implementation didn't use them in
the end.


At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote:
> I fully and enthusiastically agree with this perspective but I don't think 
> this 
> is high on our list of things to do. 
> 
> When we consider such moves, we should always consider the opportunity cost. 
> What could I accomplish instead? 
> 
> Having said that, I would like to propose that we COPY files/subcollections 
> from racket/ to compatibility/ (and keep them in sync) if we wish to indicate 
> that they are not really rackety. 

That's committed already, so I'm suggesting that we do more work to
un-commit the change. It's the spirit of avoiding more of the
kind of work that you suggest we avoid, though.

If we really want to have two names for these things --- the
compatibility name and the "compatibility" name --- then I think we
should at least consolidate to a single compatibility manual by moving
the documentation for `racket/mpair' and `racket/package' to the
compatibility manual.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] DrDr - previous/next change buttons

[Jay McCarthy]

DrDr now has green buttons to go between times the file's output has
changed. Hopefully this will help you find problematic commits easier.

Jay

-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Vincent St-Amour]

At Mon, 30 Jul 2012 16:00:12 -0400,
Matthias Felleisen wrote:
> Having said that, I would like to propose that we COPY
> files/subcollections from racket/ to compatibility/ (and keep them in
> sync) if we wish to indicate that they are not really rackety.

Assuming you mean keeping the same interface re-providing bindings from
one to the other, as opposed to duplicating the implementation, then
that's what I did.

Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] `compatibility' (was: [plt] Push #25038: master branch updated)

[Vincent St-Amour]

At Mon, 30 Jul 2012 14:52:06 -0600,
Matthew Flatt wrote:
> At Mon, 30 Jul 2012 16:00:12 -0400, Matthias Felleisen wrote:
> > I fully and enthusiastically agree with this perspective but I don't think 
> > this 
> > is high on our list of things to do. 
> > 
> > When we consider such moves, we should always consider the opportunity 
> > cost. 
> > What could I accomplish instead? 
> > 
> > Having said that, I would like to propose that we COPY files/subcollections 
> > from racket/ to compatibility/ (and keep them in sync) if we wish to 
> > indicate 
> > that they are not really rackety. 
> 
> That's committed already, so I'm suggesting that we do more work to
> un-commit the change. It's the spirit of avoiding more of the
> kind of work that you suggest we avoid, though.
> 
> If we really want to have two names for these things --- the
> compatibility name and the "compatibility" name --- then I think we
> should at least consolidate to a single compatibility manual by moving
> the documentation for `racket/mpair' and `racket/package' to the
> compatibility manual.

To make sure I understand correctly, you're suggesting that:

- We keep the `compatibility' collect.
- We keep `compatibility/defmacro'.
- We remove `compatibility/mpair' and `compatibility/package', and move
  them back to `racket/mpair' and `racket/package', respectively.
- We leave the reference and the compatibility manual as is, with docs
  for `racket/mpair' and `racket/package' in the compatibility manual.

If that's what you're suggesting, I'll implement it.

Vincent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] DrDr - previous/next change buttons

[John Clements]

On Jul 30, 2012, at 5:42 PM, Jay McCarthy wrote:

> DrDr now has green buttons to go between times the file's output has
> changed. Hopefully this will help you find problematic commits easier.

Here's what I think is a super-minor request. When I view the diff of two DrDr 
outputs; say:

http://drdr.racket-lang.org/diff/25068/25067/collects/tests/stepper/automatic-tests.rkt

I see the new one on the left, and the old one on the right, which is a bit 
confusing to me. Perhaps what I'm really asking is that the link on the page

http://drdr.racket-lang.org/25068/collects/tests/stepper/automatic-tests.rkt

link to

http://drdr.racket-lang.org/diff/25067/25068/collects/tests/stepper/automatic-tests.rkt

instead (that is, with the old one appearing first in the URL).

John


> 
> Jay
> 
> -- 
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
> 
> "The glory of God is Intelligence" - D&C 93
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/dev



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] Racket 5.2 on OpenBSD and --enable-backtrace

[Juan Francisco Cantero Hurtado]

Hi. I've a question about --enable-backtrace in the configure step. Is
it useful for the users or only is useful for the racket developers?.
This option affect to the performance of racket?.

I'm not a scheme/racket developer. I'm just the racket maintainer on
OpenBSD [1]. I'm using this configure options:

--enable-shared
--enable-libffi
--enable-gracket
--enable-jit
--enable-foreign
--enable-places
--disable-futures
--enable-float
--enable-docs
--enable-backtrace
--enable-pthread


1. 
https://github.com/juanfra684/openbsd-wip/blob/racket/lang/racket/Makefile


_
 Racket Developers list:
 http://lists.racket-lang.org/dev